Losing the platonic ideal
http://www.biep.org
more important to me is what we may stand to lose: a specification of
the ideal convergence point for programming languages.
I for one would prefer Scheme to lose all its users to other languages
but develop ever more into the grand vision that all those other
languages move towards, than it becoming one more (possibly hugely
popular) drifting cute language.
Therefore I strongly favour the split: let the chrystal jewel slowly
and flawlessly grow, orbited by other Lisps that at some point covered
a copy of that jewel with whatever mud was in vogue at that point, and
now keep on adding mud in interesting ways - some of the mud may even
dissolve and, if of the right composition, contribute to the growth of
the jewel. But the central jewel will continue to be an inspiring
Platonic ideal for these orbiting balls of mud.
dr.tf...@googlemail.com
> I for one would prefer Scheme to lose all its users to other languages
> but develop ever more into the grand vision that all those other
> languages move towards, than it becoming one more (possibly hugely
> popular) drifting cute language.
May I presume that you belong to the group of languages designers and
implementors? I respect the interests of this group and understand
your point of view. But users, I feel, have other interests which are
not at all met by the strategy you propose.
Personally, I think technical, industry standards, like the RxRS
series, are poorly suited as a vehicle for "letting the chrystal jewel
slowly and flawlessly grow." Isn't this a *scientific* goal, better
achieved via the usual means of scientific communities, such as peer
reviewed journals? The advancement of scientific knowledge is a lofty
goal, which can take place at glacier speeds if necessary. Technical
standards, like the RxRS series of Scheme standards, are practical,
dirty, political compromises ... by necessity.
-Tom Gordon
http://www.biep.org
> But users, I feel, have other interests which are
> not at all met by the strategy you propose.
But aren't there other languages, including other Lisps, that suit
those interests? Why mutate an academic and teaching language (on the
way to being a properly-done industry language) if there is so much
choice around, including supersets of Scheme such as PLT? If a
platonic language is not what one wants, then Scheme-per-se is not
what one should use, I should think.
Why destroy a diamond if all you need is a pebble, and pebbles abound?
(By the way, my guess is that simply changing the name of the language
described by the report would already make many Scheme-lovers happy.)
dr.tf...@googlemail.com
> But aren't there other languages, including other Lisps, that suit
> those interests? Why mutate an academic and teaching language (on the
> way to being a properly-done industry language) if there is so much
> choice around, including supersets of Scheme such as PLT? If a
> platonic language is not what one wants, then Scheme-per-se is not
> what one should use, I should think.
> ...
No other programming language and no other Lisp standard meets my
needs as well as R6RS Scheme would. I can't speak for all users. PLT
Scheme meets my requirements quite well, but only if I make use of
many non-standard extensions. And while PLT is great, its
performance is not (yet) in the same league as some other Scheme
implementations (e.g. Gambit, Chez, Larceny), or some competing
programming languages, including Java and, e.g. SBCL Commmon Lisp.
So what would be really great, for me, is if at least one high
performance commercial Scheme implementation (i.e. Chez) and one high
performance Open Source implementation (Gambit and/or Larceny) would
be more compatible with PLT Scheme. I'm hoping that R6RS can serve to
help facilitate this convergence.
> (By the way, my guess is that simply changing the name of the language
> described by the report would already make many Scheme-lovers happy.)
It is less important to me that such an agreement be achieved via the
RxRS process. And I wouldn't mind them calling the language something
other than Scheme.
But if R6RS is ratified, as it looks like it will be, all such
alternative scenarios seem somewhat moot. "Scheme" will be come to be
identified with the R6RS standard and it is the nonconforming
implementations who *may* need to reconsider their names. But they
already have such names: "Gambit", "Bigloo", etc.. So what's the
problem?
-Tom Gordon
Nils M Holm
> (By the way, my guess is that simply changing the name of the language
> described by the report would already make many Scheme-lovers happy.)
This would certainly be the quickest fix. :-)
--
Nils M Holm <n m h @ t 3 x . o r g> -- http://t3x.org/nmh/
Pascal Costanza
> It is less important to me that such an agreement be achieved via the
> RxRS process. And I wouldn't mind them calling the language something
> other than Scheme.
>
> But if R6RS is ratified, as it looks like it will be, all such
> alternative scenarios seem somewhat moot. "Scheme" will be come to be
> identified with the R6RS standard and it is the nonconforming
> implementations who *may* need to reconsider their names. But they
> already have such names: "Gambit", "Bigloo", etc.. So what's the
> problem?
There is a lot of existing literature, both academic and non-academic,
that uses the name "Scheme" to refer to a language that had
comparatively only slight variations over the decades up to and
including R5RS. R6RS makes quite a number of incompatible changes (or so
it seems to me), so this alone potentially creates confusion. (Whenever
people say just "Scheme", what language do they actually mean? The
existing literature will not be retroactively updated, and many authors
will probably continue to use "Scheme" to refer to the old versions of
the language.)
For new literature (research papers, etc.), authors are, strictly
speaking, now required to explicitly specify what version of Scheme they
mean when they say "Scheme." Or such papers take a turn similar to the
one in the Java community, where you now have papers describing "XYZ for
Java-like languages", whatever that means, to avoid having to deal with
features included in newer JDK versions...
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/
Andrew Reilly
> It is less important to me that such an agreement be achieved via the
> RxRS process. And I wouldn't mind them calling the language something
> other than Scheme.
It *is* called something other than Scheme: "r6rs". "Scheme" can still
refer to the platonic ideal, just as "lisp" is not "ANSI Common Lisp".
Perhaps. I'm but a punter, with nought but a user's interest.
> But if R6RS is ratified, as it looks like it will be, all such
> alternative scenarios seem somewhat moot. "Scheme" will be come to be
> identified with the R6RS standard and it is the nonconforming
> implementations who *may* need to reconsider their names. But they
> already have such names: "Gambit", "Bigloo", etc..
Not necessarily. Scheme may still be the class name for all of the
existing implementations that identify themselves as scheme. R6RS may
well continue to be referred to as "R6RS". There have been uglier
language names. (PL/1, anyone?)
--
Andrew
Harold Ancell
<andrew-...@areilly.bpc-users.org> wrote:
>On Mon, 20 Aug 2007 08:06:04 -0700, dr.tfgordon wrote:
>> It is less important to me that such an agreement be achieved via
>> the RxRS process. And I wouldn't mind them calling the language
>> something other than Scheme.
>It *is* called something other than Scheme: "r6rs". "Scheme" can
>still refer to the platonic ideal, just as "lisp" is not "ANSI
>Common Lisp"....
I've been suggesting "The Language Formerly Known As Scheme".... ^_^
Given it's stark break with Scheme "as we know it", it will require a
unique name to avoid serious confusion. R6RS doesn't exactly roll off
the tongue, so something else is needed, maybe "Scheme Six", which has
the virtues of alliteration and cadence.
>> But if R6RS is ratified, as it looks like it will be, all such
>> alternative scenarios seem somewhat moot. "Scheme" will be come to
>> be identified with the R6RS standard and it is the nonconforming
>> implementations who *may* need to reconsider their names. But they
>> already have such names: "Gambit", "Bigloo", etc..
>Not necessarily. Scheme may still be the class name for all of the
>existing implementations that identify themselves as scheme. R6RS
>may well continue to be referred to as "R6RS". There have been
>uglier language names. (PL/1, anyone?)
Hey, perhaps it's nostalgia, perhaps it's a ... minimalist sort of
personal prose style, but I LIKE the name PL/1, perhaps more than any
other computer language name.
The name, not the language itself (although it's hardly awful for
its day if you strictly avoid defaults); per a quote attributed to
Donald Knuth: "The most important thing in the programming language
is the name. A language will not succeed without a good name. I have
recently invented a very good name and now I am looking for a
suitable language."
PL/1 has a stark IBM simplicity, Programming Language 1. Like DB2
or LISP.
Scheme is a different sort of name, to be judged by different
criteria, I'd say.
- Harold
dr.tf...@googlemail.com
wrote:
> Given it's stark break with Scheme "as we know it", it will require a
> unique name to avoid serious confusion. R6RS doesn't exactly roll off
> the tongue, so something else is needed, maybe "Scheme Six", which has
> the virtues of alliteration and cadence.
OK, I bite. This argument has been made a couple of times. But I'm
not yet convinced. I know there are some incompatible changes to R5RS
Scheme, but what percentage of existing R5RS Scheme programs are
likely to be affected? And even if they are affected, how difficult
will it be to port any R5RS Scheme program to R6RS in practice?
As you might guess, I suspect (but may be wrong), that only a very
small percentage of programs will be affected.
If I am write, then I don't see how any R5RS *user* of Scheme could
possibly become confused by continuing to call R6RS "Scheme".
Does anyone have a reasonable estimate of the percentage of affected,
existing R5RS programs? And please explain how you arrived at this
estimate.
-Tom Gordon
Nils M Holm
> On 21 Aug., 13:19, Harold Ancell <comp.lang.sch...@ancell-ent.com>
> wrote:
> > Given it's stark break with Scheme "as we know it", it will require a
> > unique name to avoid serious confusion. R6RS doesn't exactly roll off
> > the tongue, so something else is needed, maybe "Scheme Six", which has
> > the virtues of alliteration and cadence.
>
> OK, I bite. This argument has been made a couple of times. But I'm
> not yet convinced. I know there are some incompatible changes to R5RS
> Scheme, but what percentage of existing R5RS Scheme programs are
> likely to be affected? And even if they are affected, how difficult
> will it be to port any R5RS Scheme program to R6RS in practice?
I guess that to many people porting programs is not the major issue with
R5.97RS, although porting programs from R5RS to R5.97RS would be harder
than porting them from, say, R4RS to R5RS.
The gap between the two reports is a philosophical one. While R5RS
emphasizes elegance, the new report sacrifices everything that its
predecessor stood for in the name of pragmatism. This decision places
the "new" language in a completely different ballpark.
Such a decision should not be made light-heartedly. In fact, I think
it should not have to be made at all. If the gap is too big, either
go back to the drawing board or give the new thing a new name.
Ray Dillinger
> The gap between the two reports is a philosophical one. While R5RS
> emphasizes elegance, the new report sacrifices everything that its
> predecessor stood for in the name of pragmatism. This decision places
> the "new" language in a completely different ballpark.
>
> Such a decision should not be made light-heartedly. In fact, I think
> it should not have to be made at all. If the gap is too big, either
> go back to the drawing board or give the new thing a new name.
Yes.
That's right.
We find ourselves faced, not with an updated standard for
scheme, but with the first standard for some different
language informed by different ideals, which is threatening
to take the *name* away from scheme.
Bear
dr.tf...@googlemail.com
> That's right.
>
> We find ourselves faced, not with an updated standard for
> scheme, but with the first standard for some different
> language informed by different ideals, which is threatening
> to take the *name* away from scheme.
>
> Bear
[Second attempt. Please ignore the long-winded previous reply, which
I've tried to delete.]
You talk about threats to "take the name away from Scheme" as if
Scheme belonged only to those who voted No, rather than the
entire Scheme community.
And wasn't the decision to move from the idealistic to a more
pragmatic
approach to Scheme standards made at the time the RxRS procedure was
changed from the
consensus model to a majority vote model, long before the first draft
of R6RS?
-Tom Gordon
Joel J. Adamson
> It *is* called something other than Scheme: "r6rs". "Scheme" can still
> refer to the platonic ideal, just as "lisp" is not "ANSI Common Lisp".
> Perhaps. I'm but a punter, with nought but a user's interest.
Just to give you all the perspective of someone with less than one
year of experience with Scheme: to people who mainly work with other
languages, it's all Lisp. Within the Lisp hackers (for lack of a
better term) I communicate with "Scheme" is mainly used to distinguish
between Common Lisp and Scheme.
Are the proposed changes going to disturb that hierarchy? In other
words, even if there is Scheme (R5RS) and newScheme (R6RS), will they
both be Scheme enough to not be Common Lisp?
[side-note Steve Yegge[1] and others have mentioned a desire for "Common
Scheme:" a language with the simplicity and elegance of Scheme, but
with Common Lisp macros]
My take is that Scheme is so much more elegant and simple --
intellectually clear -- than other languages (Perl!) that whatever
small adjustments you're discussing making, I'll probably still be
happy. It could get a heck of a lot uglier and still be slicker than
Perl. Even Common Lisp is tempting ;)
Joel
Footnotes:
[1] http://steve.yegge.googlepages.com/the-emacs-problem
--
Joel J. Adamson
Biostatistician
Pediatric Psychopharmacology Research Unit
Massachusetts General Hospital
Boston, MA 02114
(617) 643-1432
(303) 880-3109
Harold Ancell
>On 21 Aug., 16:11, Ray Dillinger <b...@sonic.net> wrote:
>
>> We find ourselves faced, not with an updated standard for
>> scheme, but with the first standard for some different
>> language informed by different ideals, which is threatening
>> to take the *name* away from scheme.
>I'm sorry you, and apparently others, feel this way. But I find this
>point of view difficult to understand. It has been admitted that
>R5RS programs can easily be ported to R6RS. Presumably most of the
>classic Scheme textbooks can still be used, with little difficulty,
>to learn R6RS Scheme. And my favorite computer science book of all
>time, which introduced me to Scheme many years ago, Abelson and
>Sussman's Structure and Interpretation of Computer Programs, can
>still be used with R6RS Scheme.
That turns out not to be the case according to this very recent
mailing to the r6rs-d...@lists.r6rs.org list (some extra blank
lines and indentation added):
Date: Tue, 21 Aug 2007 04:19:16 -0700 (PDT)
From: Elf <e...@ephemeral.net>
Subject: Re: [r6rs-discuss] comment and vote (if allowed)
Message-ID:
<Pine.LNX.4.61.07...@tesseract.thetesseract.org>
On Tue, 21 Aug 2007, Keith Wright wrote:
>> From: Elf <e...@ephemeral.net>
[...]
>> Scheme is a beautiful language, and books like SICP can
>> help them appreciate that... but with R6RS, many of the
>> exercises will no longer work.
> Do you have a specific example of this? If true, it would be a
> very serious problem, but as I recall, SICP does not make use of
> much beyond the base language. I think the part of Scheme that
> occurs in SICP has not changed much. [ Comments on macros. ]
A quick browse through where SICP code will break (using v2 of
SICP):
1.1.4, compound procedures. explanation of compound vs primitive
procedures, pg 13.
1.1.7, newtons method. sqrt redefined, pg 24. possibly different
float semantics, pg 24, as well as in exercise 1.7, pg 25.
1.2.1, linear recursion and iteration. + redefined, exercise 1.9,
pg 36.
1.2.4, exponentiation. expt redefined, pg 44-45. even?
redefined, pg 45. * redefined, exercise 1.17, pg 46.
1.2.5, greatest common divisors. gcd redefined, pg 48-49.
1.3.3, procedures as general methods. sqrt redefined, pg 69.
1.3.4, procedures as returned values, sqrt redefined, pg 73, pg
75, pg 76.
2.1.3, what is meant by data?. entire section. pgs 90-93.
2.2.1, representing sequences. entire section, particularly pgs
101-103.
im stopping here because i dont want to be typing a table of
contents, and continuing to list where SICP breaks would become a
table of contents after that point, at least for chapter 2 and much
of 3. the immutability of imports robs SICP of explanation,
demonstration, and concept of building complex procedures from basic
building blocks.
I'll admit I didn't grasp the immutability problem when I read
R5.97RS, it would seem to be a very big one.
>Yet you insist R6RS is no longer worthy of the name "Scheme"....
Many do; me, I'd rather let that be decided over time. All I insist
upon is that a failure to give it a unique name (which can incorporate
the name Scheme) will cause unnecessary confusion. And that before
those of us who do not like it give it a pejorative name that sticks,
I'd suggest those of you do who do like it agree upon one you like.
>Your argument rests on philosophical differences. I do agree with
>you that there has been a shift in philosophy in going from R5S to
>R6RS, away from "Platonic" idealism to the more usual and pragmatic
>approach to programming language standards.
>But wasn't this shift in philosophy made at the time the decision was
>made to change the procedure for creating the next version of the
>standard, away from the consensus model?
Not that I remember, but I wasn't watching then. I assumed that the
Editorial Committee was charged with developing a compromise that
would
satisfy a much larger fraction of the community, or at least one that
wouldn't cause an open revolt of such a large fraction of it.
As my vote's explanation stated, I'm entire comfortable with the
core/library mechanism/standard libraries approach taken, I just think
it was not done correctly. The more I look, the more I read, the more
I think that, but I do not see it as inherent to the process.
>Wasn't the procedure changed precisely for the reason, to allow
>Scheme to evolve in a more pragmatic and timely way, giving up the
>"Platonic ideal" philosophy of prior versions of Scheme?
If R6RS was an "abandon the 'Platonic Ideal'" effort, that escaped my
notice until I looked at their output, and again, I don't see the
necessity, in either what was produced or the process.
>If so, this philosophy was abandoned long before even the first draft
>of R6RS was created. The time to complain about this issue was at
>the time the procedure was changed, not at this late stage, after the
>vote.
BZZZT! No---ignoring that I wasn't looking at the time---I will never
concede that my right to debate the truth of a point was lost at some
time past due to a process.
That is an entirely illegitimate argument, meant only to suppress
healthy debate.
>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.
>You talk about threats to "take the name away from Scheme" as if
>Scheme belonged only to those who voted No, rather than the entire
>Scheme community.
Now that is a good point, and is one reason I'm not trying to take the
name Scheme away from it, except in the sense that I do not believe
that R6RS can rightfully claim to now be the only one true Scheme.
Anyway, my point is simple: if you wish to avoid confusion, if you
wish to avoid the coining of a pejorative name that sticks for R6RS,
give it its own unique name now. Or to take a page from your own
book, you give up the right to complain once a new name takes root.
- Harold
Bakul Shah
May be we can just call it Common Scheme as it is recognizably
a Scheme and everyone can think of a meaning of "common" that
meets their particular point of view :-)
George Neuner
wrote:
>Maybe we can just call it Common Scheme as it is recognizably
>a Scheme and everyone can think of a meaning of "common" that
>meets their particular point of view :-)
com·mon (ko(m'?n)
adj. com·mon·er, com·mon·est
:
5. Not distinguished by superior or noteworthy characteristics;
average
6. Of no special quality; standard
7. Of mediocre or inferior quality; second-rate
:
American Heritage Dictionary
George
--
for email reply remove "/" from address
Brian Harvey
>On 20 Aug., 14:18, "http://www.biep.org" <goo...@biep.org> wrote:
>
>> I for one would prefer Scheme to lose all its users to other languages
>> but develop ever more into the grand vision that all those other
>> languages move towards, than it becoming one more (possibly hugely
>> popular) drifting cute language.
>
>May I presume that you belong to the group of languages designers and
>implementors? I respect the interests of this group and understand
>your point of view. But users, I feel, have other interests which are
>not at all met by the strategy you propose.
I'm not biep.org, but I have similar feelings (although I wouldn't have put it
in such stark terms), and I'm not a designer or implementor. I'm a teacher.
I teach computer science, and it's my great joy to be able to teach the
world's best computer science course (SICP) at Berkeley.
One of the high points of the course is the exploration of a Scheme
interpreter written in Scheme. As I tell my students, if you think about
what's the easiest possible assignment to write an interpreter for language A
in language B, the desired properties of the two languages are quite
different. Basically, you want language A to be /simple/ -- not many
features, very uniform notation, no gotchas. And you want language B to be
/versatile/, able to handle symbolic data well, supporting a variety of
programming paradigms, and so on. So you might guess that the easiest thing
would be to write a Basic interpreter in Ada, say.
But, as we all know, implementing Basic in Ada /isn't/ the easiest
possibility; it's implementing Scheme in Scheme. Isn't that counterintuitive?
It's a real eye-opener for students to figure this out.
To be sure, no matter what's in R6RS, we can still use a subset of Scheme to
implement a subset of Scheme. But it won't be such an eye-opener, if we have
to tell our students that we're only implementing a toy, and you can't have a
/real/ language without hairing it up with bells and whistles. I confess,
we're really doing that already, since the SICP Scheme interpreter leaves out
two significant features: macros and call/cc -- not coincidentally, the most
controversial and least well understood parts of the existing Scheme; a lot of
the c.l.s traffic is about quite smart people not quite getting how to make
something or other work using these two features.
It's in educating the young that this Platonic-ideal stuff really matters.
You may not think that's a good enough reason to forego your bells and
whistles. But the dichotomy between developers and users is too simple; I
exemplify a class of Scheme users -- my students and I bang hard on Scheme
every day -- different from the users you have in mind.
Brian Harvey
> I know there are some incompatible changes to R5RS
>Scheme, but what percentage of existing R5RS Scheme programs are
>likely to be affected? And even if they are affected, how difficult
>will it be to port any R5RS Scheme program to R6RS in practice?
Here's an excerpt from one of my homework solution files:
|(define (make-account init-amount)
| (let ((BALANCE INIT-AMOUNT)) ;;; This is the change.
| (define (withdraw amount)
| (set! balance (- balance amount)) balance)
| (define (deposit amount)
| (set! balance (+ balance amount)) balance)
| (define (dispatch msg)
| (cond
| ((eq? msg 'withdraw) withdraw)
| ((eq? msg 'deposit) deposit)))
| dispatch))
This program won't work in R6RS because INIT-AMOUNT will be a different
variable from init-amount.
This incompatibility is intellectually uninteresting, but it's a deal-killer
for me. Even if I found R6RS desirable in other ways, this convention of
using capital letters for changed code is such a help in teaching that I'm
going to have to keep our R5RS Scheme interpreter running forever. People
have suggested using different fonts and the like, but that doesn't work on
the class newsgroup -- and newsgroups are the right technology for this sort
of discussion; that's why we're having this conversation on comp.lang.scheme
and not http://scheme.blog.com or something.
I realize I didn't answer "what percentage," but my point is that this is a
particular kind of incompatibility that can't be answered by saying "that
would be easy to port," because it concerns a use of Scheme code other than
running it in Scheme, namely communicating about it to other human beings
quickly and easily.
Lynn Winebarger
wrote:
> Given it's stark break with Scheme "as we know it", it will require a
> unique name to avoid serious confusion. R6RS doesn't exactly roll off
> the tongue, so something else is needed, maybe "Scheme Six", which has
> the virtues of alliteration and cadence.
"Scheme [sic]"
Lynn
dr.tf...@googlemail.com
And I also agree that there are different classes of users, with
somewhat different interests.
> > To be sure, no matter what's in R6RS, we can still use a subset of Scheme to
> implement a subset of Scheme. But it won't be such an eye-opener, if we have
> to tell our students that we're only implementing a toy, and you can't have a
> /real/ language without hairing it up with bells and whistles.
But isn't this "ah ha", eye-opening, effect diminished when your
students leave Berkeley and don't find this "real" language being used
in practice, at least not much? I'd be the last person to call R5RS
Scheme a "toy", but isn't it's minimalism one of the reasons for its
lack of take-up by industry?
Wouldn't you like your students to have more opportunities to continue
to use Scheme after they complete your course?
Many educators don't use Scheme at all, but rather (some subset of)
Java, or whatever other language is currently popular in industry.
Perhaps this is ill-advised. But wouldn't a commercially successful
Scheme make it easier for more educators to elect to teach using
Scheme?
I have no doubt that you are right that R5RS is better for teaching
purposes than R6RS Scheme. But I don't see how this speaks against
ratifying R6RS, if that's what you are suggesting. Wouldn't it be
wonderful if students who learn R5RS Scheme had more opportunities to
use *any* version of Scheme in their later jobs, rather than having to
use Java, Python, etc?
-Tom Gordon
Brian Harvey
>Wouldn't you like your students to have more opportunities to continue
>to use Scheme after they complete your course?
Not especially. We tell our students that the tools they're going to use in
their professional careers haven't been invented yet, but that the big ideas
we're teaching them will remain valid and useful even if they're forced to
program in Javascript or something.
Your suggestion that a lot of Scheme programming jobs would make it easier to
teach Scheme misses the point, I think. We're not "teaching Scheme." I spend
about an hour teaching Scheme, and for the rest of the semester I /use/ Scheme
to teach /computer science/.
I mean, sure, /all else being equal/ I'd be happier if there were a lot of
Lisp jobs out there, but (1) all else isn't equal; the cost is that Scheme,
real Scheme, the "not by piling feature on top of feature" Scheme, won't run
on the next generation of computers because implementors will, in the long
run, implement the latest standard of whatever language is named Scheme; and
(2) it's no problem if most of the jobs are in Common Lisp instead of Scheme.
My students will be ready for those jobs.
IMHO the talk in this thread of having a multitude of languages called Scheme
is foolish. How many implementors are producing new implementations of
Java 1.5? Or Fortran II (that one lasted a good two or three years after
Fortran IV came along, but I think that must be the record)?
Oh, well -- I'm old enough so that I can retire before it becomes impossible
to run Scheme on our instructional computers. :-)
dr.tf...@googlemail.com
> Not especially. We tell our students that the tools they're going to use in
> their professional careers haven't been invented yet, but that the big ideas
> we're teaching them will remain valid and useful even if they're forced to
> program in Javascript or something.
The sad thing for me is that good tools have been invented, long ago,
that just haven't
succeeded in the marketplace yet. There is reason to think there is a
new window
of opportunity which R6RS can take advantage of to help disseminate
these tools.
>
> Your suggestion that a lot of Scheme programming jobs would make it easier to
> teach Scheme misses the point, I think. We're not "teaching Scheme." I spend
> about an hour teaching Scheme, and for the rest of the semester I /use/ Scheme
> to teach /computer science/.
I tried to be careful to make this distinction. I wrote: "Many
educators don't use
Scheme at all ... But wouldn't a commercially successful
Scheme make it easier for more educators to elect to teach using
Scheme?" Note that I speak only of using Scheme to teach, not
teaching Scheme.
> I mean, sure, /all else being equal/ I'd be happier if there were a lot of
> Lisp jobs out there, but (1) all else isn't equal; the cost is that Scheme,
> real Scheme, the "not by piling feature on top of feature" Scheme, won't run
> on the next generation of computers because implementors will, in the long
> run, implement the latest standard of whatever language is named Scheme;
I think you are being too pessimistic, honestly. Wouldn't a R6RS
library defining
some suitable subset for teaching purposes, close to R5RS Scheme, meet
your needs?
Something like the R5RS "Teachpack" in PLT Scheme?
Your pedagogical "eye-opening" goal, of showing students how to
implement an evaluator
for a "real" language in Scheme seems somewhat illusionary to me, in
any case. What makes
a language "real"? An implementation? A standard? Practical
significance in industry?
Is there any real, existing implementation of Scheme out there which
implements *only*
R5RS Scheme? Isn't R5RS, in reality, only a subset of all real
implementations?
> (2) it's no problem if most of the jobs are in Common Lisp instead of Scheme.
> My students will be ready for those jobs.
I'll probably get flamed for this, but as far as I can tell Common
Lisp has largely
failed in the marketplace and I see no evidence that this is going to
change anytime
soon. Or course it isn't at all clear that R6RS Scheme can succeed
where Common Lisp has
failed, but I believe we at least have a chance, if the Scheme
community
makes a good faith effort to work together to make it happen.
> IMHO the talk in this thread of having a multitude of languages called Scheme
> is foolish. How many implementors are producing new implementations of
> Java 1.5? Or Fortran II (that one lasted a good two or three years after
> Fortran IV came along, but I think that must be the record)?
I agree fully. When I spoke of using R5RS Scheme for teaching
purposes, I didn't
mean to suggest that this couldn't be done using an implementation
which also supports
R6RS. I'm a PLT Scheme user, mainly, and keep thinking of PLT's
support for several
languages and "teachpacks".
> Oh, well -- I'm old enough so that I can retire before it becomes impossible
> to run Scheme on our instructional computers. :-)
I'm also a Mac OS X user, which can still run all the Unix programs
I've ever used.
Again, I think you are being too pessimistic. R6RS is not a reason to
despair, but
a reason to hope.
-Tom Gordon
David Rush
On Aug 22, 9:02 am, dr.tfgor...@googlemail.com wrote:
> On 22 Aug., 08:34, b...@cs.berkeley.edu (Brian Harvey) wrote:
>
> > Not especially. We tell our students that the tools they're going to use in
> > their professional careers haven't been invented yet, but that the big ideas
> > we're teaching them will remain valid and useful even if they're forced to
> > program in Javascript or something.
>
> The sad thing for me is that good tools have been invented, long ago,
> that just haven't succeeded in the marketplace yet.
There's many reasons for that:
http://groups.google.com/group/comp.lang.scheme/msg/886d41141e98d4ec
http://groups.google.com/group/comp.lang.scheme/msg/cd06922d6c71ac6d
outline a few of my own personal moments of rage against the machine.
> There is reason to think there is new window
> of opportunity which R6RS can take advantage of to help disseminate
> these tools.
No. There really isn't. The requirements of corporate software
development are antithetical to high-quality engineering. The
situation is not entirely different from the construction of the
railroads in the US during the 19th century. The engineering was done
in such a hurry that the bridges regularly fell down. In fact, it was
so bad that Jules Verne used the untrustworthiness of the American
railroads as one of Phileas Fogg's obstacles to overcome in _Around
the World in 80 Days_.
My point being that 'cost-effective' engineering is not the same as
'high-quality' engineering. I prefer to do high-quality work. Scheme
is a fairly high-quality language (the quality tradeoffs w/rt
engineering cost fall in lovely places for me). But the dominant cost
is labor for which there are far more cheap, half-trained puppies from
'Technical Institutes' available for hire. And those people want 'Do
What I Mean' syntax and turn to Perl and Ruby and are willing to debug
like ants by just trying random solutions and code snippets farmed
from the internet until they find something that does the job.
And the really depressing thing is that it will *never* change. I am
not teaching my children my trade. The fun has gone out of it
entirely. The software industry is turning into an industrial
revolution sweatshop full of children (immature minds) laboring 16
hour days. And the management literature - instead of examining how to
adequately budget for creative processes - is full of how to convince
developers that they actually enjoy the abuse they receive!
> > Your suggestion that a lot of Scheme programming jobs would make it easier to
> > teach Scheme misses the point, I think. We're not "teaching Scheme." I spend
> > about an hour teaching Scheme, and for the rest of the semester I /use/ Scheme
> > to teach /computer science/.
YES YES YES!!! Go Brian!
> But wouldn't a commercially successful
> Scheme make it easier for more educators to elect to teach using
> Scheme?"
Only for about the next year. Then there will be a new buzzword
clamoring for compliance. Trying to surf the market wave is a losing
strategy.
> I think you are being too pessimistic, honestly. Wouldn't a R6RS
> library defining some suitable subset for teaching purposes, close
> to R5RS Scheme, meet your needs?
This is the *essence* of most of the 'no' votes. The R5.97RS is not
factored correctly to make that possible. It's that simple. That's why
I keep hoping that sense will break out somewhere. And it's not just
important for education, either.
david rush
--
http://cyber-rush.org/drr/scheme <- a very messy construction^Wweb site
Aubrey Jaffer
> On 22 Aug., 08:34, b...@cs.berkeley.edu (Brian Harvey) wrote:
> ...
> > (2) it's no problem if most of the jobs are in Common Lisp instead
> > of Scheme. My students will be ready for those jobs.
>
> I'll probably get flamed for this, but as far as I can tell Common
> Lisp has largely failed in the marketplace and I see no evidence that
> this is going to change anytime soon. Or course it isn't at all clear
> that R6RS Scheme can succeed where Common Lisp has failed,
Not being clear is an understatement. R6RS looks to be a competitor of
Common-Lisp, and a poor one.
Its macros are much more complicated than DEFMACRO; its module system is
more complicated; it lacks arrays and read-macros; and it loses claim to
being a small language. Just what are R6RS' selling points over
Common-Lisp?
> but I believe we at least have a chance, if the Scheme community makes
> a good faith effort to work together to make it happen.
The editors made no effort to accomodate SCM or SLIB in R6RS. So I am
not inclined to make efforts on behalf of R6RS.
Abdulaziz Ghuloum
> Its macros are much more complicated than DEFMACRO; its module system is
> more complicated; it lacks arrays and read-macros; and it loses claim to
> being a small language.
Yeah, well, you know, that's just, like, your opinion, man.
Aziz,,,
Harold Ancell
<aghu...@cee.ess.dot.indiana.dot.edu> wrote:
>Aubrey Jaffer wrote [ comparing R5.97RS to Common Lisp ]:
Indeed. As Will Clinger on r6rs-d...@lists.r6rs.org is
pointing out with increasing vigor, "the people have spoken".
Frankly, as a devil I know well, Common Lisp looks rather
attractive compared to the putative benefits of R5.97RS. Examine
their value propositions:
Common Lisp is the end result of a quarter century of LISP
invention and elaboration at MIT ending with Lisp Machine Lisp,
plus various minor details like lexical scoping (from guess
where) added. (I'm sure there are other contributions I'm
slighting due to unfamiliarity, but to a Lisp Machine programmer,
except for the lexical scoping I'd already gotten from Scheme, it
was a *very* small jump.)
Sure, it's rather in your face with the multiple contributing
dialects put into a blender and legacy features from its very
long history (can a language be "industrial strength" without
some form of GOTO? (hey, we have call/cc)), anyone who knows
Scheme would be hard pressed to call it a *beautiful* language---
but it's a damned good one in the scale of things. If you forgot
Scheme existed for a moment, how many of you would prefer a
non-LISP over Common Lisp?
And it has multiple solid and healthy free and commercial
implementations, probably more solid and highly polished
collateral material to support it even if none can reach the
level of SICP (by definition :-), what would seen to be a larger
community, and two real world decimillion dollar success stories
(Yahoo Stores and ITA).
Against that, what does The Language Formerly Known As Scheme
offer? We have yet to see a full implementation, and there are
substantive questions if that is particularly practical. Yes, I
suppose when large enough jet engines are strapped on this pig,
it will fly after a fashion, but I'm not expecting to enjoy the
results.
Given the choices of Scheme As We Know it, Common Lisp, and
R5.97RS as can reasonably we expect it to be, it's not at all
difficult to rank them in order of attractiveness.
- Harold
David Rush
wrote:
> If you forgot
> Scheme existed for a moment, how many of you would prefer a
> non-LISP over Common Lisp?
*raises hand*
SML. Without a moment's hesitation. In fact, I encountered SML
*before* I encountered Scheme through Peter Lee's thesis paper on
_Realistic Compiler Generation_ and thought (as I still do) that it
was the singularly most readable programming language I had ever seen.
Having said that, I find that latently typed semantics is far more
friendly (read *way* faster) to the kind of incremental (and
frequently unfunded) development work I have done in industry and so I
*really* like Scheme.
Or does SML also count as a Scheme? I can never quite tell really ;)
david rush
--
especially since SML/NJ has call/cc ...
Nils M Holm
> On Aug 26, 12:10 pm, Harold Ancell <comp.lang.sch...@ancell-ent.com>
> wrote:
> > If you forgot
> > Scheme existed for a moment, how many of you would prefer a
> > non-LISP over Common Lisp?
>
> *raises hand*
>
> SML. Without a moment's hesitation.
I started brushing up my SML skills as soon as I saw where R6RS
was headed. Just in case.
Rainer Joswig
Harold Ancell <comp.lan...@ancell-ent.com> wrote:
> On Sat, 25 Aug 2007 19:33:23 -0400, Abdulaziz Ghuloum
> <aghu...@cee.ess.dot.indiana.dot.edu> wrote:
>
> >Aubrey Jaffer wrote [ comparing R5.97RS to Common Lisp ]:
>
> >> Its macros are much more complicated than DEFMACRO; its module
> >> system is more complicated; it lacks arrays and read-macros;
> >> and it loses claim to being a small language.
>
> >Yeah, well, you know, that's just, like, your opinion, man.
>
> Indeed. As Will Clinger on r6rs-d...@lists.r6rs.org is
> pointing out with increasing vigor, "the people have spoken".
>
> Frankly, as a devil I know well, Common Lisp looks rather
> attractive compared to the putative benefits of R5.97RS. Examine
> their value propositions:
>
> Common Lisp is the end result of a quarter century of LISP
> invention and elaboration at MIT ending with Lisp Machine Lisp,
> plus various minor details like lexical scoping (from guess
> where) added. (I'm sure there are other contributions I'm
> slighting due to unfamiliarity, but to a Lisp Machine programmer,
> except for the lexical scoping I'd already gotten from Scheme, it
> was a *very* small jump.)
Common Lisp was in many ways a 'simplification' from
Lisp Machine Lisp plus some new stuff (CLOS). Still
CLOS was based on earlier experience - mostly
LOOPS and Flavors - developed in parallel with a
reference implementation.
From reading a bit through the new draft report, the library
feature seem to be especially prominent. Is that
based on prior experience (asking, I have no idea)?
Just from looking at it I find it particular unattractive.
* it seems to non-extensible. Say you want to have
a standard documentation string. Where would you
put it?
* nothing is said about loading/unloading/finding/extending
libraries?
* library code is enclosed in a single form
* say, I have a bug in some library form. How do
I find it? edit it? replace it? reload it?
reload depending libraries?
andreu...@yahoo.com
> From reading a bit through the new draft report, the library
> feature seem to be especially prominent. Is that
> based on prior experience (asking, I have no idea)?
Yes. It was mainly designed by Matthew Flatt and Kent Dybvig
based on their experience in MzScheme and Chez. You may read
their publications online - especially Matthew Flatt's on macro
phasing is relevant.
> * nothing is said about loading/unloading/finding/extending
> libraries?
A lot is said. Look for "instantiating" and "visiting".
Admittedly, the section on phases end by saying that
implementations are free to largely ignore the model
described in that section. The result is that users
should basically not rely on library state in a way
that depends on details of the instantiation model.
That is probably easier said than done, and in practice
the best way to write a "portable" library will probably be
to test your library individually on each implementation
(which yes, defeats the purpose of a standard library
system somewhat).
> * library code is enclosed in a single form
It is easy to write an "include-file" macro so
you can keep the body of your code in a separate
file from the library-header stuff.
> * say, I have a bug in some library form. How do
> I find it? edit it? replace it? reload it?
> reload depending libraries?
Are you complaining about the feature creep of R6RS
or are you asking for more features?
Regards
Andre
Rainer Joswig
andreu...@yahoo.com wrote:
> On Aug 26, 9:27 am, Rainer Joswig <jos...@lisp.de> wrote:
>
> > From reading a bit through the new draft report, the library
> > feature seem to be especially prominent. Is that
> > based on prior experience (asking, I have no idea)?
>
> Yes. It was mainly designed by Matthew Flatt and Kent Dybvig
> based on their experience in MzScheme and Chez. You may read
> their publications online - especially Matthew Flatt's on macro
> phasing is relevant.
So MzScheme and Chez are already using this kind of library
approach?
> > * nothing is said about loading/unloading/finding/extending
> > libraries?
>
> A lot is said. Look for "instantiating" and "visiting".
But that is all behind the scenes.
> Admittedly, the section on phases end by saying that
> implementations are free to largely ignore the model
> described in that section. The result is that users
> should basically not rely on library state in a way
> that depends on details of the instantiation model.
> That is probably easier said than done, and in practice
> the best way to write a "portable" library will probably be
> to test your library individually on each implementation
> (which yes, defeats the purpose of a standard library
> system somewhat).
>
> > * library code is enclosed in a single form
>
> It is easy to write an "include-file" macro so
> you can keep the body of your code in a separate
> file from the library-header stuff.
Why would that need to be a macro?
>
> > * say, I have a bug in some library form. How do
> > I find it? edit it? replace it? reload it?
> > reload depending libraries?
>
> Are you complaining about the feature creep of R6RS
> or are you asking for more features?
I'm asking how one should work with libraries in
an interactive environment and what the interface
is for that.
> Regards
> Andre
andreu...@yahoo.com
> So MzScheme and Chez are already using this kind of library
> approach?
Yes.
> > It is easy to write an "include-file" macro so
> > you can keep the body of your code in a separate
> > file from the library-header stuff.
>
> Why would that need to be a macro?
So that it can expand to an R6RS library body at
expand-time. Look for "include" at
http://www.scheme.com/tspl3/syntax.html#./syntax:h3
> I'm asking how one should work with libraries in
> an interactive environment and what the interface
> is for that.
That was considered out of scope for R6RS. Properly
so, I think. There are many valid approaches to
development environments (some of which are not
even interactive), compilation, linking, loading, etc.
Enlarging the language by fixing these meta-details
would be in conflict with having a minimal core.
I would personally like to see R6RS reduced,
not extended.
Andre
Ray Dillinger
> On Sat, 25 Aug 2007 19:33:23 -0400, Abdulaziz Ghuloum
> <aghu...@cee.ess.dot.indiana.dot.edu> wrote:
>
>
>>Aubrey Jaffer wrote [ comparing R5.97RS to Common Lisp ]:
>
>
>>>Its macros are much more complicated than DEFMACRO; its module
>>>system is more complicated; it lacks arrays and read-macros;
>>>and it loses claim to being a small language.
>
>
>>Yeah, well, you know, that's just, like, your opinion, man.
>
>
> Indeed. As Will Clinger on r6rs-d...@lists.r6rs.org is
> pointing out with increasing vigor, "the people have spoken".
If that is true, then it confirms something I have increasingly
suspected. Sometime in the middle of July, my mailing address
was apparently dropped from the list.
Has anyone else seen complete silence there since mid-July?
Maybe something happened to the server config?
> Common Lisp is the end result of a quarter century of LISP
> invention and elaboration at MIT ending with Lisp Machine Lisp,
> plus various minor details like lexical scoping (from guess
> where) added. (I'm sure there are other contributions I'm
> slighting due to unfamiliarity, but to a Lisp Machine programmer,
> except for the lexical scoping I'd already gotten from Scheme, it
> was a *very* small jump.)
Indeed. CL is definitely a better "Big Lisp" than R5.97RS;
CL has always been a better "Big Lisp" than Scheme. And the
people who wanted the virtues of a "Big Lisp" have already
been over there for ages.
Bear
Anton van Straaten
> If that is true, then it confirms something I have increasingly
> suspected. Sometime in the middle of July, my mailing address
> was apparently dropped from the list.
>
> Has anyone else seen complete silence there since mid-July?
> Maybe something happened to the server config?
I'm not aware of any problems. Your email is still on the list, and I
don't see any bounce messages. You might check that the messages aren't
being flagged as spam somewhere on your end, e.g. see
http://sonic.net/features/antispam/
Archives are at: http://lists.r6rs.org/pipermail/r6rs-discuss/
Anton
Harold Ancell
wrote:
>On Aug 26, 12:10 pm, Harold Ancell <comp.lang.sch...@ancell-ent.com>
>wrote:
>> If you forgot Scheme existed for a moment, how many of you
>> would prefer a non-LISP over Common Lisp?
>*raises hand*
>SML. Without a moment's hesitation. In fact, I encountered SML
>*before* I encountered Scheme through Peter Lee's thesis paper
>on _Realistic Compiler Generation_ and thought (as I still do)
>that it was the singularly most readable programming language I
>had ever seen.
I expected answers of this nature, and it would certainly be
foolish for the Scheme community to ignore the other interesting
functional programming languages out there, including the one
with significant industry acceptance (Erlang).
Perhaps I'm a dinosaur, I know I'm currently lazy and I certainly
haven't given it a fair try, but its pattern matching syntax just
does not look like something I can wrap my head around. May have
something to do with my being more a scientist who programs that
a real CS type.
And there's just something I really like about dead simple
syntax. Purely because of order of exposure, C was the first
language I fell in love with (then LISP). I still like C a lot
for the niches in which it is appropriate (like a Scheme
compiler's target :-). And pretty much by definition LISPs and
Scheme particular have the most simple syntax of all (which is an
argument against the significant increase in syntax that R5.97RS
adds to the language).
>Having said that, I find that latently typed semantics is far
>more friendly (read *way* faster) to the kind of incremental
>(and frequently unfunded) development work I have done in
>industry and so I *really* like Scheme.
Well, manifest typing that is inferred would seem like it might
be the best of both worlds, but I haven't tried it, so I'll take
your word for it. Both latent and manifest typing have some very
useful properties, but as I have experienced each, latent typing
is much faster, and is more appropriate for the sorts of
programming I expect to be doing in the future.
>Or does SML also count as a Scheme? I can never quite tell
>really ;)
Now that's a good question. Getting back to the title of this
thread, what are some of the really essential aspects of this
Platonic Ideal of Scheme As We Know It?
Here I'm just throwing out thoughts, I don't have enough exposure
to languages like SML to make any sort of judgement:
Latent typing, perhaps not.
Lexical scoping would seem to be just common sense, I suspect
it's mostly an artifact of when LISP was invented that it had
dynamic scoping for so long.
While it took the rest of the world quite a bit longer to realize
it (and in all fairness, for computing power and capacity to
catch up in many but still not all domains), the same can be said
for unlimited extent (GC).
First class everything, definitely, but e.g. merely bring call/cc
forward is not enough, it's in the background everywhere. Again,
little more than "common sense", or at least an attitude that
in many domains programmers can be entrusted with incisive tools.
Meta[fill in the blank]...: How essential is reverse Polish
notation S-expression syntax? If you can't write a metacircular
evaluator in it, is it Scheme? Or to quote the first page of
SICP 2nd edition, chapter 4 (Metalinguistic Abstraction):
It is no exaggeration to regard this as the most fundamental
idea in programming:
The evaluator, which determines the meaning of expressions
in a programming language, is just another program.
The ability to write new languages at all levels, the ultimate
expression of "LISP is a ball of mud" as Joel Moses put it, would
seem to me to indeed be utterly essential. Dead simple syntax,
"the world's most powerful macros", etc. etc. all fall out of
this. (And to think this is an historical accident,
S-expressions were supposed to be replaced in due course....)
How much can you do this in e.g. SML?
Javascript is said to be a Scheme with non-LISP syntax and
various weird and sometimes useful added or different features;
where does it fit into this?
- Harold
Klaus Schilling
> languages, it's all Lisp. Within the Lisp hackers (for lack of a
> better term) I communicate with "Scheme" is mainly used to distinguish
> between Common Lisp and Scheme.
>
but what about Franz Lisp, McCarthy Lisp, Goo, Arc, Reflisp, Emacs Lisp,
Rep, Xlisp, Eulisp, Autolisp, Interlisp, Q, PCLisp, Lush,
and on and on it goes ?
Klaus Schilling
Joel J. Adamson
Well, I've seen people use those names too...my point was that if you
read Steve Yegge's blog, most of the things he says about Lisp in
comparison to other languages or families of languages apply equally
to Common Lisp or Scheme.
I'll give you another few examples: I'm talking with my friend who is
a Java hacker (I mean, that's what she does for a living, whereas my
obsession with Lisp is purely for intellectual satisfaction). I say
"I'm thinking about learning some Lisp" and she says "Yeah Lisp is
cool; if you're thinking about a dialect, Scheme is good for
learning." I say "duh." She had to establish the category of Lisp,
before she clarified that she was talking about Scheme.
*On the other hand* I'm talking to a guy who works at a company that
develops Lisp software: when he says "Lisp" I know he means Common
Lisp, especially because most of our conversations deal with the
distinctions between Common Lisp and Scheme.
And for the third contender, when I read about Emacs Lisp, most of the
time it's called "Emacs Lisp" rather than just "Lisp."
Joel