scheme seems neater
robbie carlton
scheme a symbol has only one visible binding at anytime, whereas in CL
a symbol can have a variable value a function value, a property list,
a documentation string, and probs some other junk I forgot. Question
is, why? Doesn't the CL way just promote messy unreadable code. Also,
the Scheme way means function definitions are much more pretty, and
consistent, ie assigning a symbol to a function literal. It just seems
nicer. I understand Paul Grahams arc is going to include some of that
schemeyness, but probably won't be around for a decade. Am I just
wrong, or is Scheme just more elegant than CL?
mikel
I can see why you think that way, but in practice about the only real
difference it makes is that coming up with a good macro system for
Scheme has been harder (because of the much greater likelihood of
accidental variable capture in a single namespace). There are other
differences between the languages on account of the namespace issue, and
in some respects Scheme's syntax is arguably tidier because of it, but
these wind up being mostly peripheral issues.
John Thingstad
wrote:
funcall, apply can be used to call (lambda (var) func)
(fsetf func (founction-value name) (func)) sets a function
More of these duplicates: makunbound, fmakunbound
getting the picture?
--
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
Paul Wallich
And, as people will tell you endlessly, a lot depends on your
perceptions of elegance. Stereotypically in Scheme, for example, you
pay for the increased elegance of the base language with a decrease in
the elegance of expressing your ideas in code, e.g. having to invent
misspellings, nonce names and circumlocations to avoid punning.
Some people view "I perceived with my eyes a toothed wood-cutting device
and sawed a board with it" as more elegant, and others prefer "I saw the
saw and sawed a board with it." The language that only allows the first
version is undoubtedly more elegant in some ways, the one that
encourages the second in others.
paul
Sunnan
> I can see why you think that way, but in practice about the only real
> difference it makes is that coming up with a good macro system for
> Scheme has been harder (because of the much greater likelihood of
> accidental variable capture in a single namespace).
But lisp-2:s are also vulnerable to variable capture. Use gensyms.
Scheme now has three widespread macrosystems, one very similar to the
one available in Common Lisp.
--
One love,
Sunnan
Pascal Costanza
> mikel <mi...@evins.net> writes:
>
>>I can see why you think that way, but in practice about the only real
>>difference it makes is that coming up with a good macro system for
>>Scheme has been harder (because of the much greater likelihood of
>>accidental variable capture in a single namespace).
>
> But lisp-2:s are also vulnerable to variable capture. Use gensyms.
Take a look at the paper "Syntactic Closures" by Bawden and Rees. They
present four examples, one of which is admitted to be a pathological case.
The first example in that paper cannot happen in a Lisp-2. The other two
examples present cases of name capture that you might actually want, and
therefore have to understand anyway. (Additionally, the third one can be
solved with the Common Lisp package system.)
Pascal
--
ECOOP 2004 Workshops - Oslo, Norway
*1st European Lisp and Scheme Workshop, June 13*
http://www.cs.uni-bonn.de/~costanza/lisp-ecoop/
*2nd Post-Java Workshop, June 14*
http://prog.vub.ac.be/~wdmeuter/PostJava04/
Sunnan
> And, as people will tell you endlessly, a lot depends on your
> perceptions of elegance. Stereotypically in Scheme, for example, you
> pay for the increased elegance of the base language with a decrease in
> the elegance of expressing your ideas in code, e.g. having to invent
> misspellings, nonce names and circumlocations to avoid punning.
Some would say that its well worth that price.
> Some people view "I perceived with my eyes a toothed wood-cutting
> device and sawed a board with it" as more elegant, and others prefer
> "I saw the saw and sawed a board with it." The language that only
> allows the first version is undoubtedly more elegant in some ways, the
> one that encourages the second in others.
But with CL it's cumbersome to say "I sawed the saw".
E.g. in scheme you can write (list list) which evaluates to
(#<procedure>). In CL you have to write (list #'list) to get that same
effect.
And puns can be obfuscating until you're used to them. If you want to
write the function
(defun hack-the-list (list)
(list (hackhackhack list)))
in CL, you can. Sure.
In scheme you have to change the variable name a little.
(define (hack-the-list list-)
(list (hackhackhack list-)))
How is that much less elegant than CL having to add #' pretty often?
(uses of mapcar comes to mind).
(Common idioms are lis and lst.)
So CL-ers have to add #' and funcalls in some situations, and schemers
have to change their names in some others. The same inelegancy.
However, I can't think of any drawback with a lisp-1 that a lisp-2
doesn't also have.
Variable naming is one of the things about good-looking code that's
easiest and hardest at the same time.
Here's another example that might be food for thought:
(defun hack-together-two-lists (list list)
...)
That's not valid CL, either.
Now, many people would possibly argue that "Oh, but Good Style would
dictate that you name the two variables differently so that you can
see what's going on in the function". A surprisingly lange subset of
those very same persons would still argue for CL-style punning and
twin namespaces.
In conclusion, I like CL a lot. I just don't think that having to say
"I saw the #'saw and sawed a board with it" is something to write home
about.
--
One love,
Sunnan
Sunnan
> Question is, why?
The reason is historical and political. The double namespaces have
been around since lisp 1.5 and when Common Lisp came around it was the
only politically acceptable choice since "Common Lisp was the result
of a compromise between a number of dialects of Lisp", all of them
with this issue. See http://www.dreamsongs.com/Separation.html for a
summary of the technical issues involved.
--
One love,
Sunnan
Frode Vatvedt Fjeld
> [..] In conclusion, I like CL a lot. I just don't think that having
> to say "I saw the #'saw and sawed a board with it" is something to
> write home about.
I think you're missing the point here. You don't say "I saw the #'saw
and sawed .." in CL, you say "I saw the saw and sawed ..". The point
is that contextually, humans understand that the first saw is a verb
and the second a noun, even if they are spelled identically. What this
illustrates about CL is that in e.g. (saw saw), the first saw
references the function name-space, while the second saw references
the variable name-space.
Your sentence "I saw the #'saw and sawed a board with it", is
presumably intended to correspond to a CL form like (saw #'saw).
However, the translation of (saw #'saw) to english would be something
like "I saw the verb `saw' and sawed .." where the qualification of
the second saw is required in order for it not to be mistaken for the
metal thing with teeth. Precisely the same situation as in CL, and why
we have to say (function saw), shortcut to #'saw, to express "the
value of saw in the function name-space" when not at the operator
postion in a form.
--
Frode Vatvedt Fjeld
Björn Lindberg
And the scheme version is
I saugh the sw and sawed a board with it.
;-)
Björn
Jeff Dalton
> Hi. Probs stupid question from someone relatively new to Lisp. In
> scheme a symbol has only one visible binding at anytime, whereas in CL
> a symbol can have a variable value a function value, a property list,
> a documentation string, and probs some other junk I forgot.
That is mixing up two different (sets of) issues: ones
relating to symbols as data objects and ones relating to
symbols as identifiers in code.
Scheme, like Common Lisp, has symbols as data objects, and
all kinds of things might be associated with symbols in Scheme
programs. A Scheme program might, for example, have a table
that maps symbols to property lists.
However, Scheme doesn't have that particular mapping built-in,
while Common Lisp does.
Some Scheme implementions might build-in property lists for
symbols; I don't think there's anything in RnRS or the IEEE
standard that forbids it.
When symbols are used as identifiers in code, Scheme has only
one "namespace" for them. Symbols are identifiers are always
ordinary variables that can have any object as their value.
Among those objects are functions.
Common Lisp also allows variables to have functions as values.
In Common Lisp, however, there is a second namespace in which
symbols as identifiers are mapped specifically to functions.
In Common Lisp, there are also two more namespaces: one for
block names, another for go tags.
(Are there any more than that? There didn't used to be.)
The two sets of issues meet in the top-level environment.
In Common Lisp, symbols as data objects are used as
variables and function names in the top level env.
That is, you can call a function -- symbol-value -- on a symbol and
get its top-level value as a function, and you can call another
function -- symbol-function -- to gets its top-level value as
a function name. (There aren't any top-level block names
or go tags.)
> Question is, why?
Partly history; but also it's fairly natural for names to
have different interpretations in different contexts and
to have different uses. For instance, it is fairly natural
to use "list" as a variable name without expecting that to
interfere with calling "list" as a function.
Many programming languages have multiple namespaces
of various sorts.
> Doesn't the CL way just promote messy unreadable code.
No.
> Also, the Scheme way means function definitions are much more
> pretty,
Some are, others aren't.
> and consistent, ie assigning a symbol to a function literal. It just
> seems nicer. I understand Paul Grahams arc is going to include some
> of that schemeyness, but probably won't be around for a decade. Am I
> just wrong, or is Scheme just more elegant than CL?
I think it's fair to say Scheme is more elegant, but elegance
is not the only desirable property.
-- jd
Sunnan
> and sawed .." in CL, you say "I saw the saw and sawed ..". The point
> is that contextually, humans understand that the first saw is a verb
> and the second a noun, even if they are spelled identically. What this
> illustrates about CL is that in e.g. (saw saw), the first saw
> references the function name-space, while the second saw references
> the variable name-space.
Yeah, I understand, but I warped the analogy a bit because I couldn't
think of anything cleaner. I have now, though, how about this
sentence:
"Tomorrow I am going to saw with the saw".
In CL, that would have to be
"..going to #'saw with the saw".
As for Björns comments, sure, I never denied that you can't do
CL-style puns with scheme - that was what my entire post was about!
--
One love,
Sunnan
Anton van Straaten
> robbie carlton wrote:
> > Hi. Probs stupid question from someone relatively new to Lisp. In
> > scheme a symbol has only one visible binding at anytime, whereas in CL
> > a symbol can have a variable value a function value, a property list,
> > a documentation string, and probs some other junk I forgot. Question
> > is, why? Doesn't the CL way just promote messy unreadable code. Also,
> > the Scheme way means function definitions are much more pretty, and
> > consistent, ie assigning a symbol to a function literal. It just seems
> > nicer. I understand Paul Grahams arc is going to include some of that
> > schemeyness, but probably won't be around for a decade. Am I just
> > wrong, or is Scheme just more elegant than CL?
>
> I can see why you think that way, but in practice about the only real
> difference it makes is that coming up with a good macro system for
> Scheme has been harder (because of the much greater likelihood of
> accidental variable capture in a single namespace).
This is a myth.
Most Schemes provide a defmacro just like CL's that works just fine, as far
as defmacro goes. Scheme macro systems are addressing other issues - in
particular, providing a macro system that integrates with the lexical
structure of the underlying language, rather than being entirely unaware of
that structure.
Anton
Björn Lindberg
My comment was meant the other way around; I was referring to the name
mangling necessary in Scheme, eg "list" becomes "lst", "saw" becomes
"sw" and "saugh" respectively, and so forth.
Björn
Sunnan
> The first example in that paper cannot happen in a Lisp-2. The other
> two examples present cases of name capture that you might actually
> want, and therefore have to understand anyway.
Are you saying that you never, never, ever, under the bluest of moons
would want the first example, so you should use a lisp-2 so you don't
have to understand it?
> (Additionally, the
> third one can be solved with the Common Lisp package system.)
In theory Lisp-1:s can have a standardized package system. Scheme's
lack of one isn't because it's a lisp-1.
--
One love,
Sunnan
Sunnan
> My comment was meant the other way around; I was referring to the name
> mangling necessary in Scheme, eg "list" becomes "lst", "saw" becomes
> "sw" and "saugh" respectively, and so forth.
So was I, or at least I was trying to.
Name mangling, a.k.a. choosing variable names with care, is always
necessary when you have two variables that would otherwise have the
same name, regardless of the number of namespaces involved. I guess
that's my point summed up as shortly as I can.
That's why I brought up the (defun mangle-lists (list list list) ...)
invalid example.
Maybe people who adore CL-style punning could look into having
different namespaces for other types, as well - a string and an int
having the same name in the same variable, for example. Of course(?),
that would be annoying - and that's the same argument that lisp-1
proponents present for uniting the namespace of functions with other
types.
--
One love,
Sunnan
Pascal Costanza
> Pascal Costanza <cost...@web.de> writes:
>
>>The first example in that paper cannot happen in a Lisp-2. The other
>>two examples present cases of name capture that you might actually
>>want, and therefore have to understand anyway.
>
> Are you saying that you never, never, ever, under the bluest of moons
> would want the first example, so you should use a lisp-2 so you don't
> have to understand it?
The first example shows how a global function definition is replaced
with a local value definition. If you have a good example in which this
makes sense, I'd be interested to hear about it.
>>(Additionally, the
>>third one can be solved with the Common Lisp package system.)
>
> In theory Lisp-1:s can have a standardized package system. Scheme's
> lack of one isn't because it's a lisp-1.
Right. So?
Pascal Costanza
> Maybe people who adore CL-style punning could look into having
> different namespaces for other types, as well - a string and an int
> having the same name in the same variable, for example. Of course(?),
> that would be annoying - and that's the same argument that lisp-1
> proponents present for uniting the namespace of functions with other
> types.
No, it's not. The one case would be annoying, the other case is not.
BTW, what's the point of this discussion? If you prefer one style, you
know where to find it. If you prefer the other, you also know where to
find it. What's the problem?
Sunnan
>> Maybe people who adore CL-style punning could look into having
>> different namespaces for other types, as well - a string and an int
>> having the same name in the same variable, for example. Of course(?),
>> that would be annoying - and that's the same argument that lisp-1
>> proponents present for uniting the namespace of functions with other
>> types.
>
> No, it's not. The one case would be annoying, the other case is not.
Care to clarify?
> BTW, what's the point of this discussion?
The point of this discussion, for me, is to find out whether there are
any good technical (as opposed to historical/political) reasons why
one would, today, create a new lisp-2, and if so, trying to understand
those reasons.
I am very much trying to keep it from being a Scheme vs CL
"contest". I'm not trying to present either language as better than
the other, but I am trying to refute some of the arguments for a
lisp-2 that I don't think make sense.
> If you prefer one style, you know where to find it. If you prefer
> the other, you also know where to find it.
I'm experimenting with both styles.
--
One love,
Sunnan
Frode Vatvedt Fjeld
> Yeah, I understand, but I warped the analogy a bit because I
> couldn't think of anything cleaner. I have now, though, how about
> this sentence:
>
> "Tomorrow I am going to saw with the saw".
>
> In CL, that would have to be
> "..going to #'saw with the saw".
Well it'd be "tomorrow I'm going to apply the verb `saw' to the
board", but I think in one sense you're right. In sexpr terms, this
would be
CL: (tomorrow #'saw board)
Scheme: (tomorrow saw board)
and one expects a "verb" after tomorrow, hence CL's #' might be
considered superfluous. There are problems with this, however. Humans
can expect a verb after tomorrow because humans understand the concept
of "tomorrow I'm going to" and expect an action (verb in some form) to
follow. We don't want to design the programming language after such
rules. I.e. we don't want to make tomorrow a special operator with
special evaluation rules, i.e. "the argument to tomorrow is a function
name". Such designs we leave to Perl and its ilk. So this is the
rationale for why lisp-2 accepts this minor problem. In scheme, what
if you want to say "tomorrow do the noun `saw' and the board"?
(tomorrow sw board). It's the same old story: in scheme you have to
simulate two name-spaces by making up mangled names, and so in general
it has the same problem as that CL has here, except of course the
problem is much more pervasive in scheme and there's no principled way
to deal with it.
And yes, in CL you have to "simulate namespaces by making up names"
also, when writing e.g.
(defun append-two-lists (list1 list2)
...)
but I don't see this as any argument against lisp-2. It's a rare
situation that you have two variables that would naturally be given
the same name, and I don't think there's any sensible way to resolve
this "problem" in the language design.
--
Frode Vatvedt Fjeld
Sunnan
> The first example shows how a global function definition is replaced
> with a local value definition. If you have a good example in which
> this makes sense, I'd be interested to hear about it.
Not really, but how about where a global function definition is
replaced by a local function definition? Bad style, maybe, but for the
purposes of example:
(let ((cons monitored-cons))
(push 'foo stack))
(or am I looking at the wrong example in the paper?)
>>>(Additionally, the
>>>third one can be solved with the Common Lisp package system.)
>> In theory Lisp-1:s can have a standardized package system. Scheme's
>> lack of one isn't because it's a lisp-1.
>
> Right. So?
Just saying that it isn't necesserily the lisp-2:iness off CL that
solves the third example.
(Btw, please see the other post on why I am arguing these perhaps
petty points. It is not for the purpose of hostility.)
--
One love,
Sunnan
Jeff Dalton
> > I can see why you think that way, but in practice about the only real
> > difference it makes is that coming up with a good macro system for
> > Scheme has been harder (because of the much greater likelihood of
> > accidental variable capture in a single namespace).
>
> This is a myth.
No it isn't.
The scheme designers had a very hard time coming up with a macro
system good enough to put in the language, and one of the reasons
ordinary Lisp defmacro-style macros were not as acceptable for
Scheme as they were for other Lisps was the greater danger of
unintended captures in Scheme.
> Most Schemes provide a defmacro just like CL's that works just fine,
> as far as defmacro goes.
Yes, but the point wasn't about the difficulty of coming up with
any macro system for scheme; it was about the difficulty of coming
up with a good one.
> Scheme macro systems are addressing other issues - in
> particular, providing a macro system that integrates with the lexical
> structure of the underlying language, rather than being entirely unaware of
> that structure.
Do you think it has nothing to do with accidental captures?
-- jd
Jeff Dalton
> d95...@nada.kth.se (Björn Lindberg) writes:
> > My comment was meant the other way around; I was referring to the name
> > mangling necessary in Scheme, eg "list" becomes "lst", "saw" becomes
> > "sw" and "saugh" respectively, and so forth.
>
> So was I, or at least I was trying to.
>
> Name mangling, a.k.a. choosing variable names with care,
If you think prejudicial language should be avoided,
then the use of "punning" for what happens in CL should
also be dropped.
Not all uses of multiple meanings for a word are punning.
> is always
> necessary when you have two variables that would otherwise have the
> same name, regardless of the number of namespaces involved. I guess
> that's my point summed up as shortly as I can.
CL allows context to disambiguate, so that choosing different
names is less often needed. That isn't changed by both languages
having some cases where names would clash.
> Maybe people who adore CL-style punning
I don't think anyone adores it. The CL attitude is more
pragmatic, that's all.
> could look into having
> different namespaces for other types, as well - a string and an int
> having the same name in the same variable, for example.
There are a number of factors that have to be balanced.
Things don't have to be pushed to extremes.
-- jd
Sunnan
> rules. I.e. we don't want to make tomorrow a special operator with
> special evaluation rules, i.e. "the argument to tomorrow is a function
> name".
Sure, that's understandable (see also the recent discussion about
trace).
But isn't the function/value separation as stands in CL also a kind of
"special evaluation rules"?
Something like "The first atom in a unquoted list is to have it's
function value called". (Eeep, that sentence may need some revision
but you get the gist.)
> Such designs we leave to Perl and its ilk. So this is the
> rationale for why lisp-2 accepts this minor problem. In scheme, what
> if you want to say "tomorrow do the noun `saw' and the board"?
> (tomorrow sw board).
Yeah, I'd probably do that, but I often work within a lambda or a
function so the scope is limited enough.
(let ((saw (noun saw)))
(tomorrow saw board))
works fine.
> It's the same old story: in scheme you have to
> simulate two name-spaces by making up mangled names, and so in general
> it has the same problem as that CL has here, except of course the
> problem is much more pervasive in scheme and there's no principled way
> to deal with it.
>
> And yes, in CL you have to "simulate namespaces by making up names"
> also, when writing e.g.
>
> (defun append-two-lists (list1 list2)
> ...)
>
> but I don't see this as any argument against lisp-2.
The argument is that the "simulate namespaces by making up names" is a
problem that both lisp-1 and lisp-2 (and all other languages with
variables) has. Lisp-1 has that problem more often (not *that* often -
there's a reason why the perennial example is "list"...) but being a
lisp-2 does not completely solve it and thus this argument for lisp-2
is at least somewhat void.
(One reason for this particular example is that list is a verb and a
noun in english as well, instead of being called e.g. listify.)
> It's a rare situation that you have two variables that would
> naturally be given the same name, and I don't think there's any
> sensible way to resolve this "problem" in the language design.
Agreed.
--
One love,
Sunnan
Björn Lindberg
> d95...@nada.kth.se (Björn Lindberg) writes:
> > My comment was meant the other way around; I was referring to the name
> > mangling necessary in Scheme, eg "list" becomes "lst", "saw" becomes
> > "sw" and "saugh" respectively, and so forth.
>
> So was I, or at least I was trying to.
>
> Name mangling, a.k.a. choosing variable names with care, is always
> necessary when you have two variables that would otherwise have the
> same name, regardless of the number of namespaces involved. I guess
> that's my point summed up as shortly as I can.
You're making it sound like there isn't a significant difference in
the need for name mangling between a Lisp-1 and a Lisp-2. This is
obviously wrong. Common Lisp code usually don't contain any name
mangling at all, whereas in Scheme it is the norm.
> That's why I brought up the (defun mangle-lists (list list list) ...)
> invalid example.
That is a silly example. Are you proposing different namespaces for
the first, second, etc argument to a function? How would that look
like?
> Maybe people who adore CL-style punning
It is not punning.
> could look into having
> different namespaces for other types, as well - a string and an int
> having the same name in the same variable, for example.
And what would the advantage of this be do you think?
Björn
Björn Lindberg
> Pascal Costanza <cost...@web.de> writes:
> >> Maybe people who adore CL-style punning could look into having
> >> different namespaces for other types, as well - a string and an int
> >> having the same name in the same variable, for example. Of course(?),
> >> that would be annoying - and that's the same argument that lisp-1
> >> proponents present for uniting the namespace of functions with other
> >> types.
> >
> > No, it's not. The one case would be annoying, the other case is not.
>
> Care to clarify?
>
> > BTW, what's the point of this discussion?
>
> The point of this discussion, for me, is to find out whether there are
> any good technical (as opposed to historical/political) reasons why
> one would, today, create a new lisp-2, and if so, trying to understand
> those reasons.
There are. Or rather, there are advantages to both ways. I think
ultimately it is an issue of personal preference which style you
prefer. The issue has been extensively discussed in the past on this
newsgroup, try Google groups. There is also a paper by Kent Pitman
comparing Lisp-1 and lisp-2.
> I am very much trying to keep it from being a Scheme vs CL
> "contest". I'm not trying to present either language as better than
> the other, but I am trying to refute some of the arguments for a
> lisp-2 that I don't think make sense.
As have countless others before you...
:-)
Björn
Erann Gat
van Straaten" <an...@appsolutions.com> wrote:
This is a myth. ;-)
Common Lisp macros have visibility into the lexical structure of the
langauge through the &environment mechanism. This mechanism may not be
specified in enough detail to fulfill all the desires of a Scheme
programmer, but to say that CL macros are "entirely unaware" of the
lexical structure of the language is not correct.
E.
Sunnan
>> Name mangling, a.k.a. choosing variable names with care,
>
> If you think prejudicial language should be avoided,
I didn't mind the term "name mangling" (and I've used it myself in
other responses in this thread), I just wanted to clarify what "name
mangling" sometimes is.
> then the use of "punning" for what happens in CL should
> also be dropped.
I'm sorry.
I had mostly heard the term in a positive light.
> Not all uses of multiple meanings for a word are punning.
I meant specifically (lambda (string) (string string)) and so on.
>> Maybe people who adore CL-style punning
>
> I don't think anyone adores it.
I glanced at the thread "Lisp puns considered good style?" (original
post message id: <3s-dnZLJf9G...@golden.net>) and some people
seemed to adore it. Maybe I got the wrong impression.
>> could look into having
>> different namespaces for other types, as well - a string and an int
>> having the same name in the same variable, for example.
>
> There are a number of factors that have to be balanced.
> Things don't have to be pushed to extremes.
Maybe not.
Sunnan
> You're making it sound like there isn't a significant difference in
> the need for name mangling between a Lisp-1 and a Lisp-2. This is
> obviously wrong. Common Lisp code usually don't contain any name
> mangling at all, whereas in Scheme it is the norm.
Of course there is a difference.
However, I think that the difference is exaggerated. In my current
scheme project, which is small, I admit (1226 pairs of parens), I
didn't have any name mangling.
Then I was reading through SRFI-1 and discovered the idiom of writing
"lis" for variables called "list", so I went through my code and
changed my "list" variables to "lis" to reflect that idiom (my ideas
on what constitutes idiomatic code and/or good style is somewhat
fluctuating as I gain experience with the language). I now have six
occurences of "lis" - none of them needed because none of them is in a
scope where I use the function "list".
> It is not punning.
I'm sorry. (See also my reply to Jeff.)
>> could look into having
>> different namespaces for other types, as well - a string and an int
>> having the same name in the same variable, for example.
>
> And what would the advantage of this be do you think?
I can't think of any. I just figure it being an interesting thought
experiment for me to think of advantages of multiple namespaces, since
I'm continually surprised over how people genuinely speak out in favor
of lisp-2.
--
One love,
Sunnan
Jeff Dalton
> Jeff Dalton <je...@todday.inf.ed.ac.uk> writes:
> > Not all uses of multiple meanings for a word are punning.
>
> I meant specifically (lambda (string) (string string)) and so on.
Do you mean that cases like that, which look quite strange to me,
are puns, or that any defintion in which "list", say, was used
as both a variable and a function name would be "punning"?
> >> Maybe people who adore CL-style punning
> >
> > I don't think anyone adores it.
>
> I glanced at the thread "Lisp puns considered good style?" (original
> post message id: <3s-dnZLJf9G...@golden.net>) and some people
> seemed to adore it. Maybe I got the wrong impression.
I haven't read that one.
-- jd
Frode Vatvedt Fjeld
> But isn't the function/value separation as stands in CL also a kind
> of "special evaluation rules"?
Certainly. You can't make an omelet without breaking some eggs.
> [..] but being a lisp-2 does not completely solve it and thus this
> argument for lisp-2 is at least somewhat void.
Well, this is precisely a statement I'd expect from someone chosing
lisp-1, and I disagree wholeheartedly. That some solution does not
cover every conceivable problem does not void that solution. Scheme
dismisses lisp-2 on this grounds, and continues to live with "lsp"
variables and unnecessarily complicated macro systems because
according to some twisted way of thinking this requires no solutions
that don't cover every problem. Scheme tries to make the omelet
without breaking any eggs, so they put the egg very carefully in the
frying pan, cook it long and well, and swallow the thing, eggshell and
all, satisfied that the egg remained unbroken and pure.
--
Frode Vatvedt Fjeld
Sunnan
> There are. Or rather, there are advantages to both ways. I think
> ultimately it is an issue of personal preference which style you
> prefer. The issue has been extensively discussed in the past on this
> newsgroup, try Google groups. There is also a paper by Kent Pitman
> comparing Lisp-1 and lisp-2.
I can only find http://www.dreamsongs.com/Separation.html (also at
http://www.nhplace.com/kent/Papers/Technical-Issues.html) which I've
read thoroughly, several times.
>> I am very much trying to keep it from being a Scheme vs CL
>> "contest". I'm not trying to present either language as better than
>> the other, but I am trying to refute some of the arguments for a
>> lisp-2 that I don't think make sense.
>
> As have countless others before you...
Yeah, I guess it gets pretty tiring.
Well, I didn't start the thread, but I had to jump in. My main
reaction to people adamantly defending lisp-2 is surprise and
disunderstanding.
I understand the historical/political argument, I do, but I guess I'm
blinded by my own emotion of how neat I think it is with lisp-1:s, how
blindingly flexible and beautiful the code can be.
If someone says that they choose CL *in spite of* it being a lisp-2, I
can definitely understand them. I like CL.
If someone says that they choose a lisp-2 *because* it's a lisp-2, I
react with "really? tell me more!"
However, if someone has an argument against lisp-1 that I consider
bogus (say, "you can't do macros" or "lisp-2 solves all name-mangling
issues"), I might argue against that.
My dream lisp would have the best from both scheme and CL.
Anyway, sorry.
--
One love,
Sunnan
Jeff Dalton
> The point of this discussion, for me, is to find out whether there are
> any good technical (as opposed to historical/political) reasons why
> one would, today, create a new lisp-2, and if so, trying to understand
> those reasons.
I don't think there are any technical reasons that definitively
establish that Lisp-1 or Lisp-2 is better.
They're both reasonable choices in "language space", it seems
to me.
Much of the discussion of this issue in recent years (decades?)
seems to assume that Lisp-2 is obviously worse, so that only
historical or political reasons could explain why any language
has two namespaces.
-- jd
Pascal Costanza
> Pascal Costanza <cost...@web.de> writes:
>
>>>Maybe people who adore CL-style punning could look into having
>>>different namespaces for other types, as well - a string and an int
>>>having the same name in the same variable, for example. Of course(?),
>>>that would be annoying - and that's the same argument that lisp-1
>>>proponents present for uniting the namespace of functions with other
>>>types.
>>
>>No, it's not. The one case would be annoying, the other case is not.
>
> Care to clarify?
I don't find #' annoying.
>>BTW, what's the point of this discussion?
>
> The point of this discussion, for me, is to find out whether there are
> any good technical (as opposed to historical/political) reasons why
> one would, today, create a new lisp-2, and if so, trying to understand
> those reasons.
Lisp-2 removes the most important name capturing issues in macros. I
like Common Lisp's defmacro more than Scheme's syntax-rules/syntax-case.
The Lisp-1 vs. Lisp-2 is a purely aesthetical issue, whereas being able
to write reasonable macros is an issue with clear practical relevance.
(BTW, I don't think it makes sense to create a new Lisp-2. You'd only be
reinventing the wheel.)
Pascal Costanza
> Pascal Costanza <cost...@web.de> writes:
>
>>The first example shows how a global function definition is replaced
>>with a local value definition. If you have a good example in which
>>this makes sense, I'd be interested to hear about it.
>
> Not really, but how about where a global function definition is
> replaced by a local function definition? Bad style, maybe, but for the
> purposes of example:
>
> (let ((cons monitored-cons))
> (push 'foo stack))
That's a case you might want to have and need to understand. The
annoying name capture issues are those between values and functions, not
those between values and values, or functions and functions. (Note that
you have, consciously or subconsciously, chosen an example in which cons
is replaced by a modified version thereof that you may want to see used
in the enclosed code.)
>>>>(Additionally, the
>>>>third one can be solved with the Common Lisp package system.)
>>>
>>>In theory Lisp-1:s can have a standardized package system. Scheme's
>>>lack of one isn't because it's a lisp-1.
>>
>>Right. So?
>
> Just saying that it isn't necesserily the lisp-2:iness off CL that
> solves the third example.
Huh?!? I didn't say that packages "necessarily" solve this issue. [1] I
have only said that you _can_ use them for solving this issue.
Pascal
[1] This doesn't really make sense, does it? Maybe you mean something else.
Sunnan
(Feeling kind of bad to reply with a petty aside to a good post...)
Frode Vatvedt Fjeld <fro...@cs.uit.no> writes:
<snip>
> variables and unnecessarily complicated macro systems because
> according to some twisted way of thinking this requires no solutions
> that don't cover every problem.
In practice, there's nothing wrong with scheme's macro systems. You
want CL-style defmacro, you've got it. (I wish R6RS would include
Dybvig's syntax-case, since that's rapidly becoming something of a
standard among schemes.)
(I groan at people who complain about CL's lack of tail-call
optimization, as well. Nothing prevents an implementation from
providing it. Same as being a lisp-1 doesn't mean "unwieldly macros".)
> Scheme tries to make the omelet without breaking any eggs, so they
> put the egg very carefully in the frying pan, cook it long and well,
> and swallow the thing, eggshell and all, satisfied that the egg
> remained unbroken and pure.
Yeah, I guess that's it. That's a pretty good explanation. And CL
would break the egg, a bit of the shell would fall in but most of it
would get cleaned out, and the omelet would turn out pretty fine. We
would both be happy.
(So it makes sense for scheme to be lisp-1 and CL to be lisp-2, but
can't it in theory exist languages that are lisp-1 but with some of
CL's omelettish advantages? I think it can.)
--
One love,
Sunnan
Sunnan
> Do you mean that cases like that, which look quite strange to me,
> are puns, or that any defintion in which "list", say, was used
> as both a variable and a function name would be "punning"?
Here is the example from that thread:
(defun pr-string (s string)
(setq string (string string))
--
One love,
Sunnan
Jeff Dalton
> d95...@nada.kth.se (Björn Lindberg) writes:
> > You're making it sound like there isn't a significant difference in
> > the need for name mangling between a Lisp-1 and a Lisp-2. This is
> > obviously wrong. Common Lisp code usually don't contain any name
> > mangling at all, whereas in Scheme it is the norm.
> Of course there is a difference.
> However, I think that the difference is exaggerated. In my current
> scheme project, which is small, I admit (1226 pairs of parens), I
> didn't have any name mangling.
It's not only the cases where you do it, or have to do it;
it's something that you have to think about, or have to fix
when you get it wrong, where in a Lisp-2 the whole issue
doesn't arise.
> ... I now have six occurences of "lis" - none of them needed
> because none of them is in a scope where I use the function "list".
If I'm doing list processing, I might end up introducing a use
of list as a function.
I might not notice that it would conflict with a variable.
(This is a general problem when writing. Because you know what
you mean, you tend to see the intended interpretation of what
you write, even if it's not the only one, and even if the words
don't actually support that interpretation.)
Then there might be an annoying or obscure bug.
So I would tend to program defensively and use "lis"; I might
even adopt that as a convention. I certainly would want to
look around all the time to make sure I can safely use "list"
as a variable.
In a Lisp-2, much of this is avoided.
> I'm continually surprised over how people genuinely speak out in favor
> of lisp-2.
But why is that? Why are you suprised? There seems to be a
presumption that lisp-1 is clearly better.
All the arguments for lisp-2 really need to do is to establish
that it is a reasonable choice.
-- jd
Sunnan
> Much of the discussion of this issue in recent years (decades?)
> seems to assume that Lisp-2 is obviously worse, so that only
> historical or political reasons could explain why any language
> has two namespaces.
Right, but I like to question my own assumptions. To me Lisp-2 does
seem obviously and intuitively worse - an assumption I'm well aware
could be wrong - and thus this thread is interesting to me.
(BTW, don't knock historical or political reasons - they explain many
things in computing.)
--
One love,
Sunnan
Pascal Costanza
> But isn't the function/value separation as stands in CL also a kind of
> "special evaluation rules"?
>
> Something like "The first atom in a unquoted list is to have it's
> function value called". (Eeep, that sentence may need some revision
> but you get the gist.)
You have a similar exceptional rule in Scheme: The car of an expression
is used to determine whether it indicates the use of a function or a
macro before anything is evaluated. This determines the roles of the
members of the expression's cdr.
So the car plays a special role both in Scheme and in Common Lisp. I
don't think this can be avoided. (Unless you remove macros from the
language.)
Pascal
Sunnan
> Sunnan wrote:
>> Care to clarify?
>
> I don't find #' annoying.
The other types could be accompanied by similar read-macros.
Or wait, let's just drop this paragraph, my argument was silly in
retrospect.
> Lisp-2 removes the most important name capturing issues in macros. I
> like Common Lisp's defmacro more than Scheme's
> syntax-rules/syntax-case. The Lisp-1 vs. Lisp-2 is a purely
> aesthetical issue, whereas being able to write reasonable macros is an
> issue with clear practical relevance.
Unless I've misunderstood something:
CL-ish defmacro can be implemented in ten lines of syntax-case and is
provided with many implementations of scheme.
The original scheme community was reluctant to add macros but for
reasons other than the lisp-1/lisp-2 issue.
> (BTW, I don't think it makes sense to create a new Lisp-2. You'd only
> be reinventing the wheel.)
Ok.
--
One love,
Sunnan
Sunnan
> That's a case you might want to have and need to understand. The
> annoying name capture issues are those between values and functions,
> not those between values and values, or functions and functions. (Note
> that you have, consciously or subconsciously, chosen an example in
> which cons is replaced by a modified version thereof that you may want
> to see used in the enclosed code.)
I had trouble finding the example in the paper that you referred to. I
thought you referred to a specific example and I thought you meant the
one I chose.
IMVHO, all accidental variable capture is annoying and possibly fatal.
>>>>>(Additionally, the
>>>>>third one can be solved with the Common Lisp package system.)
>>>>
>>>>In theory Lisp-1:s can have a standardized package system. Scheme's
>>>>lack of one isn't because it's a lisp-1.
>>>
>>>Right. So?
>> Just saying that it isn't necesserily the lisp-2:iness off CL that
>> solves the third example.
>
> Huh?!? I didn't say that packages "necessarily" solve this issue. [1]
(As an aside, words I tend to misspell include "adress", "necessarily"
and "occasion". Thanks for keeping me in line.)
> I have only said that you _can_ use them for solving this issue.
Which I don't disagree with. All I'm saying is that that's not an
argument in favour of lisp-2, just an argument in favour of a good
package system.
--
One love,
Sunnan
Björn Lindberg
> d95...@nada.kth.se (Björn Lindberg) writes:
> > You're making it sound like there isn't a significant difference in
> > the need for name mangling between a Lisp-1 and a Lisp-2. This is
> > obviously wrong. Common Lisp code usually don't contain any name
> > mangling at all, whereas in Scheme it is the norm.
>
> Of course there is a difference.
>
> However, I think that the difference is exaggerated. In my current
> scheme project, which is small, I admit (1226 pairs of parens), I
> didn't have any name mangling.
So what are the *huge* benefits of Lisp-1 then? There are no huge
benefits either way.
Björn
Anton van Straaten
> In article <LHAcc.13439$yN6....@newsread2.news.atl.earthlink.net>, "Anton
> van Straaten" <an...@appsolutions.com> wrote:
> > > I can see why you think that way, but in practice about the only real
> > > difference it makes is that coming up with a good macro system for
> > > Scheme has been harder (because of the much greater likelihood of
> > > accidental variable capture in a single namespace).
> >
> > This is a myth.
> >
> > Most Schemes provide a defmacro just like CL's that works just fine, as
far
> > as defmacro goes. Scheme macro systems are addressing other issues - in
> > particular, providing a macro system that integrates with the lexical
> > structure of the underlying language, rather than being entirely unaware
of
> > that structure.
>
> This is a myth. ;-)
Your "this" is much narrower than my "this", though. :) I take back the
"entirely unaware" part, and will clarify below.
> Common Lisp macros have visibility into the lexical structure of the
> langauge through the &environment mechanism. This mechanism may not be
> specified in enough detail to fulfill all the desires of a Scheme
> programmer, but to say that CL macros are "entirely unaware" of the
> lexical structure of the language is not correct.
OK, granted. However, it's not just that the CL mechanism isn't specified
in enough detail, but that it's relatively uncontrolled. The connection to
lexical structure that I made is important here: the Scheme core language is
entirely predicated on lambda and its lexical scope. What's wanted for
Scheme is a macro system which respects that structure and integrates with
it, and even (e.g. with syntax-case) requires the programmer to be explicit
about how a macro is expected to interact with its lexical context. The
hygienic Scheme macro systems do this. "Hygiene" is a basic requirement for
such systems, but in itself it's not the end goal.
Anton
Pascal Costanza
>>Lisp-2 removes the most important name capturing issues in macros. I
>>like Common Lisp's defmacro more than Scheme's
>>syntax-rules/syntax-case. The Lisp-1 vs. Lisp-2 is a purely
>>aesthetical issue, whereas being able to write reasonable macros is an
>>issue with clear practical relevance.
>
> Unless I've misunderstood something:
>
> CL-ish defmacro can be implemented in ten lines of syntax-case and is
> provided with many implementations of scheme.
Sure, but the name capture issue bites you harder with defmacro in
Scheme, because additionally to those name captures that you sometimes
might want to have you also get name captures that you will never want
to have. You don't have the latter in CL.
Furthermore, you can implement Scheme in a few lines in a number of
languages. Does this make you want to use any of those?
> The original scheme community was reluctant to add macros but for
> reasons other than the lisp-1/lisp-2 issue.
Maybe, I can't comment on that. I am only trying to get across why I
prefer a Lisp-2. (You can count me as one of those that even adore it. ;)
Björn Lindberg
> d95...@nada.kth.se (Björn Lindberg) writes:
> > There are. Or rather, there are advantages to both ways. I think
> > ultimately it is an issue of personal preference which style you
> > prefer. The issue has been extensively discussed in the past on this
> > newsgroup, try Google groups. There is also a paper by Kent Pitman
> > comparing Lisp-1 and lisp-2.
>
> I can only find http://www.dreamsongs.com/Separation.html (also at
> http://www.nhplace.com/kent/Papers/Technical-Issues.html) which I've
> read thoroughly, several times.
That is the one I was thinking of.
> >> I am very much trying to keep it from being a Scheme vs CL
> >> "contest". I'm not trying to present either language as better than
> >> the other, but I am trying to refute some of the arguments for a
> >> lisp-2 that I don't think make sense.
> >
> > As have countless others before you...
>
> Yeah, I guess it gets pretty tiring.
>
> Well, I didn't start the thread, but I had to jump in. My main
> reaction to people adamantly defending lisp-2 is surprise and
> disunderstanding.
>
> I understand the historical/political argument, I do, but I guess I'm
> blinded by my own emotion of how neat I think it is with lisp-1:s, how
> blindingly flexible and beautiful the code can be.
>
> If someone says that they choose CL *in spite of* it being a lisp-2, I
> can definitely understand them. I like CL.
>
> If someone says that they choose a lisp-2 *because* it's a lisp-2, I
> react with "really? tell me more!"
That is strange. Some of the advantages of Lisp-2 have already been
explained to you. Even if you yourself consider the advantages of
lisp-1 to bear more weight, and prefer lisp-1 yourself, surely it is
not impossible to see why others make different choices?
> However, if someone has an argument against lisp-1 that I consider
> bogus (say, "you can't do macros" or "lisp-2 solves all name-mangling
> issues"), I might argue against that.
No one said it solves /all/ name mangling issues. However, it solves
them to a significant degree (compared to lisp-1). To a person who
does not like having to mangle names, lisp-2 is likely quite
attractive.
> My dream lisp would have the best from both scheme and CL.
Many of the best things about Scheme or CL are the results of
different trade-offs, thus irreconcileable. You can't have both lisp-1
and lisp-2 at the same time for instance.
Björn
Sunnan
> In a Lisp-2, much of this is avoided.
I guess my sentiment is as follows: in a lisp-2 you *still* have to be
careful - and even if the bug comes up a bit more seldom, it can still
bite you.
If I'm going to introduce something annoying to the language, I think
there's some kind of treshold where the benefit needs to be greater
than the annoyance.
(For CL, the radical change of going from a lisp-2 to a lisp-1 could
in itself be a big annoyance.)
>> I'm continually surprised over how people genuinely speak out in favor
>> of lisp-2.
>
> But why is that? Why are you suprised? There seems to be a
> presumption that lisp-1 is clearly better.
>
> All the arguments for lisp-2 really need to do is to establish
> that it is a reasonable choice.
The reason for my surprise could be that I've never seen the "choice"
of lisp-2 being consciously made as a design choice. It was a
historical "accident"/consequence of details of the lisp 1.5 reader.
Now, some of my favourite features of lisp is historical accidents, so
this in itself would not've been an argument for lisp-1, I know...
--
One love,
Sunnan
Sunnan
> So the car plays a special role both in Scheme and in Common Lisp. I
> don't think this can be avoided. (Unless you remove macros from the
> language.)
In my (non-existing) "dream lisp" macros can be expanded in non-car
positions. Or maybe that would suck (introduce ambiguities and so on),
but I've been seriously considering it, to see how it would work.
Or maybe some lisp-1 could have macros implemented in a way such that
"mapcar macroname list" would work.
I'm just brainstorming.
Of course, the car always plays a special role in lisp eval, that's
more or less axiomatic (some exceptions have existed). I was replying
to a particular issue of function/value separation.
--
One love,
Sunnan
Pascal Costanza
> Pascal Costanza <cost...@web.de> writes:
>
>>That's a case you might want to have and need to understand. The
>>annoying name capture issues are those between values and functions,
>>not those between values and values, or functions and functions. (Note
>>that you have, consciously or subconsciously, chosen an example in
>>which cons is replaced by a modified version thereof that you may want
>>to see used in the enclosed code.)
>
> I had trouble finding the example in the paper that you referred to. I
> thought you referred to a specific example and I thought you meant the
> one I chose.
Yep, I did. The important point is that it presents an example of name
capture between a function and a value. You have changed it to present a
name capture between two functions. That's an essential change.
> IMVHO, all accidental variable capture is annoying and possibly fatal.
This sounds like the arguments for the presumably fatal errors of
non-static type systems. The important question is whether these
"possibly fatal" consequences do regularly occur in practice. Lisp-2
makes an important class of accidental name capture completely go away.
The naming conventions for global variables cover another important
class of name captures. The rest can be dealt with with packages and
gensym. These are simple and straightforward solutions that work well in
concert. They are not available in Scheme, seemingly because they are
regarded as hacks, and therefore rejected.
> (As an aside, words I tend to misspell include "adress", "necessarily"
> and "occasion". Thanks for keeping me in line.)
Ha! You need a hygienic spell checker for editing programs. ;-))
>>I have only said that you _can_ use them for solving this issue.
>
> Which I don't disagree with. All I'm saying is that that's not an
> argument in favour of lisp-2, just an argument in favour of a good
> package system.
It's an argument for a synergistic combination of language features.
Pascal
Anton van Straaten
> "Anton van Straaten" <an...@appsolutions.com> writes:
>
> > > I can see why you think that way, but in practice about the only real
> > > difference it makes is that coming up with a good macro system for
> > > Scheme has been harder (because of the much greater likelihood of
> > > accidental variable capture in a single namespace).
> >
> > This is a myth.
>
> No it isn't.
Is too.
> The scheme designers had a very hard time coming up with a macro
> system good enough to put in the language, and one of the reasons
> ordinary Lisp defmacro-style macros were not as acceptable for
> Scheme as they were for other Lisps was the greater danger of
> unintended captures in Scheme.
Do you have any references for where this "reason" was discussed?
> > Most Schemes provide a defmacro just like CL's that works just fine,
> > as far as defmacro goes.
>
> Yes, but the point wasn't about the difficulty of coming up with
> any macro system for scheme; it was about the difficulty of coming
> up with a good one.
Defmacro works very well in Scheme, and plenty of people use it. That
negates the premise that an increased chance of accidental capture is the
reason for going after better macro systems.
The difficulty of coming up with a good macro system similarly has nothing
to do with an increased chance for accidental capture. A macro system which
interacts with the lexical structure of programs turns out to be much less
trivial than defmacro, for reasons that have nothing to do with Lisp-1 or
Lisp-2.
For the purposes of these macro systems, *any* accidental capture was
considered undesirable in principle, for the reasons I've mentioned and
others. CL is no better in this respect - accidental capture can occur, and
that was considered undesirable.
> > Scheme macro systems are addressing other issues - in
> > particular, providing a macro system that integrates with the lexical
> > structure of the underlying language, rather than being entirely unaware
> > of that structure.
>
> Do you think it has nothing to do with accidental captures?
The degree to which a Lisp-1 increases the chance of accidental captures has
no bearing on the desire for a more sophisticated macro system. That's
precisely the myth that I'm debunking.
Anton
Pascal Costanza
> Jeff Dalton <je...@todday.inf.ed.ac.uk> writes:
>
>>In a Lisp-2, much of this is avoided.
>
> I guess my sentiment is as follows: in a lisp-2 you *still* have to be
> careful - and even if the bug comes up a bit more seldom, it can still
> bite you.
See
http://groups.google.com/groups?selm=9310091717.AA29226%40inferno.lucid.com
Jeff Dalton
> What's wanted for
> Scheme is a macro system which respects that structure and integrates with
> it, and even (e.g. with syntax-case) requires the programmer to be explicit
> about how a macro is expected to interact with its lexical context. The
> hygienic Scheme macro systems do this. "Hygiene" is a basic requirement for
> such systems, but in itself it's not the end goal.
It's more than a basic requirement. I think it's fair to say
hygiene is a goal.
Many Scheme implementations had non-hygienic macro systems
before hygienic macros came along. Hygiene wasn't enough
of a basic requirement to stop those earlier macro systems
from being implemented and used. And once hygiene came along,
anyone devising a macro system for Scheme had to make it
hygienic if they wanted it to have any hope of being adopted.
There was a debate about whether macros had to be defined
using rules or whether they could be done at a lower level,
and there was some difficulty in combining the two, but
hygiene was the most important issue.
Moreover, the rules don't fit all that well with Scheme.
They're a different language.
-- jd
Erann Gat
I can't recall if anyone has mentioned this already or not, but the
definitive treatment of the lisp-1/lisp2 issues is:
http://www.dreamsongs.com/Separation.html
IMHO it should be considered required reading for anyone wishing to
participate in a discussion on this topic.
E.
Jeff Dalton
> >> Just saying that it isn't necesserily the lisp-2:iness off CL that
> >> solves the third example.
> > Huh?!? I didn't say that packages "necessarily" solve this issue. [1]
> > I have only said that you _can_ use them for solving this issue.
> Which I don't disagree with. All I'm saying is that that's not an
> argument in favour of lisp-2, just an argument in favour of a good
> package system.
The argument is that when you combine 2 namespaces with packages
and certain conventions for writing macros, you get a very usable
system that is not plagued by the sorts of conflicts hygienic
macros are designed to avoid, so that having 2 namespaces is
not nearly as bad as the enemies of 2 namespaces would have us
believe.
-- jd
Jeff Dalton
> I understand the historical/political argument, I do, but I guess I'm
> blinded by my own emotion of how neat I think it is with lisp-1:s, how
> blindingly flexible and beautiful the code can be.
There's a *political* argument? What is it? In all the years
I've been seeing arguments about this, I don't think I've ever
seen anyone give a political argument for two namespaces.
> If someone says that they choose CL *in spite of* it being a lisp-2, I
> can definitely understand them. I like CL.
>
> If someone says that they choose a lisp-2 *because* it's a lisp-2, I
> react with "really? tell me more!"
I don't choose CL only because it has two namespaces, but it's
not an "in spite of" either. Both approaches are reasonable;
I slightly prefer the two namespaces most of the time, but
not always.
-- jd
Pascal Costanza
> Pascal Costanza <cost...@web.de> writes:
>
>>So the car plays a special role both in Scheme and in Common Lisp. I
>>don't think this can be avoided. (Unless you remove macros from the
>>language.)
>
> In my (non-existing) "dream lisp" macros can be expanded in non-car
> positions. Or maybe that would suck (introduce ambiguities and so on),
> but I've been seriously considering it, to see how it would work.
You want symbol macros. Check out the CL spec. ;)
> Or maybe some lisp-1 could have macros implemented in a way such that
> "mapcar macroname list" would work.
I also think this could be neat, but I also recall reading that this was
available in some of the earlier Lisp dialects. However, I don't know
the details. The problem with this is that you cannot compile away
lexical information anymore. Whether this is a real problem - I don't know.
> Of course, the car always plays a special role in lisp eval, that's
> more or less axiomatic (some exceptions have existed). I was replying
> to a particular issue of function/value separation.
Whatever. The special role of the car position doesn't make it look too
far-fetched to opt for a Lisp-2, though. That's my point.
Jeff Dalton
> Unless I've misunderstood something:
>
> CL-ish defmacro can be implemented in ten lines of syntax-case
Let's hame 'em.
> and is provided with many implementations of scheme.
Yes, but had zero chance of getting into the standard once
hygienic macros came along.
> The original scheme community was reluctant to add macros but for
> reasons other than the lisp-1/lisp-2 issue.
The name conflict issues in lisp-1 were important. I don't
know about originally (the original scheme had macros written
in a different language (MacLisp rather than Scheme) or
outputting a different language (MacLisp again), I forget
which).
But by the time of CL standardization work (mid 80s),
hygiene was the biggest issue, and the greater problem
of capture in Lisp-1 was part of that.
They were one reason why Common Lisp couldn't just become
a Lisp-1, as well.
-- jd
Sunnan
> Sunnan <sun...@handgranat.org> writes:
>> If someone says that they choose a lisp-2 *because* it's a lisp-2, I
>> react with "really? tell me more!"
>
> That is strange. Some of the advantages of Lisp-2 have already been
> explained to you.
Well, let's see:
1. The macro issue. As far as I understand it, this argument is bogus.
2. The ability to use the same variable name twice within a scope,
once for a function and once for a non-function, because the reader
(or compiler as it may be) can disambiguate. This is sometimes a
loss (causes nonobvious code) and sometimes a win. Aesthetics and
taste play some part.
Did I miss something?
Advantages of lisp-1:
1. Less redundancy (no need for flet etc).
2. Code brevity.
Not counting, since tastes vary:
3. Various aesthetic issues, including the definition of eval.
> Even if you yourself consider the advantages of lisp-1 to bear more
> weight, and prefer lisp-1 yourself, surely it is not impossible to
> see why others make different choices?
If not impossible, at least sufficiently hard to see it that I figure
that I might be missing something.
>> However, if someone has an argument against lisp-1 that I consider
>> bogus (say, "you can't do macros" or "lisp-2 solves all name-mangling
>> issues"), I might argue against that.
>
> No one said it solves /all/ name mangling issues. However, it solves
> them to a significant degree (compared to lisp-1). To a person who
> does not like having to mangle names, lisp-2 is likely quite
> attractive.
It solves "string" and "list". I've never seen saw/sw in practice.
>> My dream lisp would have the best from both scheme and CL.
>
> Many of the best things about Scheme or CL are the results of
> different trade-offs, thus irreconcileable. You can't have both lisp-1
> and lisp-2 at the same time for instance.
No, but you can have a lisp-1 with read-macros, packages, hashes,
defmacro, and (this drives me nuts, and is one of the reasons I hang
out at cll, that I may one day remember) that one CL feature that
scheme lacks that I woke up in the middle of the night longing for and
then forgot about and I can't remember what feature that was.
--
One love,
Sunnan
Jeff Dalton
Sunnan
> Furthermore, you can implement Scheme in a few lines in a number of
> languages. Does this make you want to use any of those?
Yes. I use The Gnu Image Manipulation Program, written in C, which has
SIOD as an extention language.
In some schemes, syntax-case is defined in terms of
defmacro+gensym. In others, it's the other way around. It's all
abstraction.
>> The original scheme community was reluctant to add macros but for
>> reasons other than the lisp-1/lisp-2 issue.
>
> Maybe, I can't comment on that. I am only trying to get across why I
> prefer a Lisp-2. (You can count me as one of those that even adore
> it. ;)
Right, which is why I'm pestering you, so that I may understand this
once and for all so I'll get as tired of the issue as all the other
jaded foxes (men menar positivt) that hang out here.
--
One love,
Sunnan
Peter Seibel
> Pascal Costanza <cost...@web.de> writes:
>> So the car plays a special role both in Scheme and in Common Lisp. I
>> don't think this can be avoided. (Unless you remove macros from the
>> language.)
>
> In my (non-existing) "dream lisp" macros can be expanded in non-car
> positions. Or maybe that would suck (introduce ambiguities and so on),
> but I've been seriously considering it, to see how it would work.
You might want to look at DEFINE-SYMBOL-MACRO and SYMBOL-MACROLET in
Common Lisp.
-Peter
--
Peter Seibel pe...@javamonkey.com
Lisp is the red pill. -- John Fraser, comp.lang.lisp
Jeff Dalton
> Jeff Dalton <je...@todday.inf.ed.ac.uk> writes:
> > In a Lisp-2, much of this is avoided.
>
> I guess my sentiment is as follows: in a lisp-2 you *still* have to be
> careful - and even if the bug comes up a bit more seldom, it can still
> bite you.
You have to be careful about some things, but not about variable /
function-name conflicts, because they're in separate namespaces.
> >> I'm continually surprised over how people genuinely speak out in favor
> >> of lisp-2.
> >
> > But why is that? Why are you suprised? There seems to be a
> > presumption that lisp-1 is clearly better.
> >
> > All the arguments for lisp-2 really need to do is to establish
> > that it is a reasonable choice.
>
> The reason for my surprise could be that I've never seen the "choice"
> of lisp-2 being consciously made as a design choice. It was a
> historical "accident"/consequence of details of the lisp 1.5 reader.
Lisp 1.5 *reader*? In any case, Lisp 1.5 wasn't really a 2-namespace
Lisp. It might count as such at the top level, but not "locally".
Besides, later implementations changed many things from Lisp 1.5.
-- jd
Pascal Costanza
> Right, which is why I'm pestering you, so that I may understand this
> once and for all
I don't think I can say more about it than I have already said. The rest
is up to you...
Sunnan
> See
> http://groups.google.com/groups?selm=9310091717.AA29226%40inferno.lucid.com
Thank you very much, that was the gem of the day. I'm saving that link.
--
One love,
Sunnan
Sunnan
> You want symbol macros. Check out the CL spec. ;)
Right, that's what I mean.
>> Or maybe some lisp-1 could have macros implemented in a way such that
>> "mapcar macroname list" would work.
>
> I also think this could be neat, but I also recall reading that this
> was available in some of the earlier Lisp dialects. However, I don't
> know the details. The problem with this is that you cannot compile
> away lexical information anymore. Whether this is a real problem - I
> don't know.
(mapcar #'(lambda (x) macroname x) list) works (er... does it?), which
I can't see as much less harmful.
--
One love,
Sunnan
Sunnan
> I can't recall if anyone has mentioned this already or not, but the
> definitive treatment of the lisp-1/lisp2 issues is:
>
> http://www.dreamsongs.com/Separation.html
I linked to it in one of my first messages. No one is arguing over
technical detail (with the possible exception of the macro issue).
--
One love,
Sunnan
Sunnan
> There's a *political* argument? What is it?
There was a reluctance to make radical changes because of political
reasons. Or that's how I understand it from _The Evolution of Lisp_.
> I don't choose CL only because it has two namespaces, but it's
> not an "in spite of" either.
Right, sounds reasonable. It's the "because" that has (at least in the
past) left me wondering.
--
One love,
Sunnan
Sunnan
Sorry. I mean that cases like that are puns, not necessarily any
definition where (say) list was used as both a variable and a function
name.
--
One love,
Sunnan
Sunnan
> Sunnan <sun...@handgranat.org> writes:
>
>> Unless I've misunderstood something:
>>
>> CL-ish defmacro can be implemented in ten lines of syntax-case
>
> Let's hame 'em.
(define-syntax (define-macro x)
(syntax-case x ()
((_ (name . args) . body)
#'(define-macro name (lambda args . body)))
((_ name transformer)
#'(define-syntax (name y)
(syntax-case y ()
((k . args)
(datum->syntax-object
#'k
(apply transformer (syntax-object->datum #'args)))))))) )
From chicken's sources. (Don't shoot me, Felix!) Okay, so it's eleven.
>> and is provided with many implementations of scheme.
>
> Yes, but had zero chance of getting into the standard once
> hygienic macros came along.
A bummer. I wish syntax-case could get into the standard, though.
<snip interesting history lesson, don't know what to answer to it>
--
One love,
Sunnan
Sunnan
> Yep, I did. The important point is that it presents an example of name
> capture between a function and a value. You have changed it to present
> a name capture between two functions. That's an essential change.
Right, and I just realized it could be done in CL as well, with flet,
so I broke the "can only happen in lisp-1"-requirement with my
change. I give up on that.
Still, aren't you atleast a teensy bit impressed? I figure it'd be
fine because I didn't change the macro. All I did was to change the 5
to a monitored-cons and I got something useful out of it.
>> IMVHO, all accidental variable capture is annoying and possibly fatal.
>
> This sounds like the arguments for the presumably fatal errors of
> non-static type systems. The important question is whether these
> "possibly fatal" consequences do regularly occur in practice. Lisp-2
> makes an important class of accidental name capture completely go
> away. The naming conventions for global variables cover another
> important class of name captures. The rest can be dealt with with
> packages and gensym. These are simple and straightforward solutions
> that work well in concert. They are not available in Scheme, seemingly
> because they are regarded as hacks, and therefore rejected.
gensym is available in many implementations, including the one I use,
and they work for function names as well.
>> (As an aside, words I tend to misspell include "adress", "necessarily"
>> and "occasion". Thanks for keeping me in line.)
>
> Ha! You need a hygienic spell checker for editing programs. ;-))
Naw, I'd just need to grep for "address", "necessarily", and
"occasion". Hmm, maybe introduce that to gnus... not tonight, though.
--
One love,
Sunnan
Björn Lindberg
> d95...@nada.kth.se (Björn Lindberg) writes:
> > Sunnan <sun...@handgranat.org> writes:
> >> If someone says that they choose a lisp-2 *because* it's a lisp-2, I
> >> react with "really? tell me more!"
> >
> > That is strange. Some of the advantages of Lisp-2 have already been
> > explained to you.
>
> Well, let's see:
>
> 1. The macro issue. As far as I understand it, this argument is bogus.
I don't know enough about defmacro use in Scheme to be able to make
comparisons, but using defmacro in CL would definitely be more
inconvenient and error prone if CL were a lisp-1.
> 2. The ability to use the same variable name twice within a scope,
> once for a function and once for a non-function, because the reader
> (or compiler as it may be) can disambiguate. This is sometimes a
> loss (causes nonobvious code) and sometimes a win. Aesthetics and
> taste play some part.
I cannot see how it could ever be a /disadvantage/ to be able to not
have to mange variable names?!? Increased freedom to choose ones
variable names somehow makes people worse programmers?
> Did I miss something?
No, that is pretty much it, I think.
> Advantages of lisp-1:
>
> 1. Less redundancy (no need for flet etc).
I don't understand this one. What would you use instead of flet?
> 2. Code brevity.
I don't understand this one either. In what significant way is code
brevity enchanced by having just one namespace? Are you thinking of
FUNCALL and #'? Do you really consider that that significant?
> Not counting, since tastes vary:
>
> 3. Various aesthetic issues, including the definition of eval.
Agreed. Aesthetics are subjective, and different people find both
lisp-1 and lisp-2 more aesthetically pleasing.
> > Even if you yourself consider the advantages of lisp-1 to bear more
> > weight, and prefer lisp-1 yourself, surely it is not impossible to
> > see why others make different choices?
>
> If not impossible, at least sufficiently hard to see it that I figure
> that I might be missing something.
>
> >> However, if someone has an argument against lisp-1 that I consider
> >> bogus (say, "you can't do macros" or "lisp-2 solves all name-mangling
> >> issues"), I might argue against that.
> >
> > No one said it solves /all/ name mangling issues. However, it solves
> > them to a significant degree (compared to lisp-1). To a person who
> > does not like having to mangle names, lisp-2 is likely quite
> > attractive.
>
> It solves "string" and "list". I've never seen saw/sw in practice.
>
> >> My dream lisp would have the best from both scheme and CL.
> >
> > Many of the best things about Scheme or CL are the results of
> > different trade-offs, thus irreconcileable. You can't have both lisp-1
> > and lisp-2 at the same time for instance.
>
> No, but you can have a lisp-1 with read-macros, packages, hashes,
> defmacro, and (this drives me nuts, and is one of the reasons I hang
> out at cll,
So you basically want a Lisp which is as much as possible like CL
apart from being lisp-1? I think you should give CL a try. :-)
> that I may one day remember) that one CL feature that
> scheme lacks that I woke up in the middle of the night longing for and
> then forgot about and I can't remember what feature that was.
Special variables?
Björn
Sunnan
> You have to be careful about some things, but not about variable /
> function-name conflicts, because they're in separate namespaces.
But variables can be setq'd to lambdas, so you can have a symbol that
has one function in the value cell and one in the function cell (so to
speak). Isn't that gross? Oh, I'm getting as tired on this issue as
everybody else.
> Lisp 1.5 *reader*? In any case, Lisp 1.5 wasn't really a 2-namespace
> Lisp. It might count as such at the top level, but not "locally".
I don't really know lisp 1.5 at all yet, I must admit. Here's what
http://www.dreamsongs.com/Separation.html says:
"Lisp 1.5 broke symbols into values and functions; values were stored
on an association list, and function on the property lists of
symbols. Complied and interpreted code worked in different ways. In
the interpreter, the association list was where all bindings were
kept. When an identifier was encountered )an 'atomic symbol' in Lisp
1.5 terminology), it was taken as a variable to be evaluated for its
value. First the APVAL part of the symbol was interrogated--an APVAL
was "A Permanent, system-defined VALue". Stored in a specific place in
the symbol. Second, the association list was searched. Finally, if no
binding was found, an error was signaled."
--
One love,
Sunnan
Sunnan
> I don't know enough about defmacro use in Scheme to be able to make
> comparisons, but using defmacro in CL would definitely be more
> inconvenient and error prone if CL were a lisp-1.
All right.
>> 2. The ability to use the same variable name twice within a scope,
>> once for a function and once for a non-function, because the reader
>> (or compiler as it may be) can disambiguate. This is sometimes a
>> loss (causes nonobvious code) and sometimes a win. Aesthetics and
>> taste play some part.
>
> I cannot see how it could ever be a /disadvantage/ to be able to not
> have to mange variable names?!?
*Making* that choice is what sometimes results in a loss, not being
able to. I should've been clearer.
> Increased freedom to choose ones variable names somehow makes people
> worse programmers?
No, while many people actually think so (and argue against both CL and
scheme because of the "too much freedom"-issue), I don't.
>> Advantages of lisp-1:
>>
>> 1. Less redundancy (no need for flet etc).
>
> I don't understand this one. What would you use instead of flet?
Regular let.
CL has a lot of things done twice, in one way for functions and one
way for variables. (Scheme uses define both for variables and
functions, for example, and uses the same let for variables and
functions).
Valid scheme:
(let ((hej display)
(bjoern "Hej hej"))
(hej bjoern))
While I seldom see the equivalent CL:
(let ((hej #'princ)
(bjoern "Hej hej"))
(funcall hej bjoern))
that's not the point (I never said lisp-1 makes things possible that
can't be done with #' or funcall), the point is that lisp-2 has a lot
of (from a lisp-1 point of view) unnecessary things like flet.
>> 2. Code brevity.
>
> I don't understand this one either. In what significant way is code
> brevity enchanced by having just one namespace? Are you thinking of
> FUNCALL and #'? Do you really consider that that significant?
Yeah, I do. But see also the above point about redundancy.
>> No, but you can have a lisp-1 with read-macros, packages, hashes,
>> defmacro, and (this drives me nuts, and is one of the reasons I hang
>> out at cll,
>
> So you basically want a Lisp which is as much as possible like CL
> apart from being lisp-1? I think you should give CL a try. :-)
Well, those features are already available in many non-standard
schemes, but I do use CL some (mostly to remember that elulive
feature).
>> that I may one day remember) that one CL feature that
>> scheme lacks that I woke up in the middle of the night longing for and
>> then forgot about and I can't remember what feature that was.
>
> Special variables?
No, it could've been read macros, but I'm not sure.
--
One love,
Sunnan
Hartmann Schaffer
Sunnan <sun...@handgranat.org> writes:
> ...
> Right, which is why I'm pestering you, so that I may understand this
> once and for all so I'll get as tired of the issue as all the other
> jaded foxes (men menar positivt) that hang out here.
multiple namespaces mean that you can use the same identifier in
different contexts (i doubt that that is news to you), and tastes
differ in where the inability to do so starts to be annoying. you
might as well make the argument that, e.g. in C, each structure/union
establishing a new namespace for field names is unnecessary or
esthetically displeasing because name mangling (e.g. by chosing a
different prefix for the fields of each structure) can be applied to
resolve problems.
hs
--
Patriotism is the last refuge of the scoundrel
Samuel Johnson
Patriotism is your conviction that this country is superior to all
others because you were born in it
George Bernard Shaw
Sunnan
Okay, I got tricked into a old, tiresome and unnecessary argument (I
wonder if the OP was a troll), but
1. It never turned to flames.
2. I got some question marks straightened out.
Thanks for your patience today.
--
One love,
Sunnan
Björn Lindberg
> d95...@nada.kth.se (Björn Lindberg) writes:
> > I don't know enough about defmacro use in Scheme to be able to make
> > comparisons, but using defmacro in CL would definitely be more
> > inconvenient and error prone if CL were a lisp-1.
>
> All right.
>
> >> 2. The ability to use the same variable name twice within a scope,
> >> once for a function and once for a non-function, because the reader
> >> (or compiler as it may be) can disambiguate. This is sometimes a
> >> loss (causes nonobvious code) and sometimes a win. Aesthetics and
> >> taste play some part.
> >
> > I cannot see how it could ever be a /disadvantage/ to be able to not
> > have to mange variable names?!?
>
> *Making* that choice is what sometimes results in a loss, not being
> able to. I should've been clearer.
>
> > Increased freedom to choose ones variable names somehow makes people
> > worse programmers?
>
> No, while many people actually think so (and argue against both CL and
> scheme because of the "too much freedom"-issue), I don't.
Yes, that is exactly what I meant. I thought your argument sounded
like one of those "too much freedom can't be good"-kinds sometimes
advanced from bondage-&-discipline language camps.
> >> Advantages of lisp-1:
> >>
> >> 1. Less redundancy (no need for flet etc).
> >
> > I don't understand this one. What would you use instead of flet?
>
> Regular let.
And the disadvantage of using flet would be...? (As you no doubt know,
you can use plain old let in CL too: (let ((foo #'(lambda (...) ...)))
... (funcall foo ...)).)
> CL has a lot of things done twice, in one way for functions and one
> way for variables. (Scheme uses define both for variables and
> functions, for example, and uses the same let for variables and
> functions).
That is merely a syntactic difference. It wouldn't be hard to write a
macro DEFINE which would expand into DEFUN or DEFVAR as appropriate
(forgetting for a minute that CL does not have top level lexicals).
Björn
Jeff Dalton
> Jeff Dalton <je...@todday.inf.ed.ac.uk> writes:
> > You have to be careful about some things, but not about variable /
> > function-name conflicts, because they're in separate namespaces.
>
> But variables can be setq'd to lambdas, so you can have a symbol that
> has one function in the value cell and one in the function cell (so to
> speak). Isn't that gross?
Why? Suppose I have a data structure with several fields.
Is it gross to have functions in two of them? I'm not sure
what you think the grossness is.
In any case, that's a different issue (ie, it's not name conflicts,
accidental capture, choosing names carefully, etc).
> > Lisp 1.5 *reader*? In any case, Lisp 1.5 wasn't really a 2-namespace
> > Lisp. It might count as such at the top level, but not "locally".
>
> I don't really know lisp 1.5 at all yet, I must admit. Here's what
> http://www.dreamsongs.com/Separation.html says:
Look at the Lisp 1.5 Programmer's Manual. It should be easy
to find.
It is like a 2-namespace Lisp in some ways, but not in others.
For example, LABEL can be used to bind a function name to a
function so that it can call itself recursively. (It's
a bit like Common Lisp LABELS, but for only one function.)
But this binding goes on the a-list just like a variable
binding. There's no separate a-list for function bindings,
there's nothing on the a-list that distinguishes different
kinds of bindings, and the interpreter doesnt skip names
bound to functions when its looking up the value of a variable.
So here it's working as a Lisp 1, and these "function names"
are effectively variables.
Moreover, a variable that has a function as its value can
be written as the CAR of a form and will be called as a
function.
-- jd
Jeff Dalton
> Jeff Dalton <je...@todday.inf.ed.ac.uk> writes:
>
> > Sunnan <sun...@handgranat.org> writes:
> >
> >> Unless I've misunderstood something:
> >>
> >> CL-ish defmacro can be implemented in ten lines of syntax-case
> >
> > Let's hame 'em.
>
> (define-syntax (define-macro x)
> (syntax-case x ()
> ((_ (name . args) . body)
> #'(define-macro name (lambda args . body)))
> ((_ name transformer)
> #'(define-syntax (name y)
> (syntax-case y ()
> ((k . args)
> (datum->syntax-object
> #'k
> (apply transformer (syntax-object->datum #'args)))))))) )
>
> From chicken's sources. (Don't shoot me, Felix!) Okay, so it's eleven.
Does it impose any hygiene?
(It's been years since I've looked at any Scheme macro sys.)
-- jd
Jeff Dalton
> Jeff Dalton <je...@todday.inf.ed.ac.uk> writes:
> > There's a *political* argument? What is it?
>
> There was a reluctance to make radical changes because of political
> reasons. Or that's how I understand it from _The Evolution of Lisp_.
Political or practical? Implementations would have to change;
application code would have to change; all the bugs the change
introduced would have to be found and fixed.
What do you have in mind in _Evolution_?
-- jd
Tim Bradshaw
> Am I just
> wrong, or is Scheme just more elegant than CL?
You are exactly right. BCPL is also more elegant than C. All
languages are more elegant than Perl (this is a lie, but you don't
want to think about the ones that aren't). Practically any processor
design is more elegant than any x86-family CPU. Plan 9 is more
elegant than Unix. Nothing was more elegant than ITS (what's ITS? you
say). Lisp is more elegant than Python. Python is less elegant than
Perl. English is less elegant than French. Latin is more elegant
than either, except in its numbers.
--tim
Lars Brinkhoff
> The reason for my surprise could be that I've never seen the "choice"
> of lisp-2 being consciously made as a design choice. It was a
> historical "accident"/consequence of details of the lisp 1.5 reader.
It may have been a conscious design choise in ISLisp.
--
Lars Brinkhoff, Services for Unix, Linux, GCC, HTTP
Brinkhoff Consulting http://www.brinkhoff.se/
Sunnan
> Sunnan <sun...@handgranat.org> writes:
>> (define-syntax (define-macro x)
>> (syntax-case x ()
>> ((_ (name . args) . body)
>> #'(define-macro name (lambda args . body)))
>> ((_ name transformer)
>> #'(define-syntax (name y)
>> (syntax-case y ()
>> ((k . args)
>> (datum->syntax-object
>> #'k
>> (apply transformer (syntax-object->datum #'args)))))))) )
>>
>> From chicken's sources. (Don't shoot me, Felix!) Okay, so it's eleven.
>
> Does it impose any hygiene?
As far as I understand it, the transformations between datum and
syntax-object allows you to get around the hygiene.
It's like datums and syntax-objects have separate namespaces (!) and
you can have explicit translations between them when you actually want
to.
--
One love,
Sunnan
Sunnan
> Why? Suppose I have a data structure with several fields.
> Is it gross to have functions in two of them? I'm not sure
> what you think the grossness is.
Ok, so in CL, each and every variable is in essence a data structure
with several fields, and convention has it that one of them is
generally used for functions (i.e. the slot that's assigned with
defun). I guess the grossness that I initially felt is very
subjective.
> In any case, that's a different issue (ie, it's not name conflicts,
> accidental capture, choosing names carefully, etc).
Right.
> Look at the Lisp 1.5 Programmer's Manual. It should be easy
> to find.
Thanks, I'll check it out.
--
One love,
Sunnan
Sunnan
> Yes, that is exactly what I meant. I thought your argument sounded
> like one of those "too much freedom can't be good"-kinds sometimes
> advanced from bondage-&-discipline language camps.
However (and this is a non-argument because it's based on personal
aesthetics), I prefer freedom based on simplicity.
> And the disadvantage of using flet would be...?
It's a disadvantage for implementors and for learners of the
language. It's brain clutter.
> (As you no doubt know, you can use plain old let in CL too: (let
> ((foo #'(lambda (...) ...))) ... (funcall foo ...)).)
Yeah, didn't I include such an example somewhere?
>> CL has a lot of things done twice, in one way for functions and one
>> way for variables. (Scheme uses define both for variables and
>> functions, for example, and uses the same let for variables and
>> functions).
>
> That is merely a syntactic difference. It wouldn't be hard to write a
> macro DEFINE which would expand into DEFUN or DEFVAR as appropriate
> (forgetting for a minute that CL does not have top level lexicals).
No, it's more than a syntactic difference - you still need to have
both DEFUN and DEFVAR implemented underneath.
--
One love,
Sunnan
Frode Vatvedt Fjeld
>> And the disadvantage of using flet would be...?
Sunnan <sun...@handgranat.org> writes:
> It's a disadvantage for implementors and for learners of the
> language. It's brain clutter.
In my opinion, a much stronger case can be made for the viewpoint that
lexical variables and lexical functions are conceptually quite
different things, and that shoe-horning both concepts into the same
language construct is what really constitutes brain clutter. I'm very
happy that when I see a "let" I immediately know it's a variable
binding, without having to examine the binding's value or usage. I
find that my brain has absolutely no problems dealing with the burden
of knowing both "let" and "flet".
I'd even be inclined to consider whether Common Lisp is "cluttering"
let by using it for both lexical and dynamic variable bindings.
--
Frode Vatvedt Fjeld
Björn Lindberg
> d95...@nada.kth.se (Björn Lindberg) writes:
> > Yes, that is exactly what I meant. I thought your argument sounded
> > like one of those "too much freedom can't be good"-kinds sometimes
> > advanced from bondage-&-discipline language camps.
>
> However (and this is a non-argument because it's based on personal
> aesthetics), I prefer freedom based on simplicity.
Lisp-1 and lisp-2 are both simple, but in different ways.
> > And the disadvantage of using flet would be...?
>
> It's a disadvantage for implementors and for learners of the
> language.
The number of users of a language far exceeds its learners. A language
design meant for real use should be optimized with this in
consideration.
> It's brain clutter.
I disagree. It describes intent, and can help make the code clearer
(to a human reader). But if this is your view, I am not surprised you
have a hard time coming to terms with CL. FLET and LABELS, FIRST &
REST vs CAR & CDR, DEFVAR, DEFPARAMETER, DEFCONSTANT, etc. The number
of similar-but-slightly-different operators abound...
> > (As you no doubt know, you can use plain old let in CL too: (let
> > ((foo #'(lambda (...) ...))) ... (funcall foo ...)).)
>
> Yeah, didn't I include such an example somewhere?
>
> >> CL has a lot of things done twice, in one way for functions and one
> >> way for variables. (Scheme uses define both for variables and
> >> functions, for example, and uses the same let for variables and
> >> functions).
> >
> > That is merely a syntactic difference. It wouldn't be hard to write a
> > macro DEFINE which would expand into DEFUN or DEFVAR as appropriate
> > (forgetting for a minute that CL does not have top level lexicals).
>
> No, it's more than a syntactic difference - you still need to have
> both DEFUN and DEFVAR implemented underneath.
Ok, but a DEFINE could be implemented in a CL directly, without using
DEFUN and DEFVAR too. The only difference is which cell of the symbol
something is put.
Björn
Sunnan
> The number of users of a language far exceeds its learners. A language
> design meant for real use should be optimized with this in
> consideration.
Of course.
> I disagree. It describes intent, and can help make the code clearer
> (to a human reader). But if this is your view, I am not surprised you
> have a hard time coming to terms with CL. FLET and LABELS, FIRST &
> REST vs CAR & CDR, DEFVAR, DEFPARAMETER, DEFCONSTANT, etc. The number
> of similar-but-slightly-different operators abound...
Yeah, I think you understand me now. I'm thinking that Once And Only
Once can lead to code that's simultaneously short and clear.
> Ok, but a DEFINE could be implemented in a CL directly, without using
> DEFUN and DEFVAR too. The only difference is which cell of the symbol
> something is put.
All right.
--
One love,
Sunnan
Marcin 'Qrczak' Kowalczyk
> In my opinion, a much stronger case can be made for the viewpoint that
> lexical variables and lexical functions are conceptually quite
> different things,
The point is, they are not that different. Lisp treats them differently,
but a function is just a special case of an object. A lexical variable
can hold anything; a lexical function can hold only functions. You can
do everything with the more general concept only, lexical variables.
--
__("< Marcin Kowalczyk
\__/ qrc...@knm.org.pl
^^ http://qrnik.knm.org.pl/~qrczak/
Björn Lindberg
> On Wed, 07 Apr 2004 13:41:11 +0200, Frode Vatvedt Fjeld wrote:
>
> > In my opinion, a much stronger case can be made for the viewpoint that
> > lexical variables and lexical functions are conceptually quite
> > different things,
>
> The point is, they are not that different. Lisp treats them differently,
> but a function is just a special case of an object. A lexical variable
> can hold anything; a lexical function can hold only functions. You can
> do everything with the more general concept only, lexical variables.
But there is a conceptual difference as well. Functions *operate* on
objects, apart from being objects themselves. Typically, all other
kinds of objects are *operated upon*. So in the sense of how they are
used, functions are conceptually different from all other objects.
(This is also why Sunnan's reductio ad absurdam of having separate
namespaces for all different object types is not really relevant.)
Björn
Anton van Straaten
> "Anton van Straaten" <an...@appsolutions.com> writes:
>
> > What's wanted for
> > Scheme is a macro system which respects that structure and integrates
with
> > it, and even (e.g. with syntax-case) requires the programmer to be
explicit
> > about how a macro is expected to interact with its lexical context. The
> > hygienic Scheme macro systems do this. "Hygiene" is a basic requirement
for
> > such systems, but in itself it's not the end goal.
>
> It's more than a basic requirement. I think it's fair to say
> hygiene is a goal.
I don't mean to quibble about that. I'm trying to express that hygiene is
part of a bigger picture.
For example, in Bawden & Rees' 1988 paper "Syntactic Closures", after
describing the various scenarios which violate hygiene and referential
transparency, the authors summarize it like this:
"All of these problems are consequences of the fact that macros are
oblivious to the lexical scoping of the program text that they are
constructing. Any macro facility that proposes to address this shortcoming
also has to take into account that sometimes the macro writer needs explicit
control over scoping."
It's this desire to integrate with lexical scoping, which also implies
referential transparency, that in Scheme at least, drives the design of
these macro systems. Hygiene is just a really basic issue you have to take
care of in order to achieve that.
To some extent, the term "hygienic macro" focuses on a particular technical
requirement of the implementation of these macro systems, and may cause the
larger context to be missed, as in "geez, you designed a whole complicated
new macro system just to avoid unintended capture??", when there's a lot
more to it than that. It would be a bit like assuming that LISP is only
good for LISt Processing (which someone just did in the last couple of
days).
In addition, assuming that the perceived complexity and difference of these
macro systems is all because of hygiene, or even the broader lexical scoping
problem, would be a mistake. They address a number of other issues which
aren't strictly required to deal with hygiene, for example pattern matching
of syntax, a template substitution system that supports pattern variables
that don't need to be quoted, templates that can specify the expansion of
repetitive forms, and an abstract data type for syntax that supports richer
representations of programs.
> Many Scheme implementations had non-hygienic macro systems
> before hygienic macros came along. Hygiene wasn't enough
> of a basic requirement to stop those earlier macro systems
> from being implemented and used.
Right, I'm saying hygiene was a basic requirement for macro systems which
attempted to be more sophisticated than the non-hygienic systems. It was
certainly a goal in the sense that it had to be achieved in order to achieve
the primary broader goal of integration with lexical scoping.
> And once hygiene came along,
> anyone devising a macro system for Scheme had to make it
> hygienic if they wanted it to have any hope of being adopted.
Yeah - it was a basic requirement. Now, I'm quibbling. :)
> There was a debate about whether macros had to be defined
> using rules or whether they could be done at a lower level,
> and there was some difficulty in combining the two, but
> hygiene was the most important issue.
I think this somewhat misses the point. Hygiene was very important - you
couldn't integrate macros with lexical scope without it. But it's
nevertheless a kind of implementation detail.
> Moreover, the rules don't fit all that well with Scheme.
> They're a different language.
It sounds like you're talking about syntax-rules. In that case, since
standard Scheme is not allowed within syntax-rules macros, you do indeed
have a different language, one which is guaranteed to interact correctly
with the lexical structure of the target language. However, systems like
syntax-case, which allow ordinary Scheme code, are very much the same
language as Scheme - it's ordinary Scheme augmented by some macros and
abstract data types, like much other Scheme code.
Anton
Pascal Costanza
Marcin 'Qrczak' Kowalczyk wrote:
> On Wed, 07 Apr 2004 13:41:11 +0200, Frode Vatvedt Fjeld wrote:
>
>
>>In my opinion, a much stronger case can be made for the viewpoint that
>>lexical variables and lexical functions are conceptually quite
>>different things,
>
> The point is, they are not that different. Lisp treats them differently,
> but a function is just a special case of an object. A lexical variable
> can hold anything; a lexical function can hold only functions. You can
> do everything with the more general concept only, lexical variables.
You're mixing up things here. You can compare values and function
objects, or variable bindings and function bindings. Variable bindings
are indeed more general than function bindings, but function objects and
values are treated differently even in Scheme. That's trivial.
However, Scheme also treats the car position in an expression
differently from the cdr positions. The car determines the meaning of an
expression, the cdrs don't. That's the essential part. In Lisp, the car
position is looked up in a different namespace, and _of course_ it only
makes sense to put function objects there. How would you call a value?
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/
Marcin 'Qrczak' Kowalczyk
>> The point is, they are not that different. Lisp treats them differently,
>> but a function is just a special case of an object. A lexical variable
>> can hold anything; a lexical function can hold only functions. You can
>> do everything with the more general concept only, lexical variables.
>
> You're mixing up things here. You can compare values and function
> objects, or variable bindings and function bindings.
I compare both pairs.
> Variable bindings are indeed more general than function bindings, but
> function objects and values are treated differently even in Scheme.
In Scheme function objects are a special case of values, just as function
bindings are a special case of value bindings.
In Lisp function objects are also a special case of values, but function
bindings are not a subset of value bindings - they are made disjoint.
> However, Scheme also treats the car position in an expression
> differently from the cdr positions.
Except for macros, they are evaluated using the same rules. The expression
to give as a function is a special case of an expression to give as an
argument. It can use the same set of operations for evaluation, with
the only restriction being that it must evaluate to a function object.
Every value which can be applied can also be passed as a parameter.
Macros are an exception, they make sense only when directly applied. They
are not first class objects. But functions *are* first class objects, so
it's natural to treat them as a subset of values, rather than completely
different things.
> In Lisp, the car position is looked up in a different namespace, and
> _of course_ it only makes sense to put function objects there. How would
> you call a value?
It only makes sense to put numbers as arguments of +, but Lisp doesn't
enforce it by putting variables holding numbers in a separate namespace.
So having only a subset of values legal is not enough to justify separate
namespaces.
Separate namespaces for two kinds of things don't cause trouble (other
than perhaps human confusion) in cases the usage of the kinds is disjoint.
For example C types and C values are never interchangeable. But it's
not the case for functions and other values: it does make sense to have
functions as arguments to other functions, and to call functions which
came as parameters or are computed by function calls. Separate namespaces
make it harder.
I understand how separate namespaces make non-hygienic macros a smaller
problem, and that some people like punning, but I can't agree that those
namespaces should be separated because of a fundamental difference between
functions and other objects. At least in a functional language, where
functions *are* objects.
Matthew Danish
> In Scheme function objects are a special case of values, just as function
> bindings are a special case of value bindings.
>
> In Lisp function objects are also a special case of values, but function
> bindings are not a subset of value bindings - they are made disjoint.
Keep in mind that ordinary variables may also be bound to functions.
> It only makes sense to put numbers as arguments of +, but Lisp doesn't
> enforce it by putting variables holding numbers in a separate namespace.
> So having only a subset of values legal is not enough to justify separate
> namespaces.
In a statically typed language, it is conceivable to imagine a separate
namespace for every type:
(let ((a 1)
(a "a"))
(setf a (+ a 1)) ;; A the integer
(setf a (string a))) ;; A the string
Of course, Lisp is not like this, but there is a distinction which can
be statically determined: syntactic position. Neither in Scheme nor in
CL is ((not-a-fn-value) ...) a valid program; but in CL this can be
determined statically, and in Scheme it can only be found at runtime.
In addition, in a conforming CL program, by looking up the function name
in the function namespace, it is known that if the name is bound there
then it must be bound to a function object. There is no such guarantee
in Scheme.
> Separate namespaces for two kinds of things don't cause trouble (other
> than perhaps human confusion) in cases the usage of the kinds is disjoint.
> For example C types and C values are never interchangeable. But it's
> not the case for functions and other values: it does make sense to have
> functions as arguments to other functions, and to call functions which
> came as parameters or are computed by function calls. Separate namespaces
> make it harder.
However this is partially incorrect: while it does make sense to have
higher-order functions (and Lisp-2 does not make this difficult), the
important distinction actually lies in the syntax of forms, not in the
type of objects. Without knowing anything about the runtime values
involved, it is quite clear that the first element of a function form
must be a function. CL takes this fact and makes it a part of the
language, along with macro and special forms which also can (and must)
be determined statically. So my question is: why would you want the
names of functions and the names of variables to be in the same
namespace, when the primary use of function names is to appear where a
variable name would rarely want to appear?
Consider the case of class names: why should a class named FOO prevent
the use of variables named FOO? The only time I would be referring the
class by the name FOO is in contexts which expect a class name. If, on
the rare occasion I need to get the class object which is bound to the
class name FOO, there is FIND-CLASS.
> I understand how separate namespaces make non-hygienic macros a smaller
> problem, and that some people like punning, but I can't agree that those
> namespaces should be separated because of a fundamental difference between
> functions and other objects. At least in a functional language, where
> functions *are* objects.
Remember, it is function /names/ which are separated. Function objects
don't have anything to do with namespaces. The distinction is a
syntactic one. When we write (NAME ...) we want NAME to be bound to a
function. The separate namespace guarantees it won't be bound to any
other type of object in a conforming program.
--
; Matthew Danish <mda...@andrew.cmu.edu>
; OpenPGP public key: C24B6010 on keyring.debian.org
; Signed or encrypted mail welcome.
; "There is no dark side of the moon really; matter of fact, it's all dark."
Thomas A. Russ
> In scheme you have to change the variable name a little.
>
> (define (hack-the-list list-)
> (list (hackhackhack list-)))
>
> How is that much less elegant than CL having to add #' pretty often?
> (uses of mapcar comes to mind).
Well, in most Common Lisp code, you actually don't end up really using
#' "pretty often". In part that is because there tends to be a bit less
use of mapping functions and more use of iteration constructs. As a
practical matter, it then comes down to Common Lisp having a system
where more effort is needed in the uncommon situations of passing
functions as arguments rather in the vastly more common situation of
naming variables.
> (Common idioms are lis and lst.)
>
> So CL-ers have to add #' and funcalls in some situations, and schemers
> have to change their names in some others. The same inelegancy.
>
> However, I can't think of any drawback with a lisp-1 that a lisp-2
> doesn't also have.
Well, maybe. The real problem is that Common Lisp isn't really a lisp-2
system anymore. It is a lisp-n where n is greater than two. In
addition to namespaces for variables and functions, Common Lisp also has
namespaces for:
classes
packages
and maybe a couple of other things I've forgotten about. That means
that more of the name interpretation is context dependent in the
language. Now, one could mandate that all of these namespaces be
joined, but it seems that people don't seem to have trouble using the
same name for different purposes as long as it is clear from context
which purpose is intended. It is just when one wants to use a name in a
foreign context that some special effort is needed.
--
Thomas A. Russ, USC/Information Sciences Institute
Jeff Dalton
> Well, maybe. The real problem is that Common Lisp isn't really a lisp-2
> system anymore. It is a lisp-n where n is greater than two. In
> addition to namespaces for variables and functions, Common Lisp also has
> namespaces for:
>
> classes
> packages
I would say that neither have namespaces in the sense of "namespace"
that gives us Lisp-1 and Lisp-2. Namespaces are about identifiers in
code, rather than data uses of symbols. They're about different
interpretation in the interpreter or compiler, rather than data
mappings performed by (essentially) library procedures such as
find-class or find-package.
There's a namespace of go tags and another for block names,
so that CL is a Lisp-4.
There might be some ones added after CLTL 1, but I don't
remember any off hand.
In the early days of CL, Guy Steele wrote sample interpreters
to show how the language worked. They used a 4-part environment
(one per namespace), like this:
;;; This evaluator splits the lexical environment into four
;;; logically distinct entities:
;;; VENV = lexical variable environment
;;; FENV = lexical function and macro environment
;;; BENV = block name environment
;;; GENV = go tag environment
;;; Each environment is an a-list.
...
(defstruct interpreted-lexical-closure function venv fenv benv genv)
...
(defun eval (exp)
(*eval exp nil nil nil nil))
;;; *EVAL looks useless here, but does more complex things
;;; in alternative implementations of this evaluator.
(defun *eval (exp venv fenv benv genv)
(%eval exp venv fenv benv genv))
;;; Function names beginning with "%" are intended to be internal
;;; and not defined in the Common LISP white pages.
...
-- jd
Jeff Dalton
> > And the disadvantage of using flet would be...?
>
> It's a disadvantage 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
Frode Vatvedt Fjeld
> In Lisp function objects are also a special case of values, but
> function bindings are not a subset of value bindings - they are made
> disjoint.
I find this statement utterly confused.
A lexical function binding, to me, means approximately: "In this
lexical environment I'll have this (function) operator available that
operates so an so". By no stretch of the imagination can this concept
be called "a subset of value bindings". Scheme overloads let with two
completely separate concepts, leaving the burden of disentangling the
resulting code's meaning to the human reader.
> Macros are an exception, they make sense only when directly
> applied. They are not first class objects. But functions *are* first
> class objects, so it's natural to treat them as a subset of values,
> rather than completely different things.
> [...]
> I understand how separate namespaces make non-hygienic macros a
> smaller problem, and that some people like punning, but I can't
> agree that those namespaces should be separated because of a
> fundamental difference between functions and other objects. At least
> in a functional language, where functions *are* objects.
The fact that functions are objects does not imply that there is not a
fundamental difference between functions (in general, not just in the
role "functions as objects") and other objects.
To me, the fundamental difference is obvious. Programming is to
instruct computers to do something, and the most important unit of
"doing something", certainly in Lisp, is the function. A large
percentage of all the forms one writes are of the sort "apply the
function named <foo> to these objects". No other class of objects
comes remotely close in terms of important fundamental difference from
the rest. In theory, I could make do without arrays, conses, or even
numbers, but not without functions. The fact that functions are also
objects is interesting, and perhaps even fascinating, but clearly does
not diminish their unique position.
--
Frode Vatvedt Fjeld
Cameron MacKinnon
> 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
> Sunnan <sun...@handgranat.org> writes:
>
>> > And the disadvantage of using flet would be...?
>>
>> It's a disadvantage 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.
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 weeks 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 disadvantages 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.droberts.com
Rob Warnock
+---------------
| Jeff Dalton <je...@todday.inf.ed.ac.uk> writes:
| > Why? Suppose I have a data structure with several fields.
| > Is it gross to have functions in two of them? I'm not sure
| > what you think the grossness is.
|
| Ok, so in CL, each and every variable is in essence a data structure
| with several fields, and convention has it that one of them is
| generally used for functions (i.e. the slot that's assigned with defun).
By the way, Perl is much like CL in this case -- every variable (symbol)
is in essence a data structure with several fields -- except that Perl
has chosen a particular reader macro character as an explicit indicator
of each slot:
$ for the scalar value binding, e.g., $foo
@ for the array value binding
% for the associative-array value binding
Capitalization for the I/O stream binding, e.g., FOO
* for "the symbol itself" (a.k.a. the "glob"), which
gives access to *all* of the bindings (and which is the
only way, AFAIK, to pass an I/O stream as a parameter).
-Rob
-----
Rob Warnock <rp...@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607