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)
|
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