Am Do., 8. Okt. 2020 um 19:56 Uhr schrieb Adam Nelson <xxxxxx@nels.onl>:
>
> I'm not aware of a Scheme that supports expand-time overloading in its
> type system. Expand-time overloading would require a static type system,
> or at least an incremental type system with inference. And implementing
> that kind of inference in macros would require Turing-complete logic in
> macros that, while *technically* possible to implement in portable
> syntax-rules, would be a nightmare to write.

It is less a nightmare to write, I would say, because you have (even
expand-time) compilers from a high-level language to syntax-rules (see
SRFI 148), but the expand-time performance would probably abyssal.

Whether we can do something in this direction will depend on whether
R7RS (large) gets procedural macros or not. My personal opinion on
this is clear (R7RS (small) + R7RS (large) should at least be *able*
to replace R6RS).

Anyway, I am not sure that expand-time overloading is necessarily tied
to a static type system. (And in fact, I am not very much in favor of
a static type system because only with dependent typing you can
express all types.)

As I said, we should do some research first.

For example, one objection against the many exported identifiers of
the form TYPE-OPERATION (like vector-unfold or generator-map) is the
duplication of similar identifiers. It would be enough to have general
"procedures" unfold, map, etc., which takes as their first argument an
expand-time value that selects the type (at expand-time). E.g.

(map :vector PROC ARG)

or

(unfold :generator STOP? ...)

One would implement (given that R7RS (large) becomes at least as
expressive as R6RS) map, unfold, etc. as a macro, which checks whether
the first argument carries a certain SRFI 213 property indicating that
it specifies a type. If this is the case, the correct procedure is
selected at expand-time. Otherwise, the first argument is evaluated.
If it is runtime-type specifier the correct procedure is selected at
runtime. Otherwise, we fall back to the usual behavior of, say, map or
unfold.

Finally, we need identifier syntax so that when the keywords map or
unfold do not appear at head position, they evaluate to a proper
procedure.

Clear?

Marc