Arne,

>>> 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.
>
> The reason I see that is that Javascript does it (excessively). It’s one
> reason why it got so fast (and memory-hungry), even though you can throw
> its functions anything and then they do something.
> Here’s a description of the method:
> https://dl.acm.org/doi/full/10.1145/3798245#sec-2-2

I see. Still, going into that territory means opening a whole new can of
worms. I’m not sure that’d be productive, despite the optimization
opportunities. Have to settle on something first.

> If I could ask sqrt, +, and * which types they accept, I could find the
> most specific type and use it as checked type for the magnitude/typed
> procedure.

Yes, that’s kind of the point. On optimizing and type-aware
implementations, one can use procedure-type-of to get the inferred type
instead of declared one. But that doesn’t have to be specified nor
required. It can simply happen if the implementor wishes to add it.

>> • 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.
>
> The core question for me is here: what do people need as portable
> procedure? Is type-of intended to trigger an implementation specific
> output or is it intended to be a building block for portable tools?

For type-of in particular, the goal is to have at least the name and
return format to converge across implementations. No more. That’s as far
as its portability goes. And I consider it more than enough portability
to warrant an inclusion in SRFI. Yes, the data is ultimately
implementation-specific (albeit portabilizeable with type->check that
will be part of the next draft.) But at least the interface is portable
and predictable.

Best of luck,
--
Artyom Bologov
https://aartaka.me