More r6rs/guile
Felix Thibault
(27 Sep 2020 16:35 UTC)
|
Re: More r6rs/guile
Lassi Kortela
(27 Sep 2020 16:39 UTC)
|
Re: More r6rs/guile
Felix Thibault
(27 Sep 2020 16:53 UTC)
|
Re: More r6rs/guile
Marc Nieper-Wißkirchen
(27 Sep 2020 17:17 UTC)
|
R7RS conformance
Lassi Kortela
(27 Sep 2020 17:53 UTC)
|
Re: R7RS conformance
Marc Nieper-Wißkirchen
(27 Sep 2020 18:12 UTC)
|
Re: R7RS conformance
John Cowan
(27 Sep 2020 18:47 UTC)
|
Re: R7RS conformance
Marc Nieper-Wißkirchen
(27 Sep 2020 19:18 UTC)
|
Re: R7RS conformance
John Cowan
(27 Sep 2020 19:33 UTC)
|
Re: R7RS conformance
Lassi Kortela
(27 Sep 2020 19:47 UTC)
|
Re: R7RS conformance Marc Nieper-Wißkirchen (27 Sep 2020 19:53 UTC)
|
Re: R7RS conformance
Lassi Kortela
(27 Sep 2020 19:54 UTC)
|
Re: More r6rs/guile
John Cowan
(27 Sep 2020 19:32 UTC)
|
Re: More r6rs/guile
Marc Nieper-Wißkirchen
(27 Sep 2020 19:57 UTC)
|
Re: More r6rs/guile
Felix Thibault
(27 Sep 2020 22:30 UTC)
|
Am So., 27. Sept. 2020 um 21:33 Uhr schrieb John Cowan <xxxxxx@ccil.org>: > > That definition only applies to the cond-expand *macro*, not the cond-expand *library declaration*. Macros cannot expand to libraries, so symbolic matching is the correct thing in any define-library form. Note also that the definition of cond-expand given does not correctly interact with (features). I was speaking of the cond-expand *macro*. The definition of cond-expand in 7.3 at least mentions that the N feature identifiers and the M library names have to be added, in principle. > I personally dislike and avoid the cond-expand and include macros and always use the library declarations instead. I do this because I usually work with Chibi, which does not support include in files very well (I am speaking about the search path...). In general, however, I don't see why cond-expand and include shouldn't be used locally. Of course, the syntactic context of included forms has to be fixed. (Prior work says that it should be the one of the include keyword.)