SRFI 214: Flexvectors Arthur A. Gleckler (07 Oct 2020 17:10 UTC)
Re: SRFI 214: Flexvectors Marc Nieper-Wißkirchen (08 Oct 2020 09:41 UTC)
Re: SRFI 214: Flexvectors Marc Nieper-Wißkirchen (08 Oct 2020 09:59 UTC)
Re: SRFI 214: Flexvectors Adam Nelson (08 Oct 2020 12:10 UTC)
Nomenclature Lassi Kortela (08 Oct 2020 12:19 UTC)
Re: SRFI 214: Flexvectors Marc Nieper-Wißkirchen (08 Oct 2020 12:19 UTC)
Nomenclature Lassi Kortela (08 Oct 2020 12:26 UTC)
Re: Nomenclature Marc Nieper-Wißkirchen (08 Oct 2020 12:31 UTC)
Re: Nomenclature Lassi Kortela (08 Oct 2020 12:50 UTC)
Re: Nomenclature Marc Nieper-Wißkirchen (08 Oct 2020 13:01 UTC)
Flexvectors vs subtyping Per Bothner (08 Oct 2020 17:23 UTC)
Re: Flexvectors vs subtyping Arthur A. Gleckler (08 Oct 2020 17:29 UTC)
Re: Flexvectors vs subtyping Adam Nelson (08 Oct 2020 17:32 UTC)
Re: Flexvectors vs subtyping Marc Nieper-Wißkirchen (08 Oct 2020 17:46 UTC)
Re: Flexvectors vs subtyping Adam Nelson (08 Oct 2020 17:56 UTC)
Re: Flexvectors vs subtyping Marc Nieper-Wißkirchen (08 Oct 2020 19:21 UTC)
Re: Flexvectors vs subtyping Lassi Kortela (08 Oct 2020 20:09 UTC)
Re: Flexvectors vs subtyping Marc Nieper-Wißkirchen (08 Oct 2020 20:51 UTC)
Re: Flexvectors vs subtyping Lassi Kortela (08 Oct 2020 21:23 UTC)
Re: Flexvectors vs subtyping Arvydas Silanskas (12 Oct 2020 09:58 UTC)
Re: Flexvectors vs subtyping Marc Nieper-Wißkirchen (08 Oct 2020 20:35 UTC)
Re: Flexvectors vs subtyping Per Bothner (08 Oct 2020 17:54 UTC)
Re: Flexvectors vs subtyping Lassi Kortela (08 Oct 2020 20:39 UTC)
Re: SRFI 214: Flexvectors Marc Nieper-Wißkirchen (08 Oct 2020 17:32 UTC)
Re: SRFI 214: Flexvectors Adam Nelson (08 Oct 2020 17:35 UTC)
Re: SRFI 214: Flexvectors Marc Nieper-Wißkirchen (08 Oct 2020 18:05 UTC)
Re: SRFI 214: Flexvectors Adam Nelson (08 Oct 2020 18:34 UTC)
Re: SRFI 214: Flexvectors Marc Nieper-Wißkirchen (08 Oct 2020 18:57 UTC)
Flexvector computational complexity Adam Nelson (08 Oct 2020 17:47 UTC)
Re: Flexvector computational complexity Marc Nieper-Wißkirchen (08 Oct 2020 19:04 UTC)
Re: Flexvector computational complexity John Cowan (08 Oct 2020 19:18 UTC)
Re: Flexvector computational complexity Adam Nelson (08 Oct 2020 19:40 UTC)

Re: Flexvectors vs subtyping Marc Nieper-Wißkirchen 08 Oct 2020 19:20 UTC

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