Hi Artyom,

Artyom Bologov <xxxxxx@aartaka.me> writes:

> I re-read the whole thread and I now see the difference between the
> editor and optimization use-cases you describe. So (bear with me)

(re bear with me) gladly – deeper thoughts is why I discuss here.

> So a seemingly perfect approach would be to simply return a list of
> specialization-ahem-specific checks / types instead of just one total
> specialization, from both procedure-check-of and procedure-type-of.
>
> But that’s a whole new SRFI, with concepts like specialization and
> speculative compilation; with dissection of procedures and them losing
> their atomicity. This is a lot.

Yes, that’s why the current form of procedure-type-of feels off to me:
Beyond the structure "two values, the first is an arbitrary form that
represents the argument types, the second is an arbitrary form that
represents the return value types", it can’t be used outside the
implementation. And even within the implementation it may not be usable,
because the type representations may not even be proper symbols, but
just memory addresses.

There’s also a lot of different ways in implementations to treat named,
optional, and rest arguments. The withdrawn SRFI 177 gives an overview
of keyworad arguments:
https://srfi.schemers.org/srfi-177/srfi-177.html In short:

- #!foo foo:
- #!foo :foo
- :foo :foo
- #:foo #:foo

Besides: thanks to you I now finally got the define-typed SRFI written
out and Arthur published it:
https://srfi.schemers.org/srfi-284/srfi-284.html

There I sidestep this issue by stating:

    The form define-typed* works like the form define-typed, but it
    supports named and optional arguments in the style provided by the
    implementation. The named and keyword arguments are typed in the way
    in which they are defined. Example for Guile:

    (define-typed* (foo x #:key bar) (float? #:key float? -> float?)
      x)

This way I don’t have to define how keywords work, just that they can be
used the way the implementation uses them. And staying on the surface.

> (Even SRFI-279 treats procedures as singular entities—and it’s an
> introspection SRFI. Hmmmm, maybe I should somehow fix that.)

Maybe that would be a good step: provide a comprehensive view of
procedures in Scheme, then build an abstraction that is wide enough to
support all of that but concise enough to be usable.

This is a really wide field …

> I am not sure I want to extend SRFI-283 that much, especially given that
> its conceptual base (SRFI-253) is ignorant of such adult things and
> would need a proper update to accommodate specializations et al.
> Keeping it all consistent and simple seems more important to me than
> making it super universal and covering all the possible use-cases.

I agree with that: SRFI-283 is still about "how can I check what is
passed into procedures" and does not actually have to support all this
implementation complexity. That only arises when you ask implementations
to expose their inner workings.

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