From: Burton Samograd
Subject: seperation of function namespace
Date:
Message-ID: <87k68lyisg.fsf@gmail.com>
Hi,
Are there any pointers as to discussion and/or benefits of seperating
the function namespace in more modern lisps. I can understand a bit
about why it was done, but I can't see the most obvious reason of
naming functions the same as a varaible to be very convincing. To me,
I'm just finding more of an inconvenience with my starting out
practical Lisp knowledge, but I'm sure I can be corrected with the
proper evidence and persuasion.
--
burton samograd kruhft .at. gmail
kruhft.blogspot.com www.myspace.com/kruhft metashell.blogspot.com
Burton Samograd wrote:
> To me,
> I'm just finding more of an inconvenience with my starting out
> practical Lisp knowledge, but I'm sure I can be corrected with the
> proper evidence and persuasion.
What value is there to someone, for instance me, in persuading you of
anything?
Do you stand between me and something that I want?
The information is there; make up your own mind.
Newbies who require persuasion are typically just passive-aggressive
attention seekers, who come with an agenda other than the willingness
to learn: namely, they just want to engage their personality against
another one.
If you're finding Common Lisp namespaces inconvenient, then maybe
you're just not wired for that type of language. Go program in
something in which variables, type names, goto labels, exception
handlers, and all other entities are entered into the same namespace.
From: Burton Samograd
Subject: Re: seperation of function namespace
Date:
Message-ID: <87wtclwbfc.fsf@gmail.com>
"Kaz Kylheku" <········@gmail.com> writes:
> Burton Samograd wrote:
>> To me,
>> I'm just finding more of an inconvenience with my starting out
>> practical Lisp knowledge, but I'm sure I can be corrected with the
>> proper evidence and persuasion.
>
> What value is there to someone, for instance me, in persuading you of
> anything?
>
> Do you stand between me and something that I want?
I hope not; I'm not even standing right now...
> The information is there; make up your own mind.
That's why I asked for some pointers to it.
> Newbies who require persuasion are typically just passive-aggressive
> attention seekers, who come with an agenda other than the willingness
> to learn: namely, they just want to engage their personality against
> another one.
Passive aggressive indeed. I was just curious about why such a scheme
was chosen, not trying to say it was a bad decision.
> If you're finding Common Lisp namespaces inconvenient, then maybe
> you're just not wired for that type of language. Go program in
> something in which variables, type names, goto labels, exception
> handlers, and all other entities are entered into the same
> namespace.
Just for now, I asked because I want to learn. With help and friends
like this, it's no wonder people give up so easy.
--
burton samograd kruhft .at. gmail
kruhft.blogspot.com www.myspace.com/kruhft metashell.blogspot.com
In article <························@j55g2000cwa.googlegroups.com>,
"Kaz Kylheku" <········@gmail.com> wrote:
> Burton Samograd wrote:
> > To me,
> > I'm just finding more of an inconvenience with my starting out
> > practical Lisp knowledge, but I'm sure I can be corrected with the
> > proper evidence and persuasion.
>
> What value is there to someone, for instance me, in persuading you of
> anything?
>
> Do you stand between me and something that I want?
>
> The information is there; make up your own mind.
>
> Newbies who require persuasion are typically just passive-aggressive
> attention seekers, who come with an agenda other than the willingness
> to learn: namely, they just want to engage their personality against
> another one.
>
> If you're finding Common Lisp namespaces inconvenient, then maybe
> you're just not wired for that type of language. Go program in
> something in which variables, type names, goto labels, exception
> handlers, and all other entities are entered into the same namespace.
The reason Kaz is being so defensive is that there is no principled
justification for Lisp-2. It's just a hack, and a pretty horrible one
at that. There are only one benefit [1]: avoiding a certain class of
unintended name capture in macros. It turns out that this benefit can
be had in various other ways, but this was not known at the time Common
Lisp was designed.
rg
[1] Actually there is a second benefit: making certain kinds of compiler
optimizations easier to implement. But this is generally considered a
minor benefit, and is not often cited as a rationale for Lisp-2.
Ron Garret wrote:
> The reason Kaz is being so defensive is that there is no principled
> justification for Lisp-2.
The only reason Kaz /looks/ defensive to you with respect to this topic
is that you are obsessed with it.
> It's just a hack, and a pretty horrible one at that.
Au contraire, it's actually a very clever psychological hack. And, by
golly, it has you. It's all you write about here.
There are so many interesting topics to explore related to Lisp, yet
you continue to harp on one of the most boring.
After more than twenty years of Lisp, how did you arrive at the point
where you consider some dumb macro for hiding funcall to be even
remotely interesting?
Alcohol?
Ron Garret wrote:
> In article <························@j55g2000cwa.googlegroups.com>,
> "Kaz Kylheku" <········@gmail.com> wrote:
>
>> Burton Samograd wrote:
>>> To me,
>>> I'm just finding more of an inconvenience with my starting out
>>> practical Lisp knowledge, but I'm sure I can be corrected with the
>>> proper evidence and persuasion.
>> What value is there to someone, for instance me, in persuading you of
>> anything?
>>
>> Do you stand between me and something that I want?
>>
>> The information is there; make up your own mind.
>>
>> Newbies who require persuasion are typically just passive-aggressive
>> attention seekers, who come with an agenda other than the willingness
>> to learn: namely, they just want to engage their personality against
>> another one.
>>
>> If you're finding Common Lisp namespaces inconvenient, then maybe
>> you're just not wired for that type of language. Go program in
>> something in which variables, type names, goto labels, exception
>> handlers, and all other entities are entered into the same namespace.
>
> The reason Kaz is being so defensive is that there is no principled
> justification for Lisp-2. It's just a hack, and a pretty horrible one
> at that. There are only one benefit [1]: avoiding a certain class of
> unintended name capture in macros.
I don't want to comment on Kaz's posting. I agree that Lisp-2 is a hack,
like almost everything in both Lisp and Scheme ;), but the good thing
about hacks is that they tend to work. I strongly disagree that Lisp-2
is a horrible hack. Another benefit of Lisp-2 (or Lisp-n) is that it
allows you to have puns in your source code, which can increase its
readability. (list list) is just one example. (For that matter, Lisp-2
avoids certain name clashes everywhere, not just in macros.)
> It turns out that this benefit can
> be had in various other ways, but this was not known at the time Common
> Lisp was designed.
Of course it was. IIUC, a hygienic macro system was indeed suggested for
inclusion in ANSI Common Lisp.
Pascal
--
3rd European Lisp Workshop
July 3-4 - Nantes, France - co-located with ECOOP 2006
http://lisp-ecoop06.bknr.net/
Pascal Costanza wrote:
> Ron Garret wrote:
> > The reason Kaz is being so defensive is that there is no principled
> > justification for Lisp-2. It's just a hack, and a pretty horrible one
> > at that. There are only one benefit [1]: avoiding a certain class of
> > unintended name capture in macros.
>
> I don't want to comment on Kaz's posting. I agree that Lisp-2 is a hack,
> like almost everything in both Lisp and Scheme ;), but the good thing
> about hacks is that they tend to work. I strongly disagree that Lisp-2
> is a horrible hack. Another benefit of Lisp-2 (or Lisp-n) is that it
> allows you to have puns in your source code, which can increase its
> readability. (list list) is just one example. (For that matter, Lisp-2
> avoids certain name clashes everywhere, not just in macros.)
You've been using the word "hack" a bit recently. It seems you have an
interesting definition of it; what do you mean by that term?
Could manufactured straight lines be kinda seen as a hack in that view,
as they're not as impossibly straight and thin as a mathematically
straight line?
Would Lisp's use of the reader (including parentheses, #', etc) be also
seen as a hack due to the needs of people entering code objects into
our terminals?
Tayssir
Tayssir John Gabbour wrote:
> Pascal Costanza wrote:
>> Ron Garret wrote:
>>> The reason Kaz is being so defensive is that there is no principled
>>> justification for Lisp-2. It's just a hack, and a pretty horrible one
>>> at that. There are only one benefit [1]: avoiding a certain class of
>>> unintended name capture in macros.
>> I don't want to comment on Kaz's posting. I agree that Lisp-2 is a hack,
>> like almost everything in both Lisp and Scheme ;), but the good thing
>> about hacks is that they tend to work. I strongly disagree that Lisp-2
>> is a horrible hack. Another benefit of Lisp-2 (or Lisp-n) is that it
>> allows you to have puns in your source code, which can increase its
>> readability. (list list) is just one example. (For that matter, Lisp-2
>> avoids certain name clashes everywhere, not just in macros.)
>
> You've been using the word "hack" a bit recently. It seems you have an
> interesting definition of it; what do you mean by that term?
Are you asking Ron or me?
Pascal
--
3rd European Lisp Workshop
July 3-4 - Nantes, France - co-located with ECOOP 2006
http://lisp-ecoop06.bknr.net/
Pascal Costanza wrote:
> Tayssir John Gabbour wrote:
> >> I don't want to comment on Kaz's posting. I agree that Lisp-2 is a hack,
> >> like almost everything in both Lisp and Scheme ;), but the good thing
> >> about hacks is that they tend to work. I strongly disagree that Lisp-2
> >> is a horrible hack. Another benefit of Lisp-2 (or Lisp-n) is that it
> >> allows you to have puns in your source code, which can increase its
> >> readability. (list list) is just one example. (For that matter, Lisp-2
> >> avoids certain name clashes everywhere, not just in macros.)
> >
> > You've been using the word "hack" a bit recently. It seems you have an
> > interesting definition of it; what do you mean by that term?
>
> Are you asking Ron or me?
I'm asking you. (Saying "almost everything in both Lisp and Scheme" is
a hack seemed like an interesting half-joke.)
Tayssir
Tayssir John Gabbour wrote:
> Pascal Costanza wrote:
>> Tayssir John Gabbour wrote:
>>>> I don't want to comment on Kaz's posting. I agree that Lisp-2 is a hack,
>>>> like almost everything in both Lisp and Scheme ;), but the good thing
>>>> about hacks is that they tend to work. I strongly disagree that Lisp-2
>>>> is a horrible hack. Another benefit of Lisp-2 (or Lisp-n) is that it
>>>> allows you to have puns in your source code, which can increase its
>>>> readability. (list list) is just one example. (For that matter, Lisp-2
>>>> avoids certain name clashes everywhere, not just in macros.)
>>> You've been using the word "hack" a bit recently. It seems you have an
>>> interesting definition of it; what do you mean by that term?
>> Are you asking Ron or me?
>
> I'm asking you. (Saying "almost everything in both Lisp and Scheme" is
> a hack seemed like an interesting half-joke.)
Hm, ok. Now I have to improvise. ;)
The "almost everything is a hack in both Lisp and Scheme" is a reference
to the historical origin of this language family. John McCarthy didn't
have the intention that s-expressions are used as the surface syntax of
Lisp/Scheme, he actually wanted m-expressions, which look more like what
you have in Haskell or ML nowadays. S-expressions are basically just a
"hack" to make certain kinds of reasoning about syntax simpler.
Dynamic scoping was an accident, and probably not intended. But it turns
out to be quite useful for a number of purposes. (Although lexical
scoping by default is indeed better.)
Lisp-2 was an accident, but turns out to be quite useful in conjunction
with macros.
Computational reflection just happened to be an element of a
metacircular implementation of Lisp, which was later investigated in
more detail and resulted in 3-Lisp and the CLOS MOP, among other things.
My attempt at explaining what a hack is would probably be: Something
which just happens to solve a problem and which isn't carefully thought
through. (A hack doesn't have to be accidental, you can also
intentionally apply a hack without understanding all its consequences,
or without having "first principles" from which it is derived.)
Another interesting tidbit here is that the distribution of powerful vs.
simplified features across Common Lisp and Scheme is quite odd. For
example, Scheme has call/cc which is no doubt a very powerful construct,
but at the same time provides only syntax-rules macros which don't give
you a lot of expressive power. Common Lisp has one of the most complete
object systems but doesn't provide generic access to elements in
containers. None of the two languages seem to be based on principles
that hold throughout their design.
And yet they seem to work pretty well.
Something along these lines...
Pascal
P.S.: Note that this posting is a hack, which means that I haven't
thought the ideas through that I presented here... ;)
--
3rd European Lisp Workshop
July 3-4 - Nantes, France - co-located with ECOOP 2006
http://lisp-ecoop06.bknr.net/
In article <···············@individual.net>,
Pascal Costanza <··@p-cos.net> wrote:
> Ron Garret wrote:
> > In article <························@j55g2000cwa.googlegroups.com>,
> > "Kaz Kylheku" <········@gmail.com> wrote:
> >
> >> Burton Samograd wrote:
> >>> To me,
> >>> I'm just finding more of an inconvenience with my starting out
> >>> practical Lisp knowledge, but I'm sure I can be corrected with the
> >>> proper evidence and persuasion.
> >> What value is there to someone, for instance me, in persuading you of
> >> anything?
> >>
> >> Do you stand between me and something that I want?
> >>
> >> The information is there; make up your own mind.
> >>
> >> Newbies who require persuasion are typically just passive-aggressive
> >> attention seekers, who come with an agenda other than the willingness
> >> to learn: namely, they just want to engage their personality against
> >> another one.
> >>
> >> If you're finding Common Lisp namespaces inconvenient, then maybe
> >> you're just not wired for that type of language. Go program in
> >> something in which variables, type names, goto labels, exception
> >> handlers, and all other entities are entered into the same namespace.
> >
> > The reason Kaz is being so defensive is that there is no principled
> > justification for Lisp-2. It's just a hack, and a pretty horrible one
> > at that. There are only one benefit [1]: avoiding a certain class of
> > unintended name capture in macros.
>
> I don't want to comment on Kaz's posting. I agree that Lisp-2 is a hack,
> like almost everything in both Lisp and Scheme ;), but the good thing
> about hacks is that they tend to work. I strongly disagree that Lisp-2
> is a horrible hack.
IMO any hack that generates confusion in newcomers with near 100%
reliability and has a workable alternative is a horrible hack.
> Another benefit of Lisp-2 (or Lisp-n) is that it
> allows you to have puns in your source code, which can increase its
> readability. (list list) is just one example.
Pretty much the only example. Also, the readability of (list list) is
not that much greater than e.g. (^list list), where ^FOO means get the
top-level binding of FOO. (The addition of a mechanism for accessing
top-level bindings irrespective of the lexical context is, as far as I
can tell, an operationally equivalent but IMO far less ugly hack to
Lisp-2.)
> (For that matter, Lisp-2
> avoids certain name clashes everywhere, not just in macros.)
Like what?
> > It turns out that this benefit can
> > be had in various other ways, but this was not known at the time Common
> > Lisp was designed.
>
> Of course it was. IIUC, a hygienic macro system was indeed suggested for
> inclusion in ANSI Common Lisp.
News to me. Seems to be news to Google too. Do you have a reference?
rg
Ron Garret <·········@flownet.com> wrote:
> > I agree that Lisp-2 is a hack, like almost everything in both Lisp and
> > Scheme ;), but the good thing about hacks is that they tend to work. I
> > strongly disagree that Lisp-2 is a horrible hack.
>
> IMO any hack that generates confusion in newcomers with near 100%
> reliability and has a workable alternative is a horrible hack.
But it isn't anywhere near 100% is it?
--
Duncan Harvey
From: Burton Samograd
Subject: Re: seperation of function namespace
Date:
Message-ID: <87iro4tulm.fsf@gmail.com>
··············@abbrvtd.org.uk (Duncan Harvey) writes:
> Ron Garret <·········@flownet.com> wrote:
>
>> > I agree that Lisp-2 is a hack, like almost everything in both Lisp and
>> > Scheme ;), but the good thing about hacks is that they tend to work. I
>> > strongly disagree that Lisp-2 is a horrible hack.
>>
>> IMO any hack that generates confusion in newcomers with near 100%
>> reliability and has a workable alternative is a horrible hack.
>
> But it isn't anywhere near 100% is it?
I wouldn't say that I'm confused by it, I just find it an
inconvenience that I have to work around ie. it's not really natural
and doesn't seem to fit with the elegance of simply manipulating
symbols, especailly when you have to know thier 'type' now. As
another post stated, this is an inclusion to help the compiler perform
some default optimizations, which is fine, but it seems to be a
hobbled crutch that personally, although I am a newbie to lisp (note:
I have been reading and studying for the past 5 years, I just haven't
had much time to acutally write code in it), could better be done in a
less obtrusive way.
I like filesystems and I like to think of the lisp symbol space as
such, with packages being directories and yada yada. I like the
concept that every name in the filesystem is a reference to it's
contents and data...having to make special cases for special files is
not a very elegant or obvious solution. Yes, it does solve some
technical problems, but it ruins the elegance of a nice system, simply
for the sake of an optimization that could probably be handled better.
--
burton samograd kruhft .at. gmail
kruhft.blogspot.com www.myspace.com/kruhft metashell.blogspot.com
Burton Samograd wrote:
> I have been reading and studying for the past 5 years, I just haven't
> had much time to acutally write code in it), could better be done in a
> less obtrusive way.
``Gee, I've been studying Lisp for five years without writing any code,
and now I'm suddenly perplexed by this two namespace thing.''
You know, what could possibly be less obtrusive than the complete
absence of Lisp code from your disk? Do you even have a Lisp
implementation installed?
Two namespaces can't possibly cause any more problems than one, if they
are all empty.
People get university degrees in fewer than five years. Linux got
started around 1990. In 1994, just four years later, I had contract
work for a commercial website running on Linux. SCSI drives were
chugging way, virtual memory was swapping, packets were flying, and
uptimes were in excess of 200 days. Now that's evidence of motivation.
No amount of operating system and hardware knowledge will roll out a
working OS in four years without motivation.
You're looking for problems because you're not motivated. That's what
people do. When they are not motivated to learn, they look for reasons
to avoid learning.
If your own motivation is close to zero, why should people go to the
effort to debate you?
Are you really looking to get into Lisp, or to get out of it? Do you
simply need a rationalization that will help you put an end to the
half-hearted study that has been dragging on for so long, so that you
can close off that part of your life and move on?
If you want to get out, just get out! You don't need a twisted
rationalization scheme about why you did so. Just say, ``I stopped
learning because it dragged on too long and, after some introspection,
I realized that I had next to zero interest.''
You can't get back the time you already put in, no matter what. I know,
you want to be able to say that the time you put in was all worth it,
because it led up to an important technical conclusion about the
subject which led you to abandon it a wiser man. I.e. that it wasn't
simply your waning interest level.
> not a very elegant or obvious solution. Yes, it does solve some
> technical problems, but it ruins the elegance of a nice system, simply
> for the sake of an optimization that could probably be handled better.
Thanks for sharing.
Let the newsgroup know when you have some concrete programming problem
in an actual piece of code.
You'll be surprised at how effective the responses are to that type of
thing.
From: Burton Samograd
Subject: Re: seperation of function namespace
Date:
Message-ID: <8764k4t5jy.fsf@gmail.com>
"Kaz Kylheku" <········@gmail.com> writes:
> Burton Samograd wrote:
>> I have been reading and studying for the past 5 years, I just haven't
>> had much time to acutally write code in it), could better be done in a
>> less obtrusive way.
>
<snip>
Wow, you just inspired and motivated me to learn how to setup a kill
file in Gnus. Thanks!
--
burton samograd kruhft .at. gmail
kruhft.blogspot.com www.myspace.com/kruhft metashell.blogspot.com
Burton Samograd wrote:
> I wouldn't say that I'm confused by it, I just find it an
> inconvenience that I have to work around ie. it's not really natural
> and doesn't seem to fit with the elegance of simply manipulating
> symbols, especailly when you have to know thier 'type' now.
> As another post stated, this is an inclusion to help the compiler perform
> some default optimizations,
You're citing a usenet post which was explicitly out to draw that
unusual conclusion, rather than the historical record written by two
prominent participants in the standards effort explaining why CL went
this path?
http://www.nhplace.com/kent/Papers/Technical-Issues.html
> although I am a newbie to lisp (note:
> I have been reading and studying for the past 5 years, I just haven't
> had much time to acutally write code in it), could better be done in a
> less obtrusive way.
Haven't you read this flamewar a 100 times, then?
Tayssir
From: Burton Samograd
Subject: Re: seperation of function namespace
Date:
Message-ID: <871wust56y.fsf@gmail.com>
"Tayssir John Gabbour" <···········@yahoo.com> writes:
> Burton Samograd wrote:
>> I wouldn't say that I'm confused by it, I just find it an
>> inconvenience that I have to work around ie. it's not really natural
>> and doesn't seem to fit with the elegance of simply manipulating
>> symbols, especailly when you have to know thier 'type' now.
>> As another post stated, this is an inclusion to help the compiler perform
>> some default optimizations,
>
> You're citing a usenet post which was explicitly out to draw that
> unusual conclusion, rather than the historical record written by two
> prominent participants in the standards effort explaining why CL went
> this path?
> http://www.nhplace.com/kent/Papers/Technical-Issues.html
No, I'm citing my own observations. I was thinking more about this
today, and I found why this system bothers me: it takes the elegance
of working with symbols and values, and then types the symbols to
eliminate function value aliasing thus helping the compiler writers (I
could be wrong, but that's how I managed to figure it so far). I like
the elegance of straight symbols and their values, but hey, that's
just the opinion of a newbie around here. If I wanted typed symbols
I'd be using a different language, although it seems that the one I
would like doesn't exist anymore (or at least not without some macro
hackery).
>> although I am a newbie to lisp (note:
>> I have been reading and studying for the past 5 years, I just haven't
>> had much time to acutally write code in it), could better be done in a
>> less obtrusive way.
>
> Haven't you read this flamewar a 100 times, then?
I come around here every once and a while; I was without internet for
the past year, so no. And I don't consider hanging out here to be
reading and studying something...it would be the many (tens,
hundreds?) of papers the I've read on the development and evolution of
the language. It was one of the many languages and systems I have
been studying over the past five or so years since getting out of my
professional programming career. I come in here for help when I need
it, but I guess I started a flame war with a simple question that was
answered around the third post...
--
burton samograd kruhft .at. gmail
kruhft.blogspot.com www.myspace.com/kruhft metashell.blogspot.com
"Tayssir John Gabbour" <···········@yahoo.com> writes:
> You're citing a usenet post which was explicitly out to draw that
> unusual conclusion, rather than the historical record written by two
> prominent participants in the standards effort explaining why CL went
> this path?
> http://www.nhplace.com/kent/Papers/Technical-Issues.html
It should be noted that the paper referenced above was itself
written to draw the preordained conclusion that the arguments
for Lisp-1 and Lisp-2 are roughly comparable. That is one of
the reasons this paper was exempted from LASC's usual
refereeing process.
For example, one of the reviewers who read the paper during
its informal review process noted that one of the arguments
given in favor of Lisp-2 (the space efficiency gained by using
a single symbol to refer to both the function and value cell)
was actually an argument for Lisp-1 (because of the space
gained by not having separate function and value cells for
every symbol). The obvious repair would have been to move
that argument from the list of arguments for Lisp-2 to the
list of arguments for Lisp-1. This was not done because it
would have made the list of arguments for Lisp-1 longer than
the list of arguments for Lisp-2.
Will
William D Clinger wrote:
> "Tayssir John Gabbour" <···········@yahoo.com> writes:
> > You're citing a usenet post which was explicitly out to draw that
> > unusual conclusion, rather than the historical record written by two
> > prominent participants in the standards effort explaining why CL went
> > this path?
> > http://www.nhplace.com/kent/Papers/Technical-Issues.html
>
> It should be noted that the paper referenced above was itself
> written to draw the preordained conclusion that the arguments
> for Lisp-1 and Lisp-2 are roughly comparable. That is one of
> the reasons this paper was exempted from LASC's usual
> refereeing process.
>
> For example, one of the reviewers who read the paper during
> its informal review process noted that one of the arguments
> given in favor of Lisp-2 (the space efficiency gained by using
> a single symbol to refer to both the function and value cell)
> was actually an argument for Lisp-1 (because of the space
> gained by not having separate function and value cells for
> every symbol). The obvious repair would have been to move
> that argument from the list of arguments for Lisp-2 to the
> list of arguments for Lisp-1. This was not done because it
> would have made the list of arguments for Lisp-1 longer than
> the list of arguments for Lisp-2.
Thanks for the useful caveat!
However, it seems that the space issue was in fact portrayed somewhat
in favor of Lisp-1; for example, under section 15 Space Efficiency in
their back-of-the-envelope calcuation: "That is, 12% of the symbol
space used by such a Lisp2 implementation might be saved if it were
made to be a Lisp1 implementation."
In the next section, the paper claimed that "changing from Lisp2 to
Lisp1 results in a smaller Lisp image because of the reduction in
storage needed for symbols. "
And the conclusion of section 15 was: "The issue is not likely to be
important."
Anyway, in the context of this discussion, the claim I was responding
to was that Lisp-2's purpose is to "help the compiler perform some
default optimizations", which I currently find no evidence for. (And
the original post explicitly requested "proper evidence".) Even if the
Gabriel/Pitman paper were biased in favor of Lisp-2, I'd expect the
sections on optimization to come out in favor of Lisp-2... but the
paper painted the optimization issue as a wash. Not a deciding issue.
Tayssir
From: Bill Atkins
Subject: Re: seperation of function namespace
Date:
Message-ID: <87y7x073tu.fsf@rpi.edu>
Burton Samograd <······@gmail.com> writes:
> ··············@abbrvtd.org.uk (Duncan Harvey) writes:
>
>> Ron Garret <·········@flownet.com> wrote:
>>
>>> > I agree that Lisp-2 is a hack, like almost everything in both Lisp and
>>> > Scheme ;), but the good thing about hacks is that they tend to work. I
>>> > strongly disagree that Lisp-2 is a horrible hack.
>>>
>>> IMO any hack that generates confusion in newcomers with near 100%
>>> reliability and has a workable alternative is a horrible hack.
>>
>> But it isn't anywhere near 100% is it?
>
> I wouldn't say that I'm confused by it, I just find it an
> inconvenience that I have to work around ie. it's not really natural
> and doesn't seem to fit with the elegance of simply manipulating
> symbols, especailly when you have to know thier 'type' now. As
> another post stated, this is an inclusion to help the compiler perform
> some default optimizations, which is fine, but it seems to be a
> hobbled crutch that personally, although I am a newbie to lisp (note:
> I have been reading and studying for the past 5 years, I just haven't
> had much time to acutally write code in it), could better be done in a
> less obtrusive way.
>
> I like filesystems and I like to think of the lisp symbol space as
> such, with packages being directories and yada yada. I like the
> concept that every name in the filesystem is a reference to it's
> contents and data...having to make special cases for special files is
> not a very elegant or obvious solution. Yes, it does solve some
> technical problems, but it ruins the elegance of a nice system, simply
> for the sake of an optimization that could probably be handled better.
>
> --
> burton samograd kruhft .at. gmail
> kruhft.blogspot.com www.myspace.com/kruhft metashell.blogspot.com
Jeez, I didn't know people got so worked up about a couple of
FUNCALL's.
(defmacro with-fns (bindings &body body)
"Bind each variable in BINDINGS as a function, so you can use
Lisp-1 notation - e.g. (with-fns (fn) (fn 3)) is the same
as (funcall fn 3). Each binding is either the name of the
function or an (ALIAS ORIG-NAME) list."
(labels ((pairify (binding)
(if (consp binding) binding (list binding binding))))
`(labels ,(loop for (name fn) in (mapcar #'pairify bindings)
collect `(,name (&rest args)
(apply ,fn args)))
,@body)))
(defun mymap (fn list)
(with-fns (fn)
(loop for x in list
collect (fn x))))
(mymap #'abs '(-1 3 9 33))
;; pretty version at http://paste.lisp.org/display/20129
--
You fool! You fell victim to one of the classic blunders! The most
famous is, "Never get involved in a land war in Asia", but only
slightly less well-known is this: "Never go in against a Sicilian when
death is on the line"!
In article <······································@abbrvtd.org.uk>,
··············@abbrvtd.org.uk (Duncan Harvey) wrote:
> Ron Garret <·········@flownet.com> wrote:
>
> > > I agree that Lisp-2 is a hack, like almost everything in both Lisp and
> > > Scheme ;), but the good thing about hacks is that they tend to work. I
> > > strongly disagree that Lisp-2 is a horrible hack.
> >
> > IMO any hack that generates confusion in newcomers with near 100%
> > reliability and has a workable alternative is a horrible hack.
>
> But it isn't anywhere near 100% is it?
I think it's pretty close to 100% even among experienced Lispers.
Consider:
1. What is the difference between a function designator and an extended
function designator? Under what circumstances is each one used?
2. Which of the following are legal CL code?
((setf car) x 5)
(#'(setf car) x 1)
(#.#'(setf car) x 1)
(#'car x)
(#.#'car x)
(let ((car (lambda (car) car))) (flet ((car (car) car)) (car car)))
How many people do you think would be willing to wager $100 up front
that they could answer both of those questions correctly in a
closed-book exam?
rg
Ron Garret wrote:
> In article <······································@abbrvtd.org.uk>,
> ··············@abbrvtd.org.uk (Duncan Harvey) wrote:
>
> > Ron Garret <·········@flownet.com> wrote:
> >
> > > > I agree that Lisp-2 is a hack, like almost everything in both Lisp and
> > > > Scheme ;), but the good thing about hacks is that they tend to work. I
> > > > strongly disagree that Lisp-2 is a horrible hack.
> > >
> > > IMO any hack that generates confusion in newcomers with near 100%
> > > reliability and has a workable alternative is a horrible hack.
> >
> > But it isn't anywhere near 100% is it?
>
> I think it's pretty close to 100% even among experienced Lispers.
> Consider:
>
> 1. What is the difference between a function designator and an extended
> function designator? Under what circumstances is each one used?
Right, whereas users of some Lisp-1 dialect would be better able to
answer language lawyer type questions about that dialect.
Could experienced Lisp-1 users answer language lawyer questions about
their dialect, without opportunity to cram over its specification?
In Lisp, a symbol can be a function name, but a lambda expression also
serves as a name. In addition, the name can be a compound form like
(SETF FOO). So without glancing into the CLHS, I'd guess that the
"extended" part refers to this compound form.
> 2. Which of the following are legal CL code?
>
> ((setf car) x 5)
Trick: there is no (SETF CAR) function. (The setf expander does look
for SETF functions if all else fails).
> (#'(setf car) x 1)
That would be wrong even if there was a (SETF CAR) function, since
(FUNCTION ...) isn't a function name. No evaluation takes place in the
leftmost position, so the FUNCTION operator cannot do its job.
> (#.#'(setf car) x 1)
A function object isn't a function name.
Moreover, inserting function objects into source is wrong anyway, for
other reasons: it's not (required to be) compileable. All objects in a
form have to be externalizeable.
> (#'car x)
(FUNCTION CAR) isn't a function name. No evaluation takes place, so the
FUNCTION operator here cannot do its job.
> (#.#'car x)
The CAR function isn't a function name; and, again, there is the
problem of a function object created at read time and put into a form.
> (let ((car (lambda (car) car))) (flet ((car (car) car)) (car car)))
If this is indeed the symbol COMMON-LISP::CAR, then the FLET invokes
undefined behavior, period.
If this is CAR is from some other package, then we have valid code
which returns an identity closure.
> How many people do you think would be willing to wager $100 up front
> that they could answer both of those questions correctly in a
> closed-book exam?
An exam with language-lawyer questions, with no opportunity to study
the ANSI spec?
That would be foolish.
In article <·······················@g10g2000cwb.googlegroups.com>,
"Kaz Kylheku" <········@gmail.com> wrote:
> Ron Garret wrote:
> > In article <······································@abbrvtd.org.uk>,
> > ··············@abbrvtd.org.uk (Duncan Harvey) wrote:
> >
> > > Ron Garret <·········@flownet.com> wrote:
> > >
> > > > > I agree that Lisp-2 is a hack, like almost everything in both Lisp and
> > > > > Scheme ;), but the good thing about hacks is that they tend to work. I
> > > > > strongly disagree that Lisp-2 is a horrible hack.
> > > >
> > > > IMO any hack that generates confusion in newcomers with near 100%
> > > > reliability and has a workable alternative is a horrible hack.
> > >
> > > But it isn't anywhere near 100% is it?
> >
> > I think it's pretty close to 100% even among experienced Lispers.
> > Consider:
> >
> > 1. What is the difference between a function designator and an extended
> > function designator? Under what circumstances is each one used?
>
> Right, whereas users of some Lisp-1 dialect would be better able to
> answer language lawyer type questions about that dialect.
Except that in CL these things pop up constantly in actual practice.
See below.
> > 2. Which of the following are legal CL code?
> >
> > ((setf car) x 5)
>
> Trick: there is no (SETF CAR) function.
Not until you define one:
Welcome to Macintosh Common Lisp Version 5.1!
? (defun (setf car) () 'porsche)
(SETF CAR)
? (funcall #'(setf car))
PORSCHE
?
There isn't a FOO function when you first fire up CL either, but that
doesn't mean that (FOO) is not legal CL.
rg
Ron Garret wrote:
> In article <·······················@g10g2000cwb.googlegroups.com>,
> "Kaz Kylheku" <········@gmail.com> wrote:
> > > 2. Which of the following are legal CL code?
> > >
> > > ((setf car) x 5)
> >
> > Trick: there is no (SETF CAR) function.
>
> Not until you define one:
If I'm taking a test about ANSI CL, I am free to assume that every
example is a complete program presented to an ANSI CL implementation,
and interpret it accordingly.
If some definitions are to be assumed, they have to be spelled out.
And by the way, there could be a (SETF CAR) function. You start in the
CL-USER package, where there can be arbitrary extensions. You might not
even be allowed to redefine that existing (SETF CAR) either. And of
course, you can't expect the existing SETF expander to use your (SETF
CAR), though perhaps that might actually happen.
Anything can happen when you have undefined behavior.
> There isn't a FOO function when you first fire up CL either, but that
> doesn't mean that (FOO) is not legal CL.
Just like the way there isn't a function SHELL when you fire up CLISP.
Bahaha.
In article <·······················@g10g2000cwb.googlegroups.com>,
"Kaz Kylheku" <········@gmail.com> wrote:
> Ron Garret wrote:
> > In article <·······················@g10g2000cwb.googlegroups.com>,
> > "Kaz Kylheku" <········@gmail.com> wrote:
> > > > 2. Which of the following are legal CL code?
> > > >
> > > > ((setf car) x 5)
> > >
> > > Trick: there is no (SETF CAR) function.
> >
> > Not until you define one:
>
> If I'm taking a test about ANSI CL, I am free to assume that every
> example is a complete program presented to an ANSI CL implementation,
> and interpret it accordingly.
>
> If some definitions are to be assumed, they have to be spelled out.
>
> And by the way, there could be a (SETF CAR) function.
Indeed there could be. But that does not affect the answer to the
question.
> Anything can happen when you have undefined behavior.
But none of that will help improve your grade.
The correct answer is that ((setf car) x 5) is not legal CL UNDER ANY
CIRCUMSTANCES. (And yes, I know that it actually does work under CLisp.
This is an implementation-specific extension which is actually at odds
with the standard. Not that I'm complaining mind you.)
rg
Ron Garret <·········@flownet.com> writes:
> In article <·······················@g10g2000cwb.googlegroups.com>,
> "Kaz Kylheku" <········@gmail.com> wrote:
>
> > Ron Garret wrote:
> > > In article <······································@abbrvtd.org.uk>,
> > > ··············@abbrvtd.org.uk (Duncan Harvey) wrote:
> > >
> > > > Ron Garret <·········@flownet.com> wrote:
> > > >
> > > > > > I agree that Lisp-2 is a hack, like almost everything in both Lisp and
> > > > > > Scheme ;), but the good thing about hacks is that they tend to work. I
> > > > > > strongly disagree that Lisp-2 is a horrible hack.
> > > > >
> > > > > IMO any hack that generates confusion in newcomers with near 100%
> > > > > reliability and has a workable alternative is a horrible hack.
I would dispute the assertion.
And I wonder what the single namespace confusion rate is for newcomers.
I bet there is also a near 100% reliable incidence of inadvertent
shadowing of function names by variable values among newcomers as well.
Should we hold that against lisp-1? No. It is just a characteristic
of the language that needs to be learned.
I also find that newcomers to Lisp from other languages love to put the
function symbol outside the parentheses instead of inside it. This
tends to occur at least once and often more than that when they are
first writing code. Does that mean we should change that as well?
> > > > But it isn't anywhere near 100% is it?
> > >
> > > I think it's pretty close to 100% even among experienced Lispers.
No it isn't.
Granting you the perhaps generous accolade of being an experienced
Lisper, I would venture to say that you would then be the only one who
gets confused by this. And if I were inclined to be less charitible I
would suggest that anyone still confused by the value/function namespace
dichotomy is not "experienced".
> > > Consider:
> > >
> > > 1. What is the difference between a function designator and an extended
> > > function designator? Under what circumstances is each one used?
> >
> > Right, whereas users of some Lisp-1 dialect would be better able to
> > answer language lawyer type questions about that dialect.
>
> Except that in CL these things pop up constantly in actual practice.
> See below.
No they don't. They only seem to happen to you because you seek them
out.
I've been programming in Common Lisp since it was created, and in lisp
for years before that. I never run into problems with namespace
confusion. To the best of my recollection, I never ran into such
problems learning lisp, either.
This argument has gotten entirely too silly.
Ron, it is clear that you prefer lisp-1 to lisp-n systems. There are
numerous reasons why others prefer lisp-n. I would think it is a waste
of your time trying to change this. Just choose an appropriate Scheme
implementation and write code. Everyone would be happier.
···@sevak.isi.edu (Thomas A. Russ) writes:
>
> Ron, it is clear that you prefer lisp-1 to lisp-n systems. There are
> numerous reasons why others prefer lisp-n. I would think it is a
> waste of your time trying to change this. Just choose an appropriate
> Scheme implementation and write code. Everyone would be happier.
Except of course that Scheme is a lot more than just a Lisp-1. It
doesn't seem to be completely unreasonable to me that someone would like
a Common Lisp-1. I'd be interested, to tell the truth.
--
Robert Uhl <http://public.xdi.org/=ruhl>
...so give to the National Paranoia Telethon! Research is desperately
needed and time is so very short--even as we speak bearded men with
curved daggers are tunnelling into my basement...
Robert Uhl wrote:
> ···@sevak.isi.edu (Thomas A. Russ) writes:
>> Ron, it is clear that you prefer lisp-1 to lisp-n systems. There are
>> numerous reasons why others prefer lisp-n. I would think it is a
>> waste of your time trying to change this. Just choose an appropriate
>> Scheme implementation and write code. Everyone would be happier.
>
> Except of course that Scheme is a lot more than just a Lisp-1. It
> doesn't seem to be completely unreasonable to me that someone would like
> a Common Lisp-1. I'd be interested, to tell the truth.
There are quite a few Scheme implementations that are a lot more
"complete" than R5RS. Check out PLT Scheme or Bigloo, for example. There
is also Dylan.
Pascal
--
3rd European Lisp Workshop
July 3 - Nantes, France - co-located with ECOOP 2006
http://lisp-ecoop06.bknr.net/
Pascal Costanza <··@p-cos.net> writes:
>
>>> Ron, it is clear that you prefer lisp-1 to lisp-n systems. There
>>> are numerous reasons why others prefer lisp-n. I would think it is
>>> a waste of your time trying to change this. Just choose an
>>> appropriate Scheme implementation and write code. Everyone would be
>>> happier.
>>
>> Except of course that Scheme is a lot more than just a Lisp-1. It
>> doesn't seem to be completely unreasonable to me that someone would
>> like a Common Lisp-1. I'd be interested, to tell the truth.
>
> There are quite a few Scheme implementations that are a lot more
> "complete" than R5RS. Check out PLT Scheme or Bigloo, for
> example. There is also Dylan.
Some of those are pretty cool, but what I was thinking of is something
which is exactly a Common Lisp-1: condition system, package system,
even the pathname stuff, CLOS, the whole shebang--in other words, Common
Lisp, but without FUNCTION, FUNCALL and SYMBOL-FUNCTION. It'd be kinda
cool. No idea how _useful_ it'd be, but programming six months in
Common Lisp, then six in Common Lisp-1, then repeating should provide
one all the insight one needs into whether or not it makes a difference.
--
Robert Uhl <http://public.xdi.org/=ruhl>
When C++ is your hammer, everything looks like a thumb
--Steven M. Haflich
Kaz Kylheku <········@gmail.com> wrote:
+---------------
| Ron Garret wrote:
| > (#'(setf car) x 1)
|
| That would be wrong even if there was a (SETF CAR) function, since
| (FUNCTION ...) isn't a function name. No evaluation takes place in the
| leftmost position, so the FUNCTION operator cannot do its job.
+---------------
And (FUNCALL #'(SETF CAR) X 1) would be wrong, since the order of
args is incorrect for the (SETF CAR) function:
> (funcall #'(setf car) x 1)
Type-error in KERNEL::OBJECT-NOT-LIST-ERROR-HANDLER: 1 is not of type LIST
...
>
But with the right arg order, it should work:
> x
(12 . 34)
> (funcall #'(setf car) 1 x)
1
> x
(1 . 34)
>
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
Ron Garret <·········@flownet.com> wrote:
> In article <······································@abbrvtd.org.uk>,
> ··············@abbrvtd.org.uk (Duncan Harvey) wrote:
>
> > Ron Garret <·········@flownet.com> wrote:
> >
> > > IMO any hack [here being a Lisp-2] that generates confusion in
> > > newcomers with near 100% reliability and has a workable alternative is
> > > a horrible hack.
> >
> > But it isn't anywhere near 100% is it?
>
> I think it's pretty close to 100% even among experienced Lispers.
> Consider: [snipped]
I don't think your examples support your argument that a Lisp-2
necessarily "generates confusion in newcomers". It's not been my
experience that "in CL these things pop up constantly in actual
practice". I agree with Kaz: these are language lawyer-ish issues.
--
Duncan Harvey
From: Alexander Schmolck
Subject: Re: seperation of function namespace
Date:
Message-ID: <yfsejysppuo.fsf@oc.ex.ac.uk>
Ron Garret <·········@flownet.com> writes:
> IMO any hack that generates confusion in newcomers with near 100%
> reliability and has a workable alternative is a horrible hack.
Are you talking of logical-pathnames or the package system? <duck>
> > (For that matter, Lisp-2
> > avoids certain name clashes everywhere, not just in macros.)
>
> Like what?
Types vs values; block labels -- all sorts of things. I think Lisp-2 is a
misnomer, it's more like Lisp-inf. I'm somewhat unconvinced that a single
namespace is sane (a good reason to assume it isn't is proliferation of
unpronouncable and/or visually offensive names in languages that (strive to)
only have a single namespace -- and this gets progressively worse as you try
to add new concepts into the language that would more or less naturally live
in different namespaces. Have a look at all the bizarre naming conventions in
PLT scheme and related publications).
> > > It turns out that this benefit can
> > > be had in various other ways, but this was not known at the time Common
> > > Lisp was designed.
> >
> > Of course it was. IIUC, a hygienic macro system was indeed suggested for
> > inclusion in ANSI Common Lisp.
>
> News to me. Seems to be news to Google too. Do you have a reference?
IIRC try googling Clinger's 2006 postings here.
'as
In article <···············@oc.ex.ac.uk>,
Alexander Schmolck <··········@gmail.com> wrote:
> Ron Garret <·········@flownet.com> writes:
>
> > IMO any hack that generates confusion in newcomers with near 100%
> > reliability and has a workable alternative is a horrible hack.
>
> Are you talking of logical-pathnames or the package system? <duck>
Don't get me started.
> > > (For that matter, Lisp-2
> > > avoids certain name clashes everywhere, not just in macros.)
> >
> > Like what?
>
> Types vs values; block labels -- all sorts of things.
I presume you mean something like:
(let ((list ...))
(block list ... (return-from list (coerce (foo list) 'list)) ...))
It isn't really Lisp-2 avoiding name collision here, it is, as you say,
Lisp-inf. The merits of having each of these name spaces built in to
the language is a separate, orthogonal discussion which would lead us
far afield. I'll just point out a couple of things:
1. In Python, types are (mostly) opaque first-class objects, and that
seems to work reasonably well.
2. Nothing prevents a user from creating new namespaces using
associative maps.
3. The block label namespace is static and exists only at compile time.
4. Why stop where CL did? Why not e.g. a separate name space for every
data type? Why shouldn't I be able to do:
(list-let ((x '(1 2 3)))
(vector-let ((x #(a b c)))
(integer-let ((x 1))
(cons (car x) (aref x x))) --> (1 . b)
> Have a look at all the bizarre naming conventions in
> PLT scheme and related publications).
I'm not sure which bizarre naming conventions you're referring to, but a
lot of Scheme's naming conventions are there to make the code easier to
read, not to avoid name clashes.
rg
Ron Garret wrote:
> 4. Why stop where CL did? Why not e.g. a separate name space for every
> data type? Why shouldn't I be able to do:
>
> (list-let ((x '(1 2 3)))
> (vector-let ((x #(a b c)))
> (integer-let ((x 1))
> (cons (car x) (aref x x))) --> (1 . b)
This is completely retarded. The namespace separation is on syntactic
role, not on object type. There is a namespace for operators, and a
namespace for operands. An operator is an expression in the leftmost
position of a compound; an operand is everything else.
Of course, functions can be operands, and also non-functions can be
operators (if you have funcallable objects of various types).
The above example makes no sense at all. References to X are ambiguous
because they are in the same syntactic context.
The evaluation rules become radically different, because they have to
have make use of type information about CAR and AREF, something which
is not easily available for functions in general.
That's not to mention polymorphism. Which x is passed into (identity
x)? Thorough inference is required.
Do you even superficially understand the issues you are talking about?
In article <························@g10g2000cwb.googlegroups.com>,
"Kaz Kylheku" <········@gmail.com> wrote:
> Ron Garret wrote:
> > 4. Why stop where CL did? Why not e.g. a separate name space for every
> > data type? Why shouldn't I be able to do:
> >
> > (list-let ((x '(1 2 3)))
> > (vector-let ((x #(a b c)))
> > (integer-let ((x 1))
> > (cons (car x) (aref x x))) --> (1 . b)
>
> This is completely retarded. The namespace separation is on syntactic
> role, not on object type.
Oh really? Then why does this not work:
? (setf (symbol-function 'foo) 'cdr)
> Error: value CDR is not of the expected type (SATISFIES FUNCTIONP).
> While executing: FSET
> Type Command-. to abort.
See the Restarts� menu item for further choices.
1 >
> There is a namespace for operators, and a
> namespace for operands. An operator is an expression in the leftmost
> position of a compound; an operand is everything else.
>
> Of course, functions can be operands, and also non-functions can be
> operators (if you have funcallable objects of various types).
Actually, in CL, functions cannot be operators, only operands. If
functions could be operators then the following would be legal:
(#.#'car '(1 2 3))
but it isn't.
> Do you even superficially understand the issues you are talking about?
I understand them quite a bit better than you do apparently.
rg
Ron Garret wrote:
> In article <························@g10g2000cwb.googlegroups.com>,
> "Kaz Kylheku" <········@gmail.com> wrote:
>
> > Ron Garret wrote:
> > > 4. Why stop where CL did? Why not e.g. a separate name space for every
> > > data type? Why shouldn't I be able to do:
> > >
> > > (list-let ((x '(1 2 3)))
> > > (vector-let ((x #(a b c)))
> > > (integer-let ((x 1))
> > > (cons (car x) (aref x x))) --> (1 . b)
> >
> > This is completely retarded. The namespace separation is on syntactic
> > role, not on object type.
>
> Oh really? Then why does this not work:
>
> ? (setf (symbol-function 'foo) 'cdr)
Oh boy.
This is irrelevant in more than one way.
Firstly, only the symbols SETF and SYMBOL-FUNCTION in the above
expression are subject to name lookup.
FOO and CDR are just quoted data.
So this example is almost completely irrelevant to the question of
operator and variable namespaces.
There is a constraint in place which prevents an object other than a
function from being dynamically assigned to the function slot of a
symbol.
However, you are able to /express/ the idea of doing it, and, in
principle, the mechanism can easily be opened up to admit funcallable
objects other than functions, without, in any way, altering the way the
namespaces work.
Does it work in a Lisp-1? What if we assign a symbol to a variable. We
can do that, of course: there cannot be a constraint against that:
(setf foo 'cdr)
But then can we call it like a function?
(foo '(a . b))
Sure, if we extend the Lisp-1 language so that symbols are funcallable,
why not?
Which current Lisp-1 dialects have funcallable symbols, by the way?
> > There is a namespace for operators, and a
> > namespace for operands. An operator is an expression in the leftmost
> > position of a compound; an operand is everything else.
> >
> > Of course, functions can be operands, and also non-functions can be
> > operators (if you have funcallable objects of various types).
>
> Actually, in CL, functions cannot be operators, only operands.
Good grief you are irksome!
That is not what I mean at all. I'm talking about names, hence
"namespace for operators" and "namespace for operands" above.
When I say that a function can be an operator, I mean that some
operator name like X can have a binding which refers to a function.
Of course I didn't mean that a function object can be used in the
source code of an expression as the syntax of an operator.
> If functions could be operators then the following would be legal:
>
> (#.#'car '(1 2 3))
>
> but it isn't.
You mean, if functions could be operators, /and/ if they were
externalizable objects suitable for use in source code as literals.
In article <························@j73g2000cwa.googlegroups.com>,
"Kaz Kylheku" <········@gmail.com> wrote:
> Good grief you are irksome!
The feeling is mutual, I assure you.
> > > > 4. Why stop where CL did? Why not e.g. a separate name space for every
> > > > data type? Why shouldn't I be able to do:
> > > >
> > > > (list-let ((x '(1 2 3)))
> > > > (vector-let ((x #(a b c)))
> > > > (integer-let ((x 1))
> > > > (cons (car x) (aref x x))) --> (1 . b)
> > >
> > > This is completely retarded. The namespace separation is on syntactic
> > > role, not on object type.
> >
> > Oh really? Then why does this not work:
> >
> > ? (setf (symbol-function 'foo) 'cdr)
>
> Oh boy.
>
> This is irrelevant in more than one way.
>
> Firstly, only the symbols SETF and SYMBOL-FUNCTION in the above
> expression are subject to name lookup.
What I intended was: if Common Lisp's value-function namespace
segregation is, as you claim, on syntactic role and not object type,
then why is it not legal to place anything other than a function object
in the symbol-function slot of a symbol?
That was a rhetorical question by the way, intended to make you realize
that a value-function namespace segregation is BY DEFINITION a
segregation on data type. There is in fact no fundamental difference
between my example and what CL actually does. There is no difference
between having a separate namespace for the car of a form whose values
are constrained to be functions, and a separate namespace for the
arguments to AREF, whose values are constrained to be arrays and
integers.
> FOO and CDR are just quoted data.
CDR is more than "just" quoted data. It is also (necessarily) the name
of a function.
> So this example is almost completely irrelevant to the question of
> operator and variable namespaces.
If you believe that then you have not understood my point.
> There is a constraint in place which prevents an object other than a
> function from being dynamically assigned to the function slot of a
> symbol.
>
> However, you are able to /express/ the idea of doing it, and, in
> principle, the mechanism can easily be opened up to admit funcallable
> objects other than functions, without, in any way, altering the way the
> namespaces work.
Of course you COULD. You could have a separate name space for every
argument position, for every data type, for all manner of things. The
point is (as I'm sure you'll agree) that most of these would be poor
design. The question on the table is: what is it that is so special
about the car of a form that it should merit this special treatment?
Why is it any less foolish to have a separate namespace for the car of a
form than for the arguments to aref?
> > > There is a namespace for operators, and a
> > > namespace for operands. An operator is an expression in the leftmost
> > > position of a compound; an operand is everything else.
> > >
> > > Of course, functions can be operands, and also non-functions can be
> > > operators (if you have funcallable objects of various types).
> >
> > Actually, in CL, functions cannot be operators, only operands.
>
> That is not what I mean at all. I'm talking about names, hence
> "namespace for operators" and "namespace for operands" above.
>
> When I say that a function can be an operator, I mean that some
> operator name like X can have a binding which refers to a function.
Actually, in CL the symbol X can have TWO (runtime) bindings, BOTH of
which can have functions as values (and one of which is required to if
it exists).
> Of course I didn't mean that a function object can be used in the
> source code of an expression as the syntax of an operator.
But you said "non-functions can be operators", implying that the normal
state of affairs is that operators are functions (or at the very least
that functions can be operators too). In fact operators in CL can be
only two things: symbols and lambda expressions, both of which are
non-functions. So the truth is that all operators are non-functions.
> > If functions could be operators then the following would be legal:
> >
> > (#.#'car '(1 2 3))
> >
> > but it isn't.
>
> You mean, if functions could be operators, /and/ if they were
> externalizable objects suitable for use in source code as literals.
But they are. The following, for example, IS legal CL:
(defun foo () '#.#'car)
rg
Ron Garret wrote:
> In article <························@j73g2000cwa.googlegroups.com>,
> "Kaz Kylheku" <········@gmail.com> wrote:
>
> > Good grief you are irksome!
>
> The feeling is mutual, I assure you.
Yeah, but I'm correct-irksome, not idiot-irksome. :)
> > Firstly, only the symbols SETF and SYMBOL-FUNCTION in the above
> > expression are subject to name lookup.
>
> What I intended was: if Common Lisp's value-function namespace
> segregation is, as you claim, on syntactic role and not object type,
As /I/ claim? You mean, "as is fucking obvious".
> then why is it not legal to place anything other than a function object
> in the symbol-function slot of a symbol?
This is due to the behavior of the SETF operator in conjunction with
the SYMBOL-FUNCTION place, neither of which have anything to do with
Lisp-2 versus Lisp-1. Someone decided that there shall be this
constraint, so that if someone makes the error of putting a
non-function into a function binding, that error will be intercepted as
early as possible. Otherwise, there will be a puzzling error message:
an expression like (FOO 42) will blow up because FOO isn't a function.
(Exactly as would happen in a Lisp-1 if FOO is a variable that doesn't
hold a function; doh!)
The symbol-function slot of a symbol isn't even necessarily the active
function binding in a given scope, since it could be shadowed by a
lexical binding. In that case, whatever you put in there makes no
difference anyway.
The Lisp-2 versus Lisp-1 discussion hinges around what happens when foo
is in the first position or elsewhere, i.e. (FOO ...) versus (... FOO
...). That's what separates the two types of dialect.
What happens in (SYMBOL-FUNCTION 'FOO) is completely irrelevant; it's
up to the guts of that function. A Lisp-2 dialect doesn't even have to
have that function. It doesn't have to have SETF either, and it
consequently doesn't have to implement any constraint in the
combination of the two.
The symbol 'FOO there is just literal data; it is the expression (QUOTE
FOO) in which FOO is not evaluated, and thus it is not looked up in
either namespace.
> That was a rhetorical question by the way, intended to make you realize
... that there is no bottom to your pitiful stupidity?
In article <························@g10g2000cwb.googlegroups.com>,
"Kaz Kylheku" <········@gmail.com> wrote:
> Ron Garret wrote:
> > In article <························@j73g2000cwa.googlegroups.com>,
> > "Kaz Kylheku" <········@gmail.com> wrote:
> >
> > > Good grief you are irksome!
> >
> > The feeling is mutual, I assure you.
>
> Yeah, but I'm correct-irksome, not idiot-irksome. :)
No, you are continually-missing-the-point-irksome.
> > > Firstly, only the symbols SETF and SYMBOL-FUNCTION in the above
> > > expression are subject to name lookup.
> >
> > What I intended was: if Common Lisp's value-function namespace
> > segregation is, as you claim, on syntactic role and not object type,
>
> As /I/ claim? You mean, "as is fucking obvious".
No, I meant what I said. Your claim is not obvious because it is in
fact false. But the reason it is false is subtle, and you seem to be
either unwilling to or unable to grasp subtleties. But I feel like
tilting at a windmill today so I'll give this one more try.
> > then why is it not legal to place anything other than a function object
> > in the symbol-function slot of a symbol?
>
> This is due to the behavior of the SETF operator in conjunction with
> the SYMBOL-FUNCTION place, neither of which have anything to do with
> Lisp-2 versus Lisp-1. Someone decided that there shall be this
> constraint, so that if someone makes the error of putting a
> non-function into a function binding, that error will be intercepted as
> early as possible. Otherwise, there will be a puzzling error message:
> an expression like (FOO 42) will blow up because FOO isn't a function.
> (Exactly as would happen in a Lisp-1 if FOO is a variable that doesn't
> hold a function; doh!)
Really? You mean if I do this in Scheme:
(define foo 1)
that's an error?
> The symbol-function slot of a symbol isn't even necessarily the active
> function binding in a given scope, since it could be shadowed by a
> lexical binding. In that case, whatever you put in there makes no
> difference anyway.
Ah, so if I do this:
(flet ((foo () ...))
(setf (symbol-funtion 'foo) 1)
...
(fmakunbound 'foo))
that would be OK?
> The Lisp-2 versus Lisp-1 discussion hinges around what happens when foo
> is in the first position or elsewhere, i.e. (FOO ...) versus (... FOO
> ...). That's what separates the two types of dialect.
Yes. And how is that different from a hypothetical Lisp with separate
integer and vector name spaces where the discussion would hinge around
what happens when FOO is in the first or subsequent argument position of
an AREF?
> What happens in (SYMBOL-FUNCTION 'FOO) is completely irrelevant; it's
> up to the guts of that function. A Lisp-2 dialect doesn't even have to
> have that function. It doesn't have to have SETF either, and it
> consequently doesn't have to implement any constraint in the
> combination of the two.
Yes it does. It must insure that (SYMBOL-FUNCTION 'FOO) is of a
particular type, namely, a function.
> The symbol 'FOO there is just literal data; it is the expression (QUOTE
> FOO) in which FOO is not evaluated, and thus it is not looked up in
> either namespace.
That's a red herring. The point is simply that the symbol-function slot
of a symbol is constrained to contain values of a particular type
(functions) and that therefore your claim that the Lisp-1/2 distinction
is NOT a segregation on types is false.
rg
Ron Garret wrote:
> Yes it does. It must insure that (SYMBOL-FUNCTION 'FOO) is of a
> particular type, namely, a function.
There is no such constraint in ANSI CL. The diagnostics are courtesy of
implementations. The behavior of
(setf (symbol-function 'foo) <non-function>)
is in fact undefined. This means that implementations can actually
allow the assignment to proceed, with no diagnostic, and perhaps later
allow that non-function value to be retrieved using the SYMBOL-FUNCTION
accessor, or even hash quote. That would be a perfectly conforming
response. Such an implementation would still be considered a Lisp-2
dialect.
Requiring an error would be misguided, because it would interfere with
useful, otherwise conforming extensions, such as the provision of
various kinds of funcallable objects other that functions.
In article <························@i40g2000cwc.googlegroups.com>,
"Kaz Kylheku" <········@gmail.com> wrote:
> Ron Garret wrote:
> > Yes it does. It must insure that (SYMBOL-FUNCTION 'FOO) is of a
> > particular type, namely, a function.
>
> There is no such constraint in ANSI CL.
Of course there is. Do you even bother to look these things up before
making pronouncements?
Accessor SYMBOL-FUNCTION
Syntax:
symbol-function symbol => contents
(setf (symbol-function symbol) new-contents)
Arguments and Values:
symbol---a symbol.
contents--- If the symbol is globally defined as a macro or a special
operator, an object of implementation-dependent nature and identity is
returned. If the symbol is not globally defined as either a macro or a
special operator, and if the symbol is fbound, a function object is
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
returned.
^^^^^^^^
new-contents---a function.
^^^^^^^^^^
> Requiring an error would be misguided, because it would interfere with
> useful, otherwise conforming extensions, such as the provision of
> various kinds of funcallable objects other that functions.
At least we agree on something.
rg
On Thu, 18 May 2006 12:09:43 -0700, Ron Garret <·········@flownet.com> wrote:
>
> contents--- If the symbol is globally defined as a macro or a special
> operator, an object of implementation-dependent nature and identity is
> returned. If the symbol is not globally defined as either a macro or a
> special operator, and if the symbol is fbound, a function object is
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> returned.
> ^^^^^^^^
Ron, you have selectively underlined a portion of that sentence
in order to establish an implication that is not being made (by
that specific sentence). Item 5a in the FUNCTION-TYPE Issue Writeup
says:
"The value returned by SYMBOL-FUNCTION when FBOUNDP returns true
but the symbol denotes a macro or special form is not well-defined,
but SYMBOL-FUNCTION will not signal an error."
>
> new-contents---a function.
> ^^^^^^^^^^
However this part is clear. Also, item 5b in the FUNCTION-TYPE
Issue Writeup seems (to me) to be explicit about what is intended.
--
Jack Unrue
In article <··································@4ax.com>,
Jack Unrue <·······@example.tld> wrote:
> On Thu, 18 May 2006 12:09:43 -0700, Ron Garret <·········@flownet.com> wrote:
> >
> > contents--- If the symbol is globally defined as a macro or a special
> > operator, an object of implementation-dependent nature and identity is
> > returned. If the symbol is not globally defined as either a macro or a
> > special operator, and if the symbol is fbound, a function object is
> > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > returned.
> > ^^^^^^^^
>
> Ron, you have selectively underlined a portion of that sentence
> in order to establish an implication that is not being made (by
> that specific sentence).
Fine, I'll underline more then:
If the symbol is not globally defined as either a macro or a special
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
operator, and if the symbol is fbound, a function object is returned.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> Item 5a in the FUNCTION-TYPE Issue Writeup
> says:
>
> "The value returned by SYMBOL-FUNCTION when FBOUNDP returns true
> but the symbol denotes a macro or special form is not well-defined,
> but SYMBOL-FUNCTION will not signal an error."
That is in no way at odds with what I have said.
> >
> > new-contents---a function.
> > ^^^^^^^^^^
>
> However this part is clear. Also, item 5b in the FUNCTION-TYPE
> Issue Writeup seems (to me) to be explicit about what is intended.
Then why are you picking this nit?
rg
On Thu, 18 May 2006 14:05:59 -0700, Ron Garret <·········@flownet.com> wrote:
>In article <··································@4ax.com>,
> Jack Unrue <·······@example.tld> wrote:
>
>> On Thu, 18 May 2006 12:09:43 -0700, Ron Garret <·········@flownet.com> wrote:
>> >
>> > contents--- If the symbol is globally defined as a macro or a special
>> > operator, an object of implementation-dependent nature and identity is
>> > returned. If the symbol is not globally defined as either a macro or a
>> > special operator, and if the symbol is fbound, a function object is
>> > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> > returned.
>> > ^^^^^^^^
>>
>> Ron, you have selectively underlined a portion of that sentence
>> in order to establish an implication that is not being made (by
>> that specific sentence).
>
>Fine, I'll underline more then:
>
>If the symbol is not globally defined as either a macro or a special
>^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>operator, and if the symbol is fbound, a function object is returned.
>^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
>
>> Item 5a in the FUNCTION-TYPE Issue Writeup
>> says:
>>
>> "The value returned by SYMBOL-FUNCTION when FBOUNDP returns true
>> but the symbol denotes a macro or special form is not well-defined,
>> but SYMBOL-FUNCTION will not signal an error."
>
>That is in no way at odds with what I have said.
Baloney. Your original highlighting was intended to bolster
your position, which I will remind you was:
[ That's a red herring. The point is simply that the symbol-function slot ]
[ of a symbol is constrained to contain values of a particular type ]
[ (functions) and that therefore your claim that the Lisp-1/2 distinction ]
[ is NOT a segregation on types is false. ]
So let me guess, you will next argue that symbol-function is not required
to directly set or return the slot value, but may instead substitute some
other value.
>> >
>> > new-contents---a function.
>> > ^^^^^^^^^^
>>
>> However this part is clear. Also, item 5b in the FUNCTION-TYPE
>> Issue Writeup seems (to me) to be explicit about what is intended.
>
>Then why are you picking this nit?
Trying to be fair, which I forgot is usually a mistake on Usenet.
--
Jack Unrue
In article <··································@4ax.com>,
Jack Unrue <·······@example.tld> wrote:
> On Thu, 18 May 2006 14:05:59 -0700, Ron Garret <·········@flownet.com> wrote:
>
> >In article <··································@4ax.com>,
> > Jack Unrue <·······@example.tld> wrote:
> >
> >> On Thu, 18 May 2006 12:09:43 -0700, Ron Garret <·········@flownet.com>
> >> wrote:
> >> >
> >> > contents--- If the symbol is globally defined as a macro or a special
> >> > operator, an object of implementation-dependent nature and identity is
> >> > returned. If the symbol is not globally defined as either a macro or a
> >> > special operator, and if the symbol is fbound, a function object is
> >> > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> >> > returned.
> >> > ^^^^^^^^
> >>
> >> Ron, you have selectively underlined a portion of that sentence
> >> in order to establish an implication that is not being made (by
> >> that specific sentence).
> >
> >Fine, I'll underline more then:
> >
> >If the symbol is not globally defined as either a macro or a special
> >^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> >operator, and if the symbol is fbound, a function object is returned.
> >^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> >
> >
> >> Item 5a in the FUNCTION-TYPE Issue Writeup
> >> says:
> >>
> >> "The value returned by SYMBOL-FUNCTION when FBOUNDP returns true
> >> but the symbol denotes a macro or special form is not well-defined,
> >> but SYMBOL-FUNCTION will not signal an error."
> >
> >That is in no way at odds with what I have said.
>
> Baloney. Your original highlighting was intended to bolster
> your position, which I will remind you was:
>
> [ That's a red herring. The point is simply that the symbol-function slot ]
> [ of a symbol is constrained to contain values of a particular type ]
> [ (functions) and that therefore your claim that the Lisp-1/2 distinction ]
> [ is NOT a segregation on types is false. ]
Sorry, I genuinely don't see how these things are at odds. If I said
"the symbol-function is constrained to values of particular types
(functions, and implementation-specific values representing macros and
special forms)" would that solve the problem?
> So let me guess, you will next argue that symbol-function is not required
> to directly set or return the slot value, but may instead substitute some
> other value.
No, I'm really not trying to be pedantic here. My only point is that
the function namespace is type constrained. Is that really
controversial?
rg
On Thu, 18 May 2006 16:30:43 -0700, Ron Garret <·········@flownet.com> wrote:
>In article <··································@4ax.com>,
> Jack Unrue <·······@example.tld> wrote:
>
>Sorry, I genuinely don't see how these things are at odds. If I said
>"the symbol-function is constrained to values of particular types
>(functions, and implementation-specific values representing macros and
>special forms)" would that solve the problem?
That fixes the reason that I jumped into the middle of this, thanks.
>> So let me guess, you will next argue that symbol-function is not required
>> to directly set or return the slot value, but may instead substitute some
>> other value.
>
>No, I'm really not trying to be pedantic here. My only point is that
>the function namespace is type constrained. Is that really
>controversial?
I will invoke a variation of Pascal's Wager[1]: whereas I now think
the spec could be interpreted differently from what you are saying,
I probably will have more success if I write code as though you are
correct. That's me as a programmer using CL, not implementing CL.
--
Jack Unrue
[1] http://en.wikipedia.org/wiki/Pascal%27s_Wager
Jack Unrue <·······@example.tld> writes:
> On Thu, 18 May 2006 12:09:43 -0700, Ron Garret <·········@flownet.com> wrote:
>> new-contents---a function.
>> ^^^^^^^^^^
>
> However this part is clear.
I'm not sure. Yes, the argument is supposed to be a function but that
just means that you are in the realm of undefined behavior if you try
to SETF SYMBOL-FUNCTION to a non-function value. The Exceptional
Situations section of the SYMBOL-FUNCTION entry specifies that it
Should signal an error of type type-error if symbol is not a symbol.
but says nothing about what should happen if new-contents is not a
function. So I think Kaz is right that an implementation is free to be
more liberal in what it accepts though, of course, it would be
non-portable for a program to rely on that behavior.
-Peter
--
Peter Seibel * ·····@gigamonkeys.com
Gigamonkeys Consulting * http://www.gigamonkeys.com/
Practical Common Lisp * http://www.gigamonkeys.com/book/
On Thu, 18 May 2006 20:33:05 GMT, Peter Seibel <·····@gigamonkeys.com> wrote:
>Jack Unrue <·······@example.tld> writes:
>
>> On Thu, 18 May 2006 12:09:43 -0700, Ron Garret <·········@flownet.com> wrote:
>
>>> new-contents---a function.
>>> ^^^^^^^^^^
>>
>> However this part is clear.
>
>I'm not sure. Yes, the argument is supposed to be a function but that
>just means that you are in the realm of undefined behavior if you try
>to SETF SYMBOL-FUNCTION to a non-function value. The Exceptional
>Situations section of the SYMBOL-FUNCTION entry specifies that it
>
> Should signal an error of type type-error if symbol is not a symbol.
>
>but says nothing about what should happen if new-contents is not a
>function. So I think Kaz is right that an implementation is free to be
>more liberal in what it accepts though, of course, it would be
>non-portable for a program to rely on that behavior.
OK, I think I'm starting to see it that way, too. I re-read item 5b in
the FUNCTION-TYPE issue. That paragraph lists specific types that would
be considered in error but leaves others out.
--
Jack Unrue
Ron Garret <·········@flownet.com> writes:
> In article <························@g10g2000cwb.googlegroups.com>,
> "Kaz Kylheku" <········@gmail.com> wrote:
>
>> Ron Garret wrote:
>> > In article <························@j73g2000cwa.googlegroups.com>,
>> > "Kaz Kylheku" <········@gmail.com> wrote:
>> >
>> > > Good grief you are irksome!
>> >
>> > The feeling is mutual, I assure you.
>>
>> Yeah, but I'm correct-irksome, not idiot-irksome. :)
>
> No, you are continually-missing-the-point-irksome.
Wheee! Let's see if I can be irksome too. To whom, I'm not sure.
> That's a red herring. The point is simply that the symbol-function
> slot of a symbol is constrained to contain values of a particular
> type (functions) and that therefore your claim that the Lisp-1/2
> distinction is NOT a segregation on types is false.
I'm not sure which side of this debate I'm about to enter on but that
here's a thought experiment that may or may not be on point. Let's
imagine we we have Lisp-1 dialect with the following basic evaluation
rule:
<symbol>
lookup the "value" of the variable named by <symbol>.
(<symbol> ...)
If <symbol> is the name of a special operator or macro, transform
the form as appropriate and evaluate the resulting form.
Otherwise, evaluate as if by the (<not-a-symbol> ...) rule below.
(<not-a-symbol> ...)
Evaluate all the elements of the list (according to the basic
evaluation rule) and APPLY the result of evaluating the first
element to a list containing the results of evaluating the
remaining elements.
everything else
Evaluates to itself.
To make this a Lisp-2 we need to do two things. First, we need to
provide a new namespace that is only used to name objects of a
particular type, namely functions. So we add SYMBOL-FUNCTION to hold
global bindings in this namespace, FLET to create lexical bindings,
and a new special operator FUNCTION for accessing this namespace.
Second, we need to change the basic evaluation rule for conses
starting with symbols to this:
(<symbol> ...)
If <symbol> is the name of a special operator or macro, transform
the form as appropriate and evaluate the resulting form.
Otherwise, evaluate <symbol> by looking it up in the function
namespace and APPLY the result to a list containing the results of
evaluating the remaining elements by the basic evaluation rule.
If I may be so bold, I think Ron's point is that the first bit, adding
SYMBOL-FUNCTION, FLET, and FUNCTION, is clearly about creating a new
namespace based on datatype. But Kaz's point, again if I may take a
crack at restating it, is that the second part--modifying the basic
evaluation rule is about the syntax of the language.
So, to look at Ron's argument that there's no principled distinction
between making a special namespace for names of functions and making a
special namespace for names of arrays, we could imagine making our
Lisp-2 into a Lisp-3 by adding a setf'able SYMBOL-ARRAY, a binding
operator ALET, and a special operator ARRAY. Then there would be two
distinct ways ways to name arrays built into the language, just as
there are two ways to name for functions. In this Lisp-3 we could
write:
(let ((x #(1 2 3)))
(alet ((x 1 2 3))
(aref x 0) ; uses first X
(aref (array x) 0) ; uses second X
(setf x (array x)) ; collapses two namespaces.
(aref x 0))) ; uses value of second X via first X
Just the way we can say:
(let ((x #'(lambda (a) a)))
(flet ((x (a) a))
(funcall x 0) ; uses first X
(funcall (function x) 0) ; uses second X
(setf x (function x)) ; collapses two namespaces.
(funcall x 0))) ; uses value of second X via first X
But this doesn't seem exactly analogous to the case of the function
namespace because there's no *syntactic* distinction between the array
and default namespaces other than in the "local syntax" understood by
the ALET and ARRAY special operators. Thus, and again I think this is
Kaz's point, there *is* a principled distinction between making a
Lisp-1 into a Lisp-2 and making a Lisp-2 into a Lisp-3 by adding a
namespace for arrays, in that the function namespace added to a Lisp-1
to make it into a Lisp-2 is there to support a different, syntactic,
evaluation rule. Whether that different evaluation rule is ultimately
a good idea or not, is another question that I personally doubt can be
objectively decided.
-Peter
--
Peter Seibel * ·····@gigamonkeys.com
Gigamonkeys Consulting * http://www.gigamonkeys.com/
Practical Common Lisp * http://www.gigamonkeys.com/book/
In article <··············@gigamonkeys.com>,
Peter Seibel <·····@gigamonkeys.com> wrote:
[A cogent summary of the situation]
I would take issue only with two things. First, a minor detail:
> To make this a Lisp-2 we need to do two things. First, we need to
> provide a new namespace that is only used to name objects of a
> particular type, namely functions.
I would clarify that to this is necessary only to make this a PARTICULAR
KIND of Lisp-2, one whose semantics are similar to CL's. Other kinds of
Lisp-2 are possible, including ones which do not require objects in the
additional namespaces to have a particular type.
Second, a significant point:
> But this doesn't seem exactly analogous to the case of the function
> namespace because there's no *syntactic* distinction between the array
> and default namespaces other than in the "local syntax" understood by
> the ALET and ARRAY special operators.
But that's easy to fix. Just add a new special operator, SAREF, which
is analgous to AREF but which is syntax rather than a function. The
function AREF is then analogous to FUNCALL. So to expand on your
example:
(let ((x #(1 2 3)))
(alet ((x 1 2 3))
(aref x 0) ; uses first X
; analogous to (FUNCALL X 0)
(aref (array x) 0) ; uses second X,
; analogous to (FUNCALL (FUNCTION X) 0)
(saref x 0) ; uses second X as well, analogous to (X 0)
The analogy becomes even more apparent if we introduce new reader
syntax, e.g. [x ...] --> (saref x ...). Then the last line of the
example becomes:
[x 0] ; uses second X as well, analogous to (X 0)
And now it should be evident that the two situations are exactly
comparable.
> Kaz's point, there *is* a principled distinction between making a
> Lisp-1 into a Lisp-2 and making a Lisp-2 into a Lisp-3 by adding a
> namespace for arrays, in that the function namespace added to a Lisp-1
> to make it into a Lisp-2 is there to support a different, syntactic,
> evaluation rule.
Yes, I understand Kaz's point (and I have all along). But his point is
wrong because other kinds of namespaces can also be added to support
different syntactic evaluation rules. What makes the function name
space so special?
rg
Ron Garret <·········@flownet.com> writes:
> In article <··············@gigamonkeys.com>,
> Peter Seibel <·····@gigamonkeys.com> wrote:
>
> [A cogent summary of the situation]
>
> I would take issue only with two things. First, a minor detail:
>
>> To make this a Lisp-2 we need to do two things. First, we need to
>> provide a new namespace that is only used to name objects of a
>> particular type, namely functions.
>
> I would clarify that to this is necessary only to make this a PARTICULAR
> KIND of Lisp-2, one whose semantics are similar to CL's. Other kinds of
> Lisp-2 are possible, including ones which do not require objects in the
> additional namespaces to have a particular type.
>
> Second, a significant point:
>
>> But this doesn't seem exactly analogous to the case of the function
>> namespace because there's no *syntactic* distinction between the array
>> and default namespaces other than in the "local syntax" understood by
>> the ALET and ARRAY special operators.
>
> But that's easy to fix. Just add a new special operator, SAREF,
> which is analgous to AREF but which is syntax rather than a
> function. The function AREF is then analogous to FUNCALL. So to
> expand on your example:
>
> (let ((x #(1 2 3)))
> (alet ((x 1 2 3))
> (aref x 0) ; uses first X
> ; analogous to (FUNCALL X 0)
> (aref (array x) 0) ; uses second X,
> ; analogous to (FUNCALL (FUNCTION X) 0)
> (saref x 0) ; uses second X as well, analogous to (X 0)
>
> The analogy becomes even more apparent if we introduce new reader
> syntax, e.g. [x ...] --> (saref x ...). Then the last line of the
> example becomes:
>
> [x 0] ; uses second X as well, analogous to (X 0)
>
> And now it should be evident that the two situations are exactly
> comparable.
>
>> Kaz's point, there *is* a principled distinction between making a
>> Lisp-1 into a Lisp-2 and making a Lisp-2 into a Lisp-3 by adding a
>> namespace for arrays, in that the function namespace added to a Lisp-1
>> to make it into a Lisp-2 is there to support a different, syntactic,
>> evaluation rule.
>
> Yes, I understand Kaz's point (and I have all along). But his point is
> wrong because other kinds of namespaces can also be added to support
> different syntactic evaluation rules. What makes the function name
> space so special?
Taste, I think. ;-) Let's step back even further and start with a Lisp
(Lisp-1, -2, or -3; it doesn't matter which) whose basic evaluation
rule is as follows. (This is related to an idea suggested long ago by
Kent Pitman as a way of thinking about this problem.)
<symbol>
Look up the value of the variable named by <symbol>
(<symbol> ...)
If <symbol> is the name of a macro, transform the form as
appropriate and reevaluate.
If <symbol> is the name of a special operator, evaluate according
to the special rules of that operator.
Otherwise, the form is syntactically malformed.
everything else
Evaluates to itself.
Now assume we have the special operators CALL and INDEX:
(call <symbol> ...)
Evaluate <symbol> as a function name (using the basic evaluation
rule if this is a Lisp-1 or in the function namespace if this is a
Lisp-2 or -3) and APPLY the resulting function to a list
containing the results of evaluating the remaining forms using the
basic evaluation rule.
(index <symbol> ...)
Evaluate <symbol> as an array name (using the basic evaluation
rule if this is a Lisp-1 or -2 or in the array namespace if this
is a Lisp-3) and return the value obtained by indexing into that
array with the indices produced by evaluating the remaining forms
using the basic evaluation rule.
Now someone says, "Hey, (<symbol> ...) is just an error when the
symbol isn't the name of a macro or a special operator. I call
functions a lot and am tired of typing CALL all the time; why don't we
treat those malformed expressions as that syntatic-sugar for (call
<symbol> ...)."
Now someone else says, "Hey, (<symbol> ...) is just an error when the
symbol isn't the name of a macro or a special operator. I use arrays a
lot and am tired of typing INDEX all the time; why don't we treat
those malformed expressions as that syntatic-sugar for (index <symbol>
...)."
I don't think there's any purely logical way to distinguish between
these two cases but the designers of that language could make a design
decision that says calling functions is more common or fundamental or
something and thus deserving of special syntax than array access. And
I'd say they'd be right. Thus my answer, taste.
So Lisp-1, as instantiated by Scheme anyway, is just as much of a
typed-base hack as you say Lisp-2 is because it privileges functions
over other types because I can say:
(let ((x (lambda (a) (+ 10 a))))
(x 0))
but not:
(let ((x #(1 2 3)))
(x 0))
To be completely egalitarian--and thus hack free--it seems that we
need to require:
(let ((x (lambda (a) (+ 10 a))))
(call x 0))
and
(let ((x #(1 2 3)))
(index x 0))
regardless of whether we're in a Lisp-1, Lisp-2, or Lisp-3.
-Peter
--
Peter Seibel * ·····@gigamonkeys.com
Gigamonkeys Consulting * http://www.gigamonkeys.com/
Practical Common Lisp * http://www.gigamonkeys.com/book/
In article <··············@gigamonkeys.com>,
Peter Seibel <·····@gigamonkeys.com> wrote:
> > What makes the function name space so special?
>
> Taste, I think. ;-)
Yes, that would be exactly my point.
> So Lisp-1, as instantiated by Scheme anyway, is just as much of a
> typed-base hack as you say Lisp-2 is because it privileges functions
> over other types because I can say:
>
> (let ((x (lambda (a) (+ 10 a))))
> (x 0))
>
> but not:
>
> (let ((x #(1 2 3)))
> (x 0))
Agreed, but the "as instantiated by Scheme" bit is a very important
caveat.
> To be completely egalitarian--and thus hack free--it seems that we
> need to require:
>
> (let ((x (lambda (a) (+ 10 a))))
> (call x 0))
>
> and
>
> (let ((x #(1 2 3)))
> (index x 0))
>
> regardless of whether we're in a Lisp-1, Lisp-2, or Lisp-3.
Why should we need to require that? Why could we not define (x ...) to
mean (call x ...) when x is a function and (aref x ...) when x is an
array?
(BTW, it is very important to notice that the discussion has gone off on
a tangent at this point. The decision to make (x ...) mean (call x ...)
is defensible on the grounds that CALL is far and away the most commonly
used special operator in most code. However, the decision to split off
a separate namespace for functions is an orthogonal issue, and much more
difficult to justify except as a matter of personal preference.)
rg
Ron Garret <·········@flownet.com> writes:
> In article <··············@gigamonkeys.com>,
> Peter Seibel <·····@gigamonkeys.com> wrote:
>> To be completely egalitarian--and thus hack free--it seems that we
>> need to require:
>>
>> (let ((x (lambda (a) (+ 10 a))))
>> (call x 0))
>>
>> and
>>
>> (let ((x #(1 2 3)))
>> (index x 0))
>>
>> regardless of whether we're in a Lisp-1, Lisp-2, or Lisp-3.
>
> Why should we need to require that? Why could we not define (x ...) to
> mean (call x ...) when x is a function and (aref x ...) when x is an
> array?
That'd be another egalitarian approach. Though one with puts some
burdens on the compiler writer if they want to maintain the same
performance as using explicit special operators. But that's an
implementation detail.
> (BTW, it is very important to notice that the discussion has gone
> off on a tangent at this point. The decision to make (x ...) mean
> (call x ...) is defensible on the grounds that CALL is far and away
> the most commonly used special operator in most code. However, the
> decision to split off a separate namespace for functions is an
> orthogonal issue, and much more difficult to justify except as a
> matter of personal preference.)
And isn't likewise the decision to smush down the function and
variable namespaces into a single namespace equally difficult to
justify except as a matter of personal preference? If there were some
objective proof that Lisp-1 was better, then this particular flamewar
would have been over and settled years ago. Instead, folks continually
recapitulate it because it *is* a matter of personal preference.
-Peter
P.S. Just as a data point vis a vis the effect of Lisp-1 vs Lisp-2ness
on newbies--some years ago I was doing some Javascript coding and
created a bug in my program because I didn't realize that Javascript
is a Lisp-1: I used 'foo' as both the name of a function and a
variable and didn't understand why the script on my web page worked
for a while (while the 'foo' was still a function) and then stopped
working after a while (when some code ran than assigned a new,
non-function, value to 'foo'). At the time I wasn't aware of the
Lisp-1 vs Lisp-2 distinction but after much puzzling, I eventually
managed to figure out what had happened. FWIW, when I did I thought
that was the dumbest language design decision I could possibly
imagine. I now understand why Javascript is the way it is and some of
the benefits, in that language ecosystem, but it's not the case that
Lisp-1ness never causes confusion for newbies.
--
Peter Seibel * ·····@gigamonkeys.com
Gigamonkeys Consulting * http://www.gigamonkeys.com/
Practical Common Lisp * http://www.gigamonkeys.com/book/
In article <··············@gigamonkeys.com>,
Peter Seibel <·····@gigamonkeys.com> wrote:
> > (BTW, it is very important to notice that the discussion has gone
> > off on a tangent at this point. The decision to make (x ...) mean
> > (call x ...) is defensible on the grounds that CALL is far and away
> > the most commonly used special operator in most code. However, the
> > decision to split off a separate namespace for functions is an
> > orthogonal issue, and much more difficult to justify except as a
> > matter of personal preference.)
>
> And isn't likewise the decision to smush down the function and
> variable namespaces into a single namespace equally difficult to
> justify except as a matter of personal preference?
No. All else being equal, simpler is always better.
Until recently all else was not equal. It was widely acknowledged on
both sides of the debate that Lisp-1 leads to problems with name
capture. Two different solutions to this problem were adopted, an
MIT-style solution (hygiene) and a Menlo-Park-style solution (Lisp-2).
But now there is a third solution (context-independent to top-level
bindings) which, as far as I can tell, provides what is supposedly the
major benefit of Lisp-2 (protection from certain kinds of unintentional
name capture in macros) without the attendant complexity. IMO that
changes the balance of the debate.
> If there were some
> objective proof that Lisp-1 was better, then this particular flamewar
> would have been over and settled years ago. Instead, folks continually
> recapitulate it because it *is* a matter of personal preference.
Sure. Some people like Perl too.
> P.S. Just as a data point vis a vis the effect of Lisp-1 vs Lisp-2ness
> on newbies--some years ago I was doing some Javascript coding and
> created a bug in my program because I didn't realize that Javascript
> is a Lisp-1: I used 'foo' as both the name of a function and a
> variable and didn't understand why the script on my web page worked
> for a while (while the 'foo' was still a function) and then stopped
> working after a while (when some code ran than assigned a new,
> non-function, value to 'foo'). At the time I wasn't aware of the
> Lisp-1 vs Lisp-2 distinction but after much puzzling, I eventually
> managed to figure out what had happened. FWIW, when I did I thought
> that was the dumbest language design decision I could possibly
> imagine. I now understand why Javascript is the way it is and some of
> the benefits, in that language ecosystem, but it's not the case that
> Lisp-1ness never causes confusion for newbies.
When I first encountered Pascal (the programming language, not the Lisp
programmer) I thought it was a stupid language because it didn't have
line numbers like BASIC did. Everyone makes dumb mistakes.
rg
Ron Garret <·········@flownet.com> writes:
>> I now understand why Javascript is the way it is and some of the
>> benefits, in that language ecosystem, but it's not the case that
>> Lisp-1ness never causes confusion for newbies.
>
> When I first encountered Pascal (the programming language, not the
> Lisp programmer) I thought it was a stupid language because it
> didn't have line numbers like BASIC did. Everyone makes dumb
> mistakes.
Of course. I was simply addressing your contention that Lisp-1 is
better because Lisp-2 is confusing to newbies. My experinece is proof
that Lisp-1 can also be confusing to newbies.
-Peter
--
Peter Seibel * ·····@gigamonkeys.com
Gigamonkeys Consulting * http://www.gigamonkeys.com/
Practical Common Lisp * http://www.gigamonkeys.com/book/
Peter Seibel wrote:
> Ron Garret <·········@flownet.com> writes:
>
>
>>>I now understand why Javascript is the way it is and some of the
>>>benefits, in that language ecosystem, but it's not the case that
>>>Lisp-1ness never causes confusion for newbies.
>>
>>When I first encountered Pascal (the programming language, not the
>>Lisp programmer) I thought it was a stupid language because it
>>didn't have line numbers like BASIC did. Everyone makes dumb
>>mistakes.
>
>
> Of course. I was simply addressing your contention that Lisp-1 is
> better because Lisp-2 is confusing to newbies. My experinece is proof
> that Lisp-1 can also be confusing to newbies.
>
> -Peter
>
As a counterpoint: I code a Lisp-1 dialect into my interpreter, and I've
only been using Lisp for 5-6 months. I started this particular project
about 2 months into using Lisp.
Lisp-1 wasn't confusing to this particular n00bling, for what anecdotal
evidence may tell us.
--
The science of economics is the cleverest proof of free will yet
constructed.
Ron Garret wrote:
> In article <··············@gigamonkeys.com>,
> Peter Seibel <·····@gigamonkeys.com> wrote:
>
>>> (BTW, it is very important to notice that the discussion has gone
>>> off on a tangent at this point. The decision to make (x ...) mean
>>> (call x ...) is defensible on the grounds that CALL is far and away
>>> the most commonly used special operator in most code. However, the
>>> decision to split off a separate namespace for functions is an
>>> orthogonal issue, and much more difficult to justify except as a
>>> matter of personal preference.)
>> And isn't likewise the decision to smush down the function and
>> variable namespaces into a single namespace equally difficult to
>> justify except as a matter of personal preference?
>
> No. All else being equal, simpler is always better.
>
> Until recently all else was not equal. It was widely acknowledged on
> both sides of the debate that Lisp-1 leads to problems with name
> capture. Two different solutions to this problem were adopted, an
> MIT-style solution (hygiene) and a Menlo-Park-style solution (Lisp-2).
>
> But now there is a third solution (context-independent to top-level
> bindings) which, as far as I can tell, provides what is supposedly the
> major benefit of Lisp-2 (protection from certain kinds of unintentional
> name capture in macros) without the attendant complexity. IMO that
> changes the balance of the debate.
What you describe as a third "solution" is a mere idea that you have
whipped up recently, without providing an implementation and without
providing a considerable number of examples that show how well it works,
especially in corner cases. I am not saying that your proposed
"solution" doesn't work, but want to point out that the problem of name
capture is a very subtle one, where the devil is in the details. Any
claim of yours that you indeed have provided a third "solution" has to
be taken with a grain of salt, to say the least.
You should be intellectually more honest in this regard.
Pascal
--
3rd European Lisp Workshop
July 3 - Nantes, France - co-located with ECOOP 2006
http://lisp-ecoop06.bknr.net/
In article <···············@individual.net>,
Pascal Costanza <··@p-cos.net> wrote:
> Ron Garret wrote:
> > In article <··············@gigamonkeys.com>,
> > Peter Seibel <·····@gigamonkeys.com> wrote:
> >
> >>> (BTW, it is very important to notice that the discussion has gone
> >>> off on a tangent at this point. The decision to make (x ...) mean
> >>> (call x ...) is defensible on the grounds that CALL is far and away
> >>> the most commonly used special operator in most code. However, the
> >>> decision to split off a separate namespace for functions is an
> >>> orthogonal issue, and much more difficult to justify except as a
> >>> matter of personal preference.)
> >> And isn't likewise the decision to smush down the function and
> >> variable namespaces into a single namespace equally difficult to
> >> justify except as a matter of personal preference?
> >
> > No. All else being equal, simpler is always better.
> >
> > Until recently all else was not equal. It was widely acknowledged on
> > both sides of the debate that Lisp-1 leads to problems with name
> > capture. Two different solutions to this problem were adopted, an
> > MIT-style solution (hygiene) and a Menlo-Park-style solution (Lisp-2).
> >
> > But now there is a third solution (context-independent to top-level
> > bindings) which, as far as I can tell, provides what is supposedly the
> > major benefit of Lisp-2 (protection from certain kinds of unintentional
> > name capture in macros) without the attendant complexity. IMO that
> > changes the balance of the debate.
>
> What you describe as a third "solution" is a mere idea that you have
> whipped up recently, without providing an implementation and without
> providing a considerable number of examples that show how well it works,
> especially in corner cases. I am not saying that your proposed
> "solution" doesn't work, but want to point out that the problem of name
> capture is a very subtle one, where the devil is in the details. Any
> claim of yours that you indeed have provided a third "solution" has to
> be taken with a grain of salt, to say the least.
>
> You should be intellectually more honest in this regard.
Fine. Substitute "possibility" for "solution."
rg
Ron Garret <·········@flownet.com> writes:
> In article <························@g10g2000cwb.googlegroups.com>,
> "Kaz Kylheku" <········@gmail.com> wrote:
>
> > Otherwise, there will be a puzzling error message:
> > an expression like (FOO 42) will blow up because FOO isn't a function.
> > (Exactly as would happen in a Lisp-1 if FOO is a variable that doesn't
> > hold a function; doh!)
>
> Really? You mean if I do this in Scheme:
>
> (define foo 1)
>
> that's an error?
It is if you then try
(foo 42)
which is Kaz' point.
--
Thomas A. Russ, USC/Information Sciences Institute
In article <···············@sevak.isi.edu>,
···@sevak.isi.edu (Thomas A. Russ) wrote:
> Ron Garret <·········@flownet.com> writes:
>
>
> > In article <························@g10g2000cwb.googlegroups.com>,
> > "Kaz Kylheku" <········@gmail.com> wrote:
> >
> > > Otherwise, there will be a puzzling error message:
> > > an expression like (FOO 42) will blow up because FOO isn't a function.
> > > (Exactly as would happen in a Lisp-1 if FOO is a variable that doesn't
> > > hold a function; doh!)
> >
> > Really? You mean if I do this in Scheme:
> >
> > (define foo 1)
> >
> > that's an error?
>
> It is if you then try
>
> (foo 42)
>
> which is Kaz' point.
You left out some very important context. Here's the complete quote:
> This is due to the behavior of the SETF operator in conjunction with
> the SYMBOL-FUNCTION place, neither of which have anything to do with
> Lisp-2 versus Lisp-1. Someone decided that there shall be this
> constraint, so that if someone makes the error of putting a
> non-function into a function binding, that error will be intercepted as
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> early as possible. Otherwise, there will be a puzzling error message:
^^^^^^^^^^^^^^^^^
> an expression like (FOO 42) will blow up because FOO isn't a function.
> (Exactly as would happen in a Lisp-1 if FOO is a variable that doesn't
> hold a function; doh!)
rg
Kaz Kylheku <········@gmail.com> wrote:
+---------------
| The symbol-function slot of a symbol isn't even necessarily the active
| function binding in a given scope, since it could be shadowed by a
| lexical binding. In that case, whatever you put in there makes no
| difference anyway.
...
| What happens in (SYMBOL-FUNCTION 'FOO) is completely irrelevant; it's
| up to the guts of that function. A Lisp-2 dialect doesn't even have to
| have that function.
+---------------
Well, a *Common Lisp* implementation has to have the function
SYMBOL-FUNCTION, but it certainly doesn't have to work by accessing
a "slot" in the SYMBOL object itself. ;-}
For a prime example, if you look under CMUCL's covers [and by this I
mean examine internal binary representations], you will find that the
symbol objects do not even *HAVE* a symbol-function slot!! Really.[1]
Instead, that information is kept in an implementation-internal
"INFO" database, and all of the "SYMBOL-xxx" and "Fxxx" functions
that in other implementations might access the symbol-function
slot access that INFO database instead. Distilling out a bunch of
extra layers and auxiliary functions and error checks [and ignoring
the "function wrappers" facility!], to a first approximation you
have this sort of thing:
(defun symbol-function (name)
(fdefn-function ; extract function from FDEFN
(info function definition name))) ; INFO a macro, args 1,2 not eval.
(defun fdefinition (name)
(fdefn-function
(info function definition name)))
(defun fboundp (name)
(let ((fdefn (info function definition name)))
(and fdefn (fdefn-function fdefn) t)))
E.g.:
> (info function definition '+)
#<FDEFINITION object for +>
T
> (lisp::fdefn-function *)
#<Function + {1016A5F1}>
>
[Obviously, nearly all of those INFO accesses get optimized away
in compiled code...]
So in this case the implementation really *does* make a big deal
out of CL being a Lisp2.
-Rob
[1] Yes, I confess that I found this odd. But it's true. Here's the
C structure for a CMUCL symbol. Look, Ma! No "function" slot!
struct symbol {
lispobj header;
lispobj value;
lispobj hash;
lispobj plist;
lispobj name;
lispobj package;
};
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
Ron Garret wrote:
> The following, for example, IS legal CL:
> (defun foo () '#.#'car)
My understanding is that CL doesn't allow this in a compiled file.
See CLHS 3.2.4.1 and 3.2.4.2.2.
In article <··············@junk.nocrew.org>,
Lars Brinkhoff <·········@nocrew.org> wrote:
> Ron Garret wrote:
> > The following, for example, IS legal CL:
> > (defun foo () '#.#'car)
>
> My understanding is that CL doesn't allow this in a compiled file.
> See CLHS 3.2.4.1 and 3.2.4.2.2.
I think it's more accurate to say that CL doesn't require this. (Some
implementations do allow it.) But that's one of the beauties of Lisp:
not all code has to reside in compiled files.
rg
Ron Garret wrote:
> In article <···············@oc.ex.ac.uk>,
> Alexander Schmolck <··········@gmail.com> wrote:
>
>> Ron Garret <·········@flownet.com> writes:
>>
>>> IMO any hack that generates confusion in newcomers with near 100%
>>> reliability and has a workable alternative is a horrible hack.
>> Are you talking of logical-pathnames or the package system? <duck>
>
> Don't get me started.
>
>>>> (For that matter, Lisp-2
>>>> avoids certain name clashes everywhere, not just in macros.)
>>> Like what?
>> Types vs values; block labels -- all sorts of things.
>
> I presume you mean something like:
>
> (let ((list ...))
> (block list ... (return-from list (coerce (foo list) 'list)) ...))
>
> It isn't really Lisp-2 avoiding name collision here, it is, as you say,
> Lisp-inf. The merits of having each of these name spaces built in to
> the language is a separate, orthogonal discussion which would lead us
> far afield.
No, it's not. Consider the following macro:
(defmacro with-something (&body body)
`(block foo ,@body))
The block name 'foo wouldn't clash with a function name 'foo, a variable
name 'foo, and so on. Multiple namespaces give you exactly: the
opportunity to use the same name in different circumstances.
> I'll just point out a couple of things:
>
> 1. In Python, types are (mostly) opaque first-class objects, and that
> seems to work reasonably well.
>
> 2. Nothing prevents a user from creating new namespaces using
> associative maps.
In Common Lisp, this is actually encouraged due to the fact that the
language itself already provides a considerable number of them.
> 3. The block label namespace is static and exists only at compile time.
>
> 4. Why stop where CL did? Why not e.g. a separate name space for every
> data type? Why shouldn't I be able to do:
>
> (list-let ((x '(1 2 3)))
> (vector-let ((x #(a b c)))
> (integer-let ((x 1))
> (cons (car x) (aref x x))) --> (1 . b)
As Guido van Rossum recently said, programming language design is not
the same as solving mathematical puzzles. Yes, you can try to design a
language based on "first principles", and to a certain extent this makes
sense because it potentially makes a language easier to grasp, but this
indeed only works to a certain extent. At some stage, you will face
trade offs and make some decisions that favor some issues over others.
Pascal
--
3rd European Lisp Workshop
July 3-4 - Nantes, France - co-located with ECOOP 2006
http://lisp-ecoop06.bknr.net/
In article <···············@individual.net>,
Pascal Costanza <··@p-cos.net> wrote:
> >>>> (For that matter, Lisp-2
> >>>> avoids certain name clashes everywhere, not just in macros.)
> >>> Like what?
> >> Types vs values; block labels -- all sorts of things.
> >
> > I presume you mean something like:
> >
> > (let ((list ...))
> > (block list ... (return-from list (coerce (foo list) 'list)) ...))
> >
> > It isn't really Lisp-2 avoiding name collision here, it is, as you say,
> > Lisp-inf. The merits of having each of these name spaces built in to
> > the language is a separate, orthogonal discussion which would lead us
> > far afield.
>
> No, it's not. Consider the following macro:
>
> (defmacro with-something (&body body)
> `(block foo ,@body))
>
> The block name 'foo wouldn't clash with a function name 'foo, a variable
> name 'foo, and so on. Multiple namespaces give you exactly: the
> opportunity to use the same name in different circumstances.
All that is true, but in no way contradicts what I said.
> > I'll just point out a couple of things:
> >
> > 1. In Python, types are (mostly) opaque first-class objects, and that
> > seems to work reasonably well.
> >
> > 2. Nothing prevents a user from creating new namespaces using
> > associative maps.
>
> In Common Lisp, this is actually encouraged due to the fact that the
> language itself already provides a considerable number of them.
<shrug> One could as easily argue that it is discouraged because the
language already provides all you need.
> > 3. The block label namespace is static and exists only at compile time.
> >
> > 4. Why stop where CL did? Why not e.g. a separate name space for every
> > data type? Why shouldn't I be able to do:
> >
> > (list-let ((x '(1 2 3)))
> > (vector-let ((x #(a b c)))
> > (integer-let ((x 1))
> > (cons (car x) (aref x x))) --> (1 . b)
>
> As Guido van Rossum recently said, programming language design is not
> the same as solving mathematical puzzles. Yes, you can try to design a
> language based on "first principles", and to a certain extent this makes
> sense because it potentially makes a language easier to grasp, but this
> indeed only works to a certain extent. At some stage, you will face
> trade offs and make some decisions that favor some issues over others.
Of course, but if two designs provide exactly the same benefits and one
is simpler than the other then the simpler design is always to be
preferred. IMHO of course. (In this case the situation is actually
that a simpler design provides a strict superset of the features of the
more complicated one, making the issue even more clear cut.)
rg
Ron Garret <·········@flownet.com> writes:
> In article <···············@individual.net>,
> Pascal Costanza <··@p-cos.net> wrote:
>
> > As Guido van Rossum recently said, programming language design is not
> > the same as solving mathematical puzzles. Yes, you can try to design a
> > language based on "first principles", and to a certain extent this makes
> > sense because it potentially makes a language easier to grasp, but this
> > indeed only works to a certain extent. At some stage, you will face
> > trade offs and make some decisions that favor some issues over others.
>
> Of course, but if two designs provide exactly the same benefits and one
> is simpler than the other then the simpler design is always to be
> preferred. IMHO of course. (In this case the situation is actually
> that a simpler design provides a strict superset of the features of the
> more complicated one, making the issue even more clear cut.)
Actually, the premise of this argument is not true. The simpler design
does not provide exactly the same benefits. (Or perhaps one should use
the less loaded term "features" instead of "benefits".)
The simpler design doesn't let you use the same name for different
purposes in the same scope. Now, you may argue about whether you like
being able to do that or not, but since that is at the very least an
arguable case, you can't make a valid dominance argument about it.
The issue is one of which engineering tradeoff one wishes to have.
There are clearly successful examples of both approaches (Common Lisp
and Scheme). But this is an issue that regularly gets beaten to death
here, which is why it is often regarded as a religious topic. But since
both approaches are available, perhaps the best solution is to adopt a
"live and let live" attitude rather than trying to seek converts.
If you prefer the simpler namespace, use the language variant that has
it. Build on Scheme or some derivative thereof.
--
Thomas A. Russ, USC/Information Sciences Institute
In article <···············@sevak.isi.edu>,
···@sevak.isi.edu (Thomas A. Russ) wrote:
> Ron Garret <·········@flownet.com> writes:
>
> > In article <···············@individual.net>,
> > Pascal Costanza <··@p-cos.net> wrote:
> >
> > > As Guido van Rossum recently said, programming language design is not
> > > the same as solving mathematical puzzles. Yes, you can try to design a
> > > language based on "first principles", and to a certain extent this makes
> > > sense because it potentially makes a language easier to grasp, but this
> > > indeed only works to a certain extent. At some stage, you will face
> > > trade offs and make some decisions that favor some issues over others.
> >
> > Of course, but if two designs provide exactly the same benefits and one
> > is simpler than the other then the simpler design is always to be
> > preferred. IMHO of course. (In this case the situation is actually
> > that a simpler design provides a strict superset of the features of the
> > more complicated one, making the issue even more clear cut.)
>
> Actually, the premise of this argument is not true. The simpler design
> does not provide exactly the same benefits. (Or perhaps one should use
> the less loaded term "features" instead of "benefits".)
>
> The simpler design doesn't let you use the same name for different
> purposes in the same scope.
Of course it does. It just means that the code I have to write to use
it for those different purposes is slightly different.
rg
Ron Garret <·········@flownet.com> writes:
> In article <···············@sevak.isi.edu>,
> ···@sevak.isi.edu (Thomas A. Russ) wrote:
>
> > Ron Garret <·········@flownet.com> writes:
> >
> > > In article <···············@individual.net>,
> > > Pascal Costanza <··@p-cos.net> wrote:
> > >
> > > > As Guido van Rossum recently said, programming language design is not
> > > > the same as solving mathematical puzzles. Yes, you can try to design a
> > > > language based on "first principles", and to a certain extent this makes
> > > > sense because it potentially makes a language easier to grasp, but this
> > > > indeed only works to a certain extent. At some stage, you will face
> > > > trade offs and make some decisions that favor some issues over others.
> > >
> > > Of course, but if two designs provide exactly the same benefits and one
> > > is simpler than the other then the simpler design is always to be
> > > preferred. IMHO of course. (In this case the situation is actually
> > > that a simpler design provides a strict superset of the features of the
> > > more complicated one, making the issue even more clear cut.)
> >
> > Actually, the premise of this argument is not true. The simpler design
> > does not provide exactly the same benefits. (Or perhaps one should use
> > the less loaded term "features" instead of "benefits".)
> >
> > The simpler design doesn't let you use the same name for different
> > purposes in the same scope.
>
> Of course it does. It just means that the code I have to write to use
> it for those different purposes is slightly different.
But then it's not simpler, is it?
--
Thomas A. Russ, USC/Information Sciences Institute
In article <···············@sevak.isi.edu>,
···@sevak.isi.edu (Thomas A. Russ) wrote:
> Ron Garret <·········@flownet.com> writes:
>
> > In article <···············@sevak.isi.edu>,
> > ···@sevak.isi.edu (Thomas A. Russ) wrote:
> >
> > > Ron Garret <·········@flownet.com> writes:
> > >
> > > > In article <···············@individual.net>,
> > > > Pascal Costanza <··@p-cos.net> wrote:
> > > >
> > > > > As Guido van Rossum recently said, programming language design is not
> > > > > the same as solving mathematical puzzles. Yes, you can try to design
> > > > > a
> > > > > language based on "first principles", and to a certain extent this
> > > > > makes
> > > > > sense because it potentially makes a language easier to grasp, but
> > > > > this
> > > > > indeed only works to a certain extent. At some stage, you will face
> > > > > trade offs and make some decisions that favor some issues over
> > > > > others.
> > > >
> > > > Of course, but if two designs provide exactly the same benefits and one
> > > > is simpler than the other then the simpler design is always to be
> > > > preferred. IMHO of course. (In this case the situation is actually
> > > > that a simpler design provides a strict superset of the features of the
> > > > more complicated one, making the issue even more clear cut.)
> > >
> > > Actually, the premise of this argument is not true. The simpler design
> > > does not provide exactly the same benefits. (Or perhaps one should use
> > > the less loaded term "features" instead of "benefits".)
> > >
> > > The simpler design doesn't let you use the same name for different
> > > purposes in the same scope.
> >
> > Of course it does. It just means that the code I have to write to use
> > it for those different purposes is slightly different.
>
> But then it's not simpler, is it?
That depends on what you mean by "it". The code you need to write to do
something that you probably shouldn't be doing anyway (because it tends
to be confusing) is slightly more complicated, yes. But the language
design is considerably simpler.
rg
Ron Garret <·········@flownet.com> writes:
> In article <···············@sevak.isi.edu>,
> ···@sevak.isi.edu (Thomas A. Russ) wrote:
>
> > Ron Garret <·········@flownet.com> writes:
> >
> > > In article <···············@sevak.isi.edu>,
> > > ···@sevak.isi.edu (Thomas A. Russ) wrote:
> > >
> > > > Ron Garret <·········@flownet.com> writes:
> > > >
> > > > > In article <···············@individual.net>,
> > > > > Pascal Costanza <··@p-cos.net> wrote:
> > > > >
> > > > > > As Guido van Rossum recently said, programming language design is not
> > > > > > the same as solving mathematical puzzles. Yes, you can try to design
> > > > > > a
> > > > > > language based on "first principles", and to a certain extent this
> > > > > > makes
> > > > > > sense because it potentially makes a language easier to grasp, but
> > > > > > this
> > > > > > indeed only works to a certain extent. At some stage, you will face
> > > > > > trade offs and make some decisions that favor some issues over
> > > > > > others.
> > > > >
> > > > > Of course, but if two designs provide exactly the same benefits and one
> > > > > is simpler than the other then the simpler design is always to be
> > > > > preferred. IMHO of course. (In this case the situation is actually
> > > > > that a simpler design provides a strict superset of the features of the
> > > > > more complicated one, making the issue even more clear cut.)
> > > >
> > > > Actually, the premise of this argument is not true. The simpler design
> > > > does not provide exactly the same benefits. (Or perhaps one should use
> > > > the less loaded term "features" instead of "benefits".)
> > > >
> > > > The simpler design doesn't let you use the same name for different
> > > > purposes in the same scope.
> > >
> > > Of course it does. It just means that the code I have to write to use
> > > it for those different purposes is slightly different.
> >
> > But then it's not simpler, is it?
>
> That depends on what you mean by "it". The code you need to write to do
> something that you probably shouldn't be doing anyway (because it tends
> to be confusing) is slightly more complicated, yes.
The thing you just can't get square on (or maybe can't accept, due to
unknown issues) is that this is just your opinion. There really isn't
any objective scientific type study(s) out there that in any way show
this to be a hard fact. Your insistence that your opinion here is
somehow fact borders on megalomania.
> But the language design is considerably simpler.
Even this is not fact. As many have tried to indicate it is all about
trade offs. The trade offs are more or less fact, but the value
judgments placed on them (those are good, because I like them, while
those are bad, because I don't like them) are all about opinion and
subjective aesthetics. Note: that's not a bad thing. The dodgy bit
comes when people start trying to foist these value judgments off as
fact. For some reason, you have a propensity for this.
/Jon
--
'j' - a n t h o n y at romeo/charley/november com
In article <··············@rigel.goldenthreadtech.com>,
jayessay <······@foo.com> wrote:
> Ron Garret <·········@flownet.com> writes:
>
> > In article <···············@sevak.isi.edu>,
> > ···@sevak.isi.edu (Thomas A. Russ) wrote:
> >
> > > Ron Garret <·········@flownet.com> writes:
> > >
> > > > In article <···············@sevak.isi.edu>,
> > > > ···@sevak.isi.edu (Thomas A. Russ) wrote:
> > > >
> > > > > Ron Garret <·········@flownet.com> writes:
> > > > >
> > > > > > In article <···············@individual.net>,
> > > > > > Pascal Costanza <··@p-cos.net> wrote:
> > > > > >
> > > > > > > As Guido van Rossum recently said, programming language design is
> > > > > > > not
> > > > > > > the same as solving mathematical puzzles. Yes, you can try to
> > > > > > > design
> > > > > > > a
> > > > > > > language based on "first principles", and to a certain extent
> > > > > > > this
> > > > > > > makes
> > > > > > > sense because it potentially makes a language easier to grasp,
> > > > > > > but
> > > > > > > this
> > > > > > > indeed only works to a certain extent. At some stage, you will
> > > > > > > face
> > > > > > > trade offs and make some decisions that favor some issues over
> > > > > > > others.
> > > > > >
> > > > > > Of course, but if two designs provide exactly the same benefits and
> > > > > > one
> > > > > > is simpler than the other then the simpler design is always to be
> > > > > > preferred. IMHO of course. (In this case the situation is
^^^^^^^^^^^^^^
> > > > > > actually
> > > > > > that a simpler design provides a strict superset of the features of
> > > > > > the
> > > > > > more complicated one, making the issue even more clear cut.)
> > > > >
> > > > > Actually, the premise of this argument is not true. The simpler
> > > > > design
> > > > > does not provide exactly the same benefits. (Or perhaps one should
> > > > > use
> > > > > the less loaded term "features" instead of "benefits".)
> > > > >
> > > > > The simpler design doesn't let you use the same name for different
> > > > > purposes in the same scope.
> > > >
> > > > Of course it does. It just means that the code I have to write to use
> > > > it for those different purposes is slightly different.
> > >
> > > But then it's not simpler, is it?
> >
> > That depends on what you mean by "it". The code you need to write to do
> > something that you probably shouldn't be doing anyway (because it tends
> > to be confusing) is slightly more complicated, yes.
>
> The thing you just can't get square on (or maybe can't accept, due to
> unknown issues) is that this is just your opinion. There really isn't
> any objective scientific type study(s) out there that in any way show
> this to be a hard fact.
I don't need to conduct a scientific study to know that if the features
of language X are a proper subset of language Y then language X is (most
likely -- I'm sure some wise guy will come up with a counterexample)
simpler than language Y. That's what "simpler" means.
> Your insistence that your opinion here is
> somehow fact borders on megalomania.
Please take a moment to read the highlighted passage at the top of the
page, the one that says "IMHO of course." "IMHO", in case you are not
aware, stands for "In My Humble Opinion." I don't know how much clearer
I could possibly have made it that I am NOT claiming the superiority of
one design over another as a fact.
> > But the language design is considerably simpler.
>
> Even this is not fact.
Of course it's a fact. If you have multiple name spaces you need
additional mechanisms for specifying which name space to create bindings
in. If there is only one name space there is no need to specify which
one you want (because there is only one). This is unconditionally
simpler by any reasonable definition of the word.
> As many have tried to indicate it is all about
> trade offs. The trade offs are more or less fact, but the value
> judgments placed on them (those are good, because I like them, while
> those are bad, because I don't like them) are all about opinion and
> subjective aesthetics. Note: that's not a bad thing. The dodgy bit
> comes when people start trying to foist these value judgments off as
> fact. For some reason, you have a propensity for this.
It is MY OPINION (is that clear enough?) that, as a general rule and all
else being equal, simpler is better. I am not alone in this opinion, it
is shared by a great many people, and there is a large body of
experience that shows that in CS in particular not adhering to that
particular aesthetic leads to problems. But it is not a "fact" and I
never said it was. C++ is the poster child for the opposing point of
view, and a lot of people even if they are not exactly enamored of it do
manage to get useful work done in C++ (to my continual amazement).
One final note:
> it is all about trade offs
Of course it is. That is why the "all else being equal" disclaimer is
there. If simpler were unconditionally better then unlambda would be
the ultimate programming language.
rg
Ron Garret <·········@flownet.com> writes:
> In article <··············@rigel.goldenthreadtech.com>,
> jayessay <······@foo.com> wrote:
>
> > Ron Garret <·········@flownet.com> writes:
> >
> > > In article <···············@sevak.isi.edu>,
> > > ···@sevak.isi.edu (Thomas A. Russ) wrote:
> > >
> > > > Ron Garret <·········@flownet.com> writes:
> > > >
> > > > > In article <···············@sevak.isi.edu>,
> > > > > ···@sevak.isi.edu (Thomas A. Russ) wrote:
> > > > >
> > > > > > Ron Garret <·········@flownet.com> writes:
> > > > > >
> > > > > > > In article <···············@individual.net>,
> > > > > > > Pascal Costanza <··@p-cos.net> wrote:
> > > > > > >
> > > > > > > > As Guido van Rossum recently said, programming language design is
> > > > > > > > not
> > > > > > > > the same as solving mathematical puzzles. Yes, you can try to
> > > > > > > > design
> > > > > > > > a
> > > > > > > > language based on "first principles", and to a certain extent
> > > > > > > > this
> > > > > > > > makes
> > > > > > > > sense because it potentially makes a language easier to grasp,
> > > > > > > > but
> > > > > > > > this
> > > > > > > > indeed only works to a certain extent. At some stage, you will
> > > > > > > > face
> > > > > > > > trade offs and make some decisions that favor some issues over
> > > > > > > > others.
> > > > > > >
> > > > > > > Of course, but if two designs provide exactly the same benefits and
> > > > > > > one
> > > > > > > is simpler than the other then the simpler design is always to be
> > > > > > > preferred. IMHO of course. (In this case the situation is
> ^^^^^^^^^^^^^^
> > > > > > > actually
> > > > > > > that a simpler design provides a strict superset of the features of
> > > > > > > the
> > > > > > > more complicated one, making the issue even more clear cut.)
> > > > > >
> > > > > > Actually, the premise of this argument is not true. The simpler
> > > > > > design
> > > > > > does not provide exactly the same benefits. (Or perhaps one should
> > > > > > use
> > > > > > the less loaded term "features" instead of "benefits".)
> > > > > >
> > > > > > The simpler design doesn't let you use the same name for different
> > > > > > purposes in the same scope.
> > > > >
> > > > > Of course it does. It just means that the code I have to write to use
> > > > > it for those different purposes is slightly different.
> > > >
> > > > But then it's not simpler, is it?
> > >
> > > That depends on what you mean by "it". The code you need to write to do
> > > something that you probably shouldn't be doing anyway (because it tends
> > > to be confusing) is slightly more complicated, yes.
> >
> > The thing you just can't get square on (or maybe can't accept, due to
> > unknown issues) is that this is just your opinion. There really isn't
> > any objective scientific type study(s) out there that in any way show
> > this to be a hard fact.
>
> I don't need to conduct a scientific study to know that if the features
Isn't megalomania grand?
> > > But the language design is considerably simpler.
> >
> > Even this is not fact.
>
> Of course it's a fact..
> > As many have tried to indicate it is all about
> > trade offs. The trade offs are more or less fact, but the value
> > judgments placed on them (those are good, because I like them, while
> > those are bad, because I don't like them) are all about opinion and
> > subjective aesthetics. Note: that's not a bad thing. The dodgy bit
> > comes when people start trying to foist these value judgments off as
> > fact. For some reason, you have a propensity for this.
>
> It is MY OPINION (is that clear enough?)
Make up your mind - is it "fact" or your opinion?
/Jon
--
'j' - a n t h o n y at romeo/charley/november com
In article <··············@rigel.goldenthreadtech.com>,
jayessay <······@foo.com> wrote:
> Make up your mind - is it "fact" or your opinion?
That it would be simpler is a fact. That it would be better is my
opinion.
rg
On 2006-05-19, Ron Garret <·········@flownet.com> wrote:
>
> I don't need to conduct a scientific study to know that if the features
> of language X are a proper subset of language Y then language X is (most
> likely -- I'm sure some wise guy will come up with a counterexample)
> simpler than language Y. That's what "simpler" means.
It depends on what you mean by simpler. Would it be simpler because
there is less "stuff" in the language? Even if some part, possibly large,
of the languages user base needs the feature, in some form, enough to
implement it in various fragmented and incompatable ways?
Pure Ansi C is simple in this reguard, infact it is so simple as to be
fairly usless for solving real problems, everything is pushed off into
libiries that are not part of the standard. This same model applies to
scheme as well.
Again what do you mean by simple/simpler as you have stated in other
threads CL has problems because it lacks standard networking, database
access, etc. Are you stating above that these additions would be bad
because it is less simple or it is good because these additions would
be more simple, thing language implementer vs language user.
marc
In article <·····················@sdf.lonestar.org>,
marc spitzer <······@sdf.lonestar.org> wrote:
> On 2006-05-19, Ron Garret <·········@flownet.com> wrote:
> >
> > I don't need to conduct a scientific study to know that if the features
> > of language X are a proper subset of language Y then language X is (most
> > likely -- I'm sure some wise guy will come up with a counterexample)
> > simpler than language Y. That's what "simpler" means.
>
> It depends on what you mean by simpler. Would it be simpler because
> there is less "stuff" in the language? Even if some part, possibly large,
> of the languages user base needs the feature, in some form, enough to
> implement it in various fragmented and incompatable ways?
>
> Pure Ansi C is simple in this reguard, infact it is so simple as to be
> fairly usless for solving real problems, everything is pushed off into
> libiries that are not part of the standard. This same model applies to
> scheme as well.
>
> Again what do you mean by simple/simpler as you have stated in other
> threads CL has problems because it lacks standard networking, database
> access, etc. Are you stating above that these additions would be bad
> because it is less simple or it is good because these additions would
> be more simple, thing language implementer vs language user.
Neither. Simplicity is only one dimension in a complex quality metric.
The only hard and fast rule (and even this is ONLY MY OPINION) is that
ALL ELSE BEING EQUAL, simpler is better. If not for this disclaimer,
unlambda would be the best programming language.
The question when considering adding complexity is always: what does the
extra complexity buy you? And then it's a judgment call whether the
extra complexity is worth the tradeoff.
In the case of threading etc., in my opinion in today's world even a
complicated solution is better than none at all.
rg
marc spitzer wrote:
> On 2006-05-19, Ron Garret <·········@flownet.com> wrote:
> >
> > I don't need to conduct a scientific study to know that if the features
> > of language X are a proper subset of language Y then language X is (most
> > likely -- I'm sure some wise guy will come up with a counterexample)
> > simpler than language Y. That's what "simpler" means.
>
> It depends on what you mean by simpler. Would it be simpler because
> there is less "stuff" in the language?
Both Lisp-1 and Lisp-2 are hacks which complicate the language. They do
something very silly, which is to put bindings into the space of
operators.
The simplest thing would be to have only operators in the leftmost
position of the list: macro operators and special operators.
Everything else is under the control of these operators.
For instance, the concepts of expression evaluation, variable bindings
and function calls are defined by the operators like LET, and others.
There ought to be a CALL operator which denotes that a function is to
be called. The function would be pulled from the variable namespace.
Trouble is that this perfect, rationally pure dialect is awkward to
program in, because you have to use an operator for every function
call.
This is why we have the Lisp-1 and Lisp-2 hacks, so that you don't have
to write (CALL FUNCTION ARGS ...).
Both of these have to do a nasty thing: force something into the
operator namespace which doesn't belong there.
That is not simplification. That is conflation and confusion.
Merging things that don't belong together isn't always simplification.
Sometimes it merely increases entropy and causes chaos.
A better solution would be to define an alternate set of parentheses,
whose use would be optional, for denoting function calls:
[...] = (CALL ...)
Problem solved.
- Operators have a separate namespace from variables, so you can have a
special operator FOO and a variable FOO in the same scope.
- Function bindings are just regular variable bindings.
- In Lisp-2, the FUNCALL issue goes away because you don't indirect on
operators: there are no higher order special operators. The FUNCTION
operator goes away.
- Certain ugly singularities found in Lisp-1 go away. The question no
longer exists what the expression X means if X has a special operator
binding rather than a variable binding. Likewise, assignments to
special operators do not exist.
- The square brackets make it clear what is syntax and what is a
function call. People can no longer abuse macros to do function
inlining, because the round parentheses reveal the macro operator. So
certain complaints about Lisp readability go away too.
- Square or round, they are still parentheses, damn it.
- It makes perfect sense! Evaluation of function calls is a
domain-specific language. Why not treat it the same way as any other
DSL? You have some operators, and then a bit of read syntax to make it
more convenient to use.
What would you call this dialect? It's not Lisp-1, nor Lisp-2. I would
call it Lisp-O, where the O, the letter, stands for "operator", and is
a visual pun on zero also.
In article <·······················@j73g2000cwa.googlegroups.com>,
"Kaz Kylheku" <········@gmail.com> wrote:
[A nice description of Lisp-O]
Just to be fair to history, Kent Pitman (PBUH ;-) also pointed all this
out a long, long time ago.
rg
Ron Garret <·········@flownet.com> writes:
> Just to be fair to history, Kent Pitman (PBUH ;-) also pointed all this
> out a long, long time ago.
Thanks for pointing this out - I did not know this. But it figures ... :-)
/Jon
--
'j' - a n t h o n y at romeo/charley/november com
Kaz Kylheku <········@gmail.com> wrote:
+---------------
| A better solution would be to define an alternate set of parentheses,
| whose use would be optional, for denoting function calls:
| [...] = (CALL ...)
...
| What would you call this dialect?
+---------------
Tcl.
But be careful what you wish for, since in Tcl arithmetic functions
like +, -, *, / aren't "operators", either, so you have to use the
special operator EXPR on them.
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
Kaz Kylheku wrote:
>
> For instance, the concepts of expression evaluation, variable bindings
> and function calls are defined by the operators like LET, and others.
> There ought to be a CALL operator which denotes that a function is to
> be called. The function would be pulled from the variable namespace.
>
If I am remembering right, the BASIC I had to learn way back had
for assignment
let x = 10
for calling
call foo
So classic BASIC is Lisp-0 ;)
back to lurking
-Antony
"Kaz Kylheku" <········@gmail.com> writes:
<a "lisp-0" proposal to end the madness>
That's pretty nice. I could take that.
/Jon
--
'j' - a n t h o n y at romeo/charley/november com
From: Alexander Schmolck
Subject: Re: seperation of function namespace
Date:
Message-ID: <yfs4pzopany.fsf@oc.ex.ac.uk>
Ron Garret <·········@flownet.com> writes:
> In article <···············@oc.ex.ac.uk>,
> Alexander Schmolck <··········@gmail.com> wrote:
>
> > Ron Garret <·········@flownet.com> writes:
> >
> > > IMO any hack that generates confusion in newcomers with near 100%
> > > reliability and has a workable alternative is a horrible hack.
> >
> > Are you talking of logical-pathnames or the package system? <duck>
>
> Don't get me started.
>
> > > > (For that matter, Lisp-2
> > > > avoids certain name clashes everywhere, not just in macros.)
> > >
> > > Like what?
> >
> > Types vs values; block labels -- all sorts of things.
>
> I presume you mean something like:
>
> (let ((list ...))
> (block list ... (return-from list (coerce (foo list) 'list)) ...))
>
> It isn't really Lisp-2 avoiding name collision here, it is, as you say,
> Lisp-inf. The merits of having each of these name spaces built in to
> the language is a separate, orthogonal discussion which would lead us
> far afield. I'll just point out a couple of things:
>
> 1. In Python, types are (mostly) opaque first-class objects, and that
> seems to work reasonably well.
Yes, but name clashes still happen (cls, l or lst etc.) and idiotic naming
conventions still exist as a result of the lack of namespaces
(ClassesAreCapitalized, haphazardly, some of the time).
I'd also claim that one of the reasons it works reasonably well is that one
and the same object also doubles as method. Although this is a great and
all-too-uncommon design which also confers other benefits (most importantly no
pointless loss of abstraction due to a stupid syntactic distinction between
constructor and function call), one of the benefits is abating namespace
issues.
> 2. Nothing prevents a user from creating new namespaces using
> associative maps.
Something sure does -- custom (IIRC there was a discussion in the PLT list not
too long ago, when on being asked why something didn't get its own namespace,
despite benefits -- I think the answer at least partially boiled down to
strong single namespace tradition in scheme, but my memory is hazy), lack of
insight and involved inconvenience.
This is pretty potent. Look at all the things that python does much better
than CL but that can be rather trivially implemented in CL, e.g. a better
string literal syntax to pick something that hopefully doesn't evoke strong
feelings (I've hacked it up and I guess so have others, but I haven't seen it
widely used and it causes inconvenience, e.g. because non-standard readtables
are painful to use in CL).
> 4. Why stop where CL did? Why not e.g. a separate name space for every
> data type? Why shouldn't I be able to do:
>
> (list-let ((x '(1 2 3)))
> (vector-let ((x #(a b c)))
> (integer-let ((x 1))
> (cons (car x) (aref x x))) --> (1 . b)
Because the way the English language graphemically conflates verbs and nouns
and platonic with concrete objects does not provide a rationale for it.
>
> > Have a look at all the bizarre naming conventions in
> > PLT scheme and related publications).
>
> I'm not sure which bizarre naming conventions you're referring to, but a
> lot of Scheme's naming conventions are there to make the code easier to
> read, not to avoid name clashes.
Scheme isn't a real programming language[1], but yes its naming conventions
are far less screwed up than CLs.
I was talking of PLT scheme, which is a real programming language and as
result of the concomittant complexity-increase does suffer from strange
conventions brought about at least in part by a lack of separate namespaces.
For an egregious and slightly unfair example look at PLAI (which does have
other things going for it, though) -- or grep the PLT source for [^a-z-].+
identifiers.
IMO the comparatively sane naming conventions in CL are one of CL's few
distinguishing usability (as opposed to expressiveness) features and I see
them as partly associated with the lisp-inf-ness.
'as
Footnotes:
[1] Confining oneself to any of the scheme standards when programming (i.e.
writing practical software) is just nuts. Scheme is more (an academic
tool and toy that spawned) a family of languages.
In article <···············@oc.ex.ac.uk>,
Alexander Schmolck <··········@gmail.com> wrote:
> > > > > (For that matter, Lisp-2
> > > > > avoids certain name clashes everywhere, not just in macros.)
> > > >
> > > > Like what?
> > >
> > > Types vs values; block labels -- all sorts of things.
> >
> > I presume you mean something like:
> >
> > (let ((list ...))
> > (block list ... (return-from list (coerce (foo list) 'list)) ...))
> >
> > It isn't really Lisp-2 avoiding name collision here, it is, as you say,
> > Lisp-inf. The merits of having each of these name spaces built in to
> > the language is a separate, orthogonal discussion which would lead us
> > far afield. I'll just point out a couple of things:
> >
> > 1. In Python, types are (mostly) opaque first-class objects, and that
> > seems to work reasonably well.
>
> Yes, but name clashes still happen (cls, l or lst etc.) and idiotic naming
> conventions still exist as a result of the lack of namespaces
> (ClassesAreCapitalized, haphazardly, some of the time).
I would say that these naming conventions are by and large to make the
code easier to read, not to avoid name clashes. It is very rare that
there is a class named FooBaz and a potentially conflicting variable
named foobaz (and in most of those cases it's an indication of bad
design).
> > 2. Nothing prevents a user from creating new namespaces using
> > associative maps.
>
> Something sure does -- custom (IIRC there was a discussion in the PLT list not
> too long ago, when on being asked why something didn't get its own namespace,
> despite benefits -- I think the answer at least partially boiled down to
> strong single namespace tradition in scheme, but my memory is hazy), lack of
> insight and involved inconvenience.
Custom may exert influence, but by itself it can never PREVENT anyone
from doing anything (much to the consternation of reactionaries the
world over).
> > 4. Why stop where CL did? Why not e.g. a separate name space for every
> > data type? Why shouldn't I be able to do:
> >
> > (list-let ((x '(1 2 3)))
> > (vector-let ((x #(a b c)))
> > (integer-let ((x 1))
> > (cons (car x) (aref x x))) --> (1 . b)
>
> Because the way the English language graphemically conflates verbs and nouns
> and platonic with concrete objects does not provide a rationale for it.
Oh, so if my native language isn't English then separate name spaces for
different types might be good design?
> > > Have a look at all the bizarre naming conventions in
> > > PLT scheme and related publications).
> >
> > I'm not sure which bizarre naming conventions you're referring to, but a
> > lot of Scheme's naming conventions are there to make the code easier to
> > read, not to avoid name clashes.
>
> Scheme isn't a real programming language[1]
I'm going to insert your footnote here:
> [1] Confining oneself to any of the scheme standards when programming (i.e.
> writing practical software) is just nuts. Scheme is more (an academic
> tool and toy that spawned) a family of languages.
The ANSI standard is also quite constraining, as it has nothing to say
about networking, multithreading, graphics, foreign functions, database
connectivity. In fact, the number of things that both CL and Scheme
lack is much larger than the number of things that CL has that Scheme
lacks. So by your metric, CL is a little more "real" than Scheme, but
not much.
> I was talking of PLT scheme, which is a real programming language and as
> result of the concomittant complexity-increase does suffer from strange
> conventions brought about at least in part by a lack of separate namespaces.
Sorry, I still have no idea what you're talking about. I'm not familiar
with PLT scheme, but a quick browse of the PLT documentation reveals
nothing out of the ordinary.
> For an egregious and slightly unfair example look at PLAI (which does have
> other things going for it, though) -- or grep the PLT source for [^a-z-].+
> identifiers.
What does the PLT source have to do with anything? Just because there
may be cruft in an implementation that says nothing at all about the
LANGUAGE.
> IMO the comparatively sane naming conventions in CL are one of CL's few
> distinguishing usability (as opposed to expressiveness) features and I see
> them as partly associated with the lisp-inf-ness.
I'm still waiting for an actual example to support your view.
rg
Ron Garret <·········@flownet.com> writes:
> I would say that these naming conventions are by and large to make the
> code easier to read, not to avoid name clashes.
If such conventions are not about creating namespaces, they're
encoding type information. Let's take your own slippery-slope kind of
argument from elsewhere, giving:
(<special-form>define (<function>factorial <integer>n)
(<special-form>if (<function>= <integer>n 0)
1
(<function>* <integer>n
(<function>factorial (<function>- <integer>n 1)))))
Where can I sign up for this Lisp-1 thing?
--
Marcus Breiing
In article <············@chessie.cirr.com>,
Marcus Breiing <······@2006w20.mail.breiing.com> wrote:
> Ron Garret <·········@flownet.com> writes:
>
> > I would say that these naming conventions are by and large to make the
> > code easier to read, not to avoid name clashes.
>
> If such conventions are not about creating namespaces, they're
> encoding type information. Let's take your own slippery-slope kind of
> argument from elsewhere, giving:
>
> (<special-form>define (<function>factorial <integer>n)
> (<special-form>if (<function>= <integer>n 0)
> 1
> (<function>* <integer>n
> (<function>factorial (<function>- <integer>n
> 1)))))
But that's a very poor example because it uses only built-in and
lexically apparent bindings. Try instead:
(define (x y z q)
(a (q z) (y x)))
What does that code do? Hard to tell. But what if you wrote it:
(define (confrabulate confrab-function confrab-type confrab-constructor)
(confrabulate-some-more
(confrab-constructor confrab-type)
(confrab-function confrabulate)))
Those two code snippets are equivalent, but I think you will agree that
the second one makes it easier to tell what is going on. The difference
between that and your example is merely typography.
rg
Ron Garret <·········@flownet.com> writes:
> > If such conventions are not about creating namespaces, they're
> > encoding type information. Let's take your own slippery-slope kind of
> > argument from elsewhere, giving:
> >
> > (<special-form>define (<function>factorial <integer>n)
> > (<special-form>if (<function>= <integer>n 0)
> > 1
> > (<function>* <integer>n
> > (<function>factorial (<function>- <integer>n
> > 1)))))
>
> But that's a very poor example
Duh - it's a slippery slope's endpoint, what did you expect?
BTW, there was a posting (in one of the other threads you kicked off,
I think) suggesting you use [..]-syntax for FUNCALL. I second that.
(defun crazy (f g x)
[[(hof f) x] [g x]]) ;what's left to desire?
--
Marcus Breiing
From: Holger Schauer
Subject: Re: seperation of function namespace
Date:
Message-ID: <yxzk68igz84.fsf@gmx.de>
On 4642 September 1993, Ron Garret wrote:
> In article <···············@oc.ex.ac.uk>,
> Alexander Schmolck <··········@gmail.com> wrote:
>> Yes, but name clashes still happen (cls, l or lst etc.) and idiotic naming
>> conventions still exist as a result of the lack of namespaces
>> (ClassesAreCapitalized, haphazardly, some of the time).
> I would say that these naming conventions are by and large to make the
> code easier to read, not to avoid name clashes. It is very rare that
> there is a class named FooBaz and a potentially conflicting variable
> named foobaz (and in most of those cases it's an indication of bad
> design).
I don't buy that (indication of bad design) at all. If I have some
class foo and I need in some local surrounding exactly one instance of
it, why shouldn't I name the instance just foo? If one considers
modelling (and hence naming) classes in accordance with the domain
under consideration, and I have then to code some operation on some
specific but arbitrary object of the domain, it's just straight
forward to just use the object's distinguishing characteristics (its
class name) to refer to it, just like you say "I'm going to eat that
apple" and not "that instance of an apple" or "that grbmbz that
happens to be an apple".
>> > 4. Why stop where CL did? Why not e.g. a separate name space for every
>> > data type? Why shouldn't I be able to do:
I think that this is indeed imaginable but that nobody would probably
want to use such a language, just like there are people that don't use
CL because of it being a Lisp-2. Go figure. As a hint to why it might
be a good idea to stop where CL did, I think that the distinction
between variables and functions is much more at the core of the
language than the distinction between, e.g., lists and vectors and
that, guessing wildly but accordingly, clashes between functions and
variable names are more likely to be a problem than clashes between
variable names having values of differing types.
>> > (list-let ((x '(1 2 3)))
>> > (vector-let ((x #(a b c)))
>> > (integer-let ((x 1))
>> > (cons (car x) (aref x x))) --> (1 . b)
I.e., I think that the use of the variable name "x" shows poor naming
conventions regardless what datatype the value is.
I really also don't understand why that nameclash discussion is such a
big issue anyway. That I have functions and variables of the same name
doesn't occur in my code that often. On the other hand, I don't mind
the need for funcall or #' either. I also don't see a lot of newbies
stumbling over this so called problem, at least when I take c.l.l. as
a measure. So, perhaps you just should get over it and move on to
something more interesting?
>> [1] Confining oneself to any of the scheme standards when programming (i.e.
>> writing practical software) is just nuts. Scheme is more (an academic
>> tool and toy that spawned) a family of languages.
> The ANSI standard is also quite constraining, as it has nothing to say
> about networking, multithreading, graphics, foreign functions, database
> connectivity. In fact, the number of things that both CL and Scheme
> lack is much larger than the number of things that CL has that Scheme
> lacks. So by your metric, CL is a little more "real" than Scheme, but
> not much.
That's ridiculous. Why do people think that programming nowadays
always involves databases, connecting to foreign code, networking and
multithreads? Is somebody left here that doesn't do web programming?
Holger
--
--- http://www.coling.uni-freiburg.de/~schauer/ ---
"Yeah. Sorry. Was just sketching, and you're finding paste-o's."
"`Paste-o's'?? Is that what's left after the mice finish
eating the typos?" -- K.Pitman and R. Warnock in comp.lang.lisp
On 2006-05-19 05:06:51 -0400, Holger Schauer <··············@gmx.de> said:
> As a hint to why it might
> be a good idea to stop where CL did, I think that the distinction
> between variables and functions is much more at the core of the
> language than the distinction between, e.g., lists and vectors and
> that, guessing wildly but accordingly, clashes between functions and
> variable names are more likely to be a problem than clashes between
> variable names having values of differing types.
It's also worthwhile to consider the natural language bases of this
distinction - it maps nicely to the universal natural language
distinction between verbs (functions) and nouns (variables). In
addition english has a positional grammar - the meaning of sentences
depend on where in the sentence words are - that is, word *order*
determines meaning more than inflected ending - "man bites dog" /= "dog
bites man" - and native speakers will prefer word order to inflected
ending to disambiguate meaning - a child or non-native speaker's "John
like Nancy and Alice" will be heard as "John likes Nancy and Alice" not
"Nancy and Alice like John" even though this latter gets the verb
ending right.
So the primitive grammar of lisp is that of english imperative
sentences which take the form (verb noun-phrase*) in parallel to
english imperatives such as "Feed the sheep," "Eat your breakfast,"
"Add two and two" - which maps directly to the lisp (+ 2 2), etc. It
makes sense then that the meaning of the head of such an expression
(the verb/function) should be distinguished from the meaning of the
remainder (the noun-phrases/variables) and that they should therfore be
looked up in two namespaces.
The other universal element of natural language, prepositions, map
pretty nicely to keyword arguments so the imperative "Put the the block
on the green table" is paralled by (place block-1 :on green-table). Of
course lisp is flexible enough to allow other patterns as well (such as
the now somewhat archaic verb subject reversal to form a question -
"have you any wool?" -> (has-p black-sheep wool) or the scheme (has?
black-sheep wool) and of course macros allow us to add still others.
In article
<····································@pasdespamsilvousplaitmaccom>,
Raffael Cavallaro
<················@pas-d'espam-s'il-vous-plait-mac.com> wrote:
> On 2006-05-19 05:06:51 -0400, Holger Schauer <··············@gmx.de> said:
>
> > As a hint to why it might
> > be a good idea to stop where CL did, I think that the distinction
> > between variables and functions is much more at the core of the
> > language than the distinction between, e.g., lists and vectors and
> > that, guessing wildly but accordingly, clashes between functions and
> > variable names are more likely to be a problem than clashes between
> > variable names having values of differing types.
>
> It's also worthwhile to consider the natural language bases of this
> distinction - it maps nicely to the universal natural language
> distinction between verbs (functions) and nouns (variables). In
> addition english has a positional grammar - the meaning of sentences
> depend on where in the sentence words are - that is, word *order*
> determines meaning more than inflected ending - "man bites dog" /= "dog
> bites man" - and native speakers will prefer word order to inflected
> ending to disambiguate meaning - a child or non-native speaker's "John
> like Nancy and Alice" will be heard as "John likes Nancy and Alice" not
> "Nancy and Alice like John" even though this latter gets the verb
> ending right.
>
> So the primitive grammar of lisp is that of english imperative
> sentences which take the form (verb noun-phrase*) in parallel to
> english imperatives such as "Feed the sheep," "Eat your breakfast,"
> "Add two and two" - which maps directly to the lisp (+ 2 2), etc. It
> makes sense then that the meaning of the head of such an expression
> (the verb/function) should be distinguished from the meaning of the
> remainder (the noun-phrases/variables) and that they should therfore be
> looked up in two namespaces.
>
> The other universal element of natural language, prepositions, map
> pretty nicely to keyword arguments so the imperative "Put the the block
> on the green table" is paralled by (place block-1 :on green-table). Of
> course lisp is flexible enough to allow other patterns as well (such as
> the now somewhat archaic verb subject reversal to form a question -
> "have you any wool?" -> (has-p black-sheep wool) or the scheme (has?
> black-sheep wool) and of course macros allow us to add still others.
This is a very good point, but you left out some important cases:
The sine of X.
The sine of the cosine of X.
Now the supposedly privileged first position contains neither a verb nor
a preposition but a noun.
The derivative of the cosine.
The composition of CAR and CDR.
And now you have nothing but nouns everywhere.
(And to really throw a money-wrench into the works, consider "The nth
derivative of F." Now there's an adjective up front!)
Since one of Lisp's supposed benefits is the fact that it supports
functional and higher-order programming, these cases are important. One
of the first things every Lisp student learns is MAPCAR, which is
confusing AND USEFUL precisely because it breaks the usual verb-in-front
pattern that leads to FORTRAN. So it is far from a slam-dunk that
basing a programming language's semantics on that particular pattern is
a good thing.
rg
On 2006-05-19 13:39:51 -0400, Ron Garret <·········@flownet.com> said:
> So it is far from a slam-dunk that basing a programming language's
> semantics on that particular pattern is a good thing.
No, it's just one option, but one that comes naturally to english
speakers. I wasn't defending lisp-2 as the one true lisp - just
pointing out why it is one local maximum - because it takes advantage
of a basic natural language distinction between verb and subject. The
big plus of lisp as I see it is that it allows the programmer to create
other patterns where these are useful by writing macros. This way we're
not stuck with what the language designers envisioned as our only means
of expression.
BTW, "the sin of x" is not a sentence - "Take the sin of x" is, so (sin
x) corresponds to the imperative sentence "Take the sin of x."
Functional composition corresponds to "Take the deriviative of taking
the cosine of x," etc. Again, this is just the base pattern, but one
that covers a lot of ground. Where it becomes awkward, we can always
write macros.
In article
<····································@pasdespamsilvousplaitmaccom>,
Raffael Cavallaro
<················@pas-d'espam-s'il-vous-plait-mac.com> wrote:
> BTW, "the sin of x" is not a sentence
That's right, and it's one of the reasons people have a hard time
wrapping their brains around functional programming. But (I am told --
I have not actually done it myself) once you do, there are significant
benefits to be had by freeing yourself from the tyranny of verbs.
rg
On 2006-05-19 19:37:27 -0400, Ron Garret <·········@flownet.com> said:
> That's right, and it's one of the reasons people have a hard time
> wrapping their brains around functional programming.
Let me try again: "the sin of x" is a sentence fragment because there
is an implied verb ("take" or "compute" or "find" or "look up" etc.).
The sin of x doesn't magically appear - some action is necessary and
that action is the verb/function. If anything it is more apt to compare
functional programming to a language with all verbs and no nouns:
"Take the function f of taking the function g of taking the function q
of taking the function ..." Nouns are state. Verbs are functions. Side
effects are actions upon nouns that change them (mutation of state).
Functional programming is programming with actions (functions/verbs)
only - with each action acting on the result of another previous
action. The only nouns here are the program's initial input and final
output. Everything in between that is verbs (function applications).
This is what people find confusing about functional progrmming -
natural language predisposes us to conceptualize a program as a set of
intermediate results or state (nouns) which are mutated by functions
(verbs). But functional programming means not thinking of a program as
a series of mutations of state (nouns which change because of the
actions of various verbs) but as a chain of function applications
(chains of verbs) acting of a single input and producing a single
output. This is not something one sees much in natural language: "x is
the result of applying f to applying g to applying r to applying q to
y" Most people would rather say: "Apply q to y yielding y1; apply r to
y1 yielding y2; apply g to y2 yielding y3; apply f to y3 yielding x."
Note the functional composition approach leaves out 3 nouns (that is,
it leaves out 3 intermediate mutations of state).
The reason most people find the latter easier to understand is not
merely one natural language's grammar - it seems that the
conceptualization of the world as
states/nouns/phenomena-of-long-temporal-duation on the one hand and
mutators/verbs/phenomena-of-short-temporal-duration on the other hand
is present in all natural languages. So a programming paradigm which
leaves out all the intermediate state mutations runs counter to the
metaphysics built into natural language. This is not to say that this
is necessarily a bad thing, but only that it it runs counter to our
natural language intuition about how the world works.
Now I await some clever functional programmer's natural language part
of speech analogy for monads ;^) Good luck to you whoever you are.
In any event, the bigger picture is that for people who like to think
that way the separation of the function and variable namespaces is a
good thing and so they like common lisp (or lisp-2 more generally).
For people who don't like to think this way there's always scheme - I
have to say I've never understood the crazy infighting between lispers
and schemers - both approaches have strengths and weaknesses. Having
both approaches means more options which is not something I usually
complain about. And again, macros mean you can add new syntactic forms
when you need them.
Holger Schauer wrote:
>Ron Garret wrote:
>> The ANSI standard is also quite constraining, as it has nothing to say
>> about networking, multithreading, graphics, foreign functions, database
>> connectivity. ...
>
>That's ridiculous. Why do people think that programming nowadays
>always involves databases, connecting to foreign code, networking and
>multithreads? Is somebody left here that doesn't do web programming?
Me, here, looking at LISP over the border, while firmly entrenched in
the embedded / real-time / process-control / machine-control /
javaless / phpless / dbless arenas. :(
PS: I confess I indulge in some networking and multithreading when
nobody is looking.
Roberto Waltman
[Please reply to the group,
return address is invalid ]
Holger Schauer <··············@gmx.de> writes:
> On 4642 September 1993, Ron Garret wrote:
> > The ANSI standard is also quite constraining, as it has nothing to say
> > about networking, multithreading, graphics, foreign functions, database
> > connectivity. In fact, the number of things that both CL and Scheme
> > lack is much larger than the number of things that CL has that Scheme
> > lacks. So by your metric, CL is a little more "real" than Scheme, but
> > not much.
>
> That's ridiculous. Why do people think that programming nowadays
> always involves databases, connecting to foreign code, networking and
> multithreads? Is somebody left here that doesn't do web programming?
It is indeed a ridiculous comment, but mainly because "has nothing to
say" is the antithesis of "constraining". In these matters the ANSI
spec. is completely _un_constraining (and that is precisely why some
people moan about such lack).
/Jon
--
'j' - a n t h o n y at romeo/charley/november com
In article <··············@rigel.goldenthreadtech.com>,
jayessay <······@foo.com> wrote:
> Holger Schauer <··············@gmx.de> writes:
>
> > On 4642 September 1993, Ron Garret wrote:
> > > The ANSI standard is also quite constraining, as it has nothing to say
> > > about networking, multithreading, graphics, foreign functions, database
> > > connectivity. In fact, the number of things that both CL and Scheme
> > > lack is much larger than the number of things that CL has that Scheme
> > > lacks. So by your metric, CL is a little more "real" than Scheme, but
> > > not much.
> >
> > That's ridiculous. Why do people think that programming nowadays
> > always involves databases, connecting to foreign code, networking and
> > multithreads? Is somebody left here that doesn't do web programming?
>
> It is indeed a ridiculous comment, but mainly because "has nothing to
> say" is the antithesis of "constraining". In these matters the ANSI
> spec. is completely _un_constraining (and that is precisely why some
> people moan about such lack).
You have to take these comments in context. The context in this case
was someone (I can't recall who and I don't have time to look it up)
saying that Scheme wasn't real because the standard didn't specify
enough useful stuff to write "real" code.
rg
Ron Garret <·········@flownet.com> writes:
> In article <··············@rigel.goldenthreadtech.com>,
> jayessay <······@foo.com> wrote:
>
> > Holger Schauer <··············@gmx.de> writes:
> >
> > > On 4642 September 1993, Ron Garret wrote:
> > > > The ANSI standard is also quite constraining, as it has nothing to say
> > > > about networking, multithreading, graphics, foreign functions, database
> > > > connectivity. In fact, the number of things that both CL and Scheme
> > > > lack is much larger than the number of things that CL has that Scheme
> > > > lacks. So by your metric, CL is a little more "real" than Scheme, but
> > > > not much.
> > >
> > > That's ridiculous. Why do people think that programming nowadays
> > > always involves databases, connecting to foreign code, networking and
> > > multithreads? Is somebody left here that doesn't do web programming?
> >
> > It is indeed a ridiculous comment, but mainly because "has nothing to
> > say" is the antithesis of "constraining". In these matters the ANSI
> > spec. is completely _un_constraining (and that is precisely why some
> > people moan about such lack).
>
> You have to take these comments in context. The context in this case
> was someone (I can't recall who and I don't have time to look it up)
> saying that Scheme wasn't real because the standard didn't specify
> enough useful stuff to write "real" code.
That still has nothing to do with "constraining" and doesn't change
the absurdity of the comment. It's absurd even in the context you
mention.
The "less is less" and "more isn't even enough" issue is about some
"worry" concerning _portability_. Most (if not all) the
implementations in question (CL and Scheme) have all this stuff
available - you just have to pick one. But for some reason, picking
one here is somehow vastly inferior to picking, say, Python (with its
more or less complete non portability in this respect).
/Jon
--
'j' - a n t h o n y at romeo/charley/november com
In article <··············@rigel.goldenthreadtech.com>,
jayessay <······@foo.com> wrote:
> Ron Garret <·········@flownet.com> writes:
>
> > In article <··············@rigel.goldenthreadtech.com>,
> > jayessay <······@foo.com> wrote:
> >
> > > Holger Schauer <··············@gmx.de> writes:
> > >
> > > > On 4642 September 1993, Ron Garret wrote:
> > > > > The ANSI standard is also quite constraining, as it has nothing to
> > > > > say
> > > > > about networking, multithreading, graphics, foreign functions,
> > > > > database
> > > > > connectivity. In fact, the number of things that both CL and Scheme
> > > > > lack is much larger than the number of things that CL has that Scheme
> > > > > lacks. So by your metric, CL is a little more "real" than Scheme,
> > > > > but
> > > > > not much.
> > > >
> > > > That's ridiculous. Why do people think that programming nowadays
> > > > always involves databases, connecting to foreign code, networking and
> > > > multithreads? Is somebody left here that doesn't do web programming?
> > >
> > > It is indeed a ridiculous comment, but mainly because "has nothing to
> > > say" is the antithesis of "constraining". In these matters the ANSI
> > > spec. is completely _un_constraining (and that is precisely why some
> > > people moan about such lack).
> >
> > You have to take these comments in context. The context in this case
> > was someone (I can't recall who and I don't have time to look it up)
> > saying that Scheme wasn't real because the standard didn't specify
> > enough useful stuff to write "real" code.
>
> That still has nothing to do with "constraining" and doesn't change
> the absurdity of the comment. It's absurd even in the context you
> mention.
Did you even bother to look at the context? Here is the relevant
portion:
> [1] Confining oneself to any of the scheme standards when programming (i.e.
> writing practical software) is just nuts. Scheme is more (an academic
> tool and toy that spawned) a family of languages.
So you see, I am not the one who said the standard was constraining (or
"confining" as the OP put it), it was the person I was responding to. I
was merely accepting their premise to show it was wrong by reductio. I
was actually arguing your position.
Now a warning: this is the last time I will do your homework for you.
Next time I will allow you to wallow in your foolishness.
rg
Ron Garret <·········@flownet.com> writes:
> In article <··············@rigel.goldenthreadtech.com>,
> jayessay <······@foo.com> wrote:
>
> > Ron Garret <·········@flownet.com> writes:
> >
> > > In article <··············@rigel.goldenthreadtech.com>,
> > > jayessay <······@foo.com> wrote:
> > >
> > > > Holger Schauer <··············@gmx.de> writes:
> > > >
> > > > > On 4642 September 1993, Ron Garret wrote:
> > > > > > The ANSI standard is also quite constraining, as it has nothing to
> > > > > > say
> > > > > > about networking, multithreading, graphics, foreign functions,
> > > > > > database
> > > > > > connectivity. In fact, the number of things that both CL and Scheme
> > > > > > lack is much larger than the number of things that CL has that Scheme
> > > > > > lacks. So by your metric, CL is a little more "real" than Scheme,
> > > > > > but
> > > > > > not much.
> > > > >
> > > > > That's ridiculous. Why do people think that programming nowadays
> > > > > always involves databases, connecting to foreign code, networking and
> > > > > multithreads? Is somebody left here that doesn't do web programming?
> > > >
> > > > It is indeed a ridiculous comment, but mainly because "has nothing to
> > > > say" is the antithesis of "constraining". In these matters the ANSI
> > > > spec. is completely _un_constraining (and that is precisely why some
> > > > people moan about such lack).
> > >
> > > You have to take these comments in context. The context in this case
> > > was someone (I can't recall who and I don't have time to look it up)
> > > saying that Scheme wasn't real because the standard didn't specify
> > > enough useful stuff to write "real" code.
> >
> > That still has nothing to do with "constraining" and doesn't change
> > the absurdity of the comment. It's absurd even in the context you
> > mention.
>
> Did you even bother to look at the context? Here is the relevant
> portion:
Yes, and I don't see why you think that changes anything.
> Now a warning: this is the last time I will do your homework for
> you. Next time I will allow you to wallow in your foolishness.
Yeah, that sounds like you...
/Jon
--
'j' - a n t h o n y at romeo/charley/november com
From: Alexander Schmolck
Subject: Re: seperation of function namespace
Date:
Message-ID: <yfsbqtrmm9m.fsf@oc.ex.ac.uk>
Ron Garret <·········@flownet.com> writes:
> In article <···············@oc.ex.ac.uk>,
> Alexander Schmolck <··········@gmail.com> wrote:
>
> > > > > > (For that matter, Lisp-2
> > > > > > avoids certain name clashes everywhere, not just in macros.)
> > > > >
> > > > > Like what?
> > > >
> > > > Types vs values; block labels -- all sorts of things.
> > >
> > > I presume you mean something like:
> > >
> > > (let ((list ...))
> > > (block list ... (return-from list (coerce (foo list) 'list)) ...))
> > >
> > > It isn't really Lisp-2 avoiding name collision here, it is, as you say,
> > > Lisp-inf. The merits of having each of these name spaces built in to
> > > the language is a separate, orthogonal discussion which would lead us
> > > far afield. I'll just point out a couple of things:
> > >
> > > 1. In Python, types are (mostly) opaque first-class objects, and that
> > > seems to work reasonably well.
> >
> > Yes, but name clashes still happen (cls, l or lst etc.) and idiotic naming
> > conventions still exist as a result of the lack of namespaces
> > (ClassesAreCapitalized, haphazardly, some of the time).
>
> I would say that these naming conventions are by and large to make the
> code easier to read, not to avoid name clashes. It is very rare that
> there is a class named FooBaz and a potentially conflicting variable
> named foobaz (and in most of those cases it's an indication of bad
> design).
It certainly happens to me at times. And the "bad design" is silly -- although
English is quite rich in synomys there are plenty of cases where one and the
same spelling names quite different but about equally useful concepts in
different namespaces that are awkward to express differently in order to
prevent nameclashes (e.g. record). One reason that it's a dumb idea to make
'end' a reserved keyword is that it's something you'd almost certainly like to
call a parameter and there's a darth of viable synonyms. Even if it doesn't
happen often it sucks when it happens, and is ugly to work around, especially
when several languages (or automatic mappings from identifiers to english
words for UIs) are involved.
> Custom may exert influence, but by itself it can never PREVENT anyone
> from doing anything (much to the consternation of reactionaries the
> world over).
I'm not interested in metaphysical arguments, I'm interested in predicting
whether something will happen or not and for all practical purposes custom is
the supreme preventer, often far more effective than legal sanctions or other
coercive measures.
> > > 4. Why stop where CL did? Why not e.g. a separate name space for every
> > > data type? Why shouldn't I be able to do:
> > >
> > > (list-let ((x '(1 2 3)))
> > > (vector-let ((x #(a b c)))
> > > (integer-let ((x 1))
> > > (cons (car x) (aref x x))) --> (1 . b)
> >
> > Because the way the English language graphemically conflates verbs and nouns
> > and platonic with concrete objects does not provide a rationale for it.
>
> Oh, so if my native language isn't English then separate name spaces for
> different types might be good design?
No. Read it again (or did you forget a "not"?).
1. Obviously *your* native language is utterly irrelevant. The natural
language the programming language is based on is what matters.
2. What *is not* rationalized is the seperate namespace for every datatype,
what *is* rationalized is the seperate namespace for "verbs" and "nouns"
viz. functions and values.
Your tone suggests surprise that an arbitrary natural language should have
anything to do with programming language design decisions, but did you ever
consider the possibility that the messy type of syntax that's currently most
popular (and most elegantly embodied by python), viz. a jumble of prefix
functions, infix methods and operators and largely prefix control constructs
is likely an artifact of US, and hence English predominance in the programming
world?
English is SVO ("I eat cake"), whereas most languages are SOV (I cake eat).
I'd bet that if programming had historically been dominated by say the
Japanese, a (likely more regular and nicer) Smalltalk-like syntax would be
standard. I certainly doubt very much that C++/python style syntax would be
the most popular choice.
> > > > Have a look at all the bizarre naming conventions in
> > > > PLT scheme and related publications).
> > >
> > > I'm not sure which bizarre naming conventions you're referring to, but a
> > > lot of Scheme's naming conventions are there to make the code easier to
> > > read, not to avoid name clashes.
> >
> > Scheme isn't a real programming language[1]
>
> I'm going to insert your footnote here:
>
> > [1] Confining oneself to any of the scheme standards when programming (i.e.
> > writing practical software) is just nuts. Scheme is more (an academic
> > tool and toy that spawned) a family of languages.
>
> The ANSI standard is also quite constraining, as it has nothing to say
> about networking, multithreading, graphics, foreign functions, database
> connectivity.
True.
> In fact, the number of things that both CL and Scheme lack is much larger
> than the number of things that CL has that Scheme lacks. So by your metric,
> CL is a little more "real" than Scheme, but not much.
Nonsense. People do write non-trivial applications and libraries that work on
multiple CL implementations, whereas writing cross-implementation scheme code
is so painful that the only real program that I've ever seen to do it also
threw in common lisp compatibility (!). Scheme doesn't even supply
error-handling or a way to organize code into units and any number of other
things that occur pervasively in any kind of real code and are not trivially
relegated to some relatively small compatibility layer.
That's not to say the situation in CL is satisfactory and indeed some scheme
dialects are far more complete than individual CL implementations. You might
want to have a closer look at PLT scheme, for example, maybe it'd make you
happier than CL (this is not meant as one of these "bug someone else"
suggestions -- PLT scheme certainly seems a better match to a number of your
requirements than CL. Also be sure to check out swindle).
> > I was talking of PLT scheme, which is a real programming language and as
> > result of the concomittant complexity-increase does suffer from strange
> > conventions brought about at least in part by a lack of separate namespaces.
>
> Sorry, I still have no idea what you're talking about. I'm not familiar
> with PLT scheme, but a quick browse of the PLT documentation reveals
> nothing out of the ordinary.
From the class docs:
(define stack<%> (interface () push! pop! none?))
(define stack%
(class* object% (stack<%>)
; Declare public methods that can be overridden:
(public push! pop! none?)
; Declare a public method that can be augmented, only:
(pubment print-name)
(define stack null) ; A private field
Eli Barzilay's swindle (also part of PLT scheme) used a different
<dylan>-style convention, last time I looked. I happen to find the jumble of
<stack> stack<%> stack% and stack visually offensive.
> > For an egregious and slightly unfair example look at PLAI (which does have
> > other things going for it, though) -- or grep the PLT source for [^a-z-].+
> > identifiers.
>
> What does the PLT source have to do with anything?
PLAI is a book, not plt source. It employs a wild mixture of CamelCase,
camelCase, ALLCAPS, lowercaseonly and hypen-seperated words, plus hybrids
(I guess that might also be for "readability"'s sake, but certainly there
are names in it which are only distinguished by such typographic
presentation and one does thankfully not see much similar code in CL land).
> Just because there may be cruft in an implementation that says nothing at
> all about the LANGUAGE.
Sure it does, especially if the implementation is written by the guys who
hashed out the language. But also see above.
> > IMO the comparatively sane naming conventions in CL are one of CL's few
> > distinguishing usability (as opposed to expressiveness) features and I see
> > them as partly associated with the lisp-inf-ness.
>
> I'm still waiting for an actual example to support your view.
See above (I hope you won't deny that identifiers in CL code tend to have
comparatively good names?). It is of course difficult to pin-point the exact
causes, because there are different peculiarities relating to identifiers in
CL (apart from the 2 namespace there is the nutty readtable case behaviour, a
long cultural tradition, the large character set for identifiers that can be
used even without escaping and the ability to escape any character in an
identifier and the idiosyncratic syntax).
Another thing is that the lisp-inf approach has other repercussions -- CLers
don't mind dealing with names (and manage code units via a namespace
management) whereas schemers would abhor the idea of exporting names, rather
than values. I have no well-considered opinion on this.
'as
Alexander Schmolck <··········@gmail.com> writes:
> Types vs values; block labels -- all sorts of things. I think Lisp-2
> is a misnomer, it's more like Lisp-inf. I'm somewhat unconvinced
> that a single namespace is sane (a good reason to assume it isn't is
> proliferation of unpronouncable and/or visually offensive names in
> languages that (strive to) only have a single namespace -- and this
> gets progressively worse as you try to add new concepts into the
> language that would more or less naturally live in different
> namespaces. Have a look at all the bizarre naming conventions in PLT
> scheme and related publications).
How about the bizarre convention of using `*foo*' instead of `foo'?
Worse, how about the even more bizarre convention of using
`(find-class 'foo)' instead of `foo'? This second "convention" is one
that you often don't need as a CLer since there are contexts that
expect a class name -- so the whole argument boils down to whether you
want to use first-class-objects conveniently and uniformly, or whether
you want some name shortcuts -- being able to use the same name for
different uses, and resort to mumbling extra stuff like `#'' and
`(find-class' when you need the actual values that are named.
The camp that you choose largly depends on your programming style.
For example, if you like to use lots of higher-order-functions, then
you'll often step out of the frame that makes it easy to name
functions in the first place and you'll end up using a lot of `#''s.
If you don't mind using more loops and such, and not as much
higher-order solutions, then you'd probably prefer the
common-case-is-easier-to-use.
The plain-bindings are outliars -- if CL was uniform, then it'd have a
different form for special variables and such.
--
((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay:
http://www.barzilay.org/ Maze is Life!
From: Alexander Schmolck
Subject: Re: seperation of function namespace
Date:
Message-ID: <yfsac9gpmx5.fsf@oc.ex.ac.uk>
Eli Barzilay <···@barzilay.org> writes:
> Alexander Schmolck <··········@gmail.com> writes:
>
> > Types vs values; block labels -- all sorts of things. I think Lisp-2
> > is a misnomer, it's more like Lisp-inf. I'm somewhat unconvinced
> > that a single namespace is sane (a good reason to assume it isn't is
> > proliferation of unpronouncable and/or visually offensive names in
> > languages that (strive to) only have a single namespace -- and this
> > gets progressively worse as you try to add new concepts into the
> > language that would more or less naturally live in different
> > namespaces. Have a look at all the bizarre naming conventions in PLT
> > scheme and related publications).
>
> How about the bizarre convention of using `*foo*' instead of `foo'?
I'm not a fan of the way CL does special variables, as a recent ongoing thread
here will attest. It's not much of a problem, though, since the *s are in
effect not used to create an ad-hoc namespace, but to denote the semantics of
foo (so that the pronounciation FOO will in practice be unambiguous and only
slightly lossy).
> Worse, how about the even more bizarre convention of using
> `(find-class 'foo)' instead of `foo'?
What's bizzare about that? I have no difficulty reading or pronouncing it (or
divining its meaning if I'm not familiar with it; this matters because
libraries may also introudce namespaces) and it occurs about once every blue
moon in real code. By contrast how to you pronounce <list> vs. list vs lst (or
<class> vs class vs klass vs cls)? And what do you suspect causes more typing
overhead -- the frequent <>s etc. or more rare find-class (BTW I think CLASS
would be a nicer name for the name-space escape and analogous to FUNCTION).
> This second "convention" is one that you often don't need as a CLer since
> there are contexts that expect a class name -- so the whole argument boils
> down to whether you want to use first-class-objects conveniently and
> uniformly, or whether you want some name shortcuts -- being able to use the
> same name for different uses, and resort to mumbling extra stuff like `#''
> and `(find-class' when you need the actual values that are named.
>
> The camp that you choose largly depends on your programming style.
> For example, if you like to use lots of higher-order-functions, then
> you'll often step out of the frame that makes it easy to name
> functions in the first place and you'll end up using a lot of `#''s.
I suspect the problem is an artifact of misdesigned binding mechanisms[1],
because my guess would be that if you programm a lot with HOFs, than most of
the functions you juggle around as values will be passed as arguments[2] or be
closed over. so you could write scheme's
(define (f g h)
((f (frob g) h)))
as, say
(defun f (#'g #'h)
(funcall (f (frob g) h)))
by simply binding g and h in both namespaces (I'm not insisting that (function
g) is a good way to denote that).
I've written something like that, but I haven't used it enough so the opinions
in this post are mostly a hunch.
> If you don't mind using more loops and such, and not as much
> higher-order solutions, then you'd probably prefer the
> common-case-is-easier-to-use.
>
> The plain-bindings are outliars -- if CL was uniform, then it'd have a
> different form for special variables and such.
As I said -- I think the way CL does special variables is a (minor) wart.
'as
Footnotes:
[1] IMO binding is unreasonably sucky and non-orthogonal in scheme and lisp
anyway -- there is a prodigious amount of verbose and non-combineable
binding constructs that offer functionality that would in principle be
orthogonal (multiple vs single values; destructuring vs
non-destructuring; special vs lexical; serial vs parallel).
[2] The most obvious counter example might be mappings and reductions, but
I'd argue that they're crappily designed and lisps anyway, so they're
prevalence is an artifact (e.g. list comprehensions tend to win most of
the time, IMO).
Eli Barzilay wrote:
> The camp that you choose largly depends on your programming style.
> For example, if you like to use lots of higher-order-functions, then
> you'll often step out of the frame that makes it easy to name
> functions in the first place and you'll end up using a lot of `#''s.
> If you don't mind using more loops and such, and not as much
> higher-order solutions, then you'd probably prefer the
> common-case-is-easier-to-use.
Right.
> The plain-bindings are outliars -- if CL was uniform, then it'd have a
> different form for special variables and such.
ISLISP has a better design than Common Lisp in this regard. You have
'defdynamic and 'dynamic-let for introducing special variables, and
'dynamic for accessing them. (It's actually quite similar to parameter
objects in Scheme/SRFI 39.)
Pascal
--
3rd European Lisp Workshop
July 3-4 - Nantes, France - co-located with ECOOP 2006
http://lisp-ecoop06.bknr.net/
Ron Garret wrote:
> In article <···············@individual.net>,
> Pascal Costanza <··@p-cos.net> wrote:
>
>> Ron Garret wrote:
>>
>>> The reason Kaz is being so defensive is that there is no principled
>>> justification for Lisp-2. It's just a hack, and a pretty horrible one
>>> at that. There are only one benefit [1]: avoiding a certain class of
>>> unintended name capture in macros.
>> I don't want to comment on Kaz's posting. I agree that Lisp-2 is a hack,
>> like almost everything in both Lisp and Scheme ;), but the good thing
>> about hacks is that they tend to work. I strongly disagree that Lisp-2
>> is a horrible hack.
>
> IMO any hack that generates confusion in newcomers with near 100%
> reliability and has a workable alternative is a horrible hack.
The two approaches that have been in use for decades are Lisp-1 vs.
Lisp-2/Lisp-n. They seem to work pretty well, otherwise they would have
been abandoned. I am not aware of another alternative that is proven in
practice.
The aptness of a solution for newcomers is an important issue, but by
far not the only one.
>>> It turns out that this benefit can
>>> be had in various other ways, but this was not known at the time Common
>>> Lisp was designed.
>> Of course it was. IIUC, a hygienic macro system was indeed suggested for
>> inclusion in ANSI Common Lisp.
>
> News to me. Seems to be news to Google too. Do you have a reference?
See http://groups.google.com/group/comp.lang.lisp/msg/a38b5f4c2a677b7c
and http://groups.google.com/group/comp.lang.lisp/msg/c44a03c51f2944da
Pascal
--
3rd European Lisp Workshop
July 3-4 - Nantes, France - co-located with ECOOP 2006
http://lisp-ecoop06.bknr.net/
In article <···············@individual.net>,
Pascal Costanza <··@p-cos.net> wrote:
> Ron Garret wrote:
> > In article <···············@individual.net>,
> > Pascal Costanza <··@p-cos.net> wrote:
> >
> >> Ron Garret wrote:
> >>
> >>> The reason Kaz is being so defensive is that there is no principled
> >>> justification for Lisp-2. It's just a hack, and a pretty horrible one
> >>> at that. There are only one benefit [1]: avoiding a certain class of
> >>> unintended name capture in macros.
> >> I don't want to comment on Kaz's posting. I agree that Lisp-2 is a hack,
> >> like almost everything in both Lisp and Scheme ;), but the good thing
> >> about hacks is that they tend to work. I strongly disagree that Lisp-2
> >> is a horrible hack.
> >
> > IMO any hack that generates confusion in newcomers with near 100%
> > reliability and has a workable alternative is a horrible hack.
>
> The two approaches that have been in use for decades are Lisp-1 vs.
> Lisp-2/Lisp-n. They seem to work pretty well, otherwise they would have
> been abandoned. I am not aware of another alternative that is proven in
> practice.
>
> The aptness of a solution for newcomers is an important issue, but by
> far not the only one.
I never said otherwise.
> >>> It turns out that this benefit can
> >>> be had in various other ways, but this was not known at the time Common
> >>> Lisp was designed.
> >> Of course it was. IIUC, a hygienic macro system was indeed suggested for
> >> inclusion in ANSI Common Lisp.
> >
> > News to me. Seems to be news to Google too. Do you have a reference?
>
> See http://groups.google.com/group/comp.lang.lisp/msg/a38b5f4c2a677b7c
> and http://groups.google.com/group/comp.lang.lisp/msg/c44a03c51f2944da
Well, then I stand corrected. The alternatives were not unknown, they
were just "too new and ... inefficient."
rg
Pascal Costanza <··@p-cos.net> writes:
> The two approaches that have been in use for decades are Lisp-1
> vs. Lisp-2/Lisp-n. They seem to work pretty well, otherwise they would
> have been abandoned. I am not aware of another alternative that is
> proven in practice.
Off the top of my head, a lisp-0, where you'd have to qualify all references:
(defvar (dynamic-variable list) 1)
(let (((lexical-variable list) 2))
(flet ((lexical-function list) (&rest (parameter list))
...)
((global-function list)
(lexical-function list) (lexical-variable list)
(dynamic-variable list)
(global-function list))))
In CL, you'd have to write:
(defvar *list* 1)
(let ((list 2))
(flet ((%list% (&rest .list.)
...))
(list (function %list%) list
*list*
(function list))))
I'm happy that CL provides me with a solution for 98% of the cases,
and that I can cover the remaining 1.999% with simple conventions.
--
__Pascal Bourguignon__ http://www.informatimago.com/
Our enemies are innovative and resourceful, and so are we. They never
stop thinking about new ways to harm our country and our people, and
neither do we. -- Georges W. Bush
In article <··············@thalassa.informatimago.com>,
Pascal Bourguignon <···@informatimago.com> wrote:
> Pascal Costanza <··@p-cos.net> writes:
> > The two approaches that have been in use for decades are Lisp-1
> > vs. Lisp-2/Lisp-n. They seem to work pretty well, otherwise they would
> > have been abandoned. I am not aware of another alternative that is
> > proven in practice.
>
> Off the top of my head, a lisp-0, where you'd have to qualify all references:
>
> (defvar (dynamic-variable list) 1)
> (let (((lexical-variable list) 2))
> (flet ((lexical-function list) (&rest (parameter list))
> ...)
> ((global-function list)
> (lexical-function list) (lexical-variable list)
> (dynamic-variable list)
> (global-function list))))
>
> In CL, you'd have to write:
>
> (defvar *list* 1)
> (let ((list 2))
> (flet ((%list% (&rest .list.)
> ...))
> (list (function %list%) list
> *list*
> (function list))))
>
>
> I'm happy that CL provides me with a solution for 98% of the cases,
> and that I can cover the remaining 1.999% with simple conventions.
You need to brush up on your arithmetic. There are at most six cases:
{global, lexical, dynamic} x {variable, function}. If CL doesn't cover
100% of the cases, the next best thing it could possible be is 83%.
In fact CL's syntax covers only two of the six cases, so the actual
level of coverage is 2/6=33%.
But the value/function distinction is only there because there is no
context-independent access to the global environment. If there were you
would only need three cases: lexical, dynamic, and global, e.g.:
x == (lexical-value x)
$x == (dynamic-value x)
^x == (global-value x)
This provides completely equivalent power to CL with IMHO a much cleaner
conceptual framework.
rg
Ron Garret <·········@flownet.com> writes:
>> I'm happy that CL provides me with a solution for 98% of the cases,
>> and that I can cover the remaining 1.999% with simple conventions.
>
> You need to brush up on your arithmetic. There are at most six cases:
> {global, lexical, dynamic} x {variable, function}. If CL doesn't cover
> 100% of the cases, the next best thing it could possible be is 83%.
You need to brush up your own arithmetic. Have a look at Huffman coding!
--
__Pascal Bourguignon__ http://www.informatimago.com/
Grace personified,
I leap into the window.
I meant to do that.
Ron Garret <·········@flownet.com> writes:
> The reason Kaz is being so defensive...
Are you a mind reader? That would explain some things.
> justification for Lisp-2. It's just a hack, and a pretty horrible one
> at that.
Opinion. Which is fine, but parading it out as fact is dodgy.
/Jon
--
'j' - a n t h o n y at romeo/charley/november com
Ron Garret wrote:
> In article <························@j55g2000cwa.googlegroups.com>,
> "Kaz Kylheku" <········@gmail.com> wrote:
>
>
>>Burton Samograd wrote:
>>
>>>To me,
>>>I'm just finding more of an inconvenience with my starting out
>>>practical Lisp knowledge, but I'm sure I can be corrected with the
>>>proper evidence and persuasion.
>>
>>What value is there to someone, for instance me, in persuading you of
>>anything?
>>
>>Do you stand between me and something that I want?
>>
>>The information is there; make up your own mind.
>>
>>Newbies who require persuasion are typically just passive-aggressive
>>attention seekers, who come with an agenda other than the willingness
>>to learn: namely, they just want to engage their personality against
>>another one.
>>
>>If you're finding Common Lisp namespaces inconvenient, then maybe
>>you're just not wired for that type of language. Go program in
>>something in which variables, type names, goto labels, exception
>>handlers, and all other entities are entered into the same namespace.
>
>
> The reason Kaz is being so defensive is that there is no principled
> justification for Lisp-2. It's just a hack, and a pretty horrible one
> at that. There are only one benefit [1]: avoiding a certain class of
> unintended name capture in macros. It turns out that this benefit can
> be had in various other ways, but this was not known at the time Common
> Lisp was designed.
>
> rg
>
> [1] Actually there is a second benefit: making certain kinds of compiler
> optimizations easier to implement. But this is generally considered a
> minor benefit, and is not often cited as a rationale for Lisp-2.
Is the use of the #' reader needed in Lisp-2 seen as a benefit in regard
with code clarity? I rather like the philosophy of making user-defined
semantics use the same syntax as build-in ones.
What stands in the way of doing something like this implementation-wise:
(let ((func (lambda (obj) (print obj))))
(func 'foo))
Yves Vandriessche wrote:
> Is the use of the #' reader needed in Lisp-2 seen as a benefit in regard
> with code clarity? I rather like the philosophy of making user-defined
> semantics use the same syntax as build-in ones.
You seem to have a misconception (but of course one which is
understandable). To be clear, this use of the reader is not necessary
but rather syntactic sugar. After all:
#'function-name === (function function-name)
Simply execute (first '#'function-name) for a demonstration. Lisp is
consistent in this regard -- you can of course extend the reader
yourself to do such character-syntax tricks, which stop existing once
your sourcecode-text becomes parsed into objects.
An alternate universe might have used colors rather than character
syntax like #'.
As for code clarity, it must be seen in terms of tradeoffs -- whatever
we might say about economists, at least they have the notion of
"opportunity costs," which are about tradeoffs. If you choose the
Lisp-1 way, what do you give up?
(Note: Keep in mind that this usenet forum is notorious for
irrationality when certain hot-button topics are hit. "Lisp-1 vs.
Lisp-2" is one of them. Think of the Lisp world like Hogwarts.)
> What stands in the way of doing something like this implementation-wise:
>
> (let ((func (lambda (obj) (print obj))))
> (func 'foo))
Rename FUNC to LIST in your example, and I think you will find a
clearer demonstration.
(I've heard some think it's possible to reconcile the two approaches of
"Lisp-1 vs. Lisp-2", but I'm not holding my breath until there's
something other than vaporware.)
Tayssir
In article <·······················@38g2000cwa.googlegroups.com>,
"Tayssir John Gabbour" <···········@yahoo.com> wrote:
> (I've heard some think it's possible to reconcile the two approaches of
> "Lisp-1 vs. Lisp-2", but I'm not holding my breath until there's
> something other than vaporware.)
http://groups.google.com/group/comp.lang.lisp/msg/dde6dbd67771b757?dmode=
source&hl=en
http://www.flownet.com/gat/locales.pdf section 5
rg
Yves Vandriessche wrote:
> Ron Garret wrote:
> > In article <························@j55g2000cwa.googlegroups.com>,
> > "Kaz Kylheku" <········@gmail.com> wrote:
> >
> >
> >>Burton Samograd wrote:
> >>
> >>>To me,
> >>>I'm just finding more of an inconvenience with my starting out
> >>>practical Lisp knowledge, but I'm sure I can be corrected with the
> >>>proper evidence and persuasion.
> >>
> >>What value is there to someone, for instance me, in persuading you of
> >>anything?
> >>
> >>Do you stand between me and something that I want?
> >>
> >>The information is there; make up your own mind.
> >>
> >>Newbies who require persuasion are typically just passive-aggressive
> >>attention seekers, who come with an agenda other than the willingness
> >>to learn: namely, they just want to engage their personality against
> >>another one.
> >>
> >>If you're finding Common Lisp namespaces inconvenient, then maybe
> >>you're just not wired for that type of language. Go program in
> >>something in which variables, type names, goto labels, exception
> >>handlers, and all other entities are entered into the same namespace.
> >
> >
> > The reason Kaz is being so defensive is that there is no principled
> > justification for Lisp-2. It's just a hack, and a pretty horrible one
> > at that. There are only one benefit [1]: avoiding a certain class of
> > unintended name capture in macros. It turns out that this benefit can
> > be had in various other ways, but this was not known at the time Common
> > Lisp was designed.
> >
> > rg
> >
> > [1] Actually there is a second benefit: making certain kinds of compiler
> > optimizations easier to implement. But this is generally considered a
> > minor benefit, and is not often cited as a rationale for Lisp-2.
>
> Is the use of the #' reader needed in Lisp-2 seen as a benefit in regard
> with code clarity? I rather like the philosophy of making user-defined
> semantics use the same syntax as build-in ones.
>
> What stands in the way of doing something like this implementation-wise:
>
> (let ((func (lambda (obj) (print obj))))
> (func 'foo))
The problem in terms of implementation is dealing with redefinition.
Take a lisp system like CL where a function can be written into the
REPL and compiled at any time.
In this case the compiler must create a table mapping function names to
calls to memory locations. Then when a function is called it's
location is looked up. This can be done very fast. Similarly, for
variables, local variables can be stored on the stack, their names
discarded in the compiled code, helping with speed.
All this becomes much harder if a symbol that was a variable can be
bound to a function, or vice-versa. The compiler cannot know at
compile time if the value recieved from some function call is a
function or variable, everything must treat the general case.
Rob Thorpe wrote:
> Yves Vandriessche wrote:
>
>>Ron Garret wrote:
>>
>>>In article <························@j55g2000cwa.googlegroups.com>,
>>> "Kaz Kylheku" <········@gmail.com> wrote:
>>>
>>>
>>>
>>>>Burton Samograd wrote:
>>>>
>>>>
>>>>>To me,
>>>>>I'm just finding more of an inconvenience with my starting out
>>>>>practical Lisp knowledge, but I'm sure I can be corrected with the
>>>>>proper evidence and persuasion.
>>>>
>>>>What value is there to someone, for instance me, in persuading you of
>>>>anything?
>>>>
>>>>Do you stand between me and something that I want?
>>>>
>>>>The information is there; make up your own mind.
>>>>
>>>>Newbies who require persuasion are typically just passive-aggressive
>>>>attention seekers, who come with an agenda other than the willingness
>>>>to learn: namely, they just want to engage their personality against
>>>>another one.
>>>>
>>>>If you're finding Common Lisp namespaces inconvenient, then maybe
>>>>you're just not wired for that type of language. Go program in
>>>>something in which variables, type names, goto labels, exception
>>>>handlers, and all other entities are entered into the same namespace.
>>>
>>>
>>>The reason Kaz is being so defensive is that there is no principled
>>>justification for Lisp-2. It's just a hack, and a pretty horrible one
>>>at that. There are only one benefit [1]: avoiding a certain class of
>>>unintended name capture in macros. It turns out that this benefit can
>>>be had in various other ways, but this was not known at the time Common
>>>Lisp was designed.
>>>
>>>rg
>>>
>>>[1] Actually there is a second benefit: making certain kinds of compiler
>>>optimizations easier to implement. But this is generally considered a
>>>minor benefit, and is not often cited as a rationale for Lisp-2.
>>
>>Is the use of the #' reader needed in Lisp-2 seen as a benefit in regard
>>with code clarity? I rather like the philosophy of making user-defined
>>semantics use the same syntax as build-in ones.
>>
>>What stands in the way of doing something like this implementation-wise:
>>
>>(let ((func (lambda (obj) (print obj))))
>> (func 'foo))
>
>
> The problem in terms of implementation is dealing with redefinition.
> Take a lisp system like CL where a function can be written into the
> REPL and compiled at any time.
>
> In this case the compiler must create a table mapping function names to
> calls to memory locations. Then when a function is called it's
> location is looked up. This can be done very fast. Similarly, for
> variables, local variables can be stored on the stack, their names
> discarded in the compiled code, helping with speed.
>
> All this becomes much harder if a symbol that was a variable can be
> bound to a function, or vice-versa. The compiler cannot know at
> compile time if the value recieved from some function call is a
> function or variable, everything must treat the general case.
>
Thanks, this was what I was looking for. It does reinforce the notion
that 'Lisp-2 is a hack' to have a more performant system versus 'Lisp-1
is more elegant' but paying in performance.
Yves Vandriessche wrote:
>> The problem in terms of implementation is dealing with redefinition.
>> Take a lisp system like CL where a function can be written into the
>> REPL and compiled at any time.
>>
>> In this case the compiler must create a table mapping function names to
>> calls to memory locations. Then when a function is called it's
>> location is looked up. This can be done very fast. Similarly, for
>> variables, local variables can be stored on the stack, their names
>> discarded in the compiled code, helping with speed.
>>
>> All this becomes much harder if a symbol that was a variable can be
>> bound to a function, or vice-versa. The compiler cannot know at
>> compile time if the value recieved from some function call is a
>> function or variable, everything must treat the general case.
>
> Thanks, this was what I was looking for. It does reinforce the notion
> that 'Lisp-2 is a hack' to have a more performant system versus 'Lisp-1
> is more elegant' but paying in performance.
A Lisp-1 does not necessarily perform less well than a Lisp-2. It's
actually rather straightforward for a compiler to detect whether local
bindings are changed or not. Consider the following form in Scheme:
(let ((f (lambda (x) (+ x x))))
(f 5))
It's clear that the value of f isn't changed in the body of the let
form, so a Scheme compiler can do all kinds of optimizations here. It
probably happens quite rarely that such bindings are changed.
Pascal
--
3rd European Lisp Workshop
July 3-4 - Nantes, France - co-located with ECOOP 2006
http://lisp-ecoop06.bknr.net/
From: Marcin 'Qrczak' Kowalczyk
Subject: Re: seperation of function namespace
Date:
Message-ID: <87bqtwqzjp.fsf@qrnik.zagroda>
Yves Vandriessche <·················@uhasselt.be> writes:
> Thanks, this was what I was looking for. It does reinforce the
> notion that 'Lisp-2 is a hack' to have a more performant system
> versus 'Lisp-1 is more elegant' but paying in performance.
Huh? In Lisp-1 there is no need to check whether to get the function
or the variable, because there is only one place to look at.
The only difference is that checking whether an object is a function
can be done at the time of storing it in the function slot instead of
at the time of the call.
In any case, if the compiler can be sure which function will be called
(i.e. that there will be no redefinition), it enables much more
significant optimizations than being sure that it's some function
(e.g. no need to check the arity, possibility of inlining, inferring
properties about expected arguments and the result statically).
--
__("< Marcin Kowalczyk
\__/ ······@knm.org.pl
^^ http://qrnik.knm.org.pl/~qrczak/
Yves Vandriessche wrote:
> Is the use of the #' reader needed in Lisp-2 seen as a benefit in regard
> with code clarity? I rather like the philosophy of making user-defined
> semantics use the same syntax as build-in ones.
There is no gap between user-defined and built-in constructs.
#'something is just an abbreviation for (function something). #' is a
read macro, and you can define your own read macros to build similar, or
even more complex, abbreviations.
> What stands in the way of doing something like this implementation-wise:
>
> (let ((func (lambda (obj) (print obj))))
> (func 'foo))
Nothing. But it would be a different language.
There is also nothing in the way of saying this:
func("foo")
where func = lambda(obj) print(obj);
These are design issues, and there are different trade offs wrt
different design choices.
Pascal
--
3rd European Lisp Workshop
July 3-4 - Nantes, France - co-located with ECOOP 2006
http://lisp-ecoop06.bknr.net/
Pascal Costanza wrote:
> Yves Vandriessche wrote:
>
>> Is the use of the #' reader needed in Lisp-2 seen as a benefit in
>> regard with code clarity? I rather like the philosophy of making
>> user-defined semantics use the same syntax as build-in ones.
>
>
> There is no gap between user-defined and built-in constructs.
> #'something is just an abbreviation for (function something). #' is a
> read macro, and you can define your own read macros to build similar, or
> even more complex, abbreviations.
>
I'm aware of this fact, I rather meant if the explicit 'funcall of
function objects yielded any benefit.
What were the tradeoffs considered in doing (funcall #'func arg) versus
(func arg). If the first element of a function call expression is
expected to be a function, can't the symbol-function be queried first
instead of defaulting out on symbol-value. Are there runtime
considerations? What are the design considerations?
I'm looking for why they can't be reconciled I guess :P
What would hypothetically be wrong with:
> (setf (symbol-value 'foo) '())
> (setf (symbol-function 'foo) (lambda () 'bar))
> (foo)
bar
;versus
> (funcall (symbol-function 'foo))
bar
I hope my questions are a bit clearer this time :)
Yves Vandriessche wrote:
>
> I rather meant if the explicit 'funcall of
> function objects yielded any benefit.
> What were the tradeoffs considered in doing (funcall #'func arg) versus
> (func arg). If the first element of a function call expression is
> expected to be a function, can't the symbol-function be queried first
> instead of defaulting out on symbol-value. Are there runtime
> considerations? What are the design considerations?
>
> I'm looking for why they can't be reconciled I guess :P
> What would hypothetically be wrong with:
>
> > (setf (symbol-value 'foo) '())
> > (setf (symbol-function 'foo) (lambda () 'bar))
> > (foo)
> bar
This is actually not wrong, but this is how it works anyway.
> ;versus
> > (funcall (symbol-function 'foo))
> bar
Noone expects you to do this, and there is no real benefit here to do this.
'funcall exists so that you can call functions that are bound to
"ordinary" variables.
Consider
(flet ((f (x) (+ x x)))
(f 5))
vs.
(let ((f (lambda (x) (+ x x))))
(funcall f 5))
Assuming that f is not bound anywhere else, it would not be a good idea
if the following worked in Common Lisp.
(let ((f (lambda (x) (+ x x))))
(f 5))
The reason is that this would lead to ambiguities. Consider this:
(flet ((f (x) (+ x x)))
(let ((f (lambda (x) (* x x))))
(f 5)))
In Common Lisp, there is no ambiguity what this form means.
Pascal
--
3rd European Lisp Workshop
July 3-4 - Nantes, France - co-located with ECOOP 2006
http://lisp-ecoop06.bknr.net/
Would you care to elaborate what other ways could be used to avoid name
capture and still have the CL powerful macros?
This is not an ironic question, I'm sincerely interested in the issue.
Nicolay Giraldo wrote:
> Would you care to elaborate what other ways could be used to avoid name
> capture and still have the CL powerful macros?
>
> This is not an ironic question, I'm sincerely interested in the issue.
http://srfi.schemers.org/srfi-72/srfi-72.html
Will
In article <························@y43g2000cwc.googlegroups.com>,
"William D Clinger" <········@yahoo.com> wrote:
> Nicolay Giraldo wrote:
> > Would you care to elaborate what other ways could be used to avoid name
> > capture and still have the CL powerful macros?
> >
> > This is not an ironic question, I'm sincerely interested in the issue.
>
> http://srfi.schemers.org/srfi-72/srfi-72.html
>
> Will
http://groups.google.com/group/comp.lang.lisp/msg/dde6dbd67771b757
rg
Nicolay Giraldo wrote:
> Would you care to elaborate what other ways could be used to avoid name
> capture and still have the CL powerful macros?
There is a software engineering tool for this, called a package system.
Burton Samograd wrote:
> Hi,
>
> Are there any pointers as to discussion and/or benefits of seperating
> the function namespace in more modern lisps. I can understand a bit
> about why it was done, but I can't see the most obvious reason of
> naming functions the same as a varaible to be very convincing. To me,
> I'm just finding more of an inconvenience with my starting out
> practical Lisp knowledge, but I'm sure I can be corrected with the
> proper evidence and persuasion.
A standard reference wrt this topic is
http://www.nhplace.com/kent/Papers/Technical-Issues.html
Google for "Lisp-1" and "Lisp-2" in comp.lang.lisp, and you will find a
number of discussions on this topic as well.
Pascal
--
3rd European Lisp Workshop
July 3-4 - Nantes, France - co-located with ECOOP 2006
http://lisp-ecoop06.bknr.net/