Artyom Bologov <xxxxxx@aartaka.me> writes:

>> 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.

Could an implementer start with

(define procedure-type-of procedure-check-of)
(define type->check identity)

and then incrementally adjust the return values of procedure-type-of,
keeping a map from these values to predicates in type->check ?

That would reduce the required implementation work while opening the
possibility for implementations to provide more detailed information.

>> 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.

It’s definitely a step yes.

Do you have plans for representing named (keyword) arguments, optional
arguments and rest arguments?

Best wishes,
Arne
--
Unpolitisch sein
heißt politisch sein,
ohne es zu merken.
https://www.draketo.de