Arne,

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)
procedures might have multiple type specializations made by the compiler
(e.g. one for floats, one for ints, one generic) while still being one
procedure. This is not important for the editor, because there only one
set of checks is required—the most generic one. But, for informed
optimization (and, probably, some other uses too,) all these
specializations are needed. One needs to check if their procedure is
compiling to the right specializations.

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.

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

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.

Thanks,
--
Artyom Bologov
https://aartaka.me