a simple counter-proposal
campbell@xxxxxx
(28 Aug 2004 15:52 UTC)
|
Re: a simple counter-proposal
felix
(30 Aug 2004 19:54 UTC)
|
Re: a simple counter-proposal campbell@xxxxxx (30 Aug 2004 20:21 UTC)
|
Re: a simple counter-proposal
felix
(30 Aug 2004 20:26 UTC)
|
Re: a simple counter-proposal
campbell@xxxxxx
(03 Sep 2004 17:14 UTC)
|
Re: a simple counter-proposal
felix
(06 Sep 2004 19:22 UTC)
|
Re: a simple counter-proposal campbell@xxxxxx 30 Aug 2004 20:32 UTC
On Mon, 30 Aug 2004, felix wrote: > xxxxxx@autodrip.bloodandcoffee.net wrote: > > (program (requires srfi-1)) > > (display (iota 5)) > > > > which retains all existing functionality of SRFI 7 -- the feature > > conditionalization -- and all brevity of SRFI 55's REQUIRE-EXTENSION -- > > it's only a single character longer, in fact --; furthermore, it is > > still compatible with module systems such as that of Scheme48, because > > the module data -- the configuration language -- is _still_ entirely > > disjoint from Scheme, unlike the present SRFI 55's REQUIRE-EXTENSION; > > the configuration language is very clearly separated from Scheme in > > that the PROGRAM form is the first in the file, and every following S- > > expression is Scheme. I propose that SRFI 55 be revised to define this > > amendment/extension to SRFI 7, which I expect will satisfy the demands > > in brevity of Felix as well as retain the functionality of SRFIs 0 & 7, > > and moreover still be as extremely portable as SRFI 7. > > Just one question: what makes > > (program (required srfi-1)) > (display (iota 5)) > > more portable (in the sense of being compatible with S48's module system), > than > > (require-extension (srfi 1)) > (display (iota 55)) > > ??? > > (provided SRFI-55 is changed in such a way that it's recommended > use is as the first expression in a file) Felix, I spent a significant portion of my last paragraph there in answering that question before you even asked it. The PROGRAM form is _not_ in Scheme; it's in an _entirely_disjoint_ configuration language. REQUIRE-EXTENSION as you propose would become a part of the _Scheme_ language; it would essentially extend the <command or definition> nonterminal in R5RS with a new option.