Where next?
David Rush
Since Alan Bawden has been so kind as to post all the votes on R6RS
that were submitted (ostensibly so that we can verify their
correctness) in advance of the actual result announcement, we are now
in a position where we can reasonably predict the outcome of the
ratification vote. And Alan, I apologize if this is going to end up
regretting your early posting, but after reading the votes and
counting them I'm pretty sure what the result will be and it is
worrisome.
Not having perfect name recognition, I will acknowledge that I may be
making a mistake here, but it looks like a large majority of
implementors oppose the draft, but a fair-sized majority of users are
in favor of it. Interestingly enough, it looks like there were no
'maybe' votes recorded. I thought that possibility was interesting,
but in the absence of a long discussion on voting theory, I suspect
that a better option would have been to have each voter rank the
standard from zero to ten and require a certain passing grade.
But that's a kind of 'sour grapes' response on my part. And while the
Steering Committee (not the Editorial Comittee) has the power to do
anything they want, at any time, and could take a look at the
situation and the votes (which have a lot more commonality than I
expected), and declare some kind of 'fix-it now' process; I can't even
find their names on the web. And frankly I'm not entirely sure that
would be appropriate, in spite of the comments about late changes to
the draft and the possibility of distortions of the process due to
time pressure.
The real question is this:
Which implementations have concrete plans to support it
(natively)?
I did ask this question a while ago, in a different guise. I've been
told that Andre VanTonder's compatibility package will work on any
R5RS system, but I expect that will not really be satisfactory support
for most of the users who voted 'yes'.
david rush
--
http://cyber-rush.org/drr/scheme <- a very messy construction^Wweb site
dr.tf...@googlemail.com
> implementors oppose the draft, but a fair-sized majority of users are
> in favor of it.
Here's a quick overview of how the implementors of some
implementations voted, as far as I can tell. Please double check this
yourself.
Implementations who had implementors voting Yes: Chez, PLT, Scheme48,
RScheme
Implementations who had implementors voting No: Chicken, Gambit,
Gauche, Larceny, MIT/Gnu Scheme, Scheme48, SCM
Implementation whose implementors abstained: Bigloo, Guile, JScheme,
Kawa, SISC
Summarizing:
Yes: 3
No: 6
Abstained: 6 (including Scheme48, with one implementor voting yes
and another no)
Is the large number of abstentions cause for concern? Do they mean
"I'll accept the result, either way." or "I'll ignore the result,
either way."
> ... Which implementations have concrete plans to support it
> (natively)?
Presumably at least PLT and Chez. Also, if I recall correctly,
Larceny also plans to support R6RS, despite Will Clinger's against
ratification.
It will be interesting to see how many other implementors decide also
to accept the vote, if R6RS is indeed ratified, and support the new
standard. A vote against R6RS doesn't necessarily imply a lack of
willingness to accept the will of the majority.
> I did ask this question a while ago, in a different guise. I've been
> told that Andre VanTonder's compatibility package will work on any
> R5RS system, but I expect that will not really be satisfactory support
> for most of the users who voted 'yes'.
A portable implementation of R6RS in R5RS would be helpful, even if
many optimizations are not possible.
My sincere hope is that R6RS will help to increase the number of
portable Scheme libraries, and the number of Scheme users. Both of
these are more important for *users* than the number of
implementations.
Implementors and users both have legitimate interests in the standard,
no doubt. It is not clear to me how to weigh the votes of these two
groups. Should implementors have a greater say?
-Tom Gordon
samth
The following implementors were on the Editors Committee, and voted
yes:
Mike Sperber (Scheme48)
Kent Dybvig (Chez)
Matthew Flatt (PLT)
Will Clinger (Larceny) has announced plans to support R6RS, although
he voted No.
The following implementors voted No, and therefore seem unlikely to
support R6RS:
Aubrey Jaffer (SCM)
Chris Hanson (MIT Scheme)
Felix Winkelmann (Chicken)
Jeff Siskind (Stalin) [NB Stalin doesn't support R5RS either, to the
best of my knowledge]
Jonathan Rees (Scheme 48)
Marc Feely (Gambit)
Shiro Kawai (Gauche?) voted no, but I'm unsure from his statement
whether R6RS might be supported anyway.
So, that leaves 4 implementations supporting R6RS, 4 supporting R5RS
but not R6RS, one I'm unsure of, and one not supporting R5RS.
Further, several of the No statements indicate that some of these
implementors would not have been happy with any likely result of the
R6RS process.
There are, of course, many more Scheme implementations than this, and
maybe their authors voted as well, but I didn't recognize them.
sam th
William D Clinger
> > ... Which implementations have concrete plans to support it
> > (natively)?
>
> Presumably at least PLT and Chez. Also, if I recall correctly,
> Larceny also plans to support R6RS, despite Will Clinger's against
> ratification.
Larceny's R6RS-conforming mode, if and when we get around
to implementing it at all, will be interpreter-only [1].
We might just wait for the R7RS.
Please note that Larceny's anticipated R6RS-compatible
mode will not be R6RS-conforming [1]. Furthermore some
R6RS features will be deprecated in Larceny, and those
features are unlikely to be implemented efficiently even
in R6RS-compatible mode.
> A portable implementation of R6RS in R5RS would be helpful, even if
> many optimizations are not possible.
A portable implementation of R6RS in R5RS is impossible.
To give just one example, all implementations of the R6RS
must support the set-port-position! operation on binary
ports that were opened using open-file-input-port. There
are many other examples that could be given.
sam th wrote:
> Will Clinger (Larceny) has announced plans to support R6RS, although
> he voted No.
As has been proclaimed on Larceny's web pages [1], Larceny
is and will remain an implementation of the R5RS.
As I have noted previously, the proposed R6RS is at best
a supplement to the R5RS, not a replacement. The R6RS
amounts to an enormous SRFI that introduces an alternative
to the R5RS notion of a program, bundling that notion with
a great many other things that would become available in
R6RS-style programs but are not necessarily available to
R5RS-style programs.
With the apparent ratification of the R6RS, every
implementor of the R5RS must now decide which (if any)
features of the R6RS to support, and how to make those
supported features available. I anticipate a period of
chaos while implementors decide how to make their chosen
features available within their implementations. The
success of the R6RS will depend upon the development of
SRFIs or other standards that reflect agreement on which
R6RS features are worthy of support and describe how the
new features will become available in R5RS-style programs.
In the best of all possible outcomes, the R6RS Steering
Committee will recognize the need for such standards and
will undertake an urgent R7RS project to develop those
standards while undoing some of the damage done by the
R6RS. I do not expect that outcome.
Will
[1] http://larceny.ccs.neu.edu/larceny-trac/wiki/ConformanceModes
dr.tf...@googlemail.com
> Please note that Larceny's anticipated R6RS-compatible
> mode will not be R6RS-conforming [1]. Furthermore some
> R6RS features will be deprecated in Larceny, and those
> features are unlikely to be implemented efficiently even
> in R6RS-compatible mode.
As a user, Larceny's R6RS-compatible mode is more than good enough for
me. And I really appreciate that Will Clinger and his team are making
every effort to support R6RS, despite their reservations, within
whatever limits they deem appropriate. I hope other implementors will
follow his example.
Shouldn't we expect it to be much easier for users to port libraries
between R6RS conforming and such R6RS compatible implementations of
Scheme than it has been possible in the past to port libraries between
the various R5RS implementations, because of the greater dependence on
implementation specific extensions? If so, isn't this progress
towards convergence?
> A portable implementation of R6RS in R5RS is impossible.
Excuse me. I meant including implementation specific extensions, with
some kind of configuration files or conditional compilation. Is this
also impossible?
> The success of the R6RS will depend upon the development of
> SRFIs or other standards that reflect agreement on which
> R6RS features are worthy of support and describe how the
> new features will become available in R5RS-style programs.
Perhaps we have different measures of success. For me, R6RS will have
been successful if it helps to increase the size of the Scheme
community and the number of portable libraries in Scheme. Getting a
larger percentage of the Scheme implementors to agree on some standard
would be nice, of course, but does not seem terribly important, at
least not to me.
-Tom Gordon
William D Clinger
> Shouldn't we expect it to be much easier for users to port libraries
> between R6RS conforming and such R6RS compatible implementations of
> Scheme than it has been possible in the past to port libraries between
> the various R5RS implementations, because of the greater dependence on
> implementation specific extensions? If so, isn't this progress
> towards convergence?
Eventually. In the short term, however, the R6RS draft
that appears to have been ratified leaves us without any
way for portable programs to specify files that contain
libraries whose names are not of the form (rnrs ...).
Programs that attempt to use libraries other than those
specified within the R6RS are therefore not portable.
At the moment, the closest thing we have to a portable
R6RS program is the all-in-one-file format supported by
Andre van Tonder's reference implementation of libraries
and syntax-case. As non-normative appendix E is careful
to point out, however, even the all-in-one-file solution
is not portable.
> > A portable implementation of R6RS in R5RS is impossible.
>
> Excuse me. I meant including implementation specific extensions, with
> some kind of configuration files or conditional compilation. Is this
> also impossible?
It is certainly possible to implement R6RS using
implementation-specific extensions to R5RS, just
as it is possible to implement R6RS from scratch.
> Perhaps we have different measures of success. For me, R6RS will have
> been successful if it helps to increase the size of the Scheme
> community and the number of portable libraries in Scheme.
I agree with that. My fundamental complaint about the
R6RS is that it stopped short of what was needed to do
that, while adding gratuitous barriers to portability,
backwards compatibility, and acceptance. (Those three
are closely related.)
Will
Ray Dillinger
> Implementors and users both have legitimate interests in the standard,
> no doubt. It is not clear to me how to weigh the votes of these two
> groups. Should implementors have a greater say?
I think so. In practical terms, without the support of implementors
the standard does not exist.
Bear
Ray Dillinger
> Hey y'all -
>
> Since Alan Bawden has been so kind as to post all the votes on R6RS
> that were submitted (ostensibly so that we can verify their
> correctness) in advance of the actual result announcement, we are now
> in a position where we can reasonably predict the outcome of the
> ratification vote. And Alan, I apologize if this is going to end up
> regretting your early posting, but after reading the votes and
> counting them I'm pretty sure what the result will be and it is
> worrisome.
>
I think it's more likely to cause a schism or fragmentation of the
community rather than a unification of dialect and advancement of
portability. Honestly, as I consider the future of the scheme
language, I think it would be a disaster to ratify something whose
support is thus divided.
I have implemented a lisp interpreter (Never was conformant enough
to be called "scheme," nor "common lisp" -- it was and is something
different from either, for experimenting only). And as I think of
the data structures and runtime models I evelauted, I see the
requirements in R6RS that will make any conforming implementation
very slow. Raising violation exceptions for conditions that are
very expensive to check, for example, and requiring checks (and
exceptions to be raised) on conditions that won't necessarily
impact a particular run of the program. I think a lot of users
who voted yes don't understand the runtime costs of the exception
system that R6RS specifies.
Bear
Shiro Kawai
> Shiro Kawai (Gauche?) voted no, but I'm unsure from his statement
> whether R6RS might be supported anyway.
>
> So, that leaves 4 implementations supporting R6RS, 4 supporting R5RS
> but not R6RS, one I'm unsure of, and one not supporting R5RS.
Gauche's position is in favor of providing wider compatibility;
e.g. it supports SRFI-29 (localization) even though Gauche has
and recommends to use gettext library (upper-compatible to GNU
gettext), just in case somebody picks up a library that requires
srfi-29. In the same spirit, I'm planning to support R6RS as an
optional feature, just in case if somebody picks up a library
that is written in R6RS.
Like Larceny, however, our effort will be mainly to provide a
'compatible' mode, rather than a 'conforming' mode.
andreu...@yahoo.com
> At the moment, the closest thing we have to a portable
> R6RS program is the all-in-one-file format supported by
> Andre van Tonder's reference implementation of libraries
> and syntax-case.
Lest someone should misinterpret these words by concluding that
that is the only format I support, let me just note that my
implementation also provides separate expansion of libraries
organized each in a separate file, bundles of libraries in the
same file, and files containing toplevel programs on their own.
How close these options are to r6rs-portable, though, I will not
dare to guess.
Cheers
André
Tom Lord
Some of the articulate "yes" sentiments express a realistic
pragmatism. A flawed standard that enables simultaneous
expansion of the use of Scheme and subsequent
correction/refinement is better than no standard at all,
from the perspective of these voters. (See "Exhibit A",
below).
That pragmatism arises at this point in history because
users in industry are demanding high level, dynamic
languages. (See "Exhibit B," below.)
It seems that Scheme is considered potential competition for
languages like Perl and Python, but potential users are
frustrated by the lack of fundamental capalities that are
important for popular tasks: mature DOM models, good Unicode
support, a portable library for processing RFC 822 messages,
portable CGI/FCGI libraries, modules for cryptography, etc.
Users experienced in other languages are accustomed to
languages and libraries growing by "open source"
methodology. For example, the maintainers of core Perl
developed a module system but then actual libraries for DOM,
RFC822, CGI, etc. are largely contributed by programmers who
start them off in some real world project, and then refined
by programmers trying to stretch their use. (See "Exhibit
C," below).
Users with these kinds of pragmatic interests and
expectations have traditionally been flummoxed by the Scheme
community's emphasis on clean language design. If a user
asks "how do I write a portable module?" a Scheme expert
(pre-R6) will say "we haven't really settled on any one way
to do it yet" while, say, a Perl expert will say "here,
these ways seem to work ok". (See "Exhibit D," below).
So, perhaps it is fair to say that, from the perspective of
many potential users, Scheme has been held back in
contemporary applications because "The 'great' is the enemy
of the 'good enough'," in language design. Scheme's
emphasis on greatness has kept a potential larger community
of users "at the gate," affording them no good way to
contribute, and thus no good means to cooperate among
themselves.
In open source techniques, those *other* languages have
found a way to (seemingly) reliably produce the "good
enough" for two reasons:
One open source advanatage of those other languages is
something that Scheme can't enjoy: Most of those languages
are, essentially, single implementation languages. Yes, I
know there are multiple implementations of each of them, but
the definition of each of those languages is based on a
reference implementation -- not an abstract specification.
So what? In an open source world, anyone can submit patches
to change the core language. Core language changes happen
less often, of course, but, fundamentally something like
"Unicode support for Python" happens because a small group
of progammers sit down and work out how to implement
workable Unicode support as a patch to a single reference
interpreter.
Another open source advantage of those other languages is
something that Scheme is only just beginning to catch up
with: open source contribution and development of utility
libraries. For example, Perl currently has pretty easy to
use and convenient support for running programs as CGI or
FCGI scripts. As nearly as I can tell by looking at the
jungle-which-is-CPAN this is because, early on, "several"
alternative CGI/FCGI libraries got created, then some of
these emerged as the most viable, and then community effort
doubled down on those. If Scheme can enjoy similar benefits
of open source library development, it must at least have a
portable and agreed-upon-standard way to write libraries.
Some of the "yes"-voting implementors here (e.g., PLT, Chez)
are, notably, already some of the most squarely successful
implementations in finding real world uses. We can see from
their efforts that the maintainers of these implementations
are very interested in trying to enable, at least, the
development of standard libraries using open source
techniques. (Of course, those implementors aren't alone.
We see similar interest, in a portable R5 setting, in
Snowball and SLIB, and in a single-implementation setting in
Chicken et al.)
I'm also sure that several who voted "no" (and at least one
who voted "yes") can wax eloquent about what's wrong with
the R6 approach and how to fix it. We in this group are, at
least, nervous at the prospect of a lot of code being
written to R6 but then which is hard to port to a
subsequent, better Scheme.
What would be the win/win out of this?
I think it is:
a) Yes, ratify. Let's (as a community) permit the use the
R6 document as nothing more (or less) than a signal to
the world that some of Scheme's major implementors have
agreed to build this thing which, at the very least, will
open the door to open source contribution of portable
modules.
b) Let's take the dissent to the next level, turning the
language specification itself into an open source process
(complete with branches and forks) -- and evolve a less
objectionable standard within the next couple of years.
We have (and could conceivably expand upon) the SRFI
process for this. I doubt that very many R6 contributed
libraries will be *so* R6 specific that it will take much
work to port them to something better.
What we who are dissenting are missing, just now, are
positive counter-proposals. As a group, we must now more
or less match the level effort that went into writing R6.
We can do this, I think -- but our mere intention to do
so is not obviously reason enough to further hold up R6.
-t
Exhibit A:
One of the people who voted yes, Dr. Gordon, wrote:
> [the draft helps to make Scheme] a viable alternative to
> more popular languages such as Java and Python.
He also wrote:
> Scheme standards are living documents.
His comments happen to also strongly reflect many of the
"yes" sentiments I saw go buy on comp.lang.scheme -- so I
think he is not alone.
Exhibit B:
There is huge, pent-up demand among working programmers,
to have and to be able to use high level dynamic languages
in their day to day work. c.f. Perl, Python, Ruby, Lua,
Groovy, and PHP. c.f. the number of efforts to provide
such languages on JVM.
Exhibit C:
Successful modularity plus relevant core capabilities are
all it takes for a popular high level dynamic language to
grow into a hugely used language.
The languages listed in exhibit B get so many design wins
because:
a) their library systems are good enough to create big
archives like CPAN b) they have "enough" support for
Unicode, etc. that they can provide workable DOM
implementations c) their maintainers have put a lot of
effort into porting the languages not just to platforms
(e.g., windows vs. unix) but to specific environments
(e.g., as an apache module)
Exhibit D:
None of those successful languages have communities that
emphasize language design in quite the thing-in-itself way
that Scheme community does. For example, people in the
Scheme world thought it disappointing but fundamentally
reasonable that R5RS would not standardize a module system
because there was no obviously right way to do it -- and
we wouldn't want to get stuck with a broken design. In
contrast, the module system in Perl is very obviously a
result of "piling feature on feature" albeit with a very
careful selection of features.
In other words, in Scheme the rule has long been:
We add features when we are confident that they
contribute to a basis set in which just about any style
of programming can be expressed.
but in those other languages:
We add features when we are confident that they fit in
cleanly and provide functionality that will make our
language much more applicable in contemporary practice.
samth
I fail to see how the steering committee could have done more to
involve implementors:
a total of 8 people have served on the Editors' Committee, of which 7
were implementors,
representing 6 different implementations. Of those, 4 editors
resigned, for various
reasons that we mostly don't know. The resulting committee still has
a majority of
implementors.
Perhaps we should still operate by consensus, but I think the problems
with that were
well-documented.
sam th
Nils M Holm
> Implementors and users both have legitimate interests in the standard,
> no doubt. It is not clear to me how to weigh the votes of these two
> groups. Should implementors have a greater say?
In my experience, there are (at least) two groups of users:
(1) those who think it is fine to create an octopus by attaching
extra legs to a dog;
(2) those who enjoy the beauty and elegance of a language.
The users from group (1) actually do not care whether R6RS is
created by throwing features at R5RS and breaking compatibility
whenever it is "necessary". They want features and they want
them *now*. /If/ the language was a simple and elegant core
language with clean libraries attached, they would not see any
difference to R5.97RS. They simply do not care.
In that sense, yes, I think implementors should have a greater
say, because they care more about the subtle implications.
If R5.97RS should get adopted, the mentality of group (1) is
allowed to replace the guiding principle of the RnRS:
"Programming languages should be designed not by piling feature on top
of feature, but by removing the weaknesses and restrictions that make
additional features appear necessary."
--
Nils M Holm <n m h @ t 3 x . o r g> -- http://t3x.org/nmh/
dr.tf...@googlemail.com
> dr.tfgor...@googlemail.com wrote:
>
> In my experience, there are (at least) two groups of users:
>
> (1) those who think it is fine to create an octopus by attaching
> extra legs to a dog;
> (2) those who enjoy the beauty and elegance of a language.
Very funny. But another way to characterize these two groups would
be:
(1) Users: Those who want to get work done *using* Scheme.
(2) Language Designers and Implementors: Those whose goal in life is
to design and implement the best Scheme possible.
The work of group 2 is done when such a language has been specified.
For this group Scheme is an end in itself.
On the other hand, the work of users is enabled, or at least
facilitated, by Scheme. Their work begins were the work of the
designer and implementors ends.
> The users from group (1) actually do not care whether R6RS is
> created by throwing features at R5RS and breaking compatibility
> whenever it is "necessary". They want features and they want
> them *now*.
Users have a choice of programming languages, and Scheme will be
chosen only if it better meets their requirements than such
alternatives as Java, Python, Common Lisp or even JavaScript. So,
yes, not many are willing to sacrifice features which are widely
available in real, existing alternative languages.
>/If/ the language was a simple and elegant core
> language with clean libraries attached, they would not see any
> difference to R5.97RS. They simply do not care.
True. These are black-box details for implementors. So longs as it
gets the job done, fine.
> In that sense, yes, I think implementors should have a greater
> say, because they care more about the subtle implications.
I'm not sure this conclusion follows from what your argument. Users
and "implementors" have different interests. If implementors have
greater say, then the resulting language may be elegant, but not
necessarily practical. More likely, implementors will never be able
to reach consensus, leaving users waiting indefinitely. But users
won't wait. They'll take their business elsewhere.
> If R5.97RS should get adopted, the mentality of group (1) is
> allowed to replace the guiding principle of the RnRS:
>
> "Programming languages should be designed not by piling feature on top
> of feature, but by removing the weaknesses and restrictions that make
> additional features appear necessary."
I've always thought of this as the *vision* of Scheme ... something to
strive for as Scheme evolves. Not something to wait for before
starting work.
-Tom Gordon
http://www.biep.org
> > of feature, but by removing the weaknesses and restrictions that make
> > additional features appear necessary."
>
> I've always thought of this as the *vision* of Scheme ... something to
> strive for as Scheme evolves. Not something to wait for before
> starting work.
No, the quote describes the intension; Scheme is the extension to the
extent that we know it.
Together they constitute the vision that other languages wittingly or
unwittingly strive for.
Till next week, that is.
Biep.
Nils M Holm
> On 20 Aug., 10:12, Nils M Holm <before-2007-10...@online.de> wrote:
> > dr.tfgor...@googlemail.com wrote:
> > In my experience, there are (at least) two groups of users:
> >
> > (1) those who think it is fine to create an octopus by attaching
> > extra legs to a dog;
> > (2) those who enjoy the beauty and elegance of a language.
>
> Very funny. But another way to characterize these two groups would
> be:
>
> (1) Users: Those who want to get work done *using* Scheme.
> (2) Language Designers and Implementors: Those whose goal in life is
> to design and implement the best Scheme possible.
I did not mean (1)=users and (2)=implementors, but both characteristics
were intended to describe properties of users. If you add implementors,
that would give four groups:
pragmatics designers
users (1) (2)
implementors (3) (4)
I intended to characterize (1) and (2), but not (3) or (4).
> On the other hand, the work of users is enabled, or at least
> facilitated, by Scheme. Their work begins were the work of the
> designer and implementors ends.
Exactly. And this is why they should not be involved in the
design behind the scenes. Language design should be done by
implementors.
Please do not get me wrong on this point: I am not opposed to
adding features to Scheme, I am opposed to the way in which
these features are added in R5.97RS.
To the pragmatist, there would probably be little or no
difference between R5.97RS and the version that I would like
to see in its place. However, the version that I imagine would
contain a small and elegant core that follows the guiding
principles of the RnRS series. I see no contradiction here.
> [...] More likely, implementors will never be able
> to reach consensus, leaving users waiting indefinitely. But users
> won't wait. They'll take their business elsewhere.
This risk exists, sure, but implementors have reached a consensus in
several prior revisions of the Scheme report. And good things come to
those who wait.
> I've always thought of this as the *vision* of Scheme ... something to
> strive for as Scheme evolves. Not something to wait for before
> starting work.
I see it as something that Scheme came *pretty* close to and that
is now about to be thrown overboard -- for absolutely no good reason.
Lynn Winebarger
> dr.tfgor...@googlemail.com wrote:
> > On the other hand, the work of users is enabled, or at least
> > facilitated, by Scheme. Their work begins were the work of the
> > designer and implementors ends.
>
> Exactly. And this is why they should not be involved in the
> design behind the scenes. Language design should be done by
> implementors.
Take a look at the CFP Workshop for Implementors thread at
http://www-swiss.ai.mit.edu/ftpdir/scheme-mail/HTML/rrrs-1996/threads.html.
Lynn
Alexis Hazell
> Very funny. But another way to characterize these two groups would be:
>
> (1) Users: Those who want to get work done *using* Scheme. (2) Language
> Designers and Implementors: Those whose goal in life is to design and
> implement the best Scheme possible.
>
> The work of group 2 is done when such a language has been specified. For
> this group Scheme is an end in itself.
>
> On the other hand, the work of users is enabled, or at least
> facilitated, by Scheme. Their work begins were the work of the designer
> and implementors ends.
As someone new to Scheme and the Scheme community, i've tried to avoid
putting in my 2 cents' worth on this discussion. Unfortunately, i can
restrain myself no longer. :-)
i am a user, not an implementor. Yet i must say that, having followed
these discussions, my sympathies generally lie with the many implementors
who are either uncomfortable with, or opposed to, the proposed R6RS
standard. The reasons for this are:
* Having worked in the IT industry (albeit not at the moment, due to
health reasons), i've had the experience of being told to implement
certain things regardless of the technical obstacles involved or the
potential problems such implementations may create. So i don't like the
idea of doing this to others when the situation is reversed.
* i found the clean minimalism of R5RS to be very attractive. i think
Haskell is, in many ways, a beautiful language; but i feel the Haskell 98
report is quite the thicket compared to R5RS. i would be saddened to see
Scheme move away from the very thing that attracted me to it in the first
place.
* Following on from that, i am concerned about the consequences of the
standard becoming noticeably more complex:
When i first became interested in Scheme, i tried using PLT Scheme, but it
was a bit of a strain on my Linux laptop, which has only 256M of memory
(and no, i can't afford to purchase more memory, let alone a new laptop),
and on which i constantly run Fluxbox, Firefox, KMail and Pidgin. So i
looked around for something lighter, and found Guile: not only does it
have (imho) a very newbie-friendly REPL, and (in the 1.8.x series)
extensive documentation, but i could run it within an existing Screen
session.
i have to wonder, though, whether the increase in complexity in the
proposed R6RS would mean that implementors who don't have sufficiently
large resources behind them would end up having to choose between
allocating their time and energy towards implementing R6RS fully, or
towards things such as newbie-friendly REPLs and good documentation. i
would not like to see my range of choices of Scheme environment reduced by
such a conflict.
If i had to name one thing i would like to see added to R5RS, it would be
some kind of standard package system (e.g. Scheme Now!), which would
provide the foundation for something like Perl's CPAN or Haskell's
Hackage. It would be great to be able to simply install Scheme packages
(e.g. an SMTP API) without having to worry about whether that package is
compatible with my chosen Scheme implementation. And i tend to feel that
people consider the extent of 'libraries' available for a language to be
at least as important as the language itself: CPAN was surely a
significant contributor towards the widespread use of Perl5 (i actually
come from a Perl background myself, and really like the language - i know,
heresy! ;-) ).
i realise this issue has very much been a point of contention; but i raise
it again anyway, as someone who wants to use Scheme for 'real-world'
(which i understand to mean 'non-research-oriented') tasks, and who feels
that Perl5+CPAN has made her life considerably easier. :-)
One final comment. Clearly there are sufficient 'YES' votes to see R6RS
ratified. But given the not-insignificant number of 'NO' votes, and given
that a large percentage - perhaps a majority? - of those who would
actually be /implementing/ R6RS are amongst those 'NO' voters, is it
really a good idea to go ahead with ratification? Aren't 'standards'
supposed to be based on something at least approaching consensus?
Alexis.
dr.tf...@googlemail.com
> One final comment. Clearly there are sufficient 'YES' votes to see R6RS
> ratified. But given the not-insignificant number of 'NO' votes, and given
> that a large percentage - perhaps a majority? - of those who would
> actually be /implementing/ R6RS are amongst those 'NO' voters, is it
> really a good idea to go ahead with ratification? Aren't 'standards'
> supposed to be based on something at least approaching consensus?
In the ratification procedure which was announced before the election
(http://www.r6rs.org/ratification/), it is stated: "If 60% or more of
those who cast votes vote "Yes", then the Steering Committee will
ratify the draft as the official R6RS. If fewer than 60% vote "Yes",
the Steering Committee will decide how to restart the process."
Now perhaps the Steering Committee is entitled to change its mind.
But then how will the majority who voted "yes" feel? As if they had
been robbed.
Moreover, if I recall the procedure for R6RS had been changed from the
prior consensus model to a majority vote model, precisely to make it
easier to get proposed changes passed, despite the lack of consensus.
Presumably those who voted "no" now regret this procedural change.
I understand how you feel, but I don't see a way out of this dilemma.
The Steering Committee is pretty much bound to deliver what they
promised, or risk losing all credibility.
-Tom Gordon
David Rush
> I understand how you feel, but I don't see a way out of this dilemma.
> The Steering Committee is pretty much bound to deliver what they
> promised, or risk losing all credibility.
Well no, actually. They might gain credibility as trustworthy
caretakers in the eyes of those who voted 'No'. There is a core
problem with democracy: it assumes that the majority opinion is wiser
than any given opinion. This is accepted as a religious fact in many
parts of the world, but it is also the situation that gave us the
current Iraq war and Vietnam before it (neatly ducking Godwin's law).
Have you never heard the phrase 'the Tyranny of the Majority'?
Now of course there is a problem with tyrannies as well: they assume
that a singular opinion (or a minority opinion) is wiser than all
others. This is a situation that has given us so many wonderful and
exciting events in history as well - so to summarize the summary:
People are a problem.
My point being, that I vaguely recall the Steering Committee being
composed of some serious heavy-hitters who don't have the time to
actively work on the standard (and it is a *lot* of work). An
intervention in the process, if they had a sound set of technical (or
process) arguments to support their intervention would not necessarily
undermine the process and could enhance it. That's part of why, in the
US, Supreme Court judges are not directly elected and have unlimited
terms of office. The Steering Committee is *outside* the process
precisely so they can intervene in a relatively dispassionate manner
should it become necessary.
And I don't want to get involved in a strict constructionist argument
on c.l.s Constructionist mathematics is confusing enough. :)
david rush
--
http://cyber-rush.org/drr <- a very messy construction^Wweb site
Ray Blaak
> There is a core problem with democracy: it assumes that the majority opinion
> is wiser than any given opinion. This is accepted as a religious fact in
> many parts of the world, but it is also the situation that gave us the
> current Iraq war and Vietnam before it (neatly ducking Godwin's law). Have
> you never heard the phrase 'the Tyranny of the Majority'?
Those are hardly examples of the tyranny of the majority. "Duping the
majority" is closer. "The majority not acting responsibly by kicking out the
overlords" deserves consideration too.
But that's not the point. Consider the alternative to the tyranny of the
majority. Tyranny of the minority?
If the minority's objections are so compelling, then it should not be hard to
convince the majority.
For what it's worth, I would also vote no to R6RS.
--
Cheers, The Rhythm is around me,
The Rhythm has control.
Ray Blaak The Rhythm is inside me,
rAYb...@STRIPCAPStelus.net The Rhythm has my soul.
David Rush
> But that's not the point. Consider the alternative to the tyranny of the
> majority. Tyranny of the minority?
Well I *did* say that - but improperly paraphrased from the estimable
Douglas Adams:
"The major problem - one of the major problems, for there are
several - one of the many major problems with governing people is
that of whom you get to do it; or rather of who manages to get
people to let them do it to them. To summarize: it is a well known
fact, that those people who most want to rule people are, ipso
facto, those least suited to do it. To summarize the summary:
anyone who is capable of getting themselves made President should
on no account be allowed to do the job. To summarize the summary of
the summary: people are a problem."
No process is guaranteed to work (where work is defined as achieving
some kind of desirable end). But to *really* investigate that thought
will take us down a road that ends in gun-control and Godwin's Law.
> If the minority's objections are so compelling, then it should not be hard to
> convince the majority.
Nah. Or rather - it may take far longer than is practical or
desirable. I'm sure we can all pick a couple or three current topics
in politics that should make the case eminently clear. And there are
ample examples in history. Just because the process declares a winner,
that doesn't mean the losers should shut up. And if there is an appeal
system available that doesn't mean it can't or shouldn't be used.
> For what it's worth, I would also vote no to R6RS.
You see, the ultimate deciding factor is the uptake of the standard by
implementors. And there are some very important implementations that
are clearly not fully on board in support of the R5.97RS draft.
If you dissect the voting process, it appears to me to be much easier
to have voted 'yes' than 'no' since you had to give a reason for
objection that would be displayed publicly - in other words you had to
have a publicly defensible reason for object, but you could agree with
little more conviction or knowledge than 'standards are a good thing'.
Additionally, there were an awful lot of 'I almost could vote yes'
comments alongside the no votes, and there were some 'I'd like to vote
no but a standard is better than nothing' votes in the yes camp. There
is also Will Clinger's objection about the timing of the last changes
to the record interface and the lack of time for review before voting
to consider. All in all, I would say that the results were pretty
equivocal, if you look at them in analog (rather than binary), and I
wonder how much more positive the vote might have been (and still
could be) with a little more time given to the process. Mind you, I'm
not sure that my main objections might get cleared up, but I'm not all
that far into the 'no' camp either.
david rush
--
http://cyber-rush.org/drr/scheme <- very messy construction^Wweb site
dr.tf...@googlemail.com
> You see, the ultimate deciding factor is the uptake of the standard by
> implementors. And there are some very important implementations that
> are clearly not fully on board in support of the R5.97RS draft.
That's one view. Another is that take-up by users, especially users
who implement and share libraries, is mcuh more significant. How many
implementations does a successful programming language need? How many
people use any other implmentation of Java than Sun's? How many
implementations of Perl, Python or Ruby were important for their
successful take-up?
One could argue that the large number of (incompatible)
implementations of Scheme is one of Scheme's problems, not one of its
advantages.
If R6RS is ratified and only a few implementations support it, such a
shake-out may be beneficial to the Scheme community as a whole,
helping the community to converge and work together.
If one were cynical, one might speculate that the revised procedure
for drafting and ratifying R6RS Scheme was designed to achieve exactly
this result. (But I'm not so cynical.)
-Tom Gordon
David Rush
> take-up by users, especially users
> who implement and share libraries, is mcuh more significant. How many
> implementations does a successful programming language need? How many
> people use any other implmentation of Java than Sun's? How many
> implementations of Perl, Python or Ruby were important for their
> successful take-up?
>
> One could argue that the large number of (incompatible)
> implementations of Scheme is one of Scheme's problems, not one of its
> advantages.
This is a subject that has arisen *dozens* of times over the last 7
years. If you want a single-implementation with a rich library, use
PLT.
The standard response is: "But that's a single vendor!"
The (standard response)^2 is: "But you said you only need one
vendor..."
> If R6RS is ratified and only a few implementations support it,
It will be something of a failure, returning us to the status quo ante
- although with a little more experience about what works in terms of
Computer Science and Social Engineering.
> shake-out may be beneficial to the Scheme community as a whole,
> helping the community to converge and work together.
It sure hasn't happened yet :)
> If one were cynical, one might speculate that the revised procedure
> for drafting and ratifying R6RS Scheme was designed to achieve exactly
> this result. (But I'm not so cynical.)
Neither am I. Personally, I think that it is a typical committee
result. In a psych course I took oce upon a time, we did a fishbowl
exercise. It was really interesting to watch the fishbowl's group
priority mutate from decision making into extending it's power at the
expense of the stated ideals. This happens *all the time* in group
dynamics and I think it happened here as well. And I even believe that
every step was well intentioned - it certainly was in my classroom
exercise.
And both outcomes were equally distasteful.
david rush
--
http://cyber-rush.org/drr/scheme <- a very messy construction^Wweb site
Brian Harvey
>But that's not the point. Consider the alternative to the tyranny of the
>majority. Tyranny of the minority?
Oh please. You know the answer to that -- the alternative is the protection
of hard-won and carefully selected advances in freedom (no slavery, no
established religion, freedom of speech, etc.) against the passion of the
moment (usually some form of xenophobia).
I'm not sure anything about the present discussion is really analogous, but
the candidate would be the claim that "not by piling feature on top of
feature" is so strongly constitutive of what it means to be Scheme that any
result that undoes that principle is illegitimate no matter how arrived at.
This would be a strong claim; those people who would like R6RS were it not for
one or two details can't make it, I think. The argument is available only to
those who would say that R6RS must have a page count smaller than or equal to
that of R5RS.
Note, I'm not saying that people who dislike details of the draft can't make
arguments against the process. Just that they don't get to include the
phrase "tyranny of the majority" in their argument. They could, for instance,
argue that the process is a highjacking of the Scheme polity by an
essentially opposed force. That's quite a strong claim, too, and probably not
true in the Scheme community, although you could make a better case about
recent US political events.
Summary: Although I don't like R6RS, I think our side should tone down the
rhetoric about the process.
Anton van Straaten
> I'm not sure anything about the present discussion is really analogous, but
> the candidate would be the claim that "not by piling feature on top of
> feature" is so strongly constitutive of what it means to be Scheme that any
> result that undoes that principle is illegitimate no matter how arrived at.
I'd love to see some serious analyses of what people think this
much-quoted phrase is actually supposed to imply, for a language
specification larger than R5RS.
For example, is it "piling feature on top of feature" to define an
exception API in a language that has first-class continuations?
Answering "yes" to such questions implies that very little beyond the
core language can ever be standardized.
Unless you're one of those who believes R4RS or R5RS should be the last
Scheme report (as some do), the implications of the feature-piling
exhortation are not as clear as is often implied. To make a claim of
illegitimacy based on it, something stronger and more precise than
hand-waving would be required. Without that, you may as well be
praising the virtues of "family values".
Anton
Nils M Holm
> For example, is it "piling feature on top of feature" to define an
> exception API in a language that has first-class continuations?
No, but other features added in R5.97RS definitely fall into this
category. I have outlined a few in <f8tdfs$8kp$1...@online.de>.
> Answering "yes" to such questions implies that very little beyond the
> core language can ever be standardized.
Yes, but lots of other features could /easily/ be implemented as
portable, optional, and independent libraries that require no
support at all in the core language. Again, I outlined this in
the message with above ID.
R6RS deliberately includes /all/ the features in the core language,
and makes /no/ attempt to keep the core language and the libraries
separated.
This is indeed what I call "piling feature on top of feature".
Anton van Straaten
> Yes, but lots of other features could /easily/ be implemented as
> portable, optional, and independent libraries that require no
> support at all in the core language. Again, I outlined this in
> the message with above ID.
Reviewing some of those points, you acknowledge the need for core
language support for Unicode, bytevectors (assuming efficiency is
considered important), some list procedures, exceptions and conditions,
command line access and exit values, arithmetic, syntax-case, eval,
mutable pairs, and mutable strings. (You also speculate that hash
tables could be implemented in Scheme, but that's not true if support
for eq? hashtables is provided, i.e. hashtables keyed on object
identity, as in R5.97RS.)
So in this preliminary list, you've already found reasons to put quite a
few things in the core language. If you take the exercise further, you
will encounter many of the same issues that the R6RS editors
encountered, and might even find yourself making some of the same
decisions; or alternatively, having to accept tradeoffs on a range of
issues.
> R6RS deliberately includes /all/ the features in the core language,
> and makes /no/ attempt to keep the core language and the libraries
> separated.
That's an oversimplification, and seems misleading to me.
> This is indeed what I call "piling feature on top of feature".
It doesn't make much sense to make this claim without also examining the
tradeoffs involved in the design decisions. Otherwise, you're saying
that you're willing to accept a completely unspecified set of tradeoffs
in order to maximize the property you're interested in, i.e. avoiding
what you characterize as feature-piling. I predict that in many cases,
your willingness to accept these unknowns would change as you begin
confronting them.
Tom Lord wrote the following in a message on r6rs-discuss:
"Those of us who aren't entirely excited about 5.97 have solid
criticisms all around, in my view, but we now "owe the
community" (so to speak) some work to back up our criticisms
with a pragmatic alternative."
An actual specification is never going to hold up very well against an
unspecified platonic ideal.
Anton
Jeffrey Mark Siskind
exception API in a language that has first-class continuations?
Yes.
Answering "yes" to such questions implies that very little beyond
the
core language can ever be standardized.
No. There are conceptually deep interesting and important things that
can't be
done in the core language which might warrant inclusion in a future
core. But
they are not so common place. One such (that I happen to be familiar
with
because it is my current research focus) is reverse-mode automatic
differentiation. There are others.
To make a claim of illegitimacy based on it, something stronger and
more
precise than hand-waving would be required.
I'll take a first stab. And I only intend this as a first stab. It
still may
be too hand-wavy for your taste. But I think it can be a start:
Does it codify an important contribution to computer science?
In that sense lambda and lexical scoping qualify as legitimate
inclusions
while set-port-position! does not.
The contribution need not be novel. Scheme didn't invent lambda or
lexical
scoping. Church invented lambda and mathematics has used lexical
scoping for
quantifiers and summations long before that. But they are important
for
expressing the deep ideas of computer science.
You may ask, then why does R4RS include things like write? Because it
includes
a somewhat arbitrary small but non-minimal basis inherited mostly from
prior
Lisp dialects that is sufficient for expressing many (but
unfortunately not
all) of the deep ideas of computer science.
You see, some of us see Scheme and RnRS as the Code of Computer
Science. Not
"code" as in "source code" but rather "Code" as in the the
"Maimonidean Code".
(I am viewing the Maimonidean Code as a codification of a body of
knowledge
and a philosophical viewpoint at a particular point in time, not as a
religious document. Just as there are alternate Codes to the
Maimonidean Code
that express different, and often dissenting, viewpoints and opinions,
there
are alternate Codes of Computer Science (like SML) that express
different, and
often dissenting, viewpoints and opinions. Nonetheless, while R6RS is
just a
Code (and just about code) it unfortunately appears to have evoked a
lot of
religious fervor.)
Barak Pearlmutter expressed this sentiment to me a little differently
when we
talked yesterday. He said that the early versions of R^nRS were
interesting
reading because they were manifestos, not standards. R6RS is just a
boring
language manual.
Anyway, we should lighten up this thread by shifting it away from
religion and
toward humor. An earlier thread/post suggesting christening R6RS with
a new
name distinct from Scheme before a pejorative name catches on. Well,
its too
late. The Socialist Committee for Evocative Maligning Euphemisms had
already
convened even prior to that post. To give the community incentive to
ramp up
the frequency of producing new standards and the length of each new
standard, I
will only reveal one new pejorative name upon ratification of each new
integral version of RnRS and only if that new version is four times
longer
than the previous version. Don't worry, the Komitet for Gensyming
Blasphemy
has already stockpiled a sufficient quantity of names to last up until
R^{23}RS. (Hint: one can do quite colorful things with "sch".)
There is also room for innovation in this whole process. One of the
deep
principles of computer science is raising things to the meta level. We
have
standards. But why don't we have meta standards? Introducing:
Title: The Meta Report on Scheme (R^0MRS)
Author: Joe
Ratified: 24 October by 100% of the electorate
Body: For all n>=6, the length of R^nRS must be
at least
four times the length of R^{n-1}RS.
This reaches new heights of brevity, precision, and consensus.
Determining
whether a standard is R^0MRS compliant is decidable. (But the
algorithm must
be implemented by an R6RS program because R6RS itself is written in
unicode).
And it codifies the expressed will and philosophical viewpoint of the
majority
of the R6RS electorate at the current point in time.
Anyway, in a recent post, Pascal Costanza states:
The goals of R6RS are not really clear to me. My impression is that
it
specifies too much for research purposes, but not enough for
industrial
contexts.
That reminds me of an old Yiddish/English joke:
Q: What do you get when you cross a chicken with a rabbit?
A: Nishta hen nishta hare. (A standard expression meaning roughly
"neither
here nor there", i.e. something which fails to meet either
goal.)
I find it somewhat humorous (or perhaps spiritually prophetic) that we
have
two Scheme implementations, one called Rabbit and one called Chicken,
one of
which was minimal and served a research purpose, and one of which is
full
featured and used in industrial contexts.
Pascal Costanza
Here is what I think could serve as an example: R6RS provides a way to
define constant variables. However, this feature is "piled" on top of
the module system - you can only define a variable as a constant by
exporting it from a module. R6RS doesn't provide a way to define
constants for module-internal uses. At the same time, R6RS doesn't
provide a way to export assignable variables. This seems like an
arbitrary coupling of two otherwise separate characteristics.
One way to separate these two characteristics is to make exporting
variables and defining them as constants independent of each other, for
example by providing a 'define-constant form and removing the
requirement from exported variables that they must not be assigned to.
It would then be the programmer's responsibility to decide on a
case-by-case basis which variables to export in what way. (It would also
be the R6RS designers' responsibility to decide for each predefined
variable whether it is constant or not.)
Breaking this case down further: Since R6RS adds identifier macros,
there is actually not even a need for adding constants as a core
feature. Instead, 'define-constant could expand into a 'define-syntax
form, which in turn defines an identifier macro that expands into a call
of a procedure that simply returns the defined value. In other words, it
would be sufficient to provide 'define-constant as a mere library feature.
R6RS seems to give the impression that such an analysis has not been
made for many (most?) of the newly added features - an analysis what the
core features are that are necessary to make a new feature work, and how
the core features could be provided such that the new feature can be
expressed as a mere library.
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
Nils M Holm
> > Yes, but lots of other features could /easily/ be implemented as
> > portable, optional, and independent libraries that require no
> > support at all in the core language. Again, I outlined this in
> > the message with above ID.
>
> Reviewing some of those points, you acknowledge the need for core
> language support for Unicode, bytevectors (assuming efficiency is
> considered important), some list procedures, exceptions and conditions,
> command line access and exit values, arithmetic, syntax-case, eval,
> mutable pairs, and mutable strings. (You also speculate that hash
> tables could be implemented in Scheme, but that's not true if support
> for eq? hashtables is provided, i.e. hashtables keyed on object
> identity, as in R5.97RS.)
>
> So in this preliminary list, you've already found reasons to put quite a
> few things in the core language.
No. As you wrote yourself above, I have found reasons to include
*support* *for* some features in the core langauage. The difference
is that "including a feature" means to include all the infrastructure
and utility procedures in the core (which is what R5.97RS currently
does) while I promote the idea of including the smallest possible
amount of infrastructure that is necessary to build the feature
(such as data types, essential procedures, etc), but *no* utility
procedures. All utility procedure would be built on top of the
support in the core language and placed in optional libraries.
Plus, the core should be as close as possible to R5RS.
> If you take the exercise further, you
> will encounter many of the same issues that the R6RS editors
> encountered, and might even find yourself making some of the same
> decisions; or alternatively, having to accept tradeoffs on a range of
> issues.
I do not think so.
> > R6RS deliberately includes /all/ the features in the core language,
> > and makes /no/ attempt to keep the core language and the libraries
> > separated.
>
> That's an oversimplification, and seems misleading to me.
No, it is not. R6RS defines one big blob of features and says "this
is R6RS, period". There is no visible line between the core language
and the libraries, other than the fact that the document is split in
two parts.
> Tom Lord wrote the following in a message on r6rs-discuss:
>
> "Those of us who aren't entirely excited about 5.97 have solid
> criticisms all around, in my view, but we now "owe the
> community" (so to speak) some work to back up our criticisms
> with a pragmatic alternative."
>
> An actual specification is never going to hold up very well against an
> unspecified platonic ideal.
We have something that comes close the the platomic ideal, and at this
moment it is called Scheme. In the future it may have to be called R5RS
Scheme.
But you -- and Tom Lord -- are right. A specification says more than
any meta discussion.
So, when the inevitable split of the community is final, I would be
glad to offer my help to a group that is willing to work on something
better than R5.97RS.
Harold Ancell
Harvey) wrote:
[ Heated political rhetoric. ]
>I'm not sure anything about the present discussion is really
>analogous, but the candidate would be the claim that "not by
>piling feature on top of feature" is so strongly constitutive of
>what it means to be Scheme that any result that undoes that
>principle is illegitimate no matter how arrived at. This would
>be a strong claim; those people who would like R6RS were it not
>for one or two details can't make it, I think. The argument is
>available only to those who would say that R6RS must have a page
>count smaller than or equal to that of R5RS.
I don't think the requirements for this argument need be that
stringent:
I agree with the committee's approach: new core including module
system plus standard libraries, some of which would conceptually
belong to "the core" even if they're organized as libraries. I
just don't think they executed that vision well.
To address your point:
The new core plus module system should be well below the size of
R5RS, since the module system allows you to remove a bunch of
features to standard libraries, especially ones that don't fall
into the scope of a conceptual core that would include a few
essential libraries.
This even allows adding some new features (such as making
continuations totally first class) while lowering the page count.
It seems to me that some people are only focusing on the very
first part of this deathless prose; let me quote the rest:
... but by removing the weaknesses and restrictions that make
additional features appear necessary. Scheme demonstrates that
a very small number of rules for forming expressions, with no
restrictions on how they are composed, suffice to form a
practical and efficient programming language that is flexible
enough to support most of the major programming paradigms in
use today.
It provides the clues necessary to execute the "no piling on of
features" objective while still allow for new features, and a
refactoring of R5RS into core plus libraries which results in a
smaller core.
If done right, everyone should be happy (enough); the Platonic
Ideal of the core is not merely preserved but improved, those who
want to write new standard format libraries have not just a
module specification in which to do this but examples of good
style to follow from the standard, those who want to "just use
it" have a richer and more standardized base upon which to write
their own stuff.
>Summary: Although I don't like R6RS, I think our side should
>tone down the rhetoric about the process.
Agreed 100%.
To reiterate my recommendation:
One way or another, the community agrees on two unique names for
each fork, R6RS and the continuation of the old style. Each fork
lives or dies on its own merits. We do the unique naming to
avoid confusion over what the unqualified name "Scheme" means.
We already do this to some extent, e.g. the interesting Scheme
systems that never moved past R4RS. But they didn't require a
new name, since they were in the style of "Scheme as we know it";
the break with that is what requires making the fork explicit.
- Harold
dr.tf...@googlemail.com
wrote:
> It provides the clues necessary to execute the "no piling on of
> features" objective while still allow for new features, and a
> refactoring of R5RS into core plus libraries which results in a
> smaller core.
>
> If done right, everyone should be happy (enough); the Platonic
> Ideal of the core is not merely preserved but improved, those who
> want to write new standard format libraries have not just a
> module specification in which to do this but examples of good
> style to follow from the standard, those who want to "just use
> it" have a richer and more standardized base upon which to write
> their own stuff.
This sounds like a great agenda for R7RS Scheme! If you accept that
the R5RS needs refactoring, and that such refactoring can be done in a
subsequent revised report, than I don't see why this shouldn't still
be possible, moving forward from R6RS Scheme.
> One way or another, the community agrees on two unique names for
> each fork, R6RS and the continuation of the old style.
Don't the different version of the Scheme standards already have
perfectly suitable names: R4RS Scheme, R5RS Scheme, etc.?
Scheme implementations have always informed users about which version
of the RxRS reports they implement or support, along with
discrepancies. Aren't there Schemes implementations which still do
not implement R5RS? In the future, some will continue with R5RS and
not implement R6RS. Business as usual. What's the big deal?
> Each fork lives or dies on its own merits. ...
There's been a lot of talk about the importance of implementations on
this group. I submit that it is these implementations which will live
or die on their own merits. (And only secondarily whatever version of
RxRS they implement.) The various RxRS reports, as documents, are
eternal and immortal.
Assuming PLT Scheme implements R6RS, other implementations are going
to have their work cut out in this competitive process. (I haven't
heard anything definite from the PLT team.)
> We already do this to some extent, e.g. the interesting Scheme
> systems that never moved past R4RS. But they didn't require a
> new name, since they were in the style of "Scheme as we know it";
> the break with that is what requires making the fork explicit.
If R6RS is ratified, I continue to hope that the opponents, those who
voted No, will be good sports about this and not initiate efforts to
undermine the new standard for split up the Scheme community. Just
lick your wounds, get over it, and work constructively with the rest
of the community to make the next version of Scheme more to your
liking.
-Tom Gordon
Jens Axel Søgaard
> Here is what I think could serve as an example: R6RS provides a way to
> define constant variables. However, this feature is "piled" on top of
> the module system - you can only define a variable as a constant by
> exporting it from a module. R6RS doesn't provide a way to define
> constants for module-internal uses.
You can define a define-constant with the help of identifier macros.
> At the same time, R6RS doesn't provide a way to export assignable
> variables.
Wouldn't this work?
In module A:
(define aa 'foo)
(define (set-a! val)
(set! aa val)
(define-syntax a
<identifier-macro-that-in-a-set!-context-expands-to-set-a!>))
Export a.
> This seems like an
> arbitrary coupling of two otherwise separate characteristics.
Banning assignments to exported variables is in my book a good thing.
Among other things it enables various optimizations that otherwise
would only be possible in whole-program compilers.
--
Jens Axel Søgaard
Alex Sandro Queiroz e Silva
>
> If R6RS is ratified, I continue to hope that the opponents, those who
> voted No, will be good sports about this and not initiate efforts to
> undermine the new standard for split up the Scheme community. Just
> lick your wounds, get over it, and work constructively with the rest
> of the community to make the next version of Scheme more to your
> liking.
>
The new report does not need any help to not succeed. PLT and Chez are
popular, but they don't account for the majority of Scheme developers.
- alex
David Rush
> > Nils M Holm wrote:
> No. As you wrote yourself above, I have found reasons to include
> *support* *for* some features in the core langauage.
Actually, my current thinking is that even *your* list is too much.
Perhaps just:
* fixnums on Z(2^n)
* fixnums w/carry on Z(2^n)
* flonums
* symbols
* chars (w/some kind of numerical escapes and no non-ascii literals)
* strings (w/some kind of numerical escapes and no non-ascii literals)
* vectors
* records
The usual special forms:
* LAMBDA
* IF
* LETREC
* DEFINE
* CALL/CC
And some form of library construct. R^5.97RS is not too bad on that,
but I do take the point made about version numbering possibly being
out of scope.
Anyway, the above is analogous to the C core. In order to be useful
you still need the standard library which would define ports, &cet.
I am somewhat ambivalent about how to include macros. I tend to share
the view that macros are a last-resort, but they are far too useful to
ignore.
Exceptions are on the bubble for me also, as I have felt the pain of
trying to do exception handling exclusively via CALL/CC. But I also
have reservations about exception-handling in general which it will
not serve my purposes to debate in this thread :)
> No, it is not. R6RS defines one big blob of features and says "this
> is R6RS, period". There is no visible line between the core language
> and the libraries, other than the fact that the document is split in
> two parts.
I have to say that I almost completely agree. The split is very poorly
executed. I think I could have lived with everything else I find
problematic if the split had been done more cleanly.
david rush
--
http://cyber-rush.org/drr/scheme <- a very messy construction^Wweb site
dr.tf...@googlemail.com
wrote:
Sorry, but this is a good example of the kind of destructive criticism
I had in mind.
R6RS, if ratified, will need help to succeed, also from the developers
you mention.
Wasn't my point clear? Why turn it on its head?
-Tom Gordon
Neelakantan Krishnaswami
David Rush <kumo...@gmail.com> wrote:
> The usual special forms:
> * LAMBDA
> * IF
> * LETREC
> * DEFINE
> * CALL/CC
I see you are leaving out the set! special form. I presume you want to
introduce make-box, get-box, and set-box! explicitly in its place?
--
Neel R. Krishnaswami
ne...@cs.cmu.edu
Harold Ancell
>On 23 Aug., 11:36, Harold Ancell <comp.lan...@ancell-ent.com>
>wrote:
>> [ The two full "piling feature on top of feature" sentences
>> provide ] the clues necessary to execute the "no piling on of
>> features" objective while still allow for new features, and a
>> refactoring of R5RS into core plus libraries which results in
>> a smaller core.
>> If done right, everyone should be happy (enough); the Platonic
>> Ideal of the core is not merely preserved but improved, those
>> who want to write new standard format libraries have not just
>> a module specification in which to do this but examples of
>> good style to follow from the standard, those who want to
>> "just use it" have a richer and more standardized base upon
>> which to write their own stuff.
>This sounds like a great agenda for R7RS Scheme!
The key here is "sounds like". In the considered opinions of
myself and others far more qualified to make the judgement, the
break from R5.97RS is too great to allow this.
R5.97RS implements a fundamentally different philosophy of how to
define a language, and you can't merge such divergent philosophies.
Enough of what R5.97RS sets in stone cannot ever be undone in a
later RnRS such that R6RS compliant programs and libraries could
continue to run with major modification. You could, I suppose,
embody the two distinct fork in a new standard, but that would be
silly, it would be two standards masquerading as one.
>If you accept that the R5RS needs refactoring, and that such
>refactoring can be done in a subsequent revised report,
I hope I've made the former crystal clear, and now have made my
disagreement with the latter clear.
>than I don't see why this shouldn't still be possible, moving
>forward from R6RS Scheme.
Since I don't agree with the second part, I don't see any
possibility of moving forward from R6RS for what I want. I will
move forward from R5RS.
>> One way or another, the community agrees on two unique names
>> for each fork, R6RS and the continuation of the old style.
>Don't the different version of the Scheme standards already have
>perfectly suitable names: R4RS Scheme, R5RS Scheme, etc.?
I don't believe so. The philosophy of Scheme from the first
standard to the R5RS is sufficiently changed by R5.97RS that it
really is a different enough thing that it needs a different
enough name.
To quote Jonathan Rees in his voting statement:
A new language definition, composed by a new set of people with
a new technical style, a new poitical process, and a new set of
goals, is a good thing, but it needs a new name. Simply as a
matter of branding I consider it confusing to recycle the
'Revised^N Report on the Algorithmic Language Scheme' title - a
joke that was tired years ago, by the way - for something that
is clearly not in the spirit of previous Scheme reports, much
less the Algol 60 report. Public understanding of the
programming language literature is bad enough - Scheme doesn't
need this additional source of identity crisis.
>Scheme implementations have always informed users about which
>version of the RxRS reports they implement or support, along
>with discrepancies. Aren't there Schemes implementations which
>still do not implement R5RS? In the future, some will continue
>with R5RS and not implement R6RS. Business as usual. What's the
>big deal?
The big deal is that R5.97RS is not a new version but a new
language. Its name can include Scheme, it can claim membership
in the Scheme family, but its spirit as he refers to what I term
philosophy is sufficiently different that it's just not the same
thing. I believe you are not arguing for confusion, but as you
make clear below, the extinguishing of the original branch of
Scheme from which R5.97RS forks off its own thing.
>> Each fork lives or dies on its own merits. ...
>There's been a lot of talk about the importance of
>implementations on this group. I submit that it is these
>implementations which will live or die on their own merits.
>(And only secondarily whatever version of RxRS they implement.)
>The various RxRS reports, as documents, are eternal and
>immortal.
I would prefer for history to make the latter judgement.
>Assuming PLT Scheme implements R6RS, other implementations are
>going to have their work cut out in this competitive process. (I
>haven't heard anything definite from the PLT team.)
Or not. Those of us who will not follow the R5.97RS fork *do*
have a body of work to do, we do have to come up with a next
generation standard and implement it, but I don't think that's
quite what you mean, especially since you are effectively arguing
that our fork should end with R5RS (because a merge back into a
future version is impossible).
>> We already do this to some extent, e.g. the interesting Scheme
>> systems that never moved past R4RS. But they didn't require a
>> new name, since they were in the style of "Scheme as we know
>> it"; the break with that is what requires making the fork
>> explicit.
>If R6RS is ratified, I continue to hope that the opponents,
>those who voted No, will be good sports about this and not
>initiate efforts to undermine the new standard for split up the
>Scheme community. Just lick your wounds, get over it, and work
>constructively with the rest of the community to make the next
>version of Scheme more to your liking.
You are not listening to me, which does not result in a
productive discussion. From the reply I made to you on the same
point in the "Losing the platonic ideal" thread:
>At least those critics who took part in this process,
>especially those who voted, seem to me to now be bound to
>accept the result of the vote.
Hell no. I feel bound to respect the people who voted on the
other side, and accept that they have defined a standard for a
language that I'm entirely willing to have include the name
"Scheme" in it, but the rest does not follow. I certainly do
not feel compelled to follow a standard I deeply dislike, I for
one do not welcome our new R6RS overlords. I will not toil in
R6RS, but in something that retains the "Platonic Ideals" of
Scheme as we know it.
I will repeat for your benefit:
HELL NO.
I don't think I can make it any more clear.
The split already exists, to ignore that---as manifest as it is
in the voters' statements---is to frankly ignore reality.
Deal with it. Lick your own wounds from splintering the
community. Your "side" has decided to fork Scheme. That's OK by
me, I'm quite willing to let you claim membership in the Scheme
family of languages.
What I am NOT willing to do is to let you to claim to be "The One
True Scheme". That, I think, is for history to decide, so I
suggest sufficiently unique names, and I suggest you pick one you
like NOW before a pejorative one gets rooted.
Nor am I willing to follow a direction "I deeply dislike". It
would be nice if you could accept that we have deep divisions,
that they can't be papered over, and to at least accept the
possibility that the forks can never be rejoined in a R7RS or
later standard.
(I will make only one more reply in this general thread, and I
think I'll cast it in the language of religious conflict,
e.g. the Reformation, the Counter-Reformation, and perhaps minor
unpleasant things like the 30 Years War....)
- Harold
Alex Sandro Queiroz e Silva
> On 23 Aug., 14:11, Alex Sandro Queiroz e Silva <asand...@gmail.com>
> wrote:
>> dr.tfgor...@googlemail.com writes:
>>
>> > If R6RS is ratified, I continue to hope that the opponents, those who
>> > voted No, will be good sports about this and not initiate efforts to
>> > undermine the new standard for split up the Scheme community. Just
>> > lick your wounds, get over it, and work constructively with the rest
>> > of the community to make the next version of Scheme more to your
>> > liking.
>>
>> The new report does not need any help to not succeed. PLT and Chez are
>> popular, but they don't account for the majority of Scheme developers.
>>
>> - alex
>
> Sorry, but this is a good example of the kind of destructive criticism
> I had in mind.
>
You don't understand. I'm not just "wishing" this to happen. It is going
to happen.
> R6RS, if ratified, will need help to succeed, also from the developers
> you mention.
> Wasn't my point clear? Why turn it on its head?
>
Yes, it will need help. No, it won't get much. Just because it was
ratified it does not mean everyone will forget everything and rush to adopt it.
-alex
dr.tf...@googlemail.com
wrote:
> Hell no. I feel bound to respect the people who voted on the
> other side, and accept that they have defined a standard for a
> language that I'm entirely willing to have include the name
> "Scheme" in it, but the rest does not follow. I certainly do
> not feel compelled to follow a standard I deeply dislike, I for
> one do not welcome our new R6RS overlords. I will not toil in
> R6RS, but in something that retains the "Platonic Ideals" of
> Scheme as we know it.
>
> I will repeat for your benefit:
>
> HELL NO.
You seem to have very strong feelings about the technical merits of
R6RS. I can see that. Can you point us to your contributions to the
Scheme community, to help us get a better feeling for how much weight
to give your opinion? I wasn't able to find anything on the Web, but
maybe I didn't look hard enough.
I don't have much to say about R6RS's technical merits, being only a
user. I do know a bit more about collaboration and constructive
criticism. But I do not want to bore anyone with that.
Peace,
-Tom Gordon
David Rush
> In article <<1187871413.436436.163...@q3g2000prf.googlegroups.com>>,
>
> David Rush <kumoy...@gmail.com> wrote:
> > The usual special forms:
> > * LAMBDA
> > * IF
> > * LETREC
> > * DEFINE
> > * CALL/CC
>
> I see you are leaving out the set! special form. I presume you want to
> introduce make-box, get-box, and set-box! explicitly in its place?
Well, that's an option. SET! is another slightly muddled construct,
IMHO. Back when I was looking deep into CPS and the various related
program transformations, I got a nagging feeling that there was a
similar transformation that could make SET! as a quasi-syntactic
operator disappear from compiler intermediate forms. Sorry if that's a
bit woolly - maybe someday I'll have the time to do the work on it
properly and publish a paper or two :)
So I guess I'd like to have a discussion on it anyway :) Practically I
find SET! too useful to do without, and you can't implement it as a
simple (unhygienic) macro. Also leaving it out could mean a whole raft
of cascading changes which could result in something that is truly
unlike Scheme. It brings into high relief the type issues surrounding
mutability and is not something I'd assume lightly.
In fact, I forgot to include it in my list, but I suspect that's also
a slightly Freudian slip :)
david rush
--
http://cyber-rush.org/drr/scheme <- a blah blah blah web site
Nils M Holm
> On Aug 23, 10:07 am, Nils M Holm <before-2007-10...@online.de> wrote:
> > > Nils M Holm wrote:
> > No. As you wrote yourself above, I have found reasons to include
> > *support* *for* some features in the core langauage.
>
> Actually, my current thinking is that even *your* list is too much.
My list was intended as a compromise. If R5.97RS was off the table,
my list, too, would be /much/ shorter.
> And some form of library construct. R^5.97RS is not too bad on that,
> but I do take the point made about version numbering possibly being
> out of scope.
Yes, modules/libraries would be very important. I am not yet sure about
version numbers, but I mostly agree. Maybe, there should be some kind
of low-level interface, such as an FFI, that allows to write libraries
in a language that is better at handling low-level stuff.
> Anyway, the above is analogous to the C core. In order to be useful
> you still need the standard library which would define ports, &cet.
Yes.
> I am somewhat ambivalent about how to include macros. I tend to share
> the view that macros are a last-resort, but they are far too useful to
> ignore.
I think that define-syntax/syntax-rules is fine. Sometimes I
wish there was a more low-level macro construct, but I have
not thought too much about it.
> Exceptions are on the bubble for me also, as I have felt the pain of
> trying to do exception handling exclusively via CALL/CC. But I also
> have reservations about exception-handling in general which it will
> not serve my purposes to debate in this thread :)
User-level exceptions (as syntaxctic sugar on top of call/cc) would
be fine from my point of view.
> > No, it is not. R6RS defines one big blob of features and says "this
> > is R6RS, period". There is no visible line between the core language
> > and the libraries, other than the fact that the document is split in
> > two parts.
>
> I have to say that I almost completely agree. The split is very poorly
> executed. I think I could have lived with everything else I find
> problematic if the split had been done more cleanly.
--
Ray Blaak
> You seem to have very strong feelings about the technical merits of
> R6RS. I can see that. Can you point us to your contributions to the
> Scheme community, to help us get a better feeling for how much weight
> to give your opinion? I wasn't able to find anything on the Web, but
> maybe I didn't look hard enough.
Previous contributions should not be relevant. The possible lack of them does
not invalidate his arguments.
What matters right now is that valid criticisms can be articulated and
understood by all on their own merits.
Brian Harvey
>SET! is another slightly muddled construct, IMHO.
Hey! One of the rules of this game is that you're not allowed to break SICP.
dr.tf...@googlemail.com
> What matters right now is that valid criticisms can be articulated and
> understood by all on their own merits.
I'm all in favor that! Sincerely,
But is "Hell No" an argument?
If someone resort to methods other than substantive arguments, their
credibility becomes relevant.
-Tom Gordon
Harold Ancell
<rAYb...@STRIPCAPStelus.net> wrote:
>dr.tf...@googlemail.com writes:
>> You seem to have very strong feelings about the technical
>> merits of R6RS. I can see that. Can you point us to your
>> contributions to the Scheme community, to help us get a better
>> feeling for how much weight to give your opinion? I wasn't
>> able to find anything on the Web, but maybe I didn't look hard
>> enough.
>Previous contributions should not be relevant. The possible lack
>of them does not invalidate his arguments.
>What matters right now is that valid criticisms can be
>articulated and understood by all on their own merits.
Thank you for saving me the trouble of asking a former boss named
Greenblatt to hit Mr. Troll with a stick ^_^.
While I've made the easy decision not to feed someone who refuses
to reply to my substantive points ("Hell No" obviously not being
one), I must admit he led me to the name I will use for now for
my "side".
>[...] I don't have much to say about R6RS's technical merits,
>being only a user. I do know a bit more about collaboration
>and constructive criticism....
I believe it is clear that I am not a collaborationist with the
R6RS regime, that I have joined the Résistance.
Vive la Résistance Scheme!
- Harold
dr.tf...@googlemail.com
wrote:
> On Thu, 23 Aug 2007 16:58:54 GMT, Ray Blaak> Thank you for saving me the trouble of asking a former boss named
> Greenblatt to hit Mr. Troll with a stick ^_^.
Another substantive argument?
I suppose this is the time to retreat to an observer role and let's
things cool down a bit. There are limits to the amount of abuse one
can take.
Apparently my modest efforts to facilitate this discussion have taken
a bad turn. For which I apologize, to the extent I have been a cause.
Anyway, the whole discussion this week has been just an interlude,
while waiting for decision of the Steering Committee this weekend.
Now back to your regularly scheduled programming.
-Tom Gordon
Ray Dillinger
> Yes, but lots of other features could /easily/ be implemented as
> portable, optional, and independent libraries that require no
> support at all in the core language. ...
> R6RS deliberately includes /all/ the features in the core language,
> and makes /no/ attempt to keep the core language and the libraries
> separated.
> This is indeed what I call "piling feature on top of feature".
Yes, exactly. I don't mind gigantic and even standard libraries,
but I think the language itself should retain a small and simple
core.
Honestly, I'd be happy to "freeze" the core language at R5 or even
R4 (less than either, actually, since I'd shift most of even *those*
features into libraries, and relax some requirements that made Unicode
support impractical) and devote all future standardization efforts
to libraries.
I think too much of this debate is happening in a vacuum. Those of
us who disagree with the R5.97RS proposal have not really fleshed out
the idea of how an alternative would look.
Bear
Majorinc, Kazimir
>
> Neither am I. Personally, I think that it is a typical committee
> result. In a psych course I took oce upon a time, we did a fishbowl
> exercise. It was really interesting to watch the fishbowl's group
> priority mutate from decision making into extending it's power at the
> expense of the stated ideals. This happens *all the time* in group
> dynamics and I think it happened here as well. And I even believe that
> every step was well intentioned - it certainly was in my classroom
> exercise.
David, please, tell us more about your fishbowl classroom exercise. I
think the comp.lisp.scheme community can tolerate small digression. What
happened?
Aaron Hsu
> Those of
> us who disagree with the R5.97RS proposal have not really fleshed out
> the idea of how an alternative would look.
I think it would be an excellent idea to start immediately on a
counter-proposal, but, to make it official, where can I read about how
one goes about doing the next Revised Scheme Report?
--
Aaron Hsu <aaro...@sacrificumdeo.net>
"No one could make a greater mistake than he who did nothing because he
could do only a little." - Edmund Burke
David Rush
> On 2007-08-23 15:12:02 -0500, Ray Dillinger <b...@sonic.net> said:
>
> > Those of
> > us who disagree with the R5.97RS proposal have not really fleshed out
> > the idea of how an alternative would look.
>
> I think it would be an excellent idea to start immediately on a
> counter-proposal, but, to make it official, where can I read about how
> one goes about doing the next Revised Scheme Report?
I think it is a little bit premature...at least until we see what the
committee does. Right now debating the desired features in a standard
serves two purposes - it clarifies the issues surrounding R^5.97RS as
well as preparing the ground for whatever may come afterwards.
david rush
Ray Dillinger
> Nils M Holm wrote:
>
>> Yes, but lots of other features could /easily/ be implemented as
>> portable, optional, and independent libraries that require no
>> support at all in the core language. Again, I outlined this in
>> the message with above ID.
>
>
> Reviewing some of those points, you acknowledge the need for core
> language support for Unicode, bytevectors (assuming efficiency is
> considered important), some list procedures, exceptions and conditions,
> command line access and exit values, arithmetic, syntax-case, eval,
> mutable pairs, and mutable strings. (You also speculate that hash
> tables could be implemented in Scheme, but that's not true if support
> for eq? hashtables is provided, i.e. hashtables keyed on object
> identity, as in R5.97RS.)
Taking them one at a time I'd like to say:
bytevectors:
I consider the R5.97RS specification of bytevectors (and other
uniform-typed vectors) to be The Wrong Thing because it introduces
static typing semantics into an otherwise dynamically typed
language.
Here is a concrete counterproposal that would be unequivocally
better for everybody: What these constructs are is just regular
vectors that we never put anything other than byte *VALUES*
into, and our language should treat them as that. Because
efficiency is considered important I acknowledge the need for
some form that notifies the compiler that we intend never to
put anything but byte values into this vector. Optimizing
Compilers can use it to do all the bytevector optimizations and
correctness checks, and interpreters or other implementations not
too concerned with speed can ignore it completely and still get
correct (albeit slower) results. In a dynamically typed language,
type declarations are checkable expressions of programmer intent
and optimization information, but in a correct program (ie, one
where the type information provided is in fact true) should never
affect semantics.
exceptions and conditions
Okay, legit concern in that this can't readily be implemented in
scheme without a hack for supporting dynamic environments. But
I don't like 'em at all, really; doesn't scheme provide enough
control forms already? Why are we introducing yet another thing
that passes control to a nonlocal part of the program?? And why
are we introducing yet another thing that requires a special,
magical dynamic environment variable (joining the ranks of
current-output-port etc) instead of just introducing the more
general concept of explicit dynamic environments and moving
all this accumulated cruft into nice, portable, scheme-language
libraries that use them?? Finally, did we really need to
introduce a new fundamental type to do this??
My point here is that since there are more than one or two of
these variables, the core language could be made simpler (and
the variables and attendant cruft moved into libraries) by
just handling the environments that have the scoping rules these
variables are in, rather than continuing to add procedures and
syntax to manage references to and uses of each and every one
of them. That is, "remove the constraint" (by taking the needed
support mechanism out of hiding and letting people use it) rather
than "pile feature upon feature" by maintaining a separate,
core-language syntax and procedural interface for each and every
one of these variables.
command-line access and exit values
Nice to have on environments that support 'em. Shouldn't be part
of the language standard because not all environments support 'em.
For example, MacOS up through version 9 had no command line. Neither
do most set-top boxes, PDAs and mobile phones today. This should be
a library, its specification should be in an "informative" rather
than "normative" appendix, and it should not be required for all
environments.
arithmetic
Addition, subtraction, multiplication, and division belong in the
core language. Likewise some integer division stuff like div and
mod. Move everything else into math libraries. Make one
meta-library named "Math" or similar that loads all of the other
math libraries, so people who don't want to pick and choose just
what their program needs don't have to but people who need their
program to be small can.
Also? If we're going to introduce the concept of token-syntax, we
should remove most of the restrictions R5.97 puts on it and look
for ways to shift the numeric tower from core to library. If you
don't have complex-numbers loaded, then "4.5+3.2i" should be a
syntax error and the code for most numeric operations should be
smaller-and-faster than otherwise.
syntax-case
Meh. I don't care, really. I note that it makes module support
somewhat difficult, but it's doable. What was needed was a way
to make unhygienic macros when and as necessary and pick-and-choose
about what actual arguments are handled hygienically. This serves
that purpose, although I doubt it's the simplest thing that does.
The simplest thing that does should be made part of the language
core; all other nontoken macro forms including define-syntax and
syntax-case should be moved to libraries. (Yes, I know; it complicates
build-time. It does not complicate build-time as much as syntax-case
itself does.)
eval
Since the dynamic environment keeps becoming more significant with
the addition of things like the current continuation and the current
exception handler, eval has become underspecified again. We should
probably be making dynamic environments an explicit part of the
language and considering an optional third argument for eval to
give it the dynamic environment.
Also? Eval should be in a library. Not loading it should be a good
clue for compilers that can't work it out on their own, saying that
compiled programs which don't need it, needn't carry the whole
scheme system, sources, and compiler around with them. Also, knowing
you don't need it enables a whole lot of optimizations that would
otherwise be unsafe.
mutable pairs
mutable strings
These are red herrings, really. Scheme has always had both mutable
and immutable pairs and strings. I do not understand why the current
standard committee felt compelled to complicate that.
> So in this preliminary list, you've already found reasons to put quite a
> few things in the core language.
Perhaps, but not as many as I'd like to take out of it.
Bear
Ray Dillinger
> On 23 Aug., 18:58, Ray Blaak <rAYbl...@STRIPCAPStelus.net> wrote:
>
>
>>What matters right now is that valid criticisms can be articulated and
>>understood by all on their own merits.
>
>
> I'm all in favor that! Sincerely,
>
> But is "Hell No" an argument?
>
Yes, it is a very substantive argument. The man speaks as a
representative of a user group which WILL refuse to adopt
R6RS if R6RS is based on the current proposal. That, in itself,
is an authoritative argument stating that the current proposal
if adopted will cause schism (a "fork") in the scheme community.
Bear
j.e.m....@gmail.com
> Wouldn't this work?
>
> In module A:
>
> (define aa 'foo)
>
> (define (set-a! val)
> (set! aa val)
>
> (define-syntax a
> <identifier-macro-that-in-a-set!-context-expands-to-set-a!>))
>
> Export a.
>
You could do this without identifier macros too, by just exporting get-
a and set-a! procedures. However, I'm not sure if it's a good idea no
matter how you do it.
Suppose there's a library B that imports A and calls (set! a 'bar),
and then the top level program imports both A and B.
What's the value of a? Is it 'foo or 'bar? If it's 'foo, then this
isn't buying you very much, as you might as well create a local
variable a in the top level program and use that.
Suppose there is another library C that sets a to 'baz, and the top
level program imported that too. Then the value of a would depend on
the order in which the libraries were visited, which means the program
might behave differently on different implementations.
Jens Axel Søgaard
> On Aug 23, 5:28 am, Jens Axel Søgaard <use...@soegaard.net> wrote:
>> Wouldn't this work?
>>
>> In module A:
>>
>> (define aa 'foo)
>>
>> (define (set-a! val)
>> (set! aa val)
>>
>> (define-syntax a
>> <identifier-macro-that-in-a-set!-context-expands-to-set-a!>))
>>
>> Export a.
>>
>
> You could do this without identifier macros too, by just exporting get-
> a and set-a! procedures.
I have a hunch Pascal wouldn't be content with that solution.
> However, I'm not sure if it's a good idea no
> matter how you do it.
> Suppose there's a library B that imports A and calls (set! a 'bar),
> and then the top level program imports both A and B.
> What's the value of a? Is it 'foo or 'bar? If it's 'foo, then this
> isn't buying you very much, as you might as well create a local
> variable a in the top level program and use that.
It is indeed debatable whether it is a good idea, but the question
was whether it was possible ;-)
--
Jens Axel Søgaard
Aaron Hsu
> I think it is a little bit premature...at least until we see what the
> committee does.
Don't you think that it would be a good idea to at least have the
nay-sayers quantify, to some degree, how to better the draft, whether
or not the committee ratifies the current draft? I guess we have done
that already, through these discussions, though.
Lynn Winebarger
> I'm not sure anything about the present discussion is really analogous, but
> the candidate would be the claim that "not by piling feature on top of
> feature" is so strongly constitutive of what it means to be Scheme that any
> result that undoes that principle is illegitimate no matter how arrived at.
> This would be a strong claim; those people who would like R6RS were it not for
> one or two details can't make it, I think. The argument is available only to
> those who would say that R6RS must have a page count smaller than or equal to
> that of R5RS.
Page count is the wrong measure. The right measure is more along
the lines of
finding a minimal basis for a vector space. The core language should
have the
fewest number of operators it needs to provide the features it does.
We exclude from
the span of a set of features other features that can be provided at
the cost of
whole-program transformation, such as call/cc, though even if we did
allow for
whole program tranforms, a guarantee of proper tail recursion (in some
form) would
need to be provided.
R5RS is an excellent language for computation as originally
envisioned
by mathematicians. It falls down in providing computation in the
presence of
other processes that are implemented inconsistently with the
operational semantics
of the implementation, providing dynamic creation and manipulation of
namespaces,
and promotion of code into operational objects. Addressing these
concerns will
require showing that the associated core features can be implemented
reasonably efficiently.
I proposed some vague, hand-wavy suggestions on how to approach
these issues.
For example, to resolve the first issue, you need a semantics that can
cope with
asynchronous processes (to make handling interactions with I/O and
other processes
rational), as well as a way to specify data layout in a way consistent
with these
other processes. I see Scheme's historic insistence on built-in data
types as an
unnecessary restriction from this vantage point. On the one hand, you
can always
model the provided data types with lambda, if the implementor so
desired. You
could do this after a fashion with arbitrary data layout, making bit
extraction
or array references function correctly in the system. It makes
interacting with
other processes and hardware fraught difficult, though the implementor
could wrap
external data up into lambda models consistent with the full data
layout language
if he or she were so inclined. What's worse is that the R5.97 draft
adds many
more built in data types that could be defined through a single
mechanism. I've
given the only reason I can think of that would be legitimate for
rejecting the
addition of full data layout specification. I am happy to hear of
others; the one
illegitimate reason I can produce is that it would make writing an
efficient
storage manager or interpreter difficult (this makes me think of
"Debunking the
'Expensive Procedure Call' Myth", which is why I consider it
illegitimate for
a language named "Scheme").
I'm also offended at the idea that the standard libraries should
necessarily
be written in a language other than Scheme, or that another language
should be
better suited to implementing Scheme. Scheme should be as fundamental
a substrate
of computation as C or any other language.
Lynn
Pascal Costanza
> Pascal Costanza wrote:
>
>> Here is what I think could serve as an example: R6RS provides a way to
>> define constant variables. However, this feature is "piled" on top of
>> the module system - you can only define a variable as a constant by
>> exporting it from a module. R6RS doesn't provide a way to define
>> constants for module-internal uses.
>
> You can define a define-constant with the help of identifier macros.
Then you would have two ways of defining constants. I'd call that redundant.
>> At the same time, R6RS doesn't provide a way to export assignable
> > variables.
>
> Wouldn't this work?
>
> In module A:
>
> (define aa 'foo)
>
> (define (set-a! val)
> (set! aa val)
>
> (define-syntax a
> <identifier-macro-that-in-a-set!-context-expands-to-set-a!>))
>
> Export a.
Yuck.
R6RS Scheme seems to have been designed for "correct" programs, not for
evolving ones. A typical case in bottom-up programming is that you play
around with different design ideas before you settle on a final design.
(And even a final design is not necessarily really final.)
So I expect the following to be a typical scenario: You define a
module-internal variable that refers to an unchanging value. You export
it to use it from another module. Then you realize that you actually
need to assign to it. Now you have to change all call sites, or switch
to the hack/workaround you described above.
Or you actually have exported a variable in a way as described above.
Later on you realize that nobody assigns to it and/or that nobody
actually should assign to it. You turn it into an module-internal
variable - now you have to remove all the clutter described above.
That's not a natural way of changing an interface - you have to refactor
comparatively a lot of code just to make a simple change work. That's
typically only the case in static languages.
[I smell a book coming up - "Best Practice Patterns for Scheme" ;)]
> > This seems like an
>> arbitrary coupling of two otherwise separate characteristics.
>
> Banning assignments to exported variables is in my book a good thing.
> Among other things it enables various optimizations that otherwise
> would only be possible in whole-program compilers.
Who the heck do the language designers think they are, trying to
prescribe what programming style I should use? Especially for such lame
reasons as efficiency?
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
Pascal Costanza
> Suppose there is another library C that sets a to 'baz, and the top
> level program imported that too. Then the value of a would depend on
> the order in which the libraries were visited, which means the program
> might behave differently on different implementations.
I would hope that the loading and initialization order of modules in
R6RS Scheme is unambiguous. Otherwise the module system is pretty
useless... [1]
Pascal
[1] ...and the Singleton pattern would become widely used in Scheme. At
least, the fact that the initialization order of libraries in C++ is
underspecified is probably the main reason why the Singleton pattern is
so popular over there. ;)
Pascal Costanza
> j.e.m....@gmail.com wrote:
>> On Aug 23, 5:28 am, Jens Axel Søgaard <use...@soegaard.net> wrote:
>>> Wouldn't this work?
>>>
>>> In module A:
>>>
>>> (define aa 'foo)
>>>
>>> (define (set-a! val)
>>> (set! aa val)
>>>
>>> (define-syntax a
>>> <identifier-macro-that-in-a-set!-context-expands-to-set-a!>))
>>>
>>> Export a.
>>>
>>
>> You could do this without identifier macros too, by just exporting get-
>> a and set-a! procedures.
>
> I have a hunch Pascal wouldn't be content with that solution.
You bet. ;)
Pascal
Jens Axel Søgaard
> Jens Axel Søgaard wrote:
>> Pascal Costanza wrote:
>>
>>> Here is what I think could serve as an example: R6RS provides a way
>>> to define constant variables. However, this feature is "piled" on top
>>> of the module system - you can only define a variable as a constant
>>> by exporting it from a module. R6RS doesn't provide a way to define
>>> constants for module-internal uses.
>>
>> You can define a define-constant with the help of identifier macros.
>
> Then you would have two ways of defining constants. I'd call that
> redundant.
I didn't say you should. Analyzing which variables in a module that are
assigned is relatively easy to do, so for most purposes I'd define
a constant with the normal "define".
>>> At the same time, R6RS doesn't provide a way to export assignable
>> > variables.
>>
>> Wouldn't this work?
>>
>> In module A:
>>
>> (define aa 'foo)
>>
>> (define (set-a! val)
>> (set! aa val)
>>
>> (define-syntax a
>> <identifier-macro-that-in-a-set!-context-expands-to-set-a!>))
>>
>> Export a.
>
> Yuck.
Agreed, but then I prefer to export parameters to assignable variables.
> R6RS Scheme seems to have been designed for "correct" programs, not for
> evolving ones. A typical case in bottom-up programming is that you play
> around with different design ideas before you settle on a final design.
> (And even a final design is not necessarily really final.)
>
> So I expect the following to be a typical scenario: You define a
> module-internal variable that refers to an unchanging value. You export
> it to use it from another module. Then you realize that you actually
> need to assign to it. Now you have to change all call sites, or switch
> to the hack/workaround you described above.
I'd introduce parameters, but otherwise I'd hide the yuckiness in
a library, and make
(define-assignable a 'foo)
expand to the above.
> Or you actually have exported a variable in a way as described above.
> Later on you realize that nobody assigns to it and/or that nobody
> actually should assign to it. You turn it into an module-internal
> variable - now you have to remove all the clutter described above.
>
> That's not a natural way of changing an interface - you have to refactor
> comparatively a lot of code just to make a simple change work. That's
> typically only the case in static languages.
Hide it.
>> > This seems like an
>>> arbitrary coupling of two otherwise separate characteristics.
>>
>> Banning assignments to exported variables is in my book a good thing.
>> Among other things it enables various optimizations that otherwise
>> would only be possible in whole-program compilers.
>
> Who the heck do the language designers think they are, trying to
> prescribe what programming style I should use? Especially for such lame
> reasons as efficiency?
Efficiency is not the only reason.
--
Jens Axel Søgaard
Pascal Costanza
> Pascal Costanza wrote:
>> Yuck.
>
> Agreed, but then I prefer to export parameters to assignable variables.
I don't.
>> That's not a natural way of changing an interface - you have to
>> refactor comparatively a lot of code just to make a simple change
>> work. That's typically only the case in static languages.
>
> Hide it.
How?
>>> Banning assignments to exported variables is in my book a good thing.
>>> Among other things it enables various optimizations that otherwise
>>> would only be possible in whole-program compilers.
>>
>> Who the heck do the language designers think they are, trying to
>> prescribe what programming style I should use? Especially for such
>> lame reasons as efficiency?
>
> Efficiency is not the only reason.
What are the other ones?
David Rush
> On Aug 17, 5:46 pm, Ray Dillinger <b...@sonic.net> wrote:
>
> > dr.tfgor...@googlemail.com wrote:
> > > Implementors and users both have legitimate interests in the standard,
> > > no doubt. It is not clear to me how to weigh the votes of these two
> > > groups. Should implementors have a greater say?
>
> > I think so. In practical terms, without the support of implementors
> > the standard does not exist.
>
> I fail to see how the steering committee could have done more to
> involve implementors: a total of 8 people have served on the Editors'
> Committee, of which 7 were implementors, representing 6 different
> implementations. Of those, 4 editors resigned, for various
> reasons that we mostly don't know.
Well, interestingly enough, today (2007-08-25) I was pointed to the
original Scheme Workshop notes which started the process. I have taken
the liberty of excerpting the panel discussion on developing a new
standard at <http://cyber-rush.org/drr/scheme/r6rs/process-
setup.html>. The whole document is fascinating, but the note at anchor
#d2 is particularly interesting:
* People who impede the process can just be removed.
However, I do not particularly think that such behavior was directly
enacted. I do think that sets a dangerous tone of looking at
objections as obstructionist. This is all pure speculation, however.
david rush
Neelakantan Krishnaswami
David Rush <kumo...@gmail.com> wrote:
> On Aug 23, 1:49 pm, Neelakantan Krishnaswami <ne...@cs.cmu.edu> wrote:
>> In article <<1187871413.436436.163...@q3g2000prf.googlegroups.com>>,
>> David Rush <kumoy...@gmail.com> wrote:
>> > The usual special forms:
>> > * LAMBDA
>> > * IF
>> > * LETREC
>> > * DEFINE
>> > * CALL/CC
>>
>> I see you are leaving out the set! special form. I presume you want to
>> introduce make-box, get-box, and set-box! explicitly in its place?
>
> Well, that's an option. SET! is another slightly muddled construct,
> IMHO. Back when I was looking deep into CPS and the various related
> program transformations, I got a nagging feeling that there was a
> similar transformation that could make SET! as a quasi-syntactic
> operator disappear from compiler intermediate forms. Sorry if that's a
> bit woolly - maybe someday I'll have the time to do the work on it
> properly and publish a paper or two :)
Look at Scheme's denotational semantics -- the heap is threaded through
the semantic function as an explicit argument. The fact that it is used
in a single threaded way means that you can implement set! as destructive
update, but there's nothing requiring you to.
In fact, weakening that restriction might even be a useful thing to
do; with a call-with-current-heap operator, you could implement things
like transparent rollback for error handling in a uniform way. (I
expect you'd end up feeling the need for delimited heaps quicker than
people did for delimited continuations, though. :)
Offhand, I don't know of any compiler IRs that explicitly model the
heap as a pure argument, so there are probably some interesting
scientific questions in trying it.
--
Neel R. Krishnaswami
ne...@cs.cmu.edu
Pascal Costanza
> j.e.m....@gmail.com wrote:
>
>> Suppose there is another library C that sets a to 'baz, and the top
>> level program imported that too. Then the value of a would depend on
>> the order in which the libraries were visited, which means the program
>> might behave differently on different implementations.
>
> I would hope that the loading and initialization order of modules in
> R6RS Scheme is unambiguous. Otherwise the module system is pretty
> useless... [1]
>
> Pascal
>
> [1] ...and the Singleton pattern would become widely used in Scheme. At
> least, the fact that the initialization order of libraries in C++ is
> underspecified is probably the main reason why the Singleton pattern is
> so popular over there. ;)
Forget the remark about the Singleton pattern - that was nonsense.
Pascal
barak.pe...@gmail.com
> Suppose there is another library C that sets a to 'baz, and the top
> level program imported that too. Then the value of a would depend on
> the order in which the libraries were visited, which means the program
> might behave differently on different implementations.
Yes, horrors. Who could possibly tolerate a language that left the
semantics of things like
(CONS (SET! A 1) (SET! A 2))
unspecified?
Brian Harvey
>I think too much of this debate is happening in a vacuum. Those of
>us who disagree with the R5.97RS proposal have not really fleshed out
>the idea of how an alternative would look.
Personally, I vote for R4RS.
Ray Dillinger
I'm inclined to agree.
R5RS got us multiple return values - But they're hard to justify
in terms of theory. The lambda calculus on which scheme is based
has single argument and single return from all functions; multiple
arguments are justified in terms of that theory as a syntactic hack
for a single argument which is a list of values. We can usually
avoid allocating list structure, but when we can't, the call still
packages up arguments in a list. You can't really regard multiple
return values the same way, mathematically speaking, unless the
return packages up values in a list in an isomorphic way - and we
don't have any way of specifying list handling on returns (or local
naming of return values) in our simple "nested calls" program
structure. Multiple return values as specified in R5RS are not just
a syntactic hack for list returns; they are a semantic hack as well,
and make returns less rather than more isomorphic to calls. It's better
to just return a list and put the machinery for decomposing it in
the continuation that gets it.
R5RS also got us winding continuations - which marked the first time
that a more general form had been removed from the language in order
to make way for a less general one. To wit, you can implement winding
continuations in terms of plain continuations, but the reverse is not
true. It is not at all clear that this was a good idea.
Bear
Nils M Holm
> Brian Harvey wrote:
> > Ray Dillinger <be...@sonic.net> writes:
> >
> >>I think too much of this debate is happening in a vacuum. Those of
> >>us who disagree with the R5.97RS proposal have not really fleshed out
> >>the idea of how an alternative would look.
> >
> >
> > Personally, I vote for R4RS.
>
> I'm inclined to agree.
I agree except for one point: R4RS allows to treat () as `false'
(note in section 3.2).
--
Nils M Holm <n m h @ t 3 x . o r g> -- http://t3x.org/nmh/
Brian Harvey
>I agree except for one point: R4RS allows to treat () as `false'
>(note in section 3.2).
Yeah, that's one of the reasons I like it. It means functions such as
MEMBER have a nice simple range -- lists -- instead of a kludgy range
of "lists or false."
David Rush
On Aug 28, 8:48 am, b...@cs.berkeley.edu (Brian Harvey) wrote:
(define (member-k elt list k-found k-failed)
(let look ((elts list))
(if (null? elts)
(k-failed elt list)
(if (equal? elt (car elts))
(k-found elts)
(look (cdr elts))
))))
Not everybody *likes* CPS, but being able to build conditionals into
type-punning functions is a fundamental attraction of Scheme to *me*.
And you can always build traditional MEMBER on top of it, if you don't
mind the performance hit :)
david rush
--
http://cyber-rush.org/drr/scheme <- a very messy construction^Wweb site
Jens Axel Søgaard
> Jens Axel Søgaard wrote:
>> Pascal Costanza wrote:
>>>> Banning assignments to exported variables is in my book a good thing.
>>>> Among other things it enables various optimizations that otherwise
>>>> would only be possible in whole-program compilers.
>>>
>>> Who the heck do the language designers think they are, trying to
>>> prescribe what programming style I should use? Especially for such
>>> lame reasons as efficiency?
>>
>> Efficiency is not the only reason.
>
> What are the other ones?
Consider this scenario:
Library A defines a variable a.
Library B uses A and sets a to 1.
A user writes a library C which use library B.
(The user wrote neither A or B.)
Library C works! The user is happy.
But now the user decides to extend the his program...
Library C now uses both library A and D.
Suddenly the parts of his program that involves library B
become buggy. The user is puzzled.
What the user didn't know (and shouldn't need to know)
is that library D uses also A and that it has set a to 2,
causing problems for library B.
From the user point of view, where C uses only B and D;
it is *very* hard to figure out where the problem is.
My conclusion is that as default it should be impossible to
assign to exported variables.
The next question is what to do if actually want to
assign to an exported variable. An easy solution
that doesn't require piling new features upon the
module system is to export setter-function for the
variable. If for some reason setter-functions are
frowned upon, then one can sugar coat them with
identifier macros so they look like variables.
--
Jens Axel Søgaard
Pascal Costanza
...which means that you effectively haven't solved the problem, because
exactly the same issue as you described above can arise with setter
functions as well.
If you want an effect-free language, switch to Haskell (or Liskell).
In a language with side effects, you may have these problems. Full stop.
> If for some reason setter-functions are
> frowned upon, then one can sugar coat them with
> identifier macros so they look like variables.
This is exactly the kind of workaround that we continuously have to
fight with in lesser languages. (Will we get C#-style properties in R7RS
to resolve this specific example? ;)
Again: Making a variable read-only (or constant) is a feature that is
useful independent of whether it is exported or not. Likewise,
assignable variables are useful, again independent of whether they are
exported or not. R6RS misses an opportunity to make constantness and
exportedness of variables orthogonal features.
andreu...@yahoo.com
> Jens Axel Søgaard wrote:
>
> > The next question is what to do if actually want to
> > assign to an exported variable. An easy solution
> > that doesn't require piling new features upon the
> > module system is to export setter-function for the
> > variable.
>
> ...which means that you effectively haven't solved the problem, because
> exactly the same issue as you described above can arise with setter
> functions as well.
No, there is a very important difference. With a setter function,
the defining library explicitly relinquishes control over any
modifications of its bindings. If no setter function is exported,
then the meaning of the defining library cannot be changed by client
code.
I think this is a good principle - imagine that it were not followed,
and you wanted to use a high-performance numerical library in your
code. All of a sudden, you realize that your numerical code is
running
terribly slow. After a long debugging session, you realize that it
was due
to an import of one of the SLIB libraries that redefine + at an
unrelated
point in the same program.
This principle is not as foreign to Scheme as you might think. It
was
already there to an extent in R5RS, which specified that redefining
CDR
in a user program will not change the meaning of MAP.
> In a language with side effects, you may have these problems. Full stop.
Not with a good library system you don't. (Officer, I totally
paused).
> Again: Making a variable read-only (or constant) is a feature that is
> useful independent of whether it is exported or not.
Agreed with this part, but why add more stuff to R6RS?
> R6RS misses an opportunity to make constantness and
> exportedness of variables orthogonal features.
As stated above, there is a principle of library-meaning-invariance
which IMO rightly trumps this.
Andre
Ray Dillinger
> Library C works! The user is happy.
>
> But now the user decides to extend the his program...
>
> Library C now uses both library A and D.
>
> Suddenly the parts of his program that involves library B
> become buggy. The user is puzzled.
>
> What the user didn't know (and shouldn't need to know)
> is that library D uses also A and that it has set a to 2,
> causing problems for library B.
>
> From the user point of view, where C uses only B and D;
> it is *very* hard to figure out where the problem is.
> My conclusion is that as default it should be impossible to
> assign to exported variables.
My conclusion is that the design of the module A is
just plain wrong; if an unexpected value of a (or a
value different from the one a module has set for
itself) can cause bugs, then it is clear that D and
B should each have their own private a.
This is handled by having a be a dynamic-environment
variable: Module A creates it at top-level, modules
D and B create shadowing definitions that are in force
anytime module A is reached through their call paths.
C uses B and D happily, not knowing (or caring) that
each has a different version of a.
Implementation of special variables using winding
continuations is found in one of the SRFI's: for a
less silly implementation you only need to quit lying
about not having dynamic environments and bring all
the other dynamic variables (current-output-port, etc)
into the open.
> The next question is what to do if actually want to
> assign to an exported variable.
Allow it. Permit implementations to issue a warning
if they like, or when the user tries to build with
paranoid options. But there must be some configuration
for the program that builds without the warnings.
The fundamental assumption I'm making is that the
programmer is smart. Because there may ever sometimes
be a need for a programmer to do something, allow it.
Because it may cause bugs, make sure the programmer
is doing it on purpose.
Bear
Nils M Holm
Having thought about it, both approaches have their advantages, so
either one would suit me. What bugs me is the wording in R4RS sect.
3.2, because it indicates that the empty list may be either true
/or/ false, depending on the implementation:
"Note: In some implementations the empty list also counts as false
instead of true."
Aubrey Jaffer
How about IEEE-P1178? Its like R4RS without the macro appendix.
Brian Harvey
>How about IEEE-P1178? Its like R4RS without the macro appendix.
Even better, as long as we don't have to pay to read it.
It seems clear to me, although I know others don't agree, that the
"removing weaknesses and restrictions" solution to the macro problem
is FEXPRs plus first-class environments.
Pascal Costanza
> On Aug 28, 3:05 pm, Pascal Costanza <p...@p-cos.net> wrote:
>
>> Jens Axel Søgaard wrote:
>>
>>> The next question is what to do if actually want to
>>> assign to an exported variable. An easy solution
>>> that doesn't require piling new features upon the
>>> module system is to export setter-function for the
>>> variable.
>> ...which means that you effectively haven't solved the problem, because
>> exactly the same issue as you described above can arise with setter
>> functions as well.
>
> No, there is a very important difference. With a setter function,
> the defining library explicitly relinquishes control over any
> modifications of its bindings. If no setter function is exported,
> then the meaning of the defining library cannot be changed by client
> code.
>
>> useful independent of whether it is exported or not.
>
> Agreed with this part, but why add more stuff to R6RS?
>
>> R6RS misses an opportunity to make constantness and
>> exportedness of variables orthogonal features.
>
> As stated above, there is a principle of library-meaning-invariance
> which IMO rightly trumps this.
The situation now is that it is very cumbersome to export assignable
variables, although not impossible due to identifier macros. If R6RS had
constant variables, you would get exactly the same degree of control
over assignability when exporting variables, only in a much more
straightforward way.
Always remember:
"No amount of language design can _force_ a programmer to write clear
programs. If the programmer's conception of the problem is badly
organized, then his program will also be badly organized. The extent to
which a programming language can help a programmer organize his problem
is precisely the extent to which it provides features appropriate to his
problem domain. The emphasis should not be on eliminating 'bad' language
constructs, but on discovering or inventing helpful ones."
- Guy Steele and Gerald Sussman, Lamda - The Ultimate Imperative
David Rush
Interestingly enough, Lynn Winebarger mentioned to me a new spin on
this, that I hadn't heard before: Think of Scheme as a semantics
system with IO and EVAL operators. It seems to me that macros and
libraries fall out of that definition as compile-time and link-time
optimizations (respectively).
david rush
Ray Dillinger
Been there. Did that. Got the tee-shirt.
First-class environments are a compatible and useful
addition to scheme. Mutable first-class environments
enable many good and useful constructs.
FEXPRs as implemented in early Lisps were always fatally
flawed in that they were written with no idea of the
environment in which they'd be expanded/executed, and
this affected not only variable capture by the expanded
code but also, when FEXPRs were composed, argument
evaluation occurring in environments other than the
call site. FEXPRs were eventually considered to be more
trouble than they were worth and (mostly) abandoned.
A few years ago I made an experimental interpreter in
which I tried to provide first-class, mutable
macroexpanders. FEXPRS were one of the early steps
along the path to that goal, for me. But I kept
getting beat up by the environment ambiguities,
particularly when composing them. Further, although
macros/fexprs and functions are used/invoked in a
similar way, they remained divided so you couldn't use
higher-order functions with them.
Finally, I did manage to produce an interpreter that did
what I wanted, but by that time I had a truly funky call
semantics where every argument to every function was
actually a datum-form plus environment in which to
"normally" evaluate it -- thus arguments were evaluated
under the control of the called function but in the
environment of the call site, as with lazy semantics.
Not much semantic distinction in the usual case, but
when you have the ability to decompose arguments into
a datum-form and a first-class environment, you can
deliberately evaluate them in different ways, multiple
times, or not at all, plus do funky tricks with the
environments, and everything you need syntax for in
Scheme and Common Lisp became just another function.
That made me happy.
So it was tasty theory and a consistent interpretation
of lambda calculus: The downside of course was that it
was screamingly hard to compile and utterly incompatible
with any definition of scheme's eager-evaluation semantics.
With suitable function definitions it could simulate them
well enough, but there would always be corners hanging
out in nonstandard ways where call/cc could expose them.
Bear
Brian Harvey
>FEXPRs as implemented in early Lisps were always fatally
>flawed in that they were written with no idea of the
>environment in which they'd be expanded/executed, and
>this affected not only variable capture by the expanded
>code but also, when FEXPRs were composed, argument
>evaluation occurring in environments other than the
>call site. FEXPRs were eventually considered to be more
>trouble than they were worth and (mostly) abandoned.
Yeah, I know. But if you pass the caller's environment to the FEXPR,
it can control where to eval things, no?
Maybe FEXPRs aren't the answer. But my criterion for a good answer
is that the macro system shouldn't give rise to "How do I ..." messages
on c.l.s except from newbies. That was a definite virtue of FEXPRs; even
I could understand them.
Ray Dillinger
> Ray Dillinger <be...@sonic.net> writes:
>
>>FEXPRs as implemented in early Lisps were always fatally
>>flawed in that they were written with no idea of the
>>environment in which they'd be expanded/executed, and
>>this affected not only variable capture by the expanded
>>code but also, when FEXPRs were composed, argument
>>evaluation occurring in environments other than the
>>call site. FEXPRs were eventually considered to be more
>>trouble than they were worth and (mostly) abandoned.
>
>
> Yeah, I know. But if you pass the caller's environment to the FEXPR,
> it can control where to eval things, no?
Right, and that was the next step for me in my quest to
figure out first-class macroexpanders. Until you provide
the environment with each and every argument, it still
breaks when you compose them because now you have multiple
"call" sites in the composed macro.
> Maybe FEXPRs aren't the answer. But my criterion for a good answer
> is that the macro system shouldn't give rise to "How do I ..." messages
> on c.l.s except from newbies. That was a definite virtue of FEXPRs; even
> I could understand them.
Yeah. I always thought that hygienic macros (as provided
by define-syntax) should have been implemented as a library
on top of defmacro + gensym, myself. It's pretty easy to
understand what defmacro does and to get how powerful and
neat lispy macros are. It's also pretty easy to implement
defmacro.
Hygiene is another issue, a lot more subtle, and not always
wanted. But gensym provides a way to do it. So you use defmacro
plus gensym to define define-syntax in a library and that's all
a good thing.
Bear
Jens Axel Søgaard
> Yeah. I always thought that hygienic macros (as provided
> by define-syntax) should have been implemented as a library
> on top of defmacro + gensym, myself.
Try it!
--
Jens Axel Søgaard
Anton van Straaten
> Hygiene is another issue, a lot more subtle, and not always
> wanted. But gensym provides a way to do it. So you use defmacro
> plus gensym to define define-syntax in a library and that's all
> a good thing.
That's quite a fantasy life you've got going there. ;-P
Seriously, if you want a low-level macro system to build on it seems
like you'd be much better off with explicit renaming or syntactic
closures. For example, Andre van Tonder's reference implementation for
SRFI 92, which implements syntax-rules and a version of syntax-case, was
"strongly influenced by the explicit renaming system". (I assume the
same is true of his R6RS syntax-case implementation, but I don't know).
Anton
David Rush
wrote:
> Ray Dillinger wrote:
> > Hygiene is another issue, a lot more subtle, and not always
> > wanted. But gensym provides a way to do it. So you use defmacro
> > plus gensym to define define-syntax in a library and that's all
> > a good thing.
>
> closures
I was just about to say that :)
I finally got some experience with explicit-renaming macros in
Larceny, and from a user PoV I can say it's not that bad of a system.
What I did find annoying - and I suspect where the motivation for
SYNTAX-CASE arose - is the fact that if you want to be mostly
hygienic, you end up invoking the renamer on nearly every identifier.
It makes me kinda wish for an alternative templating system to
QUASIQUOTE/UNQUOTE, and I can see how you end up in SYNTAX-CASE pretty
quickly. Fortunately, good programming habits can ameliorate
unhygienic macro bugs. It's not a scientific solution, I know, but it
works for engineering purposes :)
david rush
--
http://scheme-punks.cyber-rush.org
andreu...@yahoo.com
> For example, Andre van Tonder's reference implementation for
> SRFI 92, which implements syntax-rules and a version of syntax-case, was
> "strongly influenced by the explicit renaming system". (I assume the
> same is true of his R6RS syntax-case implementation, but I don't know).
Yes, my R6RS syntax-case implementation is just syntactic
sugar on top of explicit renaming. At core my algorithm
is very similar to Clinger and Reese's original
"Macros that work" implementation of explicit renaming.
I started off not liking syntax-case and ended up liking it.
It is true that explicit renaming is a much simpler API, but
once you have used it to implement syntax-rules, as required
anyway by R5RS, the cost of adding syntax-case is almost zero.
Syntax-case is conceptually no more complicated than
syntax-rules, if you understand syntax-rules.
My implementation proves that R6RS could have based their
macros on a simpler explicit renaming API, or even something
like the R4RS appendix that provides some minimal syntactic
sugar on top of it. However, if you are going to require
syntax-rules in the base, then syntax-case is pretty much
the simplest extension of it.
To answer Bear in a little more detail - there is no way to
get correct lexical scoping of macros with defmacro.
Andre
Pascal Costanza
> To answer Bear in a little more detail - there is no way to
> get correct lexical scoping of macros with defmacro.
That's incorrect. I have been able to implement a hygienic macro system
in terms of defmacro. I hope to be able to report on this soon.
andreu...@yahoo.com
> That's incorrect. I have been able to implement
> a hygienic macro system
> in terms of defmacro. I hope to be able to
> report on this soon.
Just to clarify: In the terminology used in the
Dybvig et. al. papers (which not everyone uses),
achieving what they call "hygiene" has never been
a problem for defmacro (simply use gensym).
But Scheme macros have to be "referentially
transparent" also, and that is of course the
difficult issue. (I am sure you know that,
but the casual reader might not.) Since macros
have been somewhat of a hobby of mine lately,
I am looking forward to reading about any new
trick you may have discovered.
Andre
Jens Axel Søgaard
> The situation now is that it is very cumbersome to export assignable
> variables, although not impossible due to identifier macros. If R6RS had
> constant variables, you would get exactly the same degree of control
> over assignability when exporting variables, only in a much more
> straightforward way.
Most variables are never assigned to. Therefore it would be a little
cumbersome to write (define-constant pi 3.14) instead of
(define pi 3.14). Since it is a simple analysis to determine which
variables are assigned to inside a module, a compiler would generate
the same code whether we mark constants or not.
[But maybe I am misinterpreting your remark, and you are thinking
of something different from define-constant ?]
--
Jens Axel Søgaard
Pascal Costanza
No, define-constant (or so) is what I have in mind.
If I say (defconst pi 3.14), I can be sure that I don't accidentally
assign a different value to pi, independent of whether pi is exported or
not.
Jens Axel Søgaard
> If I say (defconst pi 3.14), I can be sure that I don't accidentally
> assign a different value to pi, independent of whether pi is exported or
> not.
Would you also write
(defconst (add1 n)
(+ n 1))
Pascal Costanza
Sure, why not?
Ray Blaak
> mutable pairs
> mutable strings
>
> These are red herrings, really. Scheme has always had both mutable
> and immutable pairs and strings. I do not understand why the current
> standard committee felt compelled to complicate that.
I would think that this allows much better abilities at reasoning about
programs, doing optimizations, sharing, etc.
Henry Baker is big on these.
--
Cheers, The Rhythm is around me,
The Rhythm has control.
Ray Blaak The Rhythm is inside me,
rAYb...@STRIPCAPStelus.net The Rhythm has my soul.
Jens Axel Søgaard
> Jens Axel Søgaard wrote:
>> Pascal Costanza wrote:
>>
>>> If I say (defconst pi 3.14), I can be sure that I don't accidentally
>>> assign a different value to pi, independent of whether pi is exported
>>> or not.
>>
>> Would you also write
>>
>> (defconst (add1 n)
>> (+ n 1))
>>
>> ?
> Sure, why not?
Tradition/legacy.
Not sure that counts as a good reason though :-)
--
Jens Axel Søgaard