The quoted excerpts below are from several different people.
> Algorithms can certainly produce multiple results that one
> wouldn't want to restrict to being elements of a vector.
Hmm, when I think "vector" I think "homogeneous," so I can see what might
be behind that feeling. But I think the trivial implementation
(define values list)
(define (call-with-values producer consumer)
(apply consumer (producer)))
shows that this feature adds nothing to Scheme's expressiveness. People
wanted it because you can make more efficient implementations than this.
But, this one is probably a lost cause, so let's argue about something
else. :-)
> Why not define the core plus the optional industrial add ons? Why
> can't we have our cake and eat it too?
Sounds awesome. That's what the SRFI process is supposed to do.
The trouble with R6 is that it messes up the core very dramatically.
(I know, other people have objections to details about particular
extensions, but my feeling is that people like me can just ignore
the extensions, as long as you don't do things like making identifiers
case-sensitive, which is a radical piece of vandalism to the core.)
> The last thing we want from a steering committee is a radical
> commitment to change (whatever it may be); a prejudice concerning
> R6RS; a closed mind about the size of "Scheme" (it's too large,
> it's too small); a willingness to steer without making
> observations. A steering committee of overbearing curmudgeons is
> not what we want.
This sounds so reasonable, so obvious, so Obama-esque, that nobody
who's running will dare disagree with it. So I guess it's up to me. :-)
Of course nobody likes "overbearing curmudgeons"; but if one were to use a
different choice of language and call them "people with principles" our
emotional response might be different. (And yes, I understand that that would
also be an emotionally loaded choice of words -- I used it deliberately to
make exactly that point.)
Why isn't there just one perfect programming language? Part of the reason
is that different languages serve different purposes. For example, Ken
Iverson made a good case that APL is the language of choice for teaching
high school math classes; he did it by writing textbooks demonstrating how.
IMHO Scheme has a noble, holy purpose: to embarrass the designers of other
languages into reconsidering their accretions of features, and to teach
budding computer scientists the virtues of parsimony.
Now, Scheme happens also to be such a good general-purpose language (it has
to be, in order to meet the aforementioned purposes) that many people have
come to want to use it for mundane purposes, like getting work done. :-)
And that's fine if Scheme -- the "Languages should be..." Scheme -- happens
to meet their needs. But I think it's unfair for those people to screw up
Scheme's unique function in the world.
Saying that another way, Scheme is only a little bit better than CL for
getting work done, but it's /way/ better for teaching the big ideas. So the
marginal benefit of making Scheme just one more programming language is far
outweighed by the marginal cost of not having God's Programming Language
any more.
It has happened at least twice (Dylan and Guile) that someone thought Scheme
was an excellent core to be repurposed for something else, and so those
people took Scheme, modified it as they saw fit, /and renamed it/. I think
that's an excellent activity, good for the industrial users, good for us
academics, good for everyone. And it doesn't hurt Scheme at all.
R6RS hurt Scheme. A lot.
So, I want a steering committee that rejects the Obama-esque "language for
everyone" mentality. I want a Eugene V. Debs-esque "Scheme has a unique
role in the universe of programming languages" steering committee!
Of course I'm not going to get one; such candidates would be unelectable.
So, like the lefties who voted for Obama in the hope that he's really more
left-leaning than he lets on, I have to hope that the candidates who say
the R6RS /process/ was a mistake are using coded language for their secret
opinion that /R6RS/ was a mistake. :-)
Getting down to brass tacks, I think it's a realistic hope that the steering
committee might issue a statement along the lines of "Because of the extreme
divisive effect R6RS had on the Scheme community, the design process for R7RS
will start with R5RS as the baseline for discussion." People who want to
introduce R6RS features would then have to argue for them ab initio, using
the high-visibility public-involvement process that all the candidates are
promising. I'm confident that pretty much all the candidates would do a
reasonable job of involving us all in the process -- as someone else said,
we've learned that lesson. But it matters a lot what you use as a baseline
for that inclusive process.
> A small kernel, and optional addons that evolve independantly. Yet, addons
> should have *perfect* semantic and API match: it the (winning) API states
> "to remove an element, do (hash-set! h x #f) ", they one should not give a
> different semantic to this and, say, "(hash-delete h x)".
This is uncontroversial.
I think the sticking point may be something else: Maybe there's room for two
different hash-table libraries, based on different design aesthetics.
(Actually I doubt it'd come up for hash tables, but it likely would for
packages or records.) That's why a slim R7RS complemented by an /external/
collection of (something like) SRFIs might be preferable to a phone-book-size
R7RS with canonical designs for everything. You want to make it easy to port
code, but you also want to make it easy for researchers to explore new
approaches to designing. For /your/ purposes, you can say "this program
uses SRFI xxx style hash tables" and be sure the interface works as specified,
but someone else can still promulgate a competing approach.
> Consider the issue of veto power. In the R5RS process any single voting
> individual could veto features they didn't like. ...
> By contrast, with R6RS, it required a majority of editors - three out of
> the five - to veto a feature...
This is a good discussion to have!
I propose that R5RS be the baseline [I'd be happier to start even earlier,
but think that agreement on R5RS will be easiest to get], and that changes
require a 3/4 vote to approve (not to veto!), from an editoral board at
least the size and diversity of the one listed on the first page of R5RS.
Would candidates like to react to that proposal?
> Some of the candidates have made it quite clear how they feel: ANGRY.
> I don't want an angry committee.
> Whatever happens, that won't serve anyone well but for themselves.
I disagree with this, obviously, and disagree angrily :-) with the third
sentence, which I think insults candidates whom I respect.
Sometimes anger is an appropriate feeling. How do you feel about the
state of the world economy, for example? I'm angry about it.
> Scheme programmers are
> themselves dealing with text when they write their programs, and if the
> repertoire of characters allowed in a program is non-universal, the result
> is an unfair disadvantaging of people who use another repertoire natively.
Okay, I agree with this. (Although I also find Bear convincing about why
Unicode is a bad solution to that problem -- but I don't think we have the
power to fix that.)
My own personal problem with the way Unicode was handled in R6RS is that it
was the excuse for the imho disastrous shift to C-esque case-sensitive
identifiers. I followed the discussion about the non-invertibility of
conversions involving an Eszett, but talk about the tail wagging the dog!
What's needed is a way to specialize STRING-CI=? for different subsets of
Unicode, with the one we know and (some of us) love for the ASCII subset.
Maybe if you type in a symbol with an Eszett in it, Scheme will always
print it out as "ss." Not a problem.
_______________________________________________
r6rs-discuss mailing list
[email protected]
http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
