Arne,

>> No, wait the document has this text:
>>
>> “Either of the returned values may be #f in case the implementation cannot provide the checks for arguments and / or returned values.”
>
> I didn’t find that while re-checking – then this fits well together.
> Maybe not only "cannot", but also "if no checks are defined".

Oh, that might be one of the draft 2 revisions I made, sorry.

>>> Maybe an option for that: require that whatever the implementation
>>> returns can be executed as predicate. Then editors using this can be
>>> independent from the implementation as long as they use the return
>>> values as blackbox that they execute in the same REPL they used to run
>>> procedure-type-of.
>>
>> But that’s, like, what procedure-check-of is for?
>
> I thought that procedure-check-of is the definition of the requirement:
> what a variable must conform to for being accepted.
>
> But an argument for a specific procedure could be narrower. The
> procedure might even have multiple pre-compiled instances of itself to
> which it dispatches depending on the type of the argument, so asking
> procedure-type-of could be a way to discover which check predicate could
> enforce efficient use of the procedure.

Hmmmm, that’s problematic. But I am hesitant to go down the road of
accomodating this—too many implementation-specific behaviors emerge if
we abandon the “atomicity” of procedures.

> Example: procedure-type-of returns that the procedure can take values
> that match (and (real? x) (inexact? x))
> That’s basically floating point.
> By now adding (lambda (x) (and (real? x) (inexact? x))) as check for the
> procedure, you could enforce that it is only used with arguments that
> enable optimized operation.
>
> For this is could be useful to provide a list of possible types, from
> the narrowest to the broadest. Basically ask the compiler what types it
> can optimize for.

Not sure I understood this point. So what you’re saying is that types
come in hierarchies and thus procedure-type-of has to return a list of
these for more granular operation? And a list of possible “methods” in
general?

>> It returns the
>> predicates values must conform to. procedure-type-of is for opaque
>> implementation-specific types with quite a restricted set of uses.
>
> Where would you use these then?
>
> If these can’t be used in an editor or to check whether a value would be
> accepted as procedure argument, then these types feel orthogonal to
> procedure-check-of

Uses for raw types, from the top of my head:

• Disassemblers and optimizers. Checks don’t really have the granularity
  needed for e.g. proper optimization.
• Introspection. Checks are too unstructured, being plain
  procedures. While types / classes might be objects with their own
  structure. Going beyond the hierarchy which you suggest to
  special-case here.

Uses for this SRFI in general:

• In-editor suggestions you mentioned
• REPL introspection, quick type lookup
• Auto-generated documentation systems. Like scheme-index, but, like,
  auto-generated

There are more, probably, but I only care about introspection in the
abstract and cannot anticipate all the uses others might find for this
SRFI.

> kind of like it would be good to move them to a
> separate SRFI (⇒ introspect checked types vs. introspect runtime
> types?).

That’s an approach too, but I find checks and types fitting neatly
together. They are literally a mirror image of each other, just from
different perspectives. Either can be inferred from another (though it
probably won’t be useful deriving types from checks, only vice versa.)
So they kind of belong together, for the sake of SRFI completeness.

I realize that this paragraph might be unconvincing, but I’m working off
vibes here. And I feel clumping these together is the right thing.

Thanks,
--
Artyom Bologov
https://aartaka.me