Arne,

> I like the SRFI because it can make the checks useful for direct
> in-editor checking

Yes, this is one of the use-cases! I do want Scheme to have more
explanatory power and more useful editing setups, thus all my work on
types.

> I’d suggest:
> [...]

Thank you for this rationale suggestion! I rewrote some parts, but it
will end up in the next draft:

https://github.com/aartaka/srfi-283/commit/75e4bf32c0fc2a9a7477a63809cba8e878de54f4

> An implementation for procedure-check-of using the define-typed
> implementation in Guile would be:
>
> (define (procedure-check-of proc)
>     (let* ((prop (procedure-properties proc))
>            (args (and=> (assoc 'argument-types prop) cdr))
>            (ret (and=> (assoc 'return-type prop) cdr)))
>           (values (if (list? args) args (list args))
>                   (if (list? ret) ret (list ret)))))

Wow! That’s super clean and nice! I want to include it in sample
implementation. Is there some way I can detect if define-typed is loaded
& used for a procedure, besides relying on procedure-properties?

> on second reading: the implementation-specific types sound like a very
> different use-case than the checked types:
>
> The checked arguments enable ensuring guarantees across implementations
> in a single implementation, because the argument checking ontology comes
> from the application code and could be provided as library.
>
> The implementation-specific types enable gathering
> implementation-specific information but require specific code for each
> implementation, because there’s a different argument checking ontology
> for each implementation.
>
> My impression is that to make implementation-specific types more
> practical to use this would need standardized names for at least some
> types to enable code to take advantage of the added information.
> Otherwise I’d have to try my code on different implementations and
> different versions of implementations to build on that information. And
> an update could break my specific code, when the implementation gets
> better at optimizing (it could example detect that it can use a 8 bit
> integer for a number and then the integer? could turn into
> integer-uint8? and my integer-detection code would be broken).

This is a valid concern and an intuitive approach. However, I didn’t
go down that route because standardizing a set of types means getting
back to the standard as a base. Which means: predicate checks. So it’s
an ouroboros situation here: to make types portable, we have to turn
them into checks, but if we turn them into checks, then their
implementation-specific nature is no longer useful.

I under-specified procedure-type-of and type-of on purpose: they have
specific names that an implementation is required to implement, but
don’t add any more burden than that. So we have an escape hatch for
implementation-specific behavior that’s consistent but still…
implementation-specific?

I mean, I might require procedure-type-of to return pairs, this is a
pretty benign and reasonable requirement. But I don’t think going
further than that is productive and useful.

Another addition might be a “type-name” utility that’s there in most
implementations shipping introspectable types. But I think this is
getting into a dangerous feature creep territory.

Thank you for your comments, I really value that 🖤

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