Home > Archive > Lisp > April 2004 > Why flet wins, was Re: scheme seems neater
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Why flet wins, was Re: scheme seems neater
|
|
| Jeff Dalton 2004-04-07, 8:32 pm |
| Sunnan <sunnan@handgranat.org> writes:
>
> It's a di vantage for implementors and for learners of the
> language. It's brain clutter.
But natural languages are quite cluttered. It's far from clear that
all "clutter" creates problems for learning.
Natural languages also have a lot of redundancy, which tends
to make it easier to get the intended meaning.
Common Lisp is more like a natural language than Scheme is.
They very things that seem bad about Common Lisp to someone
wanting a maximally rational design are, arguably, good.
Or at least harmless, low cost. Otherwise, they'd have
been eliminated somewhere along the way. Probably.
Languages that evolve, that are shaped by use and history,
become adapted to human needs. They can be better adapted
than the language you get from a rational design.
From the rationalist point of view, Common Lisp's namespace
decisions may seem arbitrary. Why have those particular ones?
Why not a namespace per type? What is the argument that shows
Lisp-2 is best?
In fact, a namespace per type is not a completely mad idea.
In mathematics, a number of different alphabets and fonts
are used, so that it's usually clear what kind of thing
each symbol refers to.
Sometimes, the conventions change. For example, in model
theory, strange-looking German script letters were used
for models. But after (quite) a while, model theorists
started using ... (wait for it) ... M. And other ordinary
capital letters.
(This is, for most people, easier to read.)
So, in effect, mathematicians use lots of namespaces. That
they use A for something doesn't stop them from using
alpha, or lower-case a, or bold A, for another.
But programming languages haven't gone that way, for a
variety of reasons. Probably, that's a good decision.
That doesn't mean that anyone has an argument that shows
it is absolutely the right decision.
Note that programmers often create namespaces by convention.
In Java, class names begin with a capital, method names to
not. So you can have a class and method of the same name
(modulo case).
A naming convention, perhaps enforced by the language, is an
alternative to having separate function and value namespaces.
In Common Lisp, we have the *-name convention for specials,
which helps keep them from interfering with ordinary variables.
So there are many possibilities, and Common Lisp is at a
point in this space. I think it's likely that the combination
of design and history that led to current Common Lisp has
placed it at a not-too-bad point, regardless of how arbitrary
that position seems from maximally rational point of view.
-- jd
| |
| Cameron MacKinnon 2004-04-08, 12:32 am |
| Jeff Dalton wrote:
> But natural languages are quite cluttered. It's far from clear that
> all "clutter" creates problems for learning.
>
> Natural languages also have a lot of redundancy, which tends
> to make it easier to get the intended meaning.
Speaking face to face, expressions and body language help communication.
On the telephone, voice pitch and modulation give clues. Handwriting
offers a variety of modes of expression. Typesetting allows only font,
size, bold, italic and underscoring. Computer code typically allows none
of the above. And as the expressive possibilities decrease in each of
the above, the amount of formality considered appropriate to the medium
(indeed, required) increases.
> Common Lisp is more like a natural language than Scheme is.
oh i #'agree completely
> They very things that seem bad about Common Lisp to someone
> wanting a maximally rational design are, arguably, good.
> Or at least harmless, low cost. Otherwise, they'd have
> been eliminated somewhere along the way. Probably.
I can't agree with the eliminated along the way bit. Things almost never
get eliminated from computer languages, because the "our legacy code
would break with the new tools" whiners outvote the rationalization crowd.
> In fact, a namespace per type is not a completely mad idea.
See Perl.
> Sometimes, the [math] conventions change. For example, in model
> theory, strange-looking German script letters were used
> for models. But after (quite) a while, model theorists
> started using ... (wait for it) ... M. And other ordinary
> capital letters.
I don't know about model theory, but some mathematicians just change
their notation because they're sick of fighting with their
computer-typesetting vendors, no?
In the Lisp world, millions of keystrokes have been wasted because
Church was too inconsiderate to pick mu, nu, xi or pi. And other
computer languages, APL aside, are stuck choosing their symbols from the
completely irrational quasi-standard set inherited from typewriters.
So in the computer world, a lot of the freedom for language evolution
has been artificially circumscribed by legacy peripheral devices and
legacy code. I suppose the newest human languages (text messaging)
suffer from similar considerations.
> Note that programmers often create namespaces by convention.
> In Java, class names begin with a capital, method names to
> not. So you can have a class and method of the same name
> (modulo case).
Now there's an idea! Steal from German. Use initial caps for functions.
Emacs could be made smart enough to autocapitalize the car of unquoted
lists. SLIME could maybe help Emacs autocapitalize functional arguments.
Good for typing, good for legibility, and no more #'. Of course, all
those people still using uppercase-only terminals would be out of luck. :-(
--
Cameron MacKinnon
Toronto, Canada
| |
| Dave Roberts 2004-04-08, 12:32 am |
| Jeff Dalton wrote:
> Sunnan <sunnan@handgranat.org> writes:
>
>
> But natural languages are quite cluttered. It's far from clear that
> all "clutter" creates problems for learning.
>
> Natural languages also have a lot of redundancy, which tends
> to make it easier to get the intended meaning.
Don't confuse redundancy with this issue. Yes, natural languages have lots
of redundancy. There are many ways to say the same thing. That is not the
case here. The distinction between LET and FLET is not subject to my
personal mood at the time and whether I would suddenly choose one versus
the other. They are not redundant. They are different. The language forces
me to choose between LET and FLET depending on what I'm trying to
accomplish. Thus, they are "redundant" in the same way that "black" and
"white" are redundant in English... ;-)
> Common Lisp is more like a natural language than Scheme is.
It's more "real world" than scheme is, but that's because, like languages,
it's more the result of multiple variations of a common "mother tongue"
intermingling over the years. Put another way, CL evolved whereas Scheme
was designed.
> They very things that seem bad about Common Lisp to someone
> wanting a maximally rational design are, arguably, good.
> Or at least harmless, low cost. Otherwise, they'd have
> been eliminated somewhere along the way. Probably.
No, because CL was specifically created to bring together diverging Lisp
dialects (as I understand it; I'm a newbie and wasn't there ;-). If that
was the stated goal, then the reality is that CL actively sought to unify
(in the sense of creating a union) all the various features that many Lisp
dialects had created. This is exactly the opposite of paring things down to
the simplest possible model. Now that it's standardized, the baggage must
be maintained. Now, lest you think I'm slighting CL, I'm not. You can argue
quite well that CL's diversity is the result of real-world needs and thus
reflects a more broad set of concerns.
> Languages that evolve, that are shaped by use and history,
> become adapted to human needs. They can be better adapted
> than the language you get from a rational design.
Yes, exactly.
[snip...]
> So there are many possibilities, and Common Lisp is at a
> point in this space. I think it's likely that the combination
> of design and history that led to current Common Lisp has
> placed it at a not-too-bad point, regardless of how arbitrary
> that position seems from maximally rational point of view.
Right. I agree with that. As a newbie, I went through the "which dialect of
Lisp should I learn?" question. I have a soft spot for Scheme because I got
a small dosage of that first and I truthfully love simple things. Scheme is
very simple. I find that the more I reduce the complexity of a programming
language, the more I can concentrate on the problem at hand. Scheme is nice
that way. That said, the library situation in Scheme-land seems even worse
off than the library situation in CL-land, and is likely to remain so
precisely because so little of useful Scheme is standardized. Thus, I'm
learning CL. I find that even CL is a lot more simple than any other
language in terms of basic structure. The extended set of CL functions,
which is really a standardized library of sorts, is, of course, huge, but
there is a lot of time to learn a library. I'm finding that I'm productive
in CL after just a couple of w s of night-time learning of the core
concepts.
All that said, I don't yet know where I really come down on the Lisp-1/2
debate. I can see some advantages to both. My hunch is that like most
things, it's a balancing act. Pick your poison, so to speak. There are
advantages and divantages to both. Each side can trot out a pathelogical
case where the other side seems to do dumb things ("(list list)" vs. "(list
lst)"). The question is which one comes up more in daily practice? My hunch
is that Lisp-2 is probably better for real-world usage, but there is a very
elegant simplicity to Lisp-1.
--
Dave Roberts
ldave-re-move@re-move.droberts.com
| |
| Sunnan 2004-04-08, 5:45 am |
| Dave Roberts <ldave-re-move@re-move.droberts.com> writes:
> Each side can trot out a pathelogical case where the other side
> seems to do dumb things ("(list list)" vs. "(list lst)"). The
> question is which one comes up more in daily practice?
While I have no proof, my hunch is that the language actually changes
which one comes up more. Someone weaned on scheme wouldn't want to do
(list list) so much since they're used to the one namespace, while a
CL'er passes around functions slightly less.
This is ever so slightly, but a language changes the way the
programmer writes.
--
One love,
Sunnan
| |
| Dave Roberts 2004-04-08, 12:45 pm |
| Sunnan wrote:
> This is ever so slightly, but a language changes the way the
> programmer writes.
Very true. I guess that's my point. Obviously, the pathelogical cases can be
thrown around, but is it really a hardship to avoid them or do you just do
it without thinking about it.
My gut feeling is that you can probably avoid the pathelogical case in CL a
bit more naturally than in Scheme, but that it really doesn't limit
anything in practice.
--
Dave Roberts
ldave-re-move@re-move.droberts.com
| |
| Pascal Costanza 2004-04-08, 12:45 pm |
|
Dave Roberts wrote:
> My gut feeling is that you can probably avoid the pathelogical case in CL a
> bit more naturally than in Scheme, but that it really doesn't limit
> anything in practice.
That's indeed an important point. Guys, you should all realize that
these things are really only minor details compared to the overall
essential concepts in Lisp and Scheme, i.e. basically metacircularity
and the resulting freedom to mold the language to your concrete needs at
hand. Scheme and Common Lisp just follow different fundamental design
principles, and if you happen to prefer either the one or the other,
there's nothing wrong in sticking with just one of them. Personally, I
prefer Common Lisp, because I generally think that its designers have
made more "right" decisions than Scheme, but I don't have any problem
imagining to use Scheme in a world in which Common Lisp wouldn't exist.
None of the differences between Scheme and Common Lisp restrict you in
similar fundamental ways like those of most other languages.
Pascal
--
1st European Lisp and Scheme Workshop
June 13 - Oslo, Norway - co-located with ECOOP 2004
http://www.cs.uni-bonn.de/~costanza/lisp-ecoop/
| |
| Jeff Dalton 2004-04-08, 2:39 pm |
| Dave Roberts <ldave-re-move@re-move.droberts.com> writes:
> Jeff Dalton wrote:
[color=darkred]
> Don't confuse redundancy with this issue. Yes, natural languages have lots
> of redundancy. There are many ways to say the same thing.
That's not what I meant by redundancy. I meant it in the
information theoretic sense, applied to espressions in the
langauge, rather than to the langauge as a whole. Individual
sentences, for instance, will have some redundancy. Even words,
which is why misspelled words can so often be understood
even on their own.
For a Lisp example, consider that programmers use parens
and indentation. Even though the parens already give all the
grouping information, the indentation gives some of it again.
In CL, #'(lambda ...) doesn't really need the #'.
(lambda ...) would be enough on its own to indicate
the expression was a function. And indeed, CL changed
to allow programmers to write it that way. But there's
less redundancy when the #' is omitted.
> Put another way, CL evolved whereas Scheme was designed.
Evolution and design were factors for both; but Scheme is
further towards the design end, yes.
>
> No, because CL was specifically created to bring together diverging
> Lisp dialects
That's true in a sense, but misleading.
Common Lisp was created to bring together some MacLisp successor
dialects that were already quite similar; and for the most part it
stayed in that area of language space after more of the Lisp world
became involved.
> If that
> was the stated goal, then the reality is that CL actively sought to unify
> (in the sense of creating a union) all the various features that many Lisp
> dialects had created.
Common Lisp is not a union of all features.
Far from it. The list of Interlisp features not in Common
Lisp is almost as long as the list of Interlisp features. :)
Also, CL is a significant cleanup compared to most earlier
Lisps. In some ways, it became messier during standardization,
but there was tidying and cleanup during standardization as
well.
Moreover, some of the messier parts of Lisp 1.5 were eliminated
well before CL. For instance, in Maclisp.
> All that said, I don't yet know where I really come down on the Lisp-1/2
> debate. I can see some advantages to both. My hunch is that like most
> things, it's a balancing act. Pick your poison, so to speak.
Yes, I think that's right.
-- jd
| |
| Jeff Dalton 2004-04-08, 3:44 pm |
| Cameron MacKinnon <cmackin+nn@clearspot.net> writes:
> Jeff Dalton wrote:
[color=darkred]
> I can't agree with the eliminated along the way bit. Things almost
> never get eliminated from computer languages, because the "our legacy
> code would break with the new tools" whiners outvote the
> rationalization crowd.
Nonetheless, much rationalization happened during the design
of Common Lisp, and other things were eliminated earlier on.
Otherwise, we'd still have COMMON from Lisp 1.5 as well
as SPECIAL, and much else as well.
Before Common Lisp, people typically designed their own
dialect when they did an implementation, putting in the things
they liked and leaving out ones they especially didn't.
-- jd
| |
| Cameron MacKinnon 2004-04-08, 3:44 pm |
| Jeff Dalton wrote:
> Nonetheless, much rationalization happened during the design
> of Common Lisp, and other things were eliminated earlier on.
I guess this makes Lisp the only language old and diverse enough to have
had one of those great evolutionary purges that the biologists are
always on about.
The Lisp family tree!
http://www.bath.ac.uk/~cs2ylh/lispweb/Familytree.GIF
Not that you'd get the sense that Scheme is still thriving from the
diagram. And that "Lisp 2(disaster)" annotation all on its own is
intriguing...
--
Cameron MacKinnon
Toronto, Canada
| |
| Carl Shapiro 2004-04-08, 4:37 pm |
| Cameron MacKinnon <cmackin+nn@clearspot.net> writes:
> The Lisp family tree!
> http://www.bath.ac.uk/~cs2ylh/lispweb/Familytree.GIF
>
> Not that you'd get the sense that Scheme is still thriving from the
> diagram. And that "Lisp 2(disaster)" annotation all on its own is
> intriguing...
And completely false.
Lisp 2 had a number of incredibly interesting features such as the
elimination the interpreter, running all code compiled, all of the
time.
The family tree you have found is full of mistakes (such as this one)
and cannot be taken seriously.
| |
| Andy Freeman 2004-04-08, 7:44 pm |
| Jeff Dalton <jeff@todday.inf.ed.ac.uk> wrote in message news:<fx4ad1m731m.fsf@todday.inf.ed.ac.uk>...
> Dave Roberts <ldave-re-move@re-move.droberts.com> writes:
>
> That's true in a sense, but misleading.
>
> Common Lisp was created to bring together some MacLisp successor
> dialects that were already quite similar;
MacLisp, InterLisp, PSL, and others were close enough that one could
define a single language using a small set of language-specific
macros and functions. Programs written in this language could
run in any of these lisps.
-andy
| |
| Jeff Dalton 2004-04-08, 10:32 pm |
| anamax@earthlink.net (Andy Freeman) writes:
> Jeff Dalton <jeff@todday.inf.ed.ac.uk> wrote in message news:<fx4ad1m731m.fsf@todday.inf.ed.ac.uk>...
>
> MacLisp, InterLisp, PSL, and others were close enough that one could
> define a single language using a small set of language-specific
> macros and functions. Programs written in this language could
> run in any of these lisps.
Are you disagreeing with me, or just adding a comment?
Standard Lisp was meant to be something that could easily be
implemented in various Lisps in the fashion you suggest, and
I know of other attempts to define such a language.
At one point during the time of Lisp standardization, I
defined a common subset of Common Lisp, EuLisp, and Le Lisp.
However, such languages tend to be fairly small. In anything
in Interlisp really needed the spaghetti stack, for example,
it wouldn't be trivial to get it going in MacLisp.
-- jd
| |
| Andy Freeman 2004-04-10, 2:32 am |
| Jeff Dalton <jeff@tarn.inf.ed.ac.uk> wrote in message news:<fx4zn9m6itk.fsf@tarn.inf.ed.ac.uk>...
> anamax@earthlink.net (Andy Freeman) writes:
>
> Are you disagreeing with me, or just adding a comment?
My point is that the different lisps were actually similar enough
for some non-trivial purposes.
> However, such languages tend to be fairly small. In anything
> in Interlisp really needed the spaghetti stack, for example,
> it wouldn't be trivial to get it going in MacLisp.
Huh? We didn't think about "what mechanism does a language use to
provide relevant functionality"? We worried about "what functionality
do we support and how do we support it in the various implementations"?
Our language was rich enough to let people who wouldn't work in a
common/single lisp dialect share code used for a fairly large research
project. Most of them probably felt that things would be better if
others would see the light, but that wasn't going to happen. Instead,
they had to choose between sharing and writing code written in this
invented language and not sharing code and/or constantly porting.
| |
| Jeff Dalton 2004-04-10, 2:32 pm |
| anamax@earthlink.net (Andy Freeman) writes:
> Jeff Dalton <jeff@tarn.inf.ed.ac.uk> wrote in message news:<fx4zn9m6itk.fsf@tarn.inf.ed.ac.uk>...
>
> My point is that the different lisps were actually similar enough
> for some non-trivial purposes.
Yes, but what do you think the significance of that is in this
context? Why are you making that point here and now?
>
> Huh? We didn't think about "what mechanism does a language use to
> provide relevant functionality"? We worried about "what functionality
> do we support and how do we support it in the various implementations"?
How did you provide the functionality that the spaghetti stack
provide for Interlisp, for example?
> Our language was rich enough to let people who wouldn't work in a
> common/single lisp dialect share code used for a fairly large research
> project. Most of them probably felt that things would be better if
> others would see the light, but that wasn't going to happen. Instead,
> they had to choose between sharing and writing code written in this
> invented language and not sharing code and/or constantly porting.
Who is "we"? What language is "our language"?
Anyway, what I said about Common Lisp was true. As just one piece
of evidece, there is CLtL II, p 1:
Common Lisp originated in an attempt to focus the work of
several implementation groups, each of which was consctucting
successor implementations of MacLisp for different computers.
The same introduction does mention compatibility with Interlisp,
but little in CL can be traced back to Interlisp.
When CL implementations first came along, I was most used
to Franz Lisp (a close relative of MacLisp), and I could
use Common Lisp right away. A lot of Franz Lisp code would work
unchanged. Attempting to use Interlisp was a very different
experience. PSL was further from Common Lisp than Franz Lisp
was, but much closer than Interlisp.
-- jd
| |
| Andy Freeman 2004-04-10, 10:32 pm |
| Jeff Dalton <jeff@tarn.inf.ed.ac.uk> wrote in message news:<fx4y8p34ub0.fsf@tarn.inf.ed.ac.uk>...
> anamax@earthlink.net (Andy Freeman) writes:
>
> How did you provide the functionality that the spaghetti stack
> provide for Interlisp, for example?
None of our users ever wanted upwards funargs or multi-threading, so
it never came up.
Note that these folks were extremly problem driven - they didn't have
much interest in programming languages as such.
>
> Who is "we"? What language is "our language"?
We called it "@Lisp" and it was used by a couple of AI/KSL projects
at Stanford and associated institutions in the early 80s. I suspect
that much of it got ported to CommonLisp as such a port was trivial,
even in early implementations.
> Anyway, what I said about Common Lisp was true.
No one said that it wasn't.
-andy
| |
| Thomas A. Russ 2004-04-22, 7:48 pm |
| Dave Roberts <ldave-re-move@re-move.droberts.com> writes:
>
> Don't confuse redundancy with this issue. Yes, natural languages have lots
> of redundancy. There are many ways to say the same thing. That is not the
> case here. The distinction between LET and FLET is not subject to my
> personal mood at the time and whether I would suddenly choose one versus
> the other. They are not redundant. They are different. The language forces
> me to choose between LET and FLET depending on what I'm trying to
> accomplish. Thus, they are "redundant" in the same way that "black" and
> "white" are redundant in English... ;-)
If I understand Jeff Dalton's point about redundancy, it isn't that LET
and FLET are redundant with each other.
Rather, it is that having to specify both a function body and use FLET
(rather than, say a lambda expression and LET) is what is redundant. In
other words, FLET and a function value both give the same information.
That is the redundancy that you get from the situation.
--
Thomas A. Russ, USC/Information Sciences Institute
|
|
|
|
|