Artyom Bologov <xxxxxx@aartaka.me> writes:

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

>> And I really should create an SRFI for define-typed.
>
> Please do! How much would it differ from SRFI 253?

It is much simpler and keeps all types in the header. It’s basically
just the examples I showed here, optimized to the brink so it matches
the performance of the hand-crafted type boundaries described in
https://dthompson.us/posts/optimizing-guile-scheme.html

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

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.

> 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 – kind of like it would be good to move them to a
separate SRFI (⇒ introspect checked types vs. introspect runtime types?).

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