[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: LFM + LFSP = LFE?
Date: Fri, 13 Jun 2003 18:34:40 -0700
X-Authentication-Warning: orchestra.cs.caltech.edu: mvanier set sender to
email@example.com using -f
From: Michael Vanier <firstname.lastname@example.org>
Subject: Re: LFM + LFSP = LFE?
My understanding is that there have been a number of efforts over the years
to put a more "conventional" syntax on top of scheme or lisp. Of course,
they don't get far because after a while, people prefer the s-expression
syntax (which is more powerful once you factor in macros etc.). However,
this approach might be worth trying again. Perhaps this would be one way
to give scheme the LFE-nature. Does DrScheme have anything like this?
Parenthetically (pun intended), the guile scheme people did this a few
years ago but abandoned the effort.
I can't resist quoting this snippet from
Steele, Guy L., Jr. and Gabriel, Richard P. "The Evolution of Lisp."
In Bergin, Thomas J., Jr. and Gibson, Richard G., Jr. (eds.),
History of Programming Languages, ACM Press, New York, 1996, 233-330.
on the subject of "conventional" syntax for Lisp:
The idea of introducing Algol-like syntax into Lisp keeps popping up
and has seldom failed to create enormous controversy between those who
find the universal use of S-expressions a technical advantage (and
don't mind the admitted relative clumsiness of S-expressions for
numerical expressions) and those who are certain that algebraic syntax
is more concise, more convenient, or even more "natural" (whatever
that may mean, considering that all these notations are artificial).
We conjecture that Algol-style syntax has not really caught on in the
Lisp community as a whole for two reasons. First, there are not
enough special symbols to go around. When your domain of discourse is
limited to numbers or characters, there are only so many operations of
interest, and it is not difficult to assign one special character to
each and be done with it. But Lisp has a much richer domain of
discourse, and a Lisp programmer often approaches an application as
yet another exercise in language design; the style typically involves
designing new data structures and new functions to operate on
them---perhaps dozens or hundreds---and it's just too hard to invent
that many distinct symbols (though the APL community certainly has
tried). Ultimately one must always fall back on a general function-call
notation; it's just that Lisp programmers don't wait until they fail.
Second, and perhaps more important, Algol-style syntax makes programs
look less like the data structures used to represent them. In a
culture where the ability to manipulate representations of programs
is a central paradigm, a notation that distances the appearance of
a program from the appearance of its representation as data is not
likely to be warmly received (and this was, and is, one of the
principal objections to the inclusion of LOOP in Common Lisp).
On the other hand, precisely because Lisp makes it easy to play
with program representations, it is always easy for the novice to
experiment with alternative notations. Therefore we expect future
generations of Lisp programmers to continue to reinvent Algol-style
syntax for Lisp, over and over and over again, and we are equally
confident that they will continue, after an initial period of
infatuation, to reject it. (Perhaps this process should be regarded
as a rite of passage for Lisp hackers.)