seperation of function namespace
Burton Samograd
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
Pascal Costanza
> 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/
Kaz Kylheku
> 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.
Burton Samograd
> 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.
Ron Garret
"Kaz Kylheku" <kkyl...@gmail.com> 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. 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.
Pascal Costanza
> In article <1147824589.1...@j55g2000cwa.googlegroups.com>,
> "Kaz Kylheku" <kkyl...@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.
Tayssir John Gabbour
> 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
Yves Vandriessche
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))
Tayssir John Gabbour
> 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
Pascal Costanza
> 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 Costanza
> 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.
Tayssir John Gabbour
> 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
Pascal Costanza
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... ;)
Ron Garret
"Tayssir John Gabbour" <tayss...@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
Rob Thorpe
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.
Yves Vandriessche
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 :)
Ron Garret
Pascal Costanza <p...@p-cos.net> wrote:
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
Yves Vandriessche
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.
jayessay
> 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
Alexander Schmolck
> 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
Duncan Harvey
> > 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
Eli Barzilay
> 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!
Kaz Kylheku
> 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?
Pascal Costanza
> In article <4d08b9F...@individual.net>,
> Pascal Costanza <p...@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 Costanza
> 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.)
Alexander Schmolck
> Alexander Schmolck <a.sch...@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).
Burton Samograd
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.
Pascal Costanza
>
> 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 Bourguignon
> 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
Pascal Costanza
>> 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.
Ron Garret
Pascal Costanza <p...@p-cos.net> wrote:
> Ron Garret wrote:
> > In article <4d08b9F...@individual.net>,
> > Pascal Costanza <p...@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
Marcin 'Qrczak' Kowalczyk
> 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
\__/ qrc...@knm.org.pl
^^ http://qrnik.knm.org.pl/~qrczak/
Ron Garret
Pascal Bourguignon <p...@informatimago.com> wrote:
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
usenet-...@abbrvtd.org.uk (Duncan Harvey) wrote:
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
Alexander Schmolck <a.sch...@gmail.com> wrote:
> Ron Garret <rNOS...@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
Pascal Costanza
> In article <yfsejys...@oc.ex.ac.uk>,
> Alexander Schmolck <a.sch...@gmail.com> wrote:
>
>> Ron Garret <rNOS...@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.
Kaz Kylheku
> 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.
Bill Atkins
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"!
Ron Garret
Pascal Costanza <p...@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
Alexander Schmolck
> In article <yfsejys...@oc.ex.ac.uk>,
> Alexander Schmolck <a.sch...@gmail.com> wrote:
>
> > Ron Garret <rNOS...@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.
Kaz Kylheku
Ron Garret wrote:
> In article <1hfhss4.1iepvpf1b82wrmN%usenet-...@abbrvtd.org.uk>,
> usenet-...@abbrvtd.org.uk (Duncan Harvey) wrote:
>
> > Ron Garret <rNOS...@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.
Kaz Kylheku
> 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?
Ron Garret
"Kaz Kylheku" <kkyl...@gmail.com> wrote:
> Ron Garret wrote:
> > In article <1hfhss4.1iepvpf1b82wrmN%usenet-...@abbrvtd.org.uk>,
> > usenet-...@abbrvtd.org.uk (Duncan Harvey) wrote:
> >
> > > Ron Garret <rNOS...@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
Alexander Schmolck <a.sch...@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
Tayssir John Gabbour
> 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
Ron Garret
"Kaz Kylheku" <kkyl...@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
Kaz Kylheku
Ron Garret wrote:
> In article <1147905814.8...@g10g2000cwb.googlegroups.com>,
> "Kaz Kylheku" <kkyl...@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.
Kaz Kylheku
Ron Garret wrote:
> In article <1147904480....@g10g2000cwb.googlegroups.com>,
> "Kaz Kylheku" <kkyl...@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.
Ron Garret
"Kaz Kylheku" <kkyl...@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
"Kaz Kylheku" <kkyl...@gmail.com> wrote:
> Ron Garret wrote:
> > In article <1147904480....@g10g2000cwb.googlegroups.com>,
> > "Kaz Kylheku" <kkyl...@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
Rob Warnock
+---------------
| 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 <rp...@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
Burton Samograd
> 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
> 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...
Nicolay Giraldo
capture and still have the CL powerful macros?
This is not an ironic question, I'm sincerely interested in the issue.
William D Clinger
> 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
Nicolay Giraldo
Tayssir John Gabbour
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
Ron Garret
Marcus Breiing
> 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
Pascal Bourguignon
>> 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.
Duncan Harvey
> In article <1hfhss4.1iepvpf1b82wrmN%usenet-...@abbrvtd.org.uk>,
> usenet-...@abbrvtd.org.uk (Duncan Harvey) wrote:
>
> > Ron Garret <rNOS...@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
Kaz Kylheku
Ron Garret wrote:
> In article <1147911878.4...@j73g2000cwa.googlegroups.com>,
> "Kaz Kylheku" <kkyl...@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?
Kaz Kylheku
> 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.
Ron Garret
"Kaz Kylheku" <kkyl...@gmail.com> wrote:
> Ron Garret wrote:
> > In article <1147911878.4...@j73g2000cwa.googlegroups.com>,
> > "Kaz Kylheku" <kkyl...@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
Marcus Breiing <use...@2006w20.mail.breiing.com> wrote:
> Ron Garret <rNOS...@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
Thomas A. Russ
> In article <4d1egvF...@individual.net>,
> Pascal Costanza <p...@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
Thomas A. Russ
> In article <1147904480....@g10g2000cwb.googlegroups.com>,
> "Kaz Kylheku" <kkyl...@gmail.com> wrote:
>
> > Ron Garret wrote:
> > > In article <1hfhss4.1iepvpf1b82wrmN%usenet-...@abbrvtd.org.uk>,
> > > usenet-...@abbrvtd.org.uk (Duncan Harvey) wrote:
> > >
> > > > Ron Garret <rNOS...@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.
Ron Garret
t...@sevak.isi.edu (Thomas A. Russ) wrote:
> Ron Garret <rNOS...@flownet.com> writes:
>
> > In article <4d1egvF...@individual.net>,
> > Pascal Costanza <p...@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
Kaz Kylheku
> 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.
Peter Seibel
> In article <1147966637.8...@g10g2000cwb.googlegroups.com>,
> "Kaz Kylheku" <kkyl...@gmail.com> wrote:
>
>> Ron Garret wrote:
>> > In article <1147911878.4...@j73g2000cwa.googlegroups.com>,
>> > "Kaz Kylheku" <kkyl...@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 * pe...@gigamonkeys.com
Gigamonkeys Consulting * http://www.gigamonkeys.com/
Practical Common Lisp * http://www.gigamonkeys.com/book/
Ron Garret
"Kaz Kylheku" <kkyl...@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
Ron Garret
Peter Seibel <pe...@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
Peter Seibel
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.
Jack Unrue
>
> 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
Peter Seibel
> On Thu, 18 May 2006 12:09:43 -0700, Ron Garret <rNOS...@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.
Ron Garret
Peter Seibel <pe...@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
Jack Unrue <no....@example.tld> wrote:
> On Thu, 18 May 2006 12:09:43 -0700, Ron Garret <rNOS...@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
Peter Seibel
> In article <m2y7wzt...@gigamonkeys.com>,
> Peter Seibel <pe...@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.
Jack Unrue
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
Jack Unrue
>Jack Unrue <no....@example.tld> writes:
>
>> On Thu, 18 May 2006 12:09:43 -0700, Ron Garret <rNOS...@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
Marcus Breiing
> > 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
Ron Garret
Jack Unrue <no....@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?
> 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
Ron Garret
Peter Seibel <pe...@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
Jack Unrue
>In article <ffrp62d4o7e8t5tgd...@4ax.com>,
> Jack Unrue <no....@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
Peter Seibel
>> 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
Eli Gottlieb
> Ron Garret <rNOS...@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
>
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.
Rob Warnock
+---------------
| 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 <rp...@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
Pascal Costanza
> In article <m2odxvt...@gigamonkeys.com>,
> Peter Seibel <pe...@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/
Ron Garret
Pascal Costanza <p...@p-cos.net> wrote:
Fine. Substitute "possibility" for "solution."
rg
Holger Schauer
> In article <yfs4pzo...@oc.ex.ac.uk>,
> Alexander Schmolck <a.sch...@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
Raffael Cavallaro
> 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.
Roberto Waltman
>Ron Garret wrote:
>> The ANSI standard is also quite constraining, as it has nothing to say
>> about networking, multithreading, graphics, foreign functions, database
>
>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 ]
jayessay
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
Thomas A. Russ
> In article <1147966637.8...@g10g2000cwb.googlegroups.com>,
> "Kaz Kylheku" <kkyl...@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
Thomas A. Russ
> In article <ymiu07n...@sevak.isi.edu>,
> t...@sevak.isi.edu (Thomas A. Russ) wrote:
>
> > Ron Garret <rNOS...@flownet.com> writes:
> >
> > > In article <4d1egvF...@individual.net>,
> > > Pascal Costanza <p...@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?
Ron Garret
<2006051908481016807-raffaelcavallaro@pasdespamsilvousplaitmaccom>,
Raffael Cavallaro
<raffaelcavallaro@pas-d'espam-s'il-vous-plait-mac.com> wrote:
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
Ron Garret
jayessay <nos...@foo.com> wrote:
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
jayessay
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).
Ron Garret
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