[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Scheme-reports] Reformulated numeric-tower ballot
- To: xacc.ide@x
- Subject: Re: [Scheme-reports] Reformulated numeric-tower ballot
- From: John Cowan <cowan@x>
- Date: Sun, 18 May 2014 04:03:32 -0400
- Cc: scheme-reports <scheme-reports@x>
- In-reply-to: <DA6E01D8073F42F5A440D50EE15B2BA0@SIXFOUR>
- References: <DA6E01D8073F42F5A440D50EE15B2BA0@SIXFOUR>
> What I am trying to say is that there is not much point (at this
> stage) trying to define standard interfaces for libraries that can be
> implemented portably. Users can and will define this.
> It is the ones that cannot be implemented portably that should
> follow a standard interface. Only the implementer can deal with that.
While I have a good deal of sympathy with this point of view, especially
the second half of it, there are both tactical and strategic reasons for
nailing down certain obvious points. Tactically, it's easier to get
agreement on difficult matters like a networking API if you have the
experience of getting agreement on similar matters (where "agreement"
does not always mean full consensus; it may also mean the willingness
of a minority to accept results they voted against).
The strategic benefits can be expressed best through a pair of examples.
Proper tail calling is an obvious implementation strategy: it can't
hurt and it may help, and even C/C++ compilers do it. But Scheme is
different from C in this respect because Scheme *mandates* support for
proper tail calling in all cases. That means that Scheme programmers
can and do rely on it, and that gives their code a different feel from
code that cannot rely it because it is entirely behind the scenes.
By the same token, there isn't any reason why Scheme programmers
shouldn't routinely rely on the SRFI 1 list library. There are two
highly portable implementations, the sample implementation by Shivers
and the Chibi implementation, which is optimized for code size. But a
weakness in pre-R6RS Schemes is that there is no standard way to include
the library with your program (other than raw code concatenation),
and even with the standardization of `import` in R6RS and R7RS-small,
there is no standard name for this particular library.
Nailing down that in R7RS the library is called (scheme list) or (srfi 1)
or (srfi :1) is a worthwhile thing to do, because it means that the
library can be used in applications in a fully portable way. And that's
why I want to decide which portable libraries are to be included: not
to constrain implementers, but to empower users.
> >Perhaps standard interfaces and *behavior* should be defined as
> >Scheme will be stuck in toy land forever...
And that's exactly what it is the purpose of R7RS-large to escape.
As the Pythonistas say, batteries should be included.
John Cowan http://www.ccil.org/~cowan cowan@x
Uneasy lies the head that wears the Editor's hat! --Eddie Foirbeis Climo
Scheme-reports mailing list