I remember someone (Pascal Costanza?) once mentioned a code snippet
that was much easier to implement in lisp-2 than in a hypothetical
lisp-1 CL. I've been trying to search for it to no avail. Does
anyone know any examples to think about?
No flamewars please. I'm aware of the circumstances where lisp-1 is
more readable.
··········@yahoo.com (Tayss) writes:
> I remember someone (Pascal Costanza?) once mentioned a code snippet
> that was much easier to implement in lisp-2 than in a hypothetical
> lisp-1 CL. I've been trying to search for it to no avail. Does
> anyone know any examples to think about?
>
> No flamewars please. I'm aware of the circumstances where lisp-1 is
> more readable.
There are some examples in
http://www.nhplace.com/kent/Papers/Technical-Issues.html
In article <····························@posting.google.com>,
··········@yahoo.com (Tayss) wrote:
> I remember someone (Pascal Costanza?) once mentioned a code snippet
> that was much easier to implement in lisp-2 than in a hypothetical
> lisp-1 CL. I've been trying to search for it to no avail. Does
> anyone know any examples to think about?
>
> No flamewars please. I'm aware of the circumstances where lisp-1 is
> more readable.
I don't remember a specific example.
The standard argument in favor of Lisp-2 is that you can use the same
name both for a functions and a variable without any danger of
interference between the two. So you can say for example (let ((list
(...))) ...) but the function "list" is still available inside of that
let block.
The standard argument for a Lisp-1 is that you can express certain kinds
of programs in a clearer functional style - so that ((f ...) ...) makes
sense.
However, I have come to the conclusion that this is a red herring. There
are several ways to simulate Lisp-1 (or better, the kind of functional
programming style described above) within a Lisp-2. I have found just
one way to do that and posted it here, and maybe that is what you refer
to. (Other ways have been suggested by Erann and by Kent.) And probably
there is even a way to simulate Lisp-2 within a Lisp-1.
By now, I don't think that this is an important difference between
Scheme and Common Lisp. It largely depends on what kind of programs you
want to write.
Pascal
Pascal Costanza wrote:
> However, I have come to the conclusion that this is a red herring. There
> are several ways to simulate Lisp-1 (or better, the kind of functional
> programming style described above) within a Lisp-2. I have found just
> one way to do that and posted it here, and maybe that is what you refer
> to. (Other ways have been suggested by Erann and by Kent.) And probably
> there is even a way to simulate Lisp-2 within a Lisp-1.
>
> By now, I don't think that this is an important difference between
> Scheme and Common Lisp. It largely depends on what kind of programs you
> want to write.
Well put.
Here is an example of Lisp-2 in a Lisp-1 (DrScheme):
<http://makeashorterlink.com/?C15112E75>
Now that's what I call a pretty hack.
--
Jens Axel S�gaard
Pascal Costanza <········@web.de> wrote in message news:<······························@news.netcologne.de>...
> I don't remember a specific example.
>
> The standard argument in favor of Lisp-2 is that you can use the same
> name both for a functions and a variable without any danger of
> interference between the two. So you can say for example (let ((list
> (...))) ...) but the function "list" is still available inside of that
> let block.
I am aware of that wrinkle; I could have sworn there was an example
where lisp-2 syntax led to a pretty big simplification when
implementing something. Similar to... taking a really extreme
example, how Leibniz's notation for calculus made many things easier
than Newton's.
(Incidentally, in Code Complete, McConnell argues that identifiers
like "lst" are bad because they can be confused with the almost
identical looking "1st", both of which my Scheme env accepts as
identifiers.)
BTW, thanks to you and Kent for your responses. I already researched
Kent's paper with RPG, which I stupidly didn't make explicit. I went
to amsterdam today so I wasn't able to correct this earlier.
> By now, I don't think that this is an important difference between
> Scheme and Common Lisp. It largely depends on what kind of programs you
> want to write.
Well, I certainly agree there can be little sense in turning this into
Scheme vs. CL since they don't share the same goals.
My motivation is basically figuring out if it makes sense to somehow
convert my friends in doing CL projects with me, instead of python
projects. We do a lot of lisp-1ish functional stuff when it
simplifies notation, so that's basically why I want to think about a
good counterexample.
Obviously, I'm considering more important things too, but thinking
about syntax is worthwhile when debating pythonistas, and I could have
sworn I read a really good example. That's all really, I don't have
anything new about lisp-1 vs. lisp-2 so I don't want to bore everyone
with the same old big debate. Just an innocent question.
Thanks,
Tayss
Tayss wrote:
> Pascal Costanza <········@web.de> wrote in message
news:<······························@news.netcologne.de>...
> > I don't remember a specific example.
> >
> > The standard argument in favor of Lisp-2 is that you can use the same
> > name both for a functions and a variable without any danger of
> > interference between the two. So you can say for example (let ((list
> > (...))) ...) but the function "list" is still available inside of that
> > let block.
>
> I am aware of that wrinkle; I could have sworn there was an example
> where lisp-2 syntax led to a pretty big simplification when
> implementing something.
Let's assume such an example exists. Then we could take the simplified
Lisp-2 example, rename anything with conflicting names in the Lisp-1 sense,
remove funcalls and #' if necessary, and voila, we would have a Lisp-1
equivalent, compared to which the Lisp-2 example would not represent "a
pretty big simplification".
This is virtually a proof that such an example cannot exist, other than in
the sense raised by Kent Pitman, relating to one's preferences and
familiarity.
> Similar to... taking a really extreme example, how Leibniz's
> notation for calculus made many things easier than Newton's.
:)
> (Incidentally, in Code Complete, McConnell argues that identifiers
> like "lst" are bad because they can be confused with the almost
> identical looking "1st", both of which my Scheme env accepts as
> identifiers.)
'lst' is a terrible name - it's cryptic, but still, it's pronounced the same
as the word it's supposed to be distinguished from. It also doesn't tell
you anything about the contents of the list it represents, which is usually
more important than the fact that you're dealing with a list. We don't
often call variables by names like "number" or "integer", why exactly is it
different for lists?
One nice convention can be found in languages like Haskell and ML, where a
list is named as the plural of its elements, e.g. a list of individual value
s each referred to as 'x' is called 'xs'. This tends to fit naturally with
a recursive approach to processing lists. It can be even more useful if the
list elements have a short, descriptive name.
> That's all really, I don't have
> anything new about lisp-1 vs. lisp-2 so I don't want to bore everyone
> with the same old big debate. Just an innocent question.
Apparently, innocence is contextual. :)
Anton
On Wed, Aug 06, 2003 at 02:39:50AM +0000, Anton van Straaten wrote:
> Let's assume such an example exists. Then we could take the simplified
> Lisp-2 example, rename anything with conflicting names in the Lisp-1 sense,
> remove funcalls and #' if necessary, and voila, we would have a Lisp-1
> equivalent, compared to which the Lisp-2 example would not represent "a
> pretty big simplification".
How about a macro system?
> One nice convention can be found in languages like Haskell and ML, where a
> list is named as the plural of its elements, e.g. a list of individual value
> s each referred to as 'x' is called 'xs'. This tends to fit naturally with
> a recursive approach to processing lists. It can be even more useful if the
> list elements have a short, descriptive name.
One bad convention found in those languages is the tendency to use
single letter variable names in imitation of mathematicians. It only
helps make code obscure.
--
; Matthew Danish <·······@andrew.cmu.edu>
; OpenPGP public key: C24B6010 on keyring.debian.org
; Signed or encrypted mail welcome.
; "There is no dark side of the moon really; matter of fact, it's all dark."
In article <······················@newsread1.prod.itd.earthlink.net>,
"Anton van Straaten" <·····@appsolutions.com> wrote:
> > I am aware of that wrinkle; I could have sworn there was an example
> > where lisp-2 syntax led to a pretty big simplification when
> > implementing something.
>
> Let's assume such an example exists. Then we could take the simplified
> Lisp-2 example, rename anything with conflicting names in the Lisp-1 sense,
> remove funcalls and #' if necessary, and voila, we would have a Lisp-1
> equivalent, compared to which the Lisp-2 example would not represent "a
> pretty big simplification".
>
> This is virtually a proof that such an example cannot exist, other than in
> the sense raised by Kent Pitman, relating to one's preferences and
> familiarity.
I think you are oversimplifying things here. With a similar kind of
reasoning you could discuss away the expressive power of macros. "Just
macroexpand everything by hand, and voila, we would have an equivalent
program without macros, compared to which the one with macros would not
represent a simplification."
Pascal
Pascal Costanza wrote:
> "Anton van Straaten" <·····@appsolutions.com> wrote:
>
> > > I am aware of that wrinkle; I could have sworn there was an example
> > > where lisp-2 syntax led to a pretty big simplification when
> > > implementing something.
> >
> > Let's assume such an example exists. Then we could take the simplified
> > Lisp-2 example, rename anything with conflicting names in the Lisp-1
sense,
> > remove funcalls and #' if necessary, and voila, we would have a Lisp-1
> > equivalent, compared to which the Lisp-2 example would not represent "a
> > pretty big simplification".
> >
> > This is virtually a proof that such an example cannot exist, other than
in
> > the sense raised by Kent Pitman, relating to one's preferences and
> > familiarity.
>
> I think you are oversimplifying things here. With a similar kind of
> reasoning you could discuss away the expressive power of macros. "Just
> macroexpand everything by hand, and voila, we would have an equivalent
> program without macros, compared to which the one with macros would not
> represent a simplification."
There's a crucial difference: macros are capable of expanding into something
much bigger and more complex than the original, in fact, that is part of
their purpose; whereas code transformed from Lisp-2 to Lisp-1 can in all
cases be exactly the same size, if not smaller due to the removal of special
function-manipulation operators. To put it another way, there is no aspect
of the transformation which entails growth in the syntax tree of the program
being transormed.
It's not as though the transformation from Lisp-2 to Lisp-1 is a mysterious,
unclearly defined process. I'll detail the rewrite rules as I understand
them (corrections welcome):
1. Rename all conflicting variables, i.e. when a function and a variable
share a name that would conflict under Lisp-1, rename all occurrences of one
of those names.
2. Remove all occurrences of the character string "FUNCALL".
2. Remove all occurrences of the character string "FUNCTION".
3. Remove all occurrences of the character string "'#".
If I've missed some subtlety above, note that my goal is not to provide the
specification for an automatic rewriter, but rather to make it clear that no
syntax tree growth is involved in the conversion to Lisp-1.
Note that if desired, even greater isomorphism between the original and the
transformed code can be retained, by implementing macros for FUNCALL and #'
which would be no-ops, simply translating to their input expressions without
the FUNCALL or #'.
If my argument is wrong, all someone has to do is come up with a code
snippet of the sort that Tayss was looking for. Otherwise, we're talking
about a situation in which (a) a theory (described above) says that Lisp-2
cannot be "much simpler"; (b) a number of examples support the theory, found
e.g. in Gabriel & Pitman's in-depth analysis at
http://www.nhplace.com/kent/Papers/Technical-Issues.html ; (c) more examples
can easily be generated to test the theory; (d) a complete lack of
counter-examples to the theory; and (e), no theoretical basis has yet been
raised to contradict the theory.
So no, I don't think I'm oversimplifying - other than explicitly ignoring
the issue of individual preferences and familiarity.
Anton
"Anton van Straaten" <·····@appsolutions.com> writes:
> 1. Rename all conflicting variables, i.e. when a function and a variable
> share a name that would conflict under Lisp-1, rename all occurrences of one
> of those names.
In an interactive language, new names can arise later due to loading code
that did not cooperate with your renaming. An implication of this is that
you cannot reliably rename functions merely by examining a region of code
and assuming that you have complete world knowledge. An implication of this
is that you must reserve a set of names that are not for use by normal users
into which you will fold these extra names in order to make two namespaces
fit in one. This extra name component will (a) break code that does
introspection of function names, (b) disrupt existing code that does not
expect the renamed function names, and (c) call into question your claim
that the renaming would result in smaller code.
But other than that, yes, you're right.
> 2. Remove all occurrences of the character string "FUNCALL".
> 2. Remove all occurrences of the character string "FUNCTION".
2 too?
So "Too many args to FUNCALL." becomes "Too many args to ."" ??
You don't want to talk about character strings; step 1 talks about
variables. Variables in Common Lisp are _objects_, not _strings_.
They have already been through READ. There is no way to fetch the
string from which they arose, if indeed there was any (the object
might have been computed, not the direct result of textual parsing).
What about
(ecase (car form)
((funcall) ...)
...)
Does your answer change if I tell you the name of the function in which
this occurs is TRANSFORM-CONFORMING-ANSI-COMMON-LISP-CODE so that the
function being transformed is managing data that does not conform to
your technique?
I recall when reading the Portuguese translation of an Agatha Christie
novel that a young Spanish girl traveling on a train and chatting with
Hercules Poirot says to her [the sentence as I saw it was in Portuguese]
"I suppose you're wondering why my English is so good?"
The problem of reliable automatic translation of code is simply harder
than you make it out to be. That doesn't detract from your general point,
which is that there is a relatively simple relationship. However, it _does_
suggest you should steer clear of presenting the _process_ of code
transformation as trivial. It really is inherently not.
This is important in itself because _even if_ it were the case that people
bought your argument, it would (I claim) have been adequate reason for
the CL community not to have made a change to Lisp1 "merely" because of
the profoundly large cost of translating the body of existing code written
in the existing style.
> 3. Remove all occurrences of the character string "'#".
#'
Heh. "character string" again.
So "Bad character after '#'." becomes "Bad character after '." ?
I mention the example only because it's neutral as to whether you meant
to remove '# or #' and I was (probably overly) impressed with my own
cleverness in the choice of example.
> If I've missed some subtlety above, note that my goal is not to provide the
> specification for an automatic rewriter, but rather to make it clear that no
> syntax tree growth is involved in the conversion to Lisp-1.
Right. But remarks such as yours, unchallenged, make it seem to others
reading along that what you have suggested is a workable scheme for doing
the translation. Speaking as someone who has done translation of large
systems from one dialect to another, I can tell you from experience that
there are all manner of odd problems when you do this kind of thing, and
you should never without substantially more thought than you have done here
try to handwave away that complexity.
> Note that if desired, even greater isomorphism between the original and the
> transformed code can be retained, by implementing macros for FUNCALL and #'
> which would be no-ops, simply translating to their input expressions without
> the FUNCALL or #'.
>
> If my argument is wrong, all someone has to do is come up with a code
> snippet of the sort that Tayss was looking for. Otherwise, we're talking
> about a situation in which (a) a theory (described above) says that Lisp-2
> cannot be "much simpler"; (b) a number of examples support the theory, found
> e.g. in Gabriel & Pitman's in-depth analysis at
> http://www.nhplace.com/kent/Papers/Technical-Issues.html ; (c) more examples
> can easily be generated to test the theory; (d) a complete lack of
> counter-examples to the theory; and (e), no theoretical basis has yet been
> raised to contradict the theory.
Well, I don't think I agree with this claim.
Let me pose an example in the reverse. In the T language, a dialect of
Scheme and definitely in the Lisp1 family, we made the whole object system
based on a horrible pun about message names. That is, the function that is
vaguely generic-function-like which is called (if I recall) an "operation"
is bound to some function FOO and what it does is to look up something in the
dispatch table of the object. Now, what it looks up happens to be the
function which does the lookup; that is, the function FOO itself. The
advantage of this is that in T, an operation variable FOO points to a function
that sends that function FOO (as an object) as a message to its first arg.
A consequence of this is that if you have another environment in which you
want to call this another thing you can do
(LET ((MY-FOO FOO))
...)
and then inside there you can talk about the operation as if it were MY-FOO
both in the caller (MY-FOO obj) and in the dispatch
(COND ((EQ MESSAGE MY-FOO) ...) ...)
because the object system deals always in the value and not the name, and a
single renaming (as by LET) is sufficient to do this. In CL (a Lisp2), this
pun is not trivially possible even if you dispatch on objects in the same
way, since you'd have to do
(LET ((MY-FOO FOO))
(FLET ((MY-FOO (&REST ARGS) (APPLY MY-FOO ARGS)))
...))
which is more painful. I suppose you could say there was no more complexity
there, since I could macrofy the result, but then I have to wonder what the
term "complexity" means. Certainly I have to manage two bindings systems
rather than one at every point in code.
Now, you _could_ say "with that kind of ability to pun, why would
anyone want to be without it?" The answer is, not everyone likes
puns. (Ironically, I'd bet that most people who do like puns are in
the CL community and most people who don't are in the Scheme
community. CL people resonate, for example, to the designator concept
and to a single all-purpose NIL, while the Scheme community has
separated () from NIL and has avoided overloading operators like
STRING-EQUAL to take both strings and symbols, etc. I suppose there
is something structurally different about the T pun on objects that
makes it acceptable, but I've never been able to articulate or name
that subtle distinction.) In CL, for some odd reason, we prefer to
"disambiguate" (the opposite of punning) in this important case.
And so we get the power of being able to do
(defun copy-cons (cons)
(cons (car cons) (cdr cons)))
That is, we resonate to the idea that the variable CONS and the function
CONS are different. So one gets power in both directions and there is
not a simple preference of one mode over the other in terms of the
"cool things you can do".
Anyway, the reason I raise this is to show that there are material design
decisions that hinge on the choice of namespace. I happen not to be able
to cite more than trivial examples for Lisp2, but I think such examples
exist. By showing that there are advantages to both styles and by showing
a case where the Lisp1 mattered, I hope I've illustrated that the issue
is not always trivial.
> So no, I don't think I'm oversimplifying - other than explicitly ignoring
> the issue of individual preferences and familiarity.
This is a little like saying that
1. Words are just sequences of letters.
2. Sentences are made of words.
3. Therefore, people never will argue because (ignoring issues of
preferences and familiarity), words are harmless.
In the Programmer's Apprentice project at MIT, we set out to turn programs
into boxes and arrows representing control and data flow. A hypothesis
was that if we did this, we could treat "surface language" as superficial
and trivial, and write a single program that manipulated "real underlying
programs" ignoring syntax, and could be asked to code the result in any
language. The problem, as we found when we implemented a big piece of
this, is that languages differ in datatypes, operations, and all kinds of
other details, many of which are suggested and directed by the syntax, such
that when you go to re-express "real languages" (not just theoretical dialects,
like Lisp1 to Lisp2 or vice versa, but CL to Scheme), you find that there are
massive other differences such that "the details matter" and all the stuff
you are handwaving away is of enormous substance.
A secondary consequence of all of this is that I'm not sure any longer that
I see your point...
Kent M Pitman wrote:
> In an interactive language, new names can arise later due to loading code
> that did not cooperate with your renaming. An implication of this is that
> you cannot reliably rename functions merely by examining a region of code
> and assuming that you have complete world knowledge. An implication of
this
> is that you must reserve a set of names that are not for use by normal
users
> into which you will fold these extra names in order to make two namespaces
> fit in one. This extra name component will (a) break code that does
> introspection of function names, (b) disrupt existing code that does not
> expect the renamed function names, and (c) call into question your claim
> that the renaming would result in smaller code.
>
> But other than that, yes, you're right.
I like that last statement. The prior paragraph isn't relevant to the point
I was making, it's relevant to the question of conversion (possibly
automatic) which I explicitly disclaimed.
I'll repeat my only real point, to avoid it getting lost in the noise: the
Lisp-2 snippet Tayss was wondering about, which would illustrate how much
easier some operation is to implement in Lisp-2, does not exist, and cannot
exist. I think I've shown that quite convincingly. However, I'll address
the other points you've raised, below.
> You don't want to talk about character strings; step 1 talks about
> variables. Variables in Common Lisp are _objects_, not _strings_.
> They have already been through READ.
I was speaking loosely, and it was silly of me to use the word "strings".
My point is just that, for the purposes of the point I am making, the tokens
named FUNCTION and FUNCALL can simply be removed. In cases where they are
not removed for some reason, they are not relevant to the problem. These
exceptional cases you point out are examples of the subtleties to which I
referred (requoted below), and in no way affect the end result of comparison
between code snippets in the two dialects.
> > If I've missed some subtlety above, note that my goal is not to provide
the
> > specification for an automatic rewriter, but rather to make it clear
that no
> > syntax tree growth is involved in the conversion to Lisp-1.
>
> Right. But remarks such as yours, unchallenged, make it seem to others
> reading along that what you have suggested is a workable scheme for doing
> the translation.
That's an assertion about what other people may be thinking, for which I've
seen no evidence. It's not clear to me why readers of C.L.L. would be
interested in performing such a translation, either - there's no Lisp-1
version of CL available, and we weren't talking about a translation to
Scheme, which would obviously be enormously more complex.
> Speaking as someone who has done translation of large
> systems from one dialect to another, I can tell you from experience that
> there are all manner of odd problems when you do this kind of thing, and
> you should never without substantially more thought than you have done
here
> try to handwave away that complexity.
That's why I explictly stated that I wasn't talking about automatic
translation. I was providing rules to demonstrate how code snippets in
Lisp-1 could not be significantly more complex, bigger, or whatever than
snippets in Lisp-2. I believe the rules I provided suffice for that
purpose, although they could certainly be stated more precisely.
> The problem of reliable automatic translation of code is simply harder
> than you make it out to be.
I explicitly did not make the process of reliable automatic translation
trivial. I apologize if the flaws in my Usenet posting and my habit of
speaking loosely on occasion misled anyone.
> That doesn't detract from your general point, which is that there is
> a relatively simple relationship.
Thank you.
> However, it _does_ suggest you should steer clear
> of presenting the _process_ of code transformation
> as trivial. It really is inherently not.
In general, I'd have to disagree. It completely depends on the scope and
nature of the transformation in question. Some transformations can
successfully be executed with ordinary textual substitution. Many of the
transformations involved in basic compilation to some target language are
also quite trivial, depending on the source & target languages in question.
There's a big spectrum of easy to difficult in code transformation. I think
what you're getting at, is that when it's difficult, it can be very very
difficult, which I acknowledge.
> This is important in itself because _even if_ it were the case that people
> bought your argument, it would (I claim) have been adequate reason for
> the CL community not to have made a change to Lisp1 "merely" because of
> the profoundly large cost of translating the body of existing code written
> in the existing style.
And I agree with that, and have said or implied as much in other messages.
If you think otherwise, perhaps you could point out to me what I said, so
that I can avoid such serious mistakes in future. But more likely, I think
that what's happening here is a process of projection, fed by some
misunderstandings:
* I defended Lisp-1
* therefore I must be anti-Lisp-2
* therefore I must want Common Lisp to be changed to a Lisp-1, or better
yet, all Common Lispers to convert to Scheme
Beyond the first point, the subsequent points are all incorrect and do not
describe my positions.
Other than a much more general comment about language refactoring which I
recently made to Kenny Tilton, I have not intended to imply that I thought
the CL community should have switched to Lisp-1 at any time, whether now, in
the past, or in the future. And my comment to Kenny Tilton was not
addressed to any specific language community - it applies to every language
I've ever come across. That specific comment could certainly be criticized
for excessive handwaving, and I acknowledge that.
In this part of the thread, I attempted to respond to one issue, and one
issue alone: that a code snippet demonstrating that writing some piece of
code in Lisp-2 was much easier, could not exist. By making this claim,
which I believe is factual and well-supported, I did not intend to imply
anything about the relative merits of Lisp-1 and Lisp-2 in general, other
than the direct claim I made; and I did not intend to imply anything about
the relative merits of Lisp, Common Lisp, T, or Scheme.
Where I have strayed from the point I was trying to make, I did so only in
response to tangential issues being raised by others, but in general, I have
attempted to remain "on message" - in fact, all I have really been trying to
do is defend my original position.
> > If my argument is wrong, all someone has to do is come up with a code
> > snippet of the sort that Tayss was looking for. Otherwise, we're
talking
> > about a situation in which (a) a theory (described above) says that
Lisp-2
> > cannot be "much simpler"; (b) a number of examples support the theory,
found
> > e.g. in Gabriel & Pitman's in-depth analysis at
> > http://www.nhplace.com/kent/Papers/Technical-Issues.html ; (c) more
examples
> > can easily be generated to test the theory; (d) a complete lack of
> > counter-examples to the theory; and (e), no theoretical basis has yet
been
> > raised to contradict the theory.
>
> Well, I don't think I agree with this claim.
I'm glad to finally discuss the actual point I was trying to make.
Your T example may certainly be an example of questionable behavior, perhaps
of Lisp-1 being abused, but the fact that abuse is possible does not say
anything about the ability to express something *without abuse* in Lisp-1.
So once again, you seem to be trying to move the discussion towards all the
things which you dislike about Lisp-1, which have nothing to do with the
point I am (apparently poorly) trying to make, and the only point I'm
interested in defending.
The reason I'm not particularly interested in defending Lisp-1 in general,
is that I agree with you that there are huge issues of preference which make
such discussion of questionable value, unless done between people with a
constructive goal in mind and a willingness to work with each other.
> And so we get the power of being able to do
> (defun copy-cons (cons)
> (cons (car cons) (cdr cons)))
> That is, we resonate to the idea that the variable CONS and the function
> CONS are different. So one gets power in both directions and there is
> not a simple preference of one mode over the other in terms of the
> "cool things you can do".
Your characterization of this as "power" is one of those preference things.
A Scheme equivalent doesn't appear (to me) to suffer from lack of power:
(define (copy-cons pair)
(cons (car pair) (cdr pair)))
I note that this transformation follows the rules I outlined, with the
expected result.
> Anyway, the reason I raise this is to show that there are material design
> decisions that hinge on the choice of namespace. I happen not to be able
> to cite more than trivial examples for Lisp2, but I think such examples
> exist. By showing that there are advantages to both styles and by showing
> a case where the Lisp1 mattered, I hope I've illustrated that the issue
> is not always trivial.
The advantages you cite seem to be preference issues, such as the ability to
pun in different ways. These puns are of questionable importance on both
sides of the fence, IMO. One could, as a matter of preference, avoid puns
wherever possible, in either dialect. I don't see that you have illustrated
anything material to the point I am making.
> > So no, I don't think I'm oversimplifying - other than explicitly
ignoring
> > the issue of individual preferences and familiarity.
>
> This is a little like saying that
> 1. Words are just sequences of letters.
> 2. Sentences are made of words.
> 3. Therefore, people never will argue because (ignoring issues of
> preferences and familiarity), words are harmless.
It's not like that at all.
If you factor in the preferences issue, then all you can say is essentially
this: for someone familiar with Lisp-2, implementing something in Lisp-2 is
easier. This is a completely uninteresting claim that is hardly worth any
discussion.
However, I'm assuming (based on plenty of evidence) that with appropriate
diligence and caution, it's possible to factor out issues of preference, and
compare things like expressiveness and power between languages. We don't
have good tools for this (Matthias Felleisen's paper on the subject
notwithstanding), but there are cases where fairly unambiguous comparisons
can be made.
I gave an example in my first response to you: implementing higher-order
functions (or some reasonable facsimile) is more difficult in C than in
Lisp. I say this as someone roughly equally familiar with C and Scheme, and
I don't think it's merely a preference issue. Whether one wishes to
implement code in the style engendered by higher-order functions is a
separate question, which might be subject to preference, but the greater
difficulty of implementing that behavior in C seems to be a fundamental
difference in the characteristics of C vs. Lisp.
If you're willing to grant some leeway in that I haven't provided a formal
description of this phenomenon, then call this kind of difference a
"substantive objective difference" between the languages, and agree that
such do exist. For example, we don't program much in assembler any more,
because of substantive objective differences which work in favor of high
level languages.
One might argue that this is still all preference: we prefer to write fewer
lines of code, so we use high level languages. That would be a definitional
problem, though: if there's an absolute unavoidable difference in something
like number of lines of code needed to express the same algorithm, that
argues for a substantive objective difference.
My point is that, given the nature of the translation between Lisp-2 and
Lisp-1, the difference between them cannot have the quality of a substantive
objective difference.
If I understand you correctly, you seem inclined to dismiss the possibility
of a substantive objective difference, essentially saying that preference
cannot be factored out. I'm guessing, though, that you wouldn't claim that
the relatively minimal use of assembler today, compared to 30 years ago, is
merely a fad. We'd have to have some discussion to settle on how you see
differences between languages and dialects being measured objectively; I
won't try to speculate.
> In the Programmer's Apprentice project at MIT, we set out to turn programs
> into boxes and arrows representing control and data flow. A hypothesis
> was that if we did this, we could treat "surface language" as superficial
> and trivial, and write a single program that manipulated "real underlying
> programs" ignoring syntax, and could be asked to code the result in any
> language. The problem, as we found when we implemented a big piece of
> this, is that languages differ in datatypes, operations, and all kinds of
> other details, many of which are suggested and directed by the syntax,
such
> that when you go to re-express "real languages" (not just theoretical
dialects,
> like Lisp1 to Lisp2 or vice versa, but CL to Scheme), you find that there
are
> massive other differences such that "the details matter" and all the stuff
> you are handwaving away is of enormous substance.
I'm not talking about anything nearly as complicated or ambitious. Perhaps
you can provide a specific relevant example.
> A secondary consequence of all of this is that I'm not sure any longer
that
> I see your point...
Perhaps I've made it clearer above. If not, I'm not sure I can do any
better.
Along these lines, I'd be interested to hear a summary of your position -
you've been taking issues with aspects of my argument, but I'm not
completely sure what your position on the matter is. I've gathered three
possibilities:
1. Factoring out preference is meaningless. If that's your position, then
we have to agree to disagree. I think there's evidence to show that it's
possible to make meaningful comparisons after having factored out
preference.
2. Even with preference factored out, there exists a code snippet which
demonstrates that some problems are much more easily expressed in Lisp-2
than Lisp-1. If you claim this, I think you need to do a better job of
refuting my argument, ideally by providing an example.
3. Something other than the above, which may not actually be relevant to my
point.
Anton
"Anton van Straaten" <·····@appsolutions.com> wrote in message news:<··················@newsread1.prod.itd.earthlink.net>...
> I'll repeat my only real point, to avoid it getting lost in the noise: the
> Lisp-2 snippet Tayss was wondering about, which would illustrate how much
> easier some operation is to implement in Lisp-2, does not exist, and cannot
> exist. I think I've shown that quite convincingly. However, I'll address
> the other points you've raised, below.
To show a sublte difference in expressiveness
is like trying to show the force of gravity in
an atomic nucleus. Gravity is one of the weakest
forces in nature, and should be the most easily
dismissed. The binding forces that hold the
nucleus together are so many orders of magnitude
stronger, gravity is simply lost in the noise
and can't be shown to have any meaningful effect
in such an example as a single nucleus.
But it adds up. The overall effect we should be
looking for is at the cosmic level, not the
subatomic level.
Good software development consists of building
your library until it has everything your program
needs, so your program itself becomes a trivial
usage of that library. You might have many
thousands of function names, and you might spend
a considerable fraction of your development time
inventing new names.
To impose any subtle burden on that effort is like
gravity imposing a subtle force on an atom. It's
lost in the noise, so it doesn't seem to matter.
The burden you impose is that for each of those
thousands of function names, we have to be sure our
local variables don't conflict, and we have to
spend more time on each name we invent, to take
such conflicts into account, and to think of more
different ways to express the same idea. Then we
have to keep straight in our minds which different
ways to express the same idea actually do express
the same idea and which ones actually express
subtly different ideas.
So, yes, you're right, no such gain in expressiveness
is visible at the level of a single simple example.
Just as no effect of gravity is visible in an atom.
But if you continue in that direction too far, you
might end up in a black hole.
Eric Smith wrote:
> "Anton van Straaten" <·····@appsolutions.com> wrote in message
news:<··················@newsread1.prod.itd.earthlink.net>...
>
> > I'll repeat my only real point, to avoid it getting lost in the noise:
the
> > Lisp-2 snippet Tayss was wondering about, which would illustrate how
much
> > easier some operation is to implement in Lisp-2, does not exist, and
cannot
> > exist. I think I've shown that quite convincingly. However, I'll
address
> > the other points you've raised, below.
>
> To show a sublte difference in expressiveness
> is like trying to show the force of gravity in
> an atomic nucleus.
Nice point!
> But it adds up. The overall effect we should be
> looking for is at the cosmic level, not the
> subatomic level.
I agree completely.
> So, yes, you're right, no such gain in expressiveness
> is visible at the level of a single simple example.
That's really all I was trying to say, although I admit my assumption in
this case was that even at a macro level, any objective difference would
still not be great.
> Just as no effect of gravity is visible in an atom.
> But if you continue in that direction too far, you
> might end up in a black hole.
You might. But it's at this level that I'm inclined to assume that strong
elements of preference and familiarity are involved. In which case, the
gravity you refer to could be what binds people to languages - people stick
to languages in which that subtle gravitational effect accumulates in a way
which attracts them, and they avoid languages in which that effect repels
them. But to mix physical metaphors, people, like subatomic particles, have
different polarities and spins, and are attracted and repelled by different
things. (In subhadronic terms, you could say that some of us are charming,
some of us are colorful, and some of us are strange :)
Of course, it would be convenient if some languages and/or companies *did*
collapse into black holes, since it would provide a most satisfying
opportunity for one side or the other to say "I told you so!", and provide
much fodder for speculation about exactly which features finally did them
in. "Did you hear about Globalcorp? Two weeks after they began
implementing Web Services(tm) in C#, they just went, like, poof!"
Anton
"Anton van Straaten" <·····@appsolutions.com> writes:
> > > If I've missed some subtlety above, note that my goal is not to
> > > provide the specification for an automatic rewriter, but rather
> > > to make it clear that no syntax tree growth is involved in the
> > > conversion to Lisp-1.
> >
> > Right. But remarks such as yours, unchallenged, make it seem to others
> > reading along that what you have suggested is a workable scheme for doing
> > the translation.
>
> That's an assertion about what other people may be thinking, for which I've
> seen no evidence. It's not clear to me why readers of C.L.L. would be
> interested in performing such a translation, either - there's no Lisp-1
> version of CL available, and we weren't talking about a translation to
> Scheme, which would obviously be enormously more complex.
I was meaning to say that, a priori (absent special very knowledge of
a lucky situation), I don't think _any_ reliable translation of any
meaningful body of code between any real two languages is ever
"trivial". The very tiny length and simplistic nature of the "rewrite
rules" you were offering is suggestive in and of itself of you having
considered the issue too little. My real point is that readers who think
translating a large body of code is trivial and mechanical and requires
no budget should reconsider.
I hate it when people lowball their ideas of how much work a project
is going to take or how much it is going to cost and then badger you
(or me) when their very naive expectation of "it shouldn't be that
hard" is violated. So I'm doing early expectation-control mode here.
> ... more likely, I think
> that what's happening here is a process of projection, fed by some
> misunderstandings:
>
> * I defended Lisp-1
> * therefore I must be anti-Lisp-2
> * therefore I must want Common Lisp to be changed to a Lisp-1, or better
> yet, all Common Lispers to convert to Scheme
No, certainly I don't have that theory. However, I have the theory
that many Lisp1ers in the woodwork are looking for a proof that they
are right that the world really is simpler than they think and they
glomb onto any oversimplified explanation that supports their
argument, independent of whether that's the purpose for which the
oversimplified explanation is offered.
It's a general problem of usenet that adding remarks to someone else's
post makes it look like you are (or "one is") addressing the person
who wrote the remarks. In many cases, I'm just speaking generally
about thoughts I have that someone has reminded me to spout and for
which sohas been kind enough to give me a vaguely relevant forum.
[ ... a bunch of stuff got lost here in a system crash and I'm too tired
to retype it even if I remembered it. ... sorry, I think this post was
more coherent before the crash, but that's the way it goes sometimes...]
> Along these lines, I'd be interested to hear a summary of your position -
> you've been taking issues with aspects of my argument, but I'm not
> completely sure what your position on the matter is. I've gathered three
> possibilities:
>
> 1. Factoring out preference is meaningless. If that's your position, then
> we have to agree to disagree. I think there's evidence to show that it's
> possible to make meaningful comparisons after having factored out
> preference.
Not this. What I said (or meant) that you are thinking might be this is:
I'm not convinced that factoring out preferences doesn't lose something.
If you insist on just saying "preferences" and having that be enough to
factor something out without other evidence, I think that's overaggressive.
> 2. Even with preference factored out, there exists a code snippet which
> demonstrates that some problems are much more easily expressed in Lisp-2
> than Lisp-1. If you claim this, I think you need to do a better job of
> refuting my argument, ideally by providing an example.
I don't know what you mean by "easily expressed" so I don't know if this is
what I meant but suspect it is not...
> 3. Something other than the above, which may not actually be relevant to my
> point.
I'd like to better understand what you mean by objective substantive power,
or whatever you called it. How would I prove or disprove that. Is this
one of those things like pornography that one knows when one sees it, or
does it have a real working definition?
Kent M Pitman wrote:
> "Anton van Straaten" <·····@appsolutions.com> writes:
> > That's an assertion about what other people may be thinking, for which
I've
> > seen no evidence. It's not clear to me why readers of C.L.L. would be
> > interested in performing such a translation, either - there's no Lisp-1
> > version of CL available, and we weren't talking about a translation to
> > Scheme, which would obviously be enormously more complex.
>
> I was meaning to say that, a priori (absent special very knowledge of
> a lucky situation), I don't think _any_ reliable translation of any
> meaningful body of code between any real two languages is ever
> "trivial".
Actually, it seems to me that the translation we're talking about here would
not be a significantly difficult project. The exceptions you raised in an
earlier post are all quite manageable.
Although I've implemented a number of DSLs as well as a commercial
shrinkwrap language product, most of my actual experience of code
transformation comes from one-off projects to convert a body of code. In
those cases, you don't necessarily need your automatic transformation to be
perfect - you want it to get 98% of the job done, and then use testing and
tweaking to finish the job. Many of the hard problems of code
transformation fall in that other 2%, but they tend to be much easier for
humans, especially for humans that are familiar with the code in question.
So I'd say code transformation can be easy in many circumstances, if not
approached with the goal of achieving a 100% automated solution.
> The very tiny length and simplistic nature of the "rewrite rules"
> you were offering is suggestive in and of itself of you having
> considered the issue too little.
It should have been suggestive of my only putting in as much effort as
needed for the requirement at hand, which wasn't an automatic rewriter, but
rather a demonstration of a point about lack of growth of the syntax tree as
a result of the transformation.
> My real point is that readers who think translating a large body
> of code is trivial and mechanical and requires no budget should
> reconsider.
Software developers who think that *anything* requires no budget should
reconsider.
> I hate it when people lowball their ideas of how much work a project
> is going to take or how much it is going to cost and then badger you
> (or me) when their very naive expectation of "it shouldn't be that
> hard" is violated. So I'm doing early expectation-control mode here.
If anyone comes to you asking to convert a large body of Lisp2 code to Lisp1
on the cheap, just refer them to me. :)
> No, certainly I don't have that theory. However, I have the theory
> that many Lisp1ers in the woodwork are looking for a proof that they
> are right that the world really is simpler than they think and they
> glomb onto any oversimplified explanation that supports their
> argument, independent of whether that's the purpose for which the
> oversimplified explanation is offered.
Fair point. If the argument that these Lisp1 lurkers believe is being
supported is that converting real Lisp2 code to a real Lisp1 dialect is
trivial, let me state for the record that this is most certainly not the
case. And as I've already said, nothing I said was intended to indicate
that one or the other dialect was better - in fact the opposite, I was
suggesting there is little "objective" difference between the two. Some
here seem to disagree with that, but that's my opinion.
> It's a general problem of usenet that adding remarks to someone else's
> post makes it look like you are (or "one is") addressing the person
> who wrote the remarks. In many cases, I'm just speaking generally
> about thoughts I have that someone has reminded me to spout and for
> which sohas been kind enough to give me a vaguely relevant forum.
OK.
> [ ... a bunch of stuff got lost here in a system crash and I'm too tired
> to retype it even if I remembered it. ... sorry, I think this post was
> more coherent before the crash, but that's the way it goes sometimes...]
I hate when that happens!
> > 1. Factoring out preference is meaningless. If that's your position,
then
> > we have to agree to disagree. I think there's evidence to show that
it's
> > possible to make meaningful comparisons after having factored out
> > preference.
>
> Not this. What I said (or meant) that you are thinking might be this is:
> I'm not convinced that factoring out preferences doesn't lose something.
> If you insist on just saying "preferences" and having that be enough to
> factor something out without other evidence, I think that's
overaggressive.
>
> > 2. Even with preference factored out, there exists a code snippet which
> > demonstrates that some problems are much more easily expressed in Lisp-2
> > than Lisp-1. If you claim this, I think you need to do a better job of
> > refuting my argument, ideally by providing an example.
>
> I don't know what you mean by "easily expressed" so I don't know if this
is
> what I meant but suspect it is not...
Tayss' original request was for "a code snippet that was much easier to
implement in lisp-2 than in a hypothetical
lisp-1 CL." As I've said, I interpreted that to mean "easier in some
absolute sense", rather than "easier for a Lisp-2 programmer". Tayss
subsequently confirmed that interpretation. We didn't ever define that
"absolute sense", but I've been talking about factoring out preference and
familiarity to indicate that.
Certainly, there are many situations in which "factoring out preference and
familiarity" would be ludicrous. A sane project manager doesn't just decide
to switch a project from Java to OCaml and tell the programmers "don't
worry, it only seems hard because it's unfamiliar". But it's possible, and
can be useful, to compare languages without reference to a specific
population of programmers, and in such cases, preferences for the features
of a specific language can be much less important, if they're a factor at
all.
I'm not writing an academic paper here, and it's a fuzzy topic, so there's
plenty of ambiguity. The notion I think that's involved is commonly
referred to as "expressive power" (forget my previous term, I should have
chosen something more standard, sorry).
> I'd like to better understand what you mean by objective substantive
power,
> or whatever you called it. How would I prove or disprove that. Is this
> one of those things like pornography that one knows when one sees it, or
> does it have a real working definition?
Felleisen has an old paper about it, "On the Expressive Power of Programming
Languages":
http://www.ccs.neu.edu/scheme/pubs/scp91-felleisen.ps.gz
The paper provides a formal framework, which is applied to a couple of small
Scheme dialects and Algol-like program constructs. I've never seen it
applied to a full-scale language, but the paper also discusses and proves a
number of qualities which can be used to judge expressiveness, which tend to
be quite intuitive.
One example is that of programming patterns: in less expressive languages,
patterns arise which need to be repeated throughout a body of code. The
specific kinds of patterns I'm talking about are those which can essentially
be generated from a boilerplate template, filling in the gaps with code
specific to the task at hand. C++ and Java are notorious for such patterns.
Smart programmers often come up with ways of automating the process of
filling in the boiler plate - template languages and code generators of all
kinds. Quite commonly, they create domain-specific languages using XML or
whatever, which are used as a basis for generating code. In some sense,
those DSLs are in fact more expressive than the language for which they
generate code. However, they also tend to be limited in other respects, so
may not be more expressive in every way.
If, however, you add a powerful macro system to a language, you provide the
ability to abstract certain kinds of patterns out of the main body of code.
You no longer need to resort to external code generators and other languages
to write the program you want to write. A language with a macro system can
thus be more expressive than a language without one. This can be tested by
comparing programs which implement the same functionality: all else being
equal, the program expressed in the language with macros will be both
shorter and more comprehensible than in the language without macros, simply
because the program in the language without macros will contain
un-abstractable code patterns, which both increase the size of the code and
obscure the underlying algorithms.
There's plenty of room for argument in the last paragraph: agreed-on ways to
reliably assess comprehensibility would obviously be needed, for example.
Some particularly expressive languages without macros may compensate for
that lack by providing a battery of features - Haskell-style features such
as list comprehensions and laziness come to mind. But hopefully I've
communicated the general idea.
Most people who've thought about it do acknowledge that some languages are
more expressive than others: C is (mostly) more expressive than assembler,
Lisp (mostly) more expressive than C. I say 'mostly' because there are
certain things that can be easier to express in the less expressive
language. Measuring this quality is a very different question, though.
It's not always as "easy" as the patterns vs. macro case. But in fact, I
think it's possible to make useful comparisons on the basis of what
"reasonable people can agree" on.
To bring this full circle, in my initial post I was implying that I thought
that reasonable people could agree that there was no significant difference
in expressive power between Lisp1 and Lisp2, and certainly not one that
could be illustrated by code snippets. I realize now that this may be a
more controversial claim than I had imagined.
Anton
From: Joe Marshall
Subject: Re: Looking for examples of lisp-2's expressiveness
Date:
Message-ID: <oez1l2eu.fsf@ccs.neu.edu>
"Anton van Straaten" <·····@appsolutions.com> writes:
> To bring this full circle, in my initial post I was implying that I thought
> that reasonable people could agree that there was no significant difference
> in expressive power between Lisp1 and Lisp2, and certainly not one that
> could be illustrated by code snippets. I realize now that this may be a
> more controversial claim than I had imagined.
I pretty much agree with this. Certainly the differences between
lisp-1 and lisp-2 are infinitessimal compared with the differences
between Lisp and, say, Java or C or Basic.
Kent M Pitman <······@world.std.com> wrote:
+---------------
| I was meaning to say that, a priori (absent special very knowledge of
| a lucky situation), I don't think _any_ reliable translation of any
| meaningful body of code between any real two languages is ever
| "trivial". The very tiny length and simplistic nature of the "rewrite
| rules" you were offering is suggestive in and of itself of you having
| considered the issue too little. My real point is that readers who think
| translating a large body of code is trivial and mechanical and requires
| no budget should reconsider.
|
| I hate it when people lowball their ideas of how much work a project
| is going to take or how much it is going to cost and then badger you
| (or me) when their very naive expectation of "it shouldn't be that
| hard" is violated. So I'm doing early expectation-control mode here.
+---------------
A reminder that Kent has at least one major project to back up these
opinions: <URL:http://www.nhplace.com/kent/Papers/Fortran-to-Lisp.html>
-Rob
-----
Rob Warnock, PP-ASEL-IA <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
Rob Warnock wrote:
> Kent M Pitman <······@world.std.com> wrote:
> +---------------
> | I was meaning to say that, a priori (absent special very knowledge of
> | a lucky situation), I don't think _any_ reliable translation of any
> | meaningful body of code between any real two languages is ever
> | "trivial". The very tiny length and simplistic nature of the "rewrite
> | rules" you were offering is suggestive in and of itself of you having
> | considered the issue too little. My real point is that readers who
think
> | translating a large body of code is trivial and mechanical and requires
> | no budget should reconsider.
> |
> | I hate it when people lowball their ideas of how much work a project
> | is going to take or how much it is going to cost and then badger you
> | (or me) when their very naive expectation of "it shouldn't be that
> | hard" is violated. So I'm doing early expectation-control mode here.
> +---------------
>
> A reminder that Kent has at least one major project to back up these
> opinions: <URL:http://www.nhplace.com/kent/Papers/Fortran-to-Lisp.html>
Meaning no slight to Kent's impressive body of work, I think that was part
of the problem here: no-one was suggesting an actual automated translation.
I think my use of the term "rewrite rules" in connection with Lisp[*],
without an accompanying 80-page specification, triggered an involuntary
response.
Further, as I pointed out, not all automated translation projects have to be
100% solutions. Depending on the requirements, picking one's battles can be
particularly effective in this area.
Anton
[*] Common Lisp, that is. Scheme would be much easier to translate
automatically.[**]
[**] Of course, I mean R5RS Scheme, since nothing else is standard enough to
write rules for.[***]
[***] As everyone here no doubt knows, R5RS is barely Turing-complete.[****]
[****] Oh wait, Kent worked on R5RS. Now I've gone and backed myself into a
corner...
On Sun, Aug 10, 2003 at 07:41:03AM +0000, Anton van Straaten wrote:
> Meaning no slight to Kent's impressive body of work, I think that was part
> of the problem here: no-one was suggesting an actual automated translation.
> I think my use of the term "rewrite rules" in connection with Lisp[*],
> without an accompanying 80-page specification, triggered an involuntary
> response.
Actually it was the usage of string-replacement which probably triggered
the response. What did you expect, anyway, in a Lisp newsgroup? If we
wanted that kind of code rewriting, we'd be using cpp.
--
; Matthew Danish <·······@andrew.cmu.edu>
; OpenPGP public key: C24B6010 on keyring.debian.org
; Signed or encrypted mail welcome.
; "There is no dark side of the moon really; matter of fact, it's all dark."
Matthew Danish wrote:
> On Sun, Aug 10, 2003 at 07:41:03AM +0000, Anton van Straaten wrote:
> > Meaning no slight to Kent's impressive body of work, I think that was
part
> > of the problem here: no-one was suggesting an actual automated
translation.
> > I think my use of the term "rewrite rules" in connection with Lisp[*],
> > without an accompanying 80-page specification, triggered an involuntary
> > response.
>
> Actually it was the usage of string-replacement which probably triggered
> the response. What did you expect, anyway, in a Lisp newsgroup? If we
> wanted that kind of code rewriting, we'd be using cpp.
Yes, you're right. I used phrases like "Remove all occurrences of the
character string 'FUNCALL'". I should have used the term "token". I was
speaking loosely, but also chose the phrasing somewhat deliberately to point
out that really, it looked to me as though almost all occurrences of those
"strings" could be blindly removed, i.e. that properly parsing the code -
even though that's so easy with a Lisp - wouldn't even be necessary.
Of course, emphasizing that point in such a way, without being explicit, was
exactly the wrong thing to do, here. You're absolutely correct, you could
probably use cpp to implement the rewrite I described, and achieve a 98%
solution. The exceptions Kent pointed out were actually very minor.
On a topic like this, leaving the slightest weakness in a post provides an
opportunity for attack. It's been a while since I've had to deal with such
tactics, I'm rusty.
Anton
On Sun, Aug 10, 2003 at 11:12:12AM +0000, Anton van Straaten wrote:
> Of course, emphasizing that point in such a way, without being explicit, was
> exactly the wrong thing to do, here. You're absolutely correct, you could
> probably use cpp to implement the rewrite I described, and achieve a 98%
> solution. The exceptions Kent pointed out were actually very minor.
Let me point out a few exceptions which aren't so ``minor''[1] then:
I will use |=> to mean your string-replacement rewrite.
(funcall 'foo 1 2 3) |=> ( 'foo 1 2 3)
;; as in
(defun foo (&rest args) (format t "~&Global foo ~A" args))
(flet ((foo (&rest args) (format t "Lexical foo ~A" args)))
(foo 1 2 3)
(funcall 'foo 1 2 3))
;; This has a totally different meaning from this
(apply 'funcall #'foo '(1 2 3)) |=> (apply ' foo '(1 2 3))
(defparameter *dispatch-table*
'(... (call-fun "Calls a function" funcall) ...))
|=>
(defparameter *dispatch-table*
'(... (call-fun "Calls a function" ) ...))
(multiple-value-call #'funcall (values #'identity 1))
|=> (multiple-value-call (values identity 1)) ;; broken
;; and of course
(function list) |=> ( list)
Basically, when translating from a Lisp-2 to a Lisp-1, you can't ignore
the difference in namespaces. Also your rewrite rules fail to take into
account extended function designators (not to mention SETF functions).
> On a topic like this, leaving the slightest weakness in a post provides an
> opportunity for attack. It's been a while since I've had to deal with such
> tactics, I'm rusty.
It isn't a slight weakness, it is a fundamental flaw as far as Lispers
are concerned.
[1] The issues were only minor insofar as they could've been addressed
by using a proper code-walker; which should've been the original
solution.
--
; Matthew Danish <·······@andrew.cmu.edu>
; OpenPGP public key: C24B6010 on keyring.debian.org
; Signed or encrypted mail welcome.
; "There is no dark side of the moon really; matter of fact, it's all dark."
Matthew Danish wrote:
> On Sun, Aug 10, 2003 at 11:12:12AM +0000, Anton van Straaten wrote:
> > Of course, emphasizing that point in such a way, without being explicit,
was
> > exactly the wrong thing to do, here. You're absolutely correct, you
could
> > probably use cpp to implement the rewrite I described, and achieve a 98%
> > solution. The exceptions Kent pointed out were actually very minor.
>
> Let me point out a few exceptions which aren't so ``minor''[1] then:
Yeah, I was exaggerating a little in the above quote. The points you raise
are all good.
> > On a topic like this, leaving the slightest weakness in a post provides
an
> > opportunity for attack. It's been a while since I've had to deal with
such
> > tactics, I'm rusty.
>
> It isn't a slight weakness, it is a fundamental flaw as far as Lispers
> are concerned.
So far, I've seen only two or three "Lispers" make an issue of this. I
don't have enough info to extrapolate. I think I'll give Lispers the
benefit of the doubt for being able to interpret things in the context in
which they are meant.
> [1] The issues were only minor insofar as they could've been addressed
> by using a proper code-walker; which should've been the original
> solution.
The "original solution" was explicitly not a specification for an automated
rewriter. None of the exceptions you or Kent raised are anything more than
incidental to that initial purpose. As I said, my unfortunate mischoice of
words simply provided an opportunity for Kent to pick at something that was
irrelevant to the discussion.
Anton
In article <····························@posting.google.com>,
··········@yahoo.com (Tayss) wrote:
> I am aware of that wrinkle; I could have sworn there was an example
> where lisp-2 syntax led to a pretty big simplification when
> implementing something.
Yes, I recall seeing such an example as well but I don't remember the
exact details. It was posted this year here in c.l.l. Google doesn't
seem to be helpful though...
Pascal
Hi Pascal Costanza,
> In article <····························@posting.google.com>,
> ··········@yahoo.com (Tayss) wrote:
>
>> I am aware of that wrinkle; I could have sworn there was an example
>> where lisp-2 syntax led to a pretty big simplification when
>> implementing something.
>
> Yes, I recall seeing such an example as well but I don't remember the
> exact details. It was posted this year here in c.l.l. Google doesn't
> seem to be helpful though...
Here's one from last year:
<http://groups.google.com/groups?selm=87ofgl7ymo.fsf%40Samaris.tunes.org>
Francois-Rene Rideau writes "since today is Saint Paternus, it's a good
day to announce my pattern-matcher. I'm developing an extensible
pattern-matcher in CL, that has a Lisp2 style that I find very natural ...
Actually, I had first thought about this pattern-matcher when I was more
of a Lisp1 fan, and the fact that Lisp2 was much more natural for the
pattern matcher finished to turn me into a Lisp2 fan."
Regards,
Adam
Adam Warner wrote:
> Hi Pascal Costanza,
>
> > In article <····························@posting.google.com>,
> > ··········@yahoo.com (Tayss) wrote:
> >
> >> I am aware of that wrinkle; I could have sworn there was an example
> >> where lisp-2 syntax led to a pretty big simplification when
> >> implementing something.
> >
> > Yes, I recall seeing such an example as well but I don't remember the
> > exact details. It was posted this year here in c.l.l. Google doesn't
> > seem to be helpful though...
>
> Here's one from last year:
> <http://groups.google.com/groups?selm=87ofgl7ymo.fsf%40Samaris.tunes.org>
>
> Francois-Rene Rideau writes "since today is Saint Paternus, it's a good
> day to announce my pattern-matcher. I'm developing an extensible
> pattern-matcher in CL, that has a Lisp2 style that I find very natural ...
> Actually, I had first thought about this pattern-matcher when I was more
> of a Lisp1 fan, and the fact that Lisp2 was much more natural for the
> pattern matcher finished to turn me into a Lisp2 fan."
Rideau is talking about applying what he calls "Lisp2 style" to the design
of his pattern matcher, and claims a benefit from doing so. This is an
application design decision above the level of the underlying language.
This application could easily be implemented in a Lisp-1, still using
Rideau's "Lisp2 style". In fact, a well-known pattern matcher for Scheme
uses a similar style - the matcher in Eli Barzilay's excellent Swindle
library (http://www.cs.cornell.edu/eli/Swindle/).
In addition, what Rideau means by "Lisp2 style" has nothing to do with dual
namespaces, but rather that his match patterns require explicit constructor
functions such as 'list*' and 'list' to be specified. As he puts it, "you
can trust that any symbol in head position is a pattern name, while any
symbol in parameter position is a variable name." Although the comparison
to Lisp-2 in that description is obvious, the issue that's really being
addressed here is the ambiguity of literal list definitions in all Lisps.
Anton
In article <······························@consulting.net.nz>,
Adam Warner <······@consulting.net.nz> wrote:
> > Yes, I recall seeing such an example as well but I don't remember the
> > exact details. It was posted this year here in c.l.l. Google doesn't
> > seem to be helpful though...
>
> Here's one from last year:
> <http://groups.google.com/groups?selm=87ofgl7ymo.fsf%40Samaris.tunes.org>
>
I had another example in mind. But thanks for that.
Pascal
Tayss wrote:
> I am aware of that wrinkle; I could have sworn there was an example
> where lisp-2 syntax led to a pretty big simplification when
> implementing something. Similar to... taking a really extreme
> example, how Leibniz's notation for calculus made many things easier
> than Newton's.
Take a look at this similar thread below. I bet there are some examples
in that thread.
This message is however the other way around.
<http://groups.google.com/groups?q=g:thl324145581d&dq=&hl=en&lr=&ie=UTF-8&selm=gat-2905030836430001%40192.168.1.51&rnum=94>
--
Jens Axel S�gaard
"Tayss" wrote:
> I remember someone (Pascal Costanza?) once mentioned a code snippet
> that was much easier to implement in lisp-2 than in a hypothetical
> lisp-1 CL. I've been trying to search for it to no avail. Does
> anyone know any examples to think about?
>
> No flamewars please. I'm aware of the circumstances where lisp-1 is
> more readable.
It's hard to see how something could be "much easier" to implement in
lisp-2, since lisp-1 can express any lisp-2 program, as long as any
conflicting names are changed so as not to conflict.
Anton
"Anton van Straaten" <·····@appsolutions.com> writes:
> "Tayss" wrote:
> > I remember someone (Pascal Costanza?) once mentioned a code snippet
> > that was much easier to implement in lisp-2 than in a hypothetical
> > lisp-1 CL. I've been trying to search for it to no avail. Does
> > anyone know any examples to think about?
> >
> > No flamewars please. I'm aware of the circumstances where lisp-1 is
> > more readable.
>
> It's hard to see how something could be "much easier" to implement in
> lisp-2, since lisp-1 can express any lisp-2 program, as long as any
> conflicting names are changed so as not to conflict.
I often think too little is made of the importance of syntax. I think
people get used to a syntax and find it hard to think in another.
I don't think that always makes one syntax intrinsically better
than another, although I do think that there are material differences
between syntaxes--most make certain things easier and other things
harder--that is, none get anything for free, but mostly all get at least
something for their choices.
I think things that are presented in a 'friendly form' ARE 'easier to
implement', but not in some fundamental way--rather in a way that takes
into account the needs of the person doing the expression.
Some people find the lisp1 notation (define (foo f x) (f x))
to be merely "concise" while others find it "doesn't make certain
important things overtly visible". Some find the lisp2 notation
(defun foo (f x) (funcall f x)) to be merely "perspicuous", highlighting
a 'variable function call' in a clear way, while others find it
"painfully verbose and bordering on redundant".
Syntax matters, or we wouldn't discuss it too much. So let's not make
light of it.
Kent M Pitman wrote:
> Syntax matters, or we wouldn't discuss it too much. So let's not make
> light of it.
Assuming this is in response to what I actually said, I didn't think I was
making light of it. I wrote:
> > It's hard to see how something could be "much easier" to implement in
> > lisp-2, since lisp-1 can express any lisp-2 program, as long as any
> > conflicting names are changed so as not to conflict.
And I think that's true. I interpreted Tayss' phrase "much easier to
implement" as referring to something a little more absolute than whether the
person doing the implementing was much more comfortable with one syntax than
another. I might say it's much easier to implement higher-order functions
in Lisp than in C, for example, and I think I'd be talking about something
more than preference.
Anton
"Anton van Straaten" <·····@appsolutions.com> writes:
> Kent M Pitman wrote:
> > Syntax matters, or we wouldn't discuss it too much. So let's not make
> > light of it.
>
> Assuming this is in response to what I actually said, I didn't think I was
> making light of it. I wrote:
>
> > > It's hard to see how something could be "much easier" to implement in
> > > lisp-2, since lisp-1 can express any lisp-2 program, as long as any
> > > conflicting names are changed so as not to conflict.
>
> And I think that's true. I interpreted Tayss' phrase "much easier to
> implement" as referring to something a little more absolute than whether the
> person doing the implementing was much more comfortable with one syntax than
> another. I might say it's much easier to implement higher-order functions
> in Lisp than in C, for example, and I think I'd be talking about something
> more than preference.
You're making light again. (Not intentionally I'm sure. But it probably
means you're missing my point.)
I'm saying that for any given programmer, having to work in an unfamiliar
or annoying syntax makes something materially harder to implement. I
sometimes say of a programmer that in strange circumstances, they have to
"run interpreted" instead of "run compiled" in those circumstances, having
to consider and apply each aspect of the language semantics repeatedly at
each use rather than being able to just rattle it off.
To me, Lisp1 is not just a matter of syntax but a matter of landmines.
Every function call is a potential lie, a landmind waiting to bite me,
_whether or not it does_.
And that's material, at least to me. I'm not saying it is to everyone.
I'm just documenting a sense I have, as best I can, for the record...
A couple of asides:
I used to play Galaga (an arcade game) a lot, and someone once showed
me how to disable the bombs dropped by the aliens. It's laborious and
takes a long time to do, so mostly I didn't do it often. So here was
the problem: I could have learned to play this way, but at the cost of
losing my reflexes if the bombs ever came back. So I ended up dodging
the bombs that were not falling, just to keep my reflexes intact. And
as such, the game was, for me, nearly as hard to play without the bombs
as it was with the bombs. To someone who's mind's eye did not see the
bombs falling in predictable ways, my dodging around would have appeared
laughable and my complaining that the game was difficult nonsense.
I used to do a lot of "square dancing" too. Modern western square
dancing is a process of dynamically programming dancers by downloading
little program texts to them dynamically as they dance. For most people,
there are a tiny number of such programs (several dozen) but there are
levels of square dancing, and at the higher level there are not only
thousands of "calls" (usually "function invocations") but some of the
"calls" are modifiers that can be strung together to make the number of
possible invocations huge. Now, since each level of square dancing
subsumes the previous, you could claim that if the caller only calls
"low level" calls, the dancing should be easy. Certainly dancing at a
low level dance is easy. But if you're at a high level dance, the same
dance might be a lot harder, not because the calls are happened to be
hard but because at the hearing of each call, one must compare them to
the space of possible calls (which is much larger) and dismiss the
possibility in each case that a high level call _could have been_ called.
(People trying to speak in a non-native human language notice this, too,
that it's sometimes easy to speak in a known-to-be-limited vocabulary
in some specialized case, but it's much harder to understand that same
vocabulary if you have to worry at each word that a larger vocabulary
_might have been_ in play, and you have to each time assure you're using
the simple case.)
Back to Lisp1/Lisp2:
The problem for me with Scheme is that CL is not just an arbitrary
situation involving two namespaces that might be bound. (I speak in
terms of CL/Scheme, not Lisp1/Lisp2, because here we are talking not
just about the binding nature but the full set of binding operators
available, as well as a highly evolved set of style rules specific to
CL which might not exist in other Lisp2 situations). GOOD CL code
does not, as a matter of style, EVER override global function names to
become lexical function [with a few limited exceptions that I always
relegate to macros that use such overriding as cooperative information
control hidden as an implementation technique; ignore that case, since
one doesn't see it when reading code]. As a consequence, when I see a
function, I know what it means that the function space is _constant_.
When I see a function, it means what it means. Variables, by
contrast, are more wishy washy and I have to look around and say
"where did this come from".
I think Scheme people often don't see this and don't realize what is
lost to a CL'er when they go to Scheme. CL people are used to looking
at (f x) and knowing that it means either "F is known to me as a
global function name and therefore would not be lexically bound OR F
is not known to me as a global function name and therefore must be
lexically bound using FLET or LABELS." It does not _ever_ mean "F
might mean what I know it to mean globally or it might mean what it
has been overridden to mean locally". But in Scheme this is not so.
It is permissible both actually and stylistically to override a global
name in a lexical situation.
This means I must distrust the meaning of every reference to f in
(f x), which slows me down. I have in my mind done the thing which
I said I did not want to do in the game above--lost my reflexes against
this. I have learned to trust, at the compiled level, that (f x) means
the f I expect it to mean because of CL rules. But the cost to me
of having become efficient at being able to reel off code that does this
kind of trust is that walking through Lisp1 code, _even code that does
not use the trick_, is like walking through a minefield, always worrying
that you _might have_.
So the mental overhead cost of using Lisp1 is not evident by a mere
static analysis of the code text that you are looking at.
My goal here has not been to make the case that Lisp2 is better than
Lisp1 for all people, but to try as subjectively as possible to give
you the sense of what it "feels like" to me to be confronting the shift.
A subjective consequence is that the fact that (f x) looks the same in
both languages does not mean that it is equally easy to understand in
either language. The IDENTICAL (in both form and meaning) expression
may take me longer to both write and understand in Scheme than in Lisp
because upon the seeing of the expression, I feel the need to look
around for traps if I know I am under Lisp1 rules that I do not feel
the need to look around for in Lisp2.
[As I said, it is possible for Schemere to make the case that the
equivalent thing in reverse is that they like "just looking for LET"
(although they really have to look for DEFINE, LETREC, and others) to
find out if a variable is bound, and that it "adds complexity" to look
for FLET, LABELS, etc. As I said, I am aware of this argument, I just
don't buy it, because (a) I believe the list of things you look for is
statically learnable and then compiled in wetware and no longer
matters because the brain already accomodates enormous patterns just
to understand natural language, and understanding programs is trivial
by comparison and (b) the process of spreading an ambiguity [one
namespace into two] is not symmetric; it may require extra mental
bookkeeping to keep track of the two namespaces, but (1) I allege that
for those who get past the kicking and whining, it becomes automatic
and (2) once you've done the associated bookkeeping, there are
objectively fewer ambiguous situations in the Lisp2 case. What is
often attributed as "ambiguity" (not being sure whether (f x) refers
to function f or variable f) is actually "failure to learn the
language", not a material failure of the language to identify whether
one or the other of these references is in play at any given time.]
If there is an argument for preferring Lisp1, it is better made in
an asymmetric way -- not by denying what I've said above, but by
emphasizing another value that is perhaps not important to me but that
is important to others. For example:
- Mathematics has, for better or worse, not notated a funcall
operation, and people who do a lot of math are not used to
notating funcall. So for people who have slugged through the
pain of learning math with its Godawful myriad infixy syntaxes
including weird Greek letters and other such glyphs, use of
boldness, bracketing, position, and other information to convey
subtle semantics. In that light, it's hard for me to understand
why anyone likes Lisp/Scheme at all because it moves so far into
unfamiliar syntax, but perhaps the introduction of the extra
notation to make funcall explicit is painful.
I personally don't do mathy stuff like this and so the loss of
this capability doesn't affect me materially. I don't mind
notating funcall because, for example, it does not destroy the
beauty of the Y operator because I don't use the Y operator...
I'd rather know when data I'm given is being funcalled, just like
I'd rather know when HTML pages I'm given contain executable code.
Some people prefer to blur these things, at some measurable risk
in security. They may be happy with this "risk", and might prefer
to call it "power". That's ok with me, but it helps to show
the difference.
- One might make an argument that part of what Scheme is about is
punning and that what I personally shy from as "ambiguity" is
again "being deliberately evasive as to implementation". I think
somewhere in here is some of the power of "functional abstraction"
that Scheme goes after. I'm content to see this abstraction more
overtly notated in my code, but perhaps people who plan to use it
with more than a certain degree of frequency just get tired of
doing it. For example, you can get a door that always locks behind
you when you close it, and for some people that's really handy because
they may go away and leave it often and like knowing it's locked, while
for others who are mostly present at the building going in and out,
the constant need to pull uot a key is frustrating. This is a purely
statistical argument, but I'm sure is of no small importance to
locksmiths. Perhaps locksmiths argue endlessly over whether
self-locking doors are better than manually-locking ones. I _hope_
they don't. I hope they just cheerfully manufacture both kinds and
leave it to me, the end user, to sort out.
(It's unfortunate that no unified architecture exists for Lisp/Scheme;
I tried doing this and had to table the project before I got far
enough to show usable progress. The remnants of my struggle ended
up in http://www.nhplace.com/kent/Half-Baked/
for brave people to peruse... I mentioned this a while back and some
people visited but no one told me if it was a worthwhile
experience to offer half-finished junk, so I'm leary about mentioning
it again, but ... nothing ventured, nothing gained...)
From: Barry Margolin
Subject: Re: Looking for examples of lisp-2's expressiveness
Date:
Message-ID: <ENRXa.20$Mg5.16@news.level3.com>
In article <···············@shell01.TheWorld.com>,
Kent M Pitman <······@world.std.com> wrote:
>I'm saying that for any given programmer, having to work in an unfamiliar
>or annoying syntax makes something materially harder to implement. I
>sometimes say of a programmer that in strange circumstances, they have to
>"run interpreted" instead of "run compiled" in those circumstances, having
>to consider and apply each aspect of the language semantics repeatedly at
>each use rather than being able to just rattle it off.
>
>To me, Lisp1 is not just a matter of syntax but a matter of landmines.
>Every function call is a potential lie, a landmind waiting to bite me,
>_whether or not it does_.
>
>And that's material, at least to me. I'm not saying it is to everyone.
>I'm just documenting a sense I have, as best I can, for the record...
This is likely to be true about just about any aspect of programming, from
the choice of language all the way down to details of particular dialects
or implementations. It's hard to say that any one choice is objectively
"better" or "much easier" -- people naturally find familiar things easier.
In some cases the details may be purely arbitrary, analogous to whether you
drive on the left or right side of the road. In other cases, as in the
Lisp1/Lisp2 debate, the proponents of each style may be able to provide
justifications for their preferences. But since both sides usually have
good points, the choice ends up being a trade-off. Programmers then get
used to the language they use, and learn to adapt their programming style
to fit it best.
So to a CL programmer, variable names like "lst" look clunky; they're
likely to ridicule Scheme because it makes programmers choose silly names
like that. But to Scheme programmers, it's just an idiom that they've
adopted; I imagine they use the abbreviation even when it's not needed to
avoid name clashes (e.g. "foo-lst" rather than "foo-list"). Conversely,
Scheme programmers find CL's FUNCALL and #' to be annoying, although CL
programmers can generally defend them.
So it mostly comes down to taste, and tastes are shaped by experiences.
--
Barry Margolin, ··············@level3.com
Level(3), Woburn, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
Kent M Pitman wrote:
> In that light, it's hard for me to understand
> why anyone likes Lisp/Scheme at all because it moves so far into
> unfamiliar syntax, but perhaps the introduction of the extra
> notation to make funcall explicit is painful.
It is an interesting discussion. I often have thougt that an explicit
funcall mechanism as in CommonLisp could help to document one's Scheme
code.
I have been using Schme for more than a year now; with the emphasize
that my code was more or less imperative. But now I often try to get
used to a Scheme programming which relies on some basic functional
programming principles, for example first class functions, and there
funcall would really often help for the sake of code reuse.
I hope I am not speculating but as far as I can remember my beloved
Clean does not make a separation between name spaces too. There is also
no explicit funcall mechanism or marker. I mention that because Clean is
a product of newer days and the inventors had surely a good clue.
S. Gonzi
Siegfried Gonzi <···············@kfunigraz.ac.at> wrote:
+---------------
| It is an interesting discussion. I often have thougt that an explicit
| funcall mechanism as in CommonLisp could help to document one's
| Scheme code.
+---------------
Well, if that's what you really want, it's easy enough to do in Scheme:
> (define (funcall f . rest)
(apply f rest))
> (funcall + 3 4 5)
12
>
;-} ;-}
-Rob
-----
Rob Warnock, PP-ASEL-IA <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
Kent M Pitman wrote:
> "Anton van Straaten" <·····@appsolutions.com> writes:
> > > > It's hard to see how something could be "much easier" to
> > > > implement in lisp-2, since lisp-1 can express any lisp-2
> > > > program, as long as any conflicting names are changed
> > > > so as not to conflict.
> >
> > And I think that's true. I interpreted Tayss' phrase "much easier to
> > implement" as referring to something a little more absolute than whether
> > the person doing the implementing was much more comfortable with one
> > syntax than another. I might say it's much easier to implement
higher-order
> > functions in Lisp than in C, for example, and I think I'd be talking
about
> > something more than preference.
>
> You're making light again. (Not intentionally I'm sure. But it probably
> means you're missing my point.)
>
> I'm saying that for any given programmer, having to work in an unfamiliar
> or annoying syntax makes something materially harder to implement.
I agree with that last statement. I don't think I'm missing your point
(because I agree with it). But perhaps you're missing mine, or the logic
behind it. My original quote above *assumed* what you're saying, and
assumed that this was trivial, obvious, and well-known. So when I wrote
about about something being "much easier to implement", I assumed that Tayss
was talking about something other than subjective familiarity and
preference, and I was talking about something other than that myself. My
original statement should be interpreted as being preceded by "factoring out
subjective familiarity and preference, ..." I'm sorry for any confusion
caused by omitting that.
Perhaps my assumptions were incorrect, though, and Tayss was in fact looking
for a code snippet to demonstrate how a Lisp-2 programmer's preferences and
unfamiliarity with Lisp-1 can make things much harder to implement in
Lisp-1. If that were the case, though, code snippets would be a poor way to
demonstrate this, since the issue is subjective. At best, snippets could be
used as an aid in being able to point out specific ways in which a Lisp-2
programmer might find the Lisp-1 snippet more difficult to implement.
However, even that is likely to be of limited value in this case, since the
difficulty here is manifested when designing code, and choosing and using
names - not in examining code for which unique names have already been
chosen. After all, ignoring unrelated differences, a Lisp-1 program with
uniquely chosen names can be a valid Lisp-2 program, so should not present
any particular difficulties to a Lisp-2 reader.
Finally, Tayss indicated that the code snippet he was searching for was
rare: "I've been trying to search for it to no avail." If he was looking
for something merely to demonstrate subjective preferences and familiarity,
almost any code snippets would do. It is therefore reasonable to assume
that Tayss was looking for a code snippet that demonstrated something other
than subjective preferences and familiarity.
My response was intended to indicate that I felt it unlikely that such a
code snippet existed, for the reasons already described.
Anton
From: ··········@YahooGroups.Com
Subject: Re: Looking for examples of lisp-2's expressiveness
Date:
Message-ID: <REM-2003aug11-004@Yahoo.Com>
{{Date: 05 Aug 2003 12:38:23 -0400
From: Kent M Pitman <······@world.std.com>}}
Before I start the details of my reply, let me say generally: You've
written some fine stuff in this newsgroup, but this message you wrote
here is especially good!
{{To me, Lisp1 is not just a matter of syntax but a matter of
landmines. Every function call is a potential lie, a landmind waiting
to bite me, _whether or not it does_.}}
Indeed, if the implementation allows the rebinding of any symbol which
is the name of any function you might want to call. By comparison, in
lisp2, function names are hardly ever rebound, and variables are almost
always either global (with asterisks to warn you) or lexical (not a
problem because binding and all references are close to each other so
you can SEE what's going on).
{{there are levels of square dancing, and at the higher level there are
not only thousands of "calls" (usually "function invocations") but
some of the "calls" are modifiers that can be strung together to make
the number of possible invocations huge. Now, since each level of
square dancing subsumes the previous, you could claim that if the
caller only calls "low level" calls, the dancing should be easy.
Certainly dancing at a low level dance is easy. But if you're at a
high level dance, the same dance might be a lot harder, not because
the calls are happened to be hard but because at the hearing of each
call, one must compare them to the space of possible calls (which is
much larger) and dismiss the possibility in each case that a high
level call _could have been_ called.}}
Great metaphor!! This is an instance of a general theory of learning
that I realized when I was using the flashcard program I invented to
teach my pre-school children how to read and spell. Initially they had
only two words to learn, then three, etc. At first it might be easy for
them to just guess which of those very few words they were seeing on
the screen. But after they had learned to read hundreds of words, those
same old words coming back for re-testing were harder because so many
words were in memory space that guessing was impossible and actual
decoding was absolutely necessary. So the total amount of learning
acquired by the student by learning n words is not a linear function of
n, but something that grows faster. (The general theory is of course
that the more different things there are in memory, the more difficult
it is to remember any one of them.)
{{GOOD CL code does not, as a matter of style, EVER override global
function names to become lexical function [with a few limited
exceptions that I always relegate to macros ... one doesn't see it
when reading code].}}
Indeed, I can't think of any good reason to do it, so I'd be curious to
see one of your nasty macros.
{{When I see a function, it means what it means.}}
It means what it usually means, what it's defined to mean by the manual
or specification or online help etc. Yes. Without that assurance, how
can anybody write LISP software without going bonkers??
Regarding a function defined globally which is *also* lambda-bound in
lisp1: {{walking through Lisp1 code, _even code that does not use the
trick_, is like walking through a minefield, always worrying that you
_might have_.}}
Indeed, as soon as you've burned once by some programmer doing that in
code you're trying to study, you know it *can* happen, and you have to
be paranoid forever after when looking at lisp1 code. So why do
lisp1/scheme programmers do that horrible thing in the first place? Do
they have a good reason, or is just that the implementation doesn't
warn about doing it, so they do it by accident and get in the habit of
doing it?
{{The IDENTICAL (in both form and meaning) expression may take me
longer to both write and understand in Scheme than in Lisp because
upon the seeing of the expression, I feel the need to look around for
traps if I know I am under Lisp1 rules that I do not feel the need to
look around for in Lisp2.}}
Indeed. Given that the main reason for LISP in the first place is ease
of rapidly developing elaborate software to do amazing things, this
slowdown when using lisp1 is a killer, a pretty good reason never to
use that form of lisp, at least not when rebinding function definitions
and thereby masking global definitions is allowed by the
implementation.
One question: Is this rebinding done lexically (so all tainted
references to that function name are within the lexical context of
where it was rebound), or special (so the landmine could go off
anywhere whatsoever within the dynamic context of such rebinding, even
in an entirely different source file which was compiled months ago and
was believed to be working and suddenly it doesn't work now; It's not
just that you're afraid to call a function because you don't know
whether the global or rebound definition will actually be used, but
you're afraid to ever bind a variable because you might call some
function that uses that variable name as a function name and will stop
working if you rebind it)?
{{Mathematics has, for better or worse, not notated a funcall
operation, and people who do a lot of math are not used to notating
funcall.}}
Actually when I was a math major in college I hated several aspects of
functional notation, especially when parentheses were removed because
the functions in question took only one argument each, and especially
when the function symbols were effectively lambda-bound via FOR ALL or
THERE EXISTS, and especially when "multiplication" of functions was
function composition right-to-left to match the sloppy parentheses-free
notation. So I invented my own notation for feeding an argument to a
function of one argument, a backwards-epsilon infix-operator which
means feed the argument on the left to the function on the right, and
my own notation for function composition, a little circle centered in
the line, again infix. I'll denote them {ep} and {o} below.
Accordingly, instead of having h = gf defined as h(x) = g(f(x)), with
the pun hx = gfx, I had h = f {o} g defined as x {ep} (f {o} g) =
(x {ep} f) {ep} g. So I suppose if I had known about LISP back then, I
would have clearly preferred explicit FUNCALL rather than puns where I
have constantly guess what was really meant and figure out whether
other interpretations of the pun were valid or not in each case.
{{I'd rather know when data I'm given is being funcalled}}
I would too, and just now it occurred to me that not knowing when data
is being executed is the fundamental reason why e-mail viruses are so
much trouble. (Likewise I hate javascript being enabled by default in
the major Web browsers, and I hate Web services that require javascript
to do things that used to be done by submitting a form to the server,
such as virtually all services of Yahoo! Mail nowadays).
Regarding doors that lock behind me: I hate them, because it's so easy
to leave the keys locked inside. I always use the deadbolt, which must
be locked with the key from the outside, instead of the door handle, on
my apartment. I always lock my car door from the outside, so I know the
key isn't still inside. I hate the trunk of my car which is
self-locking, because I have to take special care to make sure my keys
don't fall inside just as it's slamming shut.
Somebody suggested declaring system function names constant, so they
couldn't be rebound or redefined by user code. I like that idea and
plan to elaborate on that idea if that article is still in my queue to
reply to after I finish here. I wonder if that fix would solve the
landmine problem in lisp1? Kent, would that restriction break any of
your nasty macros in a way you can't program around?
{{http://www.nhplace.com/kent/Half-Baked/
SPIEL}}
Instead of trying to make a unified LISP environment which somehow
supports both lisp1 and lisp2, how about the alternative idea of
getting remote procedure calls really working usably? On a single
machine with a virtual address space and system calls to map shared
pages, when you want to publish a large block of data from one
implementation of lisp and subscribe to it from the other, the first
one can repack all the parts of the data into contiguous pages, where
the first byte is where the handle attaches, and then map that block to
the other implementation which makes up a handle to the first byte as
soon as it has the mapped pages. If the two implementations use the
same represention of data, you're done, else the second implementation
uses something like Pascal records foreign-data-structure access. Over
the net, of course there's no big efficiency gain in packing the raw
data into contiguous memory, so you might as well write to an I/O
buffer in some standard communication format, probably s-expressions
rather than XML/.NET of course unless you really want the MicroSoft
albatross forcing you to re-code for a new version of the protocol
twice a year and not even being able to learn what exactly the protocol
was until after it's already obsolete.
Robert Maas wrote:
> Regarding a function defined globally which is *also* lambda-bound in
> lisp1: {{walking through Lisp1 code, _even code that does not use the
> trick_, is like walking through a minefield, always worrying that you
> _might have_.}}
>
> Indeed, as soon as you've burned once by some programmer doing that in
> code you're trying to study, you know it *can* happen, and you have to
> be paranoid forever after when looking at lisp1 code. So why do
> lisp1/scheme programmers do that horrible thing in the first place?
I'm not aware that they do do it, except in special circumstances. I've
always considered that what Kent wrote about CL applies equally to Scheme:
"GOOD CL code does not, as a matter of style, EVER override global
function names to become lexical function [with a few limited
exceptions...]."
> Do they have a good reason, or is just that the implementation doesn't
> warn about doing it, so they do it by accident and get in the habit of
> doing it?
It's certainly not a habit, as far as I've ever seen. I've never seen code
that makes use of this without good reason. Example below.
> {{When I see a function, it means what it means.}}
>
> It means what it usually means, what it's defined to mean by the manual
> or specification or online help etc. Yes. Without that assurance, how
> can anybody write LISP software without going bonkers??
Simply by following good practices, as Kent suggests. If you can't redefine
functions, it rules out all sorts of useful possibilities for "language
building". Good taste and style dicates that redefining standard functions
should be done in such a way so as not to break code or create surprising
behavior. An example of a Scheme program that does a fair amount of this,
and does it well, is Swindle, which redefines quite a few basic operations
in order to provide a number of extensions, including CLOS-like
functionality. If Scheme couldn't do this kind of thing, I wouldn't be
using it. It's precisely its language-building capabilities which I find
most powerful. This, of course, goes to the question of the different goals
for CL & Scheme.
> Indeed, as soon as you've burned once by some programmer doing that in
> code you're trying to study, you know it *can* happen, and you have to
> be paranoid forever after when looking at lisp1 code.
I'll be sure to let everyone know when that happens to me. I'd also point
out that you don't, in fact, "have to be paranoid forever after". That's
your choice. Seems to me there's a fair amount of living in self-imposed
fear going on here.
> One question: Is this rebinding done lexically (so all tainted
> references to that function name are within the lexical context of
> where it was rebound), or special (so the landmine could go off
> anywhere whatsoever within the dynamic context of such rebinding, even
> in an entirely different source file which was compiled months ago and
> was believed to be working and suddenly it doesn't work now; It's not
> just that you're afraid to call a function because you don't know
> whether the global or rebound definition will actually be used, but
> you're afraid to ever bind a variable because you might call some
> function that uses that variable name as a function name and will stop
> working if you rebind it)?
You can lexically shadow a global variable, including one which is bound to
a function. Global redefinition of built-in procedures via set! is
implementation dependent, i.e. an implementation can choose to allow it,
prevent it, control it, etc. Some full-features implementations of Scheme,
like PLT, provide powerful capabilities via its module system to declare
which functions are being provided to clients, and allows "custom languages"
to be defined this way. It's an incredibly powerful mechanism, and provides
excellent security capabilities, because it allows features to be omitted
from custom languages, as well as included.
> Indeed. Given that the main reason for LISP in the first place is ease
> of rapidly developing elaborate software to do amazing things, this
> slowdown when using lisp1 is a killer, a pretty good reason never to
> use that form of lisp, at least not when rebinding function definitions
> and thereby masking global definitions is allowed by the
> implementation.
You seem to be speculating on this slowdown, since your question above
indicated you weren't even sure how Lisp1 works in this respect. Rejecting
the possibilities involved, out of what I would argue is ultimately a
misapprehension, and without being familiar with those possibilities and
their benefits, seems short-sighted.
You prefer Lisp2, I get that. At the very least, everyone here is
comfortable with Lisp2. But do you have to trash Lisp1 in order to justify
your choice? If that is, in fact, your reason for preferring Lisp2, then if
it turns out - when you learn more - that Lisp1 is not actually as bad as
you think, it would call into question your choice of Lisp2! I hope you are
capable of withstanding the resulting existential crisis...
Anton
"Anton van Straaten" <·····@appsolutions.com> writes:
> I'm not aware that they do do it, except in special circumstances. I've
> always considered that what Kent wrote about CL applies equally to Scheme:
>
> "GOOD CL code does not, as a matter of style, EVER override global
> function names to become lexical function [with a few limited
> exceptions...]."
But in Scheme you don't get anything in exchange for this.
In CL, when you see (f g) in a piece of strange code, the first half of which
is scrolled off the screen, you still know that G is a local variable and F
is a global function name. That is, the local notation teaches you about
the global arrangement. In Scheme, you can't tell by looking whether F or G
or both or neither is a lexical or global variable unless you already know
or unless you scroll back to see the full set of bindings presently active.
In article <···············@shell01.TheWorld.com>,
Kent M Pitman <······@world.std.com> wrote:
> "Anton van Straaten" <·····@appsolutions.com> writes:
>
> > I'm not aware that they do do it, except in special circumstances. I've
> > always considered that what Kent wrote about CL applies equally to Scheme:
> >
> > "GOOD CL code does not, as a matter of style, EVER override global
> > function names to become lexical function [with a few limited
> > exceptions...]."
>
> But in Scheme you don't get anything in exchange for this.
>
> In CL, when you see (f g) in a piece of strange code, the first half of which
> is scrolled off the screen, you still know that G is a local variable and F
> is a global function name. That is, the local notation teaches you about
> the global arrangement. In Scheme, you can't tell by looking whether F or G
> or both or neither is a lexical or global variable unless you already know
> or unless you scroll back to see the full set of bindings presently active.
I guess they probably solve this by convention.
So for example, I would guess that code that includes an form (f g) is
either example code that illustrates something - then it is probably not
a very large piece of code. Or otherwise, both f and g are most probably
local definitions because one shouldn't give such short and meaningless
names to global definitions. (BTW in CL, I would suspect f to be a local
function as well.)
For example, you could also argue that the naming convention for
dynamically scoped variables in CL is too weak because is it just only a
convention. I have actually gotten a remark along these lines in a
review for my paper on dynamically scoped functions. However, noone in
the CL community would take such a comment seriously. The same probably
also holds for the Scheme community with regard to other naming
conventions.
I don't know any programming language that doesn't rely on naming
conventions to a certain extent.
Pascal
Pascal Costanza <········@web.de> writes:
> In article <···············@shell01.TheWorld.com>,
> Kent M Pitman <······@world.std.com> wrote:
>
> > But in Scheme you don't get anything in exchange for this.
> >
> > In CL, when you see (f g) in a piece of strange code, the first
> > half of which is scrolled off the screen, you still know that G is
> > a local variable and F is a global function name. That is, the
> > local notation teaches you about the global arrangement. In
> > Scheme, you can't tell by looking whether F or G or both or
> > neither is a lexical or global variable unless you already know or
> > unless you scroll back to see the full set of bindings presently
> > active.
>
> I guess they probably solve this by convention.
>
> So for example, I would guess that code that includes an form (f g)
> is either example code that illustrates something - then it is
> probably not a very large piece of code. Or otherwise, both f and g
> are most probably local definitions because one shouldn't give such
> short and meaningless names to global definitions. (BTW in CL, I
> would suspect f to be a local function as well.)
I see your point, but it doesn't generalize to all names. Some people
(certainly I am among them) routinely make parameter names that are
as descriptive as global function names, such that
(make-new-widget widget-template)
means use the global function MAKE-NEW-WIDGET on the local var
WIDGET-TEMPLATE in CL, while in Scheme there's no telling what these
two references mean because the entire purpose of the Lisp1 syntax is
to make that programming element flexible. That's not an accident,
it's the reason for the language feature. IMO, you can't both say you
want that power (which is a legitimate power to want) and also say
that no ill comes of it (since there are legitimate drawbacks).
> For example, you could also argue that the naming convention for
> dynamically scoped variables in CL is too weak because is it just
> only a convention.
Yes, although offhand I can think of only two stylistic reasons it is
ever violated:
- legacy code (which was very important at one time, but which mostly
may have been translated by now; if this were the only reason, I might
say we should just restrict users to always using *'s).
- "custom interpreters"; that is, the ability to do
(let ((my-vars '(x y z)) (my-vals '(1 2 3)))
(progv my-vars my-vals (eval some-form)))
I think it's common here to want to supply expressions that are *-free.
Hmmm. If we had global lexicals primitively, I might say that PROGV
should set up an initial lexical rather than initial special environment,
but because of the vagueries of the ambiguous CL notation in this area,
specials are able to more or less pass as lexicals (except for closures,
but users know--or learn--to work around that), and so I think the
reason that users want to not have *'s here is that they are really
'thinking lexical' not 'thinking special'. This is also why I think it's
wrong for CMU CL to force a special declaration when it sees undeclared
specials, especially those not containing *'s.
> I have actually gotten a remark along these lines
> in a review for my paper on dynamically scoped functions. However,
> noone in the CL community would take such a comment seriously.
If I think the speaker is commenting in earnest, I take their comments
seriously. I just don't, after reflection, agree with all of them.
> The same probably also holds for the Scheme community with regard to
> other naming conventions.
Well, my remarks are not a suggestion for a change to their notation;
rather, just a comment that the choice is double-edged, offering benefits
at some cost. Which, incidentally, is something I say about nearly all
choices--I don't mean to single this one out. Rather, I mean to say that
in spite of rhetoric which sometimes seems to suggest that Lisp1 somehow
escapes the ordinary conservation properties of the Universe [*], Lisp1 is
just like everything else--you get something in exchange for something.
[*] While at MIT studying Maxwell's equations (sometimes called the
"sweatshirt equations", since they appeared on lots of sweatshirts),
I recall the professor standing back at one point and observing that
really all this complication was probably just a manifestation of a
simpler principle, that is, that some quantity "U" is conserved, and
he wrote "U = 0" on the blackboard. But that doesn't really give you
a specific handle on the particular ways in which the stretching
occurs, so he went back to explaining the uglier formulae...
> I don't know any programming language that doesn't rely on naming
> conventions to a certain extent.
Surely. And this is consistent with what I was saying. People
routinely point to the negatives they see in Lisp2, so I haven't
repeated them. They come with positives, too, though, and I both like
those positives and don't mind the negatives. Lisp1 comes with
positives and negatives, where I happen to dislike the negatives and
not find the positives enough to offset that. The issues of like and
dislike are my subjective judgments. But the fact of the positives
and negatives are not, I think, subjective. Those things are truths
that exist, objectively, and it's up to the viewer to assign
goodness/badness to them in the context of their use. But that they
exist is necessary in order to make sure that U = 0 (i.e., Newton's
L
Third Law, as applied to language design) is not violated.
Kent M Pitman wrote:
> Pascal Costanza <········@web.de> writes:
> > I guess they probably solve this by convention.
> >
> > So for example, I would guess that code that includes an form (f g)
> > is either example code that illustrates something - then it is
> > probably not a very large piece of code. Or otherwise, both f and g
> > are most probably local definitions because one shouldn't give such
> > short and meaningless names to global definitions. (BTW in CL, I
> > would suspect f to be a local function as well.)
>
> I see your point, but it doesn't generalize to all names. Some people
> (certainly I am among them) routinely make parameter names that are
> as descriptive as global function names, such that
> (make-new-widget widget-template)
> means use the global function MAKE-NEW-WIDGET on the local var
> WIDGET-TEMPLATE in CL, while in Scheme there's no telling what these
> two references mean because the entire purpose of the Lisp1 syntax is
> to make that programming element flexible.
I think we can do better than "no telling". (make-new-widget
widget-template) implies the following: make-new-widget must refer to a
function, otherwise there's a bug in the code. True, it could be either
global or local, but as I understand it, the same is true of CL.
The issue you seem to be concerned about is that make-new-widget could in
fact be a local definition which shadows a global one, such that it's not
clear which is being invoked. I have never known this to be a concern in
practice, because of the style rules you've already raised. You apparently
have experienced such ambiguity, but a question which I have about that is
whether this might not simply have been due to operating in an experimental
environment, which seemed to have been trying to take punning where no pun
had gone before, per your own description.
Continuing the analysis, widget-template has similar potential to be either
global, local, or a local overriding a global. Again, isn't the same true
of CL? In addition, it could be a value of any type - we don't know without
further context. One of the types of values it could be is a function. In
CL, if this were the case, it would be annotated as such.
Now, you don't seem to be arguing that code should be written as
(make-new-widget (integer widget-template)) in the case where
widget-template is expected to contain an integer. Clearly, both CL and
Scheme programmers (and programmers in almost all languages, even
statically-typed ones) are able to deal with this sort of thing - we have
some idea of the types that our variables contain, even when we're not
staring at their definition or initialization. So we can apply the same
intuition to the type of widget-template, that we would to the type of any
argument to any function. We may know about widget-template's type from the
local procedure definition, or from the definition of make-new-widget.
There's no real difference here than in any other language, except as it
happens CL, which requires that function values used in operand position be
annotated with their type at the call site.
So it doesn't seem to be the case that Lisp1 function calls provide such
significantly reduced information ("no telling"), unless one assumes that
lexical overriding of global names is being abused. My understanding is
that one could still do a similar thing in CL (override a global name
lexically), so I'm confused as to the difference you're getting at. Could
you explain which information it is that's missing in Lisp1/Scheme, that's
somehow always present in CL, other than the type of function-valued
arguments?
> That's not an accident,
> it's the reason for the language feature. IMO, you can't both say you
> want that power (which is a legitimate power to want) and also say
> that no ill comes of it (since there are legitimate drawbacks).
True. One can, on the other hand, exaggerate the reality of the possible
drawbacks to quite a significant extent, apparently.
> > For example, you could also argue that the naming convention for
> > dynamically scoped variables in CL is too weak because is it just
> > only a convention.
>
> Yes, although offhand I can think of only two stylistic reasons it is
> ever violated:
So you concede that in CL, there are things which one should avoid doing for
stylistic reasons, because they're potentially confusing. Why can't you
extend that same concession to other dialects? Especially considering that
the style rule in question - not overriding global functions locally -
applies roughly equally in both dialects?
> > I don't know any programming language that doesn't rely on naming
> > conventions to a certain extent.
>
> Surely. And this is consistent with what I was saying. People
> routinely point to the negatives they see in Lisp2, so I haven't
> repeated them.
So this is all about affirmative action? Politics indeed.
Anton
"Anton van Straaten" <·····@appsolutions.com> writes:
> I think we can do better than "no telling". (make-new-widget
> widget-template) implies the following: make-new-widget must refer to a
> function, otherwise there's a bug in the code. True, it could be either
> global or local, but as I understand it, the same is true of CL.
Not really. The only sense in which it can be local just means "I put the
definition in the body of this function", but does not mean "I may have
passed you a different function". That is, there is no
(defun foo (&function bar)
... (bar ...) ...)
but only
(defun foo ()
(flet ((bar ...))
... (bar ...) ...))
and in many such cases you can directly rewrite this as
(defun bar () ...)
(defun foo () ...)
modulo additional arguments which may be received implicitly because
the FLET may use internal variables.
In this regard, it's as if there is a function BAR that is only used one
place, and one has syntactically moved that definition into FOO almost
as a matter of program bookkeeping, more than anything else.
(Yes, once in a while there are practial matters of argument conventions,
loop invariants and 'closure variables' and the like, that can get
simplified if you move one function into another, but personally I find
this extremely rare in my code, to the point where for me it is a non-issue.)
Although it's valid to do so, I consider it poor style to have two functions
use the same internal function name. That is, I wouldn't do
(defun foo1 ()
(flet ((bar ...))
...))
(defun foo2 ()
(flet ((bar ...))
...))
> The issue you seem to be concerned about is that make-new-widget could in
> fact be a local definition which shadows a global one, such that it's not
> clear which is being invoked. I have never known this to be a concern in
> practice, because of the style rules you've already raised. You apparently
> have experienced such ambiguity, but a question which I have about that is
> whether this might not simply have been due to operating in an experimental
> environment, which seemed to have been trying to take punning where no pun
> had gone before, per your own description.
You may not be experienced with the kind of software engineering that Scheme
was developed to do, but part of the original purpose of Scheme's syntax
was to allow you to change a program like:
(define (make-frob x)
(make-widget frob-template x))
and change it to
(define (make-frob make-widget x)
(make-widget frob-template x))
or, more likely, to:
(define setup-frob (make-widget)
(set! make-frob
(lambda (x) (make-widget frob-template x)))
..etc.)
That is, to allow you to parameterize what seemed to be constant
without rewriting your program. Unless I'm misremembering, that is
one of many things that Sussman wanted to be able to do with Scheme in
the original design, and it wouldn't surprise me if S&ICP has lessons
in doing precisely this, though I haven't recently looked. While it
may be uncommon, I don't know it to be bad style in modern Scheme.
My purpose here is also not to tell you what kinds of things you worry
about. You worry about what you worry about. My purpose here is to
assert that I've programmed Scheme for a living on more than one occasion
and to say "these are things _I_ worried about" and "these are reasons
_I_ found it quite uncomfortable to use this syntax".
You keep turning this into a slander of you and trying to defend yourself,
but I haven't said that. I have merely tried to articulate the reasons
for preferring Lisp2, which inevitably tells you what _I_ (not you)
find distasteful about it. I think you think I am exercising my predictive
powers to tell you what _you_ experience, but I am exercising my powers
of (admittedly ever-more-failing, but thought to be still-mostly-working)
memory...
> Continuing the analysis, widget-template has similar potential to be either
> global, local, or a local overriding a global. Again, isn't the same true
> of CL?
No. It would be *widget-template* if it were global in well-styled CL.
No well-styled code would ever use widget-template for a global special,
and we have no global lexicals. Consequently, there is no conflict.
> Now, you don't seem to be arguing that code should be written as
> (make-new-widget (integer widget-template)) in the case where
> widget-template is expected to contain an integer. Clearly, both CL and
> Scheme programmers (and programmers in almost all languages, even
> statically-typed ones) are able to deal with this sort of thing - we have
> some idea of the types that our variables contain, even when we're not
> staring at their definition or initialization. So we can apply the same
> intuition to the type of widget-template, that we would to the type of any
> argument to any function. We may know about widget-template's type from the
> local procedure definition, or from the definition of make-new-widget.
> There's no real difference here than in any other language, except as it
> happens CL, which requires that function values used in operand position be
> annotated with their type at the call site.
It's not teh type but the nature. YOu might be planning to pass
(lambda (&rest x) `(widget ,@x))
for make-widget for some nefarious debugging purpose. Or you might do
(defun multiply (x y &optional (* #'*))
(funcall * x y))
but if we had
(defun multiply (x y &optional &function (* #'*))
(* x y))
I would be misled into thinking * was the function * and not realizing
that (multiple 3 4 (lambda (x y) `(times ,x ,y))) would yield something
very different.
> So it doesn't seem to be the case that Lisp1 function calls provide such
> significantly reduced information ("no telling"), unless one assumes that
> lexical overriding of global names is being abused. My understanding is
> that one could still do a similar thing in CL (override a global name
> lexically), so I'm confused as to the difference you're getting at. Could
> you explain which information it is that's missing in Lisp1/Scheme, that's
> somehow always present in CL, other than the type of function-valued
> arguments?
>
> > That's not an accident,
> > it's the reason for the language feature. IMO, you can't both say you
> > want that power (which is a legitimate power to want) and also say
> > that no ill comes of it (since there are legitimate drawbacks).
>
> True. One can, on the other hand, exaggerate the reality of the possible
> drawbacks to quite a significant extent, apparently.
>
> > > For example, you could also argue that the naming convention for
> > > dynamically scoped variables in CL is too weak because is it just
> > > only a convention.
> >
> > Yes, although offhand I can think of only two stylistic reasons it is
> > ever violated:
>
> So you concede that in CL, there are things which one should avoid doing for
> stylistic reasons, because they're potentially confusing. Why can't you
> extend that same concession to other dialects? Especially considering that
> the style rule in question - not overriding global functions locally -
> applies roughly equally in both dialects?
Because that isn't the case.
The whole reason macro hygiene exists is to enable you to do just the
pun that you're saying you want to stylistically never do. If it was
really never going to happen, you wouldn't need hygienic macro
handling. The reason Scheme needs it (and CL doesn't) is that Scheme
is full of things where you have to say "this reference to CAR is from
this context but that reference to CAR is from that context" whereas
in CL such matters of separation are sorted out by symbol identity and
packages, and by namespace, the combined effects of which obviate the
need for special macro processing in order to get reliable expansions.
> > > I don't know any programming language that doesn't rely on naming
> > > conventions to a certain extent.
> >
> > Surely. And this is consistent with what I was saying. People
> > routinely point to the negatives they see in Lisp2, so I haven't
> > repeated them.
>
> So this is all about affirmative action? Politics indeed.
It's about being allowed to be safe from intrusion in my own home. I
don't call that "affirmative action". Let Lisp1 be wants to be in the
places that have elected it for their own use, but don't come to the
place that Lisp2 is the norm and tell me and otehrs there's no
difference between Lisp1 and Lisp2 that can't be handwaved away by a
trivial syntactic rewrite into Lisp1. I don't buy that. It's wrong
and it's passive aggressive. You said something I found offensive and
then find yourself wondering why I'm talking about this? I didn't
just leap up to talk about it. I responded to things you were already
saying.
Kent M Pitman <······@world.std.com> wrote:
+---------------
| Although it's valid to do so, I consider it poor style to have two
| functions use the same internal function name. That is, I wouldn't do
| (defun foo1 ()
| (flet ((bar ...))
| ...))
| (defun foo2 ()
| (flet ((bar ...))
| ...))
+---------------
Though, actually, there's one pattern in which I *do* re-use the same
internal function name a lot, and that's when the internal function
is some sort of recursive (especially tree-walking) function, though
to be sure in, that case it's a LABELS instead of an FLET. The name
that gets (re)used [by me, at least] is most commonly AUX [yes, an
unfortunate name I got used to using in Scheme long before I knew
about CL's &AUX, FWIW], so that I do tend to see this kind of thing
fairly often in my code:
(defun foo1 ()
(labels ((aux ...))
...))
(defun foo2 ()
(labels ((aux ...))
...))
The bodies of fooN generally set up some initial stuff, and then make
one call to AUX, returning whatever it returns.
Hmmm... Looking at some of my old Scheme code, I see that one of the
more common patterns was converting a call with spread arguments into
a call with a single list arg, in CL:
(defun foo (a b &rest rest)
(labels ((aux (list)
...))
(aux rest)))
Another common pattern involved the outer function initializing one
or more accumulators, which the inner then passed around to itself
(possibly along with other args), e.g., a function which takes a bunch
of arguments and separates them out into separate categories might
look like:
(defun foo (&rest rest)
(labels ((aux (remaining accum1 accum2)
...))
(aux rest '() '())))
[Yes, I now know that LOOP can handle many of these cases.]
-Rob
-----
Rob Warnock, PP-ASEL-IA <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
On Tue, Aug 12, 2003 at 08:00:45PM +0000, Anton van Straaten wrote:
> I think we can do better than "no telling". (make-new-widget
> widget-template) implies the following: make-new-widget must refer to a
> function, otherwise there's a bug in the code. True, it could be either
> global or local, but as I understand it, the same is true of CL.
>
> The issue you seem to be concerned about is that make-new-widget could in
> fact be a local definition which shadows a global one, such that it's not
> clear which is being invoked. I have never known this to be a concern in
> practice, because of the style rules you've already raised. You apparently
> have experienced such ambiguity, but a question which I have about that is
> whether this might not simply have been due to operating in an experimental
> environment, which seemed to have been trying to take punning where no pun
> had gone before, per your own description.
>
> Continuing the analysis, widget-template has similar potential to be either
> global, local, or a local overriding a global. Again, isn't the same true
> of CL? In addition, it could be a value of any type - we don't know without
> further context. One of the types of values it could be is a function. In
> CL, if this were the case, it would be annotated as such.
I think you are confused. Function values do not need to be annotated.
> Now, you don't seem to be arguing that code should be written as
> (make-new-widget (integer widget-template)) in the case where
> widget-template is expected to contain an integer. Clearly, both CL and
> Scheme programmers (and programmers in almost all languages, even
> statically-typed ones) are able to deal with this sort of thing - we have
> some idea of the types that our variables contain, even when we're not
> staring at their definition or initialization. So we can apply the same
> intuition to the type of widget-template, that we would to the type of any
> argument to any function. We may know about widget-template's type from the
> local procedure definition, or from the definition of make-new-widget.
> There's no real difference here than in any other language, except as it
> happens CL, which requires that function values used in operand position be
> annotated with their type at the call site.
Which is incorrect. Consider the following code:
(let ((fn (lambda (x) x)))
(funcall fn 1))
If function values had to be annotated in operand position, that would
be (funcall #'fn 1). But this is incorrect. Function values do not
have to be annotated, function names in the operand position do.
Ignoring other namespaces for the moment, Common Lisp works as follows:
There is a variable namespace and a function namespace. Names in either
namespace may be bound to values. As it happens, the consequences of
binding a non-function value to a name in the function namespace is
undefined.
In a given form (F G) the F is considered to be one of:
* a special operator or macro name
* a function name looked up in the function namespace
* a form beginning with LAMBDA
Notice that I said ``name'', not value. F is not evaluated. The
argument, G, is evaluated, and if it is a name, then there will be a
look-up in the variable namespace for that name.
Suppose the variable G is bound to a function value. If you want to
call that function, you cannot simply place the name G in the first
position of a form, because then it will be looked up in the function
namespace. Therefore, a function is provided which calls its first
argument with the remaining arguments. (FUNCALL G 1) looks up G in the
variable namespace, and gets its value which is a function in this case.
Suppose you want to access function value bound to a function name.
Normally, the only way to refer to the value bound to a function name is
by placing the name in the first position of a form, such as F in (F G).
Therefore, a special operator called FUNCTION is provided. FUNCTION
looks up its argument in the function namespace, and returns its value
(which should be a function value). Hence, (F (FUNCTION F)) looks up
the function F twice from the function namespace: first to get the value
and call it, and second to get the value and pass it.
As for a LAMBDA form, there are two ways of looking at it:
(1) It is a function designator, and therefore should be permitted in
the operator position of a form, and should be ``looked-up''
by the FUNCTION operator when in the operand position.
(2) It is a special form which simply returns a function value, and
therefore should have nothing to do with FUNCTION.
CL supports both viewpoints.
Advantages of namespace separation:
* Variable names don't conflict with function names.
You can have a variable named LIST and a function named LIST and they
will not conflict. The variable LIST can even hold the value of the
function named LIST:
(let ((list #'list))
(values (funcall list 1 2 3)
(list 1 2 3)))
- This leads to other advantages, in combination with other CL features,
such as a simpler macro system.
* Implementations may remove the dynamic type check of the value bound
to a name in the function namespace. In (F G), F is statically known
to be bound to a function, because users are not supposed to put non-
functions in the function namespace.
Disadvantages:
* It is more cumbersome to call functions which have been bound to names
in the variable namespace. This can be annoying when you program in
an extremely functional style.
--
; Matthew Danish <·······@andrew.cmu.edu>
; OpenPGP public key: C24B6010 on keyring.debian.org
; Signed or encrypted mail welcome.
; "There is no dark side of the moon really; matter of fact, it's all dark."
In article <···············@shell01.TheWorld.com>,
Kent M Pitman <······@world.std.com> wrote:
> > So for example, I would guess that code that includes an form (f g)
> > is either example code that illustrates something - then it is
> > probably not a very large piece of code. Or otherwise, both f and g
> > are most probably local definitions because one shouldn't give such
> > short and meaningless names to global definitions. (BTW in CL, I
> > would suspect f to be a local function as well.)
>
> I see your point, but it doesn't generalize to all names. Some people
> (certainly I am among them) routinely make parameter names that are
> as descriptive as global function names, such that
> (make-new-widget widget-template)
> means use the global function MAKE-NEW-WIDGET on the local var
> WIDGET-TEMPLATE in CL, while in Scheme there's no telling what these
> two references mean because the entire purpose of the Lisp1 syntax is
> to make that programming element flexible. That's not an accident,
> it's the reason for the language feature. IMO, you can't both say you
> want that power (which is a legitimate power to want) and also say
> that no ill comes of it (since there are legitimate drawbacks).
OK, I see your point. I also understand your distinction between
subjective choices and objective positives and negatives.
However, I remeber a face-to-face conversation with a Schemer in which I
have explained the potential drawbacks of Lisp-1, and his response was
that he has simply never experienced such problems in practice.
I know that this is only a vague anecdote. (For example, maybe I just
haven't explained the drawbacks well enough.)
However, couldn't it be that the objective drawbacks just don't happen
in practice?
Somehow, this discussion reminds me of static vs. dynamic typing
discussions: people who believe in static typing tend to emphasize the
worst case scenarios in which all kinds of horrendous type errors occur
at runtime. However, experienced users of dynamically-typed programming
languages just don't make these experiences. At least not to the extreme
amount the first group of people tries to make one believe.
I would be interested in your opinion whether you think that there is a
qualitative difference between the Lisp-1 vs Lisp-2 discussion and the
static vs dynamic typing discussion.
Pascal
Pascal Costanza <········@web.de> writes:
> However, couldn't it be that the objective drawbacks just don't happen
> in practice?
Surely one could develop personal programming styles to avoid them,
but I don't see how to avoid them in others' code without publishing
a style guide saying not to do this or that, and I know of no such
style guide.
It seems more likely that people don't "feel them", which is fine, but
is not quite the same thing in that it doesn't undo the fact that
others (e.g., me) do. I have worked in and with Scheme on a daily
basis at various times in my life, I'm not just speaking academically.
I just never dug myself out of that feeling and never liked it. But I
certainly don't allege that all Schemers feel it--whether or not it is
there.
I certainly agree that the issue of "having to remember two namespaces
at once in order to correctly understand the meaning of a symbol in
context" for CL is something that seems a problem objectively and is
often cited by Lisp1'ers, but that I don't think happens in practice
because of specific brain hardware that is good at this, and I cite
natural language's considerable use of the same context handling as
evidence that we don't mind it.
> Somehow, this discussion reminds me of static vs. dynamic typing
> discussions: people who believe in static typing tend to emphasize the
> worst case scenarios in which all kinds of horrendous type errors occur
> at runtime. However, experienced users of dynamically-typed programming
> languages just don't make these experiences. At least not to the extreme
> amount the first group of people tries to make one believe.
And, conversely, people who see all kinds of advantages with static typing
don't see why we who prefer dynamic typing would feel the stranglehold of
static typing so intensely. But you're right, that's another good example.
> I would be interested in your opinion whether you think that there is a
> qualitative difference between the Lisp-1 vs Lisp-2 discussion and the
> static vs dynamic typing discussion.
Surely differences might be drawn--obviously they are not the same
thing. An analogy is made by ignoring certain features and comparing
others, and certainly at the level of "finding a design point that can
usefully go either way", they seem proper analogs. All analogies break
down if pushed on too hard or taken for more than they are worth, but
I think certainly I'd expect the same kinds of confusions.
Both the Lisp2/Lisp1 discussion and the dynamic/static debates do have
parallels in that one (the right hand, or "conservative", of each pair
as I've listed them) are more often (in my personal experience) seen
as "obviously right" by their proponents because of some lack of
flexibility they offer, with the proponents of that position having a
harder time seeing the benefits of the other (left hand, "liberal")
position. [That is, in my experience I've seen more people who prefer
dynamic languages still understand and appreciate static languages
than I have seen static language people who seem to understand and
appreciate dynamic languages... but maybe that's just my impression.
In both cases, the sets of "values" to be satisified in the end user
are not agreed upon. This underscores again why I think of languages
as political parties.]
Kent M Pitman wrote:
> I just never dug myself out of that feeling and never liked it. But I
> certainly don't allege that all Schemers feel it--whether or not it is
> there.
I'm glad to hear you say that, since many of your other comments have
implied that you are describing something much more than your own
preference.
> I certainly agree that the issue of "having to remember two namespaces
> at once in order to correctly understand the meaning of a symbol in
> context" for CL is something that seems a problem objectively and is
> often cited by Lisp1'ers, but that I don't think happens in practice
> because of specific brain hardware that is good at this, and I cite
> natural language's considerable use of the same context handling as
> evidence that we don't mind it.
Happily, Schemers have specific brain hardware that allows them to deal with
the awesome, potentially mind-melting power that is Lisp1. It is a great
responsibility - but with it come great rewards!
Anton
Kent M Pitman <······@world.std.com> wrote in message news:<···············@shell01.TheWorld.com>...
> This underscores again why I think of languages
> as political parties.]
This statement triggered part of a night looking at the politics
behind lisp. Including your article on lambda as a political party,
as well as things like:
http://zurich.ai.mit.edu/pipermail/rrrs-authors/1988-February/000808.html
I suppose this should be frightening, but it's probably clear that
when the benevolent dictators of other languages I like leave,
politics will grow rife as well.
From: Joe Marshall
Subject: Re: Looking for examples of lisp-2's expressiveness
Date:
Message-ID: <adade0xq.fsf@ccs.neu.edu>
Kent M Pitman <······@world.std.com> writes:
> [*] While at MIT studying Maxwell's equations (sometimes called the
> "sweatshirt equations", since they appeared on lots of sweatshirts),
> I recall the professor standing back at one point and observing that
> really all this complication was probably just a manifestation of a
> simpler principle, that is, that some quantity "U" is conserved, and
> he wrote "U = 0" on the blackboard. But that doesn't really give you
> a specific handle on the particular ways in which the stretching
> occurs, so he went back to explaining the uglier formulae...
I seem to recall that it has to do with the boundary conditions of an
infinitessimal element of a vector field. If you set the derivative of
the div or curl or somethingorother to zero, you can derive gausses law
and stokes law etc.
In article <···············@shell01.TheWorld.com>,
Kent M Pitman <······@world.std.com> wrote:
> "Anton van Straaten" <·····@appsolutions.com> writes:
>
> > I'm not aware that they do do it, except in special circumstances. I've
> > always considered that what Kent wrote about CL applies equally to Scheme:
> >
> > "GOOD CL code does not, as a matter of style, EVER override global
> > function names to become lexical function [with a few limited
> > exceptions...]."
>
> But in Scheme you don't get anything in exchange for this.
>
> In CL, when you see (f g) in a piece of strange code, the first half of which
> is scrolled off the screen, you still know that G is a local variable and F
> is a global function name. That is, the local notation teaches you about
> the global arrangement. In Scheme, you can't tell by looking whether F or G
> or both or neither is a lexical or global variable unless you already know
> or unless you scroll back to see the full set of bindings presently active.
I guess they probably solve this by convention.
So for example, I would guess that code that includes an form (f g) is
either example code that illustrates something - then it is probably not
a very large piece of code. Or otherwise, both f and g are most probably
local definitions because one shouldn't give such short and meaningless
names to global definitions. (BTW in CL, I would suspect f to be a local
function as well.)
For example, you could also argue that the naming convention for
dynamically scoped variables in CL is too weak because is it just only a
convention. I have actually gotten a remark along these lines in a
review for my paper on dynamically scoped functions. However, noone in
the CL community would take such a comment seriously. The same probably
also holds for the Scheme community with regard to other naming
conventions.
I don't know any programming language that doesn't rely on naming
conventions to a certain extent.
Pascal
Kent M Pitman wrote:
> "Anton van Straaten" <·····@appsolutions.com> writes:
>
> > I'm not aware that they do do it, except in special circumstances. I've
> > always considered that what Kent wrote about CL applies equally to
Scheme:
> >
> > "GOOD CL code does not, as a matter of style, EVER override global
> > function names to become lexical function [with a few limited
> > exceptions...]."
>
> But in Scheme you don't get anything in exchange for this.
>
> In CL, when you see (f g) in a piece of strange code, the first half of
which
> is scrolled off the screen, you still know that G is a local variable and
F
> is a global function name. That is, the local notation teaches you about
> the global arrangement. In Scheme, you can't tell by looking whether F or
G
> or both or neither is a lexical or global variable unless you already know
> or unless you scroll back to see the full set of bindings presently
active.
How do you "know that G is a local variable", as opposed to a global
variable? Surely all that you know is that G is a variable, which may be
global, or may be local, or may be a local shadowing of a global?
It seems to me that all one's intuitions and capabilities for dealing with
variable names apply equally well to function names.
Also, as has been discussed elsewhere, you seem to be extrapolating to an
extreme something that I've only ever rarely seen done in real code, and
then only for obvious reasons, in short functions. I.e. "good Scheme code
does not, as a matter of style..." Add to that the matter of taste, which
is when one breaks the style rule for some presumably good reason - the
limited exceptions you mention - one does so in a tasteful way.
I wonder if some of your antipathy towards Lisp1 comes from having
experienced pathological uses of the anti-capabilities it offers, perhaps
with T. Anything powerful can be abused. Presumably you're not suggesting
that bad CL code which abuses powerful CL features cannot be written.
Anton
"Anton van Straaten" <·····@appsolutions.com> writes:
> How do you "know that G is a local variable", as opposed to a global
> variable? Surely all that you know is that G is a variable, which may be
> global, or may be local, or may be a local shadowing of a global?
There are no global lexicals, and global specials in well-styled code get
*'s around their name.
> Also, as has been discussed elsewhere, you seem to be extrapolating to an
> extreme something that I've only ever rarely seen done in real code, and
> then only for obvious reasons, in short functions. I.e. "good Scheme code
> does not, as a matter of style..." Add to that the matter of taste, which
> is when one breaks the style rule for some presumably good reason - the
> limited exceptions you mention - one does so in a tasteful way.
>
> I wonder if some of your antipathy towards Lisp1
I don't have any antipathy toward Lisp1, nor even Lisp1 users.
However, I have observed that many Lisp1 users express what I have
interpreted as a near deathwish for Lisp2 and often express
extraordinary surprise after-the-fact when I finally get them to
listen long enough to find that someone actually likes Lisp2. They
profess to have lived in a world where no one ever mentioned to them
that this might be a desirable state and so I routinely make a
practice of assuring there is adequate opportunity for them to find
this out to avoid the unpleasantries I have been subjected to by them
in the past. I quite assure you that if I had not felt someone else's
antipathy first, I would not be responding as I do.
> comes from having experienced pathological uses of the
> anti-capabilities it offers, perhaps with T.
Nope.
Incidentally, I've used Scheme48 and Pseudolisp in work since then.
Jonathan Rees and I have worked together and he prefers to program
in that. He is both an authority on Scheme and meticulous in his
programming practices.
> Anything powerful can be abused.
So can anything powerless. I guess we should conclude that "anything
can be abused." :) But I don't think that's it. If there's anything
that was abused that started this, it was me personally.
> Presumably you're not suggesting
> that bad CL code which abuses powerful CL features cannot be
> written.
No. I am not. I am not making assertions about bad code at all.
I am making assertions that are not intended to make anyone who uses
Lisp1 feel bad about it, but merely to inform those people why I
am not ignorant for preferring Lisp2.
From: Kenny Tilton
Subject: Re: Looking for examples of lisp-2's expressiveness
Date:
Message-ID: <3F2FA55B.1090909@nyc.rr.com>
Anton van Straaten wrote:
> "Tayss" wrote:
>
>>I remember someone (Pascal Costanza?) once mentioned a code snippet
>>that was much easier to implement in lisp-2 than in a hypothetical
>>lisp-1 CL. I've been trying to search for it to no avail. Does
>>anyone know any examples to think about?
>>
>>No flamewars please. I'm aware of the circumstances where lisp-1 is
>>more readable.
>
>
> It's hard to see how something could be "much easier" to implement in
> lisp-2, since lisp-1 can express any lisp-2 program, as long as any
> conflicting names are changed so as not to conflict.
Would you say the same thing about the famous nil qua false issue, since
(if this then that) can be expressed as--just guessing at the Scheme--
(if (null? this) that then)?:
http://www.alu.org/humor/large-programs.html
:)
--
kenny tilton
clinisys, inc
http://www.tilton-technology.com/
---------------------------------------------------------------
"Career highlights? I had two. I got an intentional walk from
Sandy Koufax and I got out of a rundown against the Mets."
-- Bob Uecker
Kenny Tilton wrote:
> > It's hard to see how something could be "much easier" to implement in
> > lisp-2, since lisp-1 can express any lisp-2 program, as long as any
> > conflicting names are changed so as not to conflict.
>
> Would you say the same thing about the famous nil qua false issue, since
> (if this then that) can be expressed as--just guessing at the Scheme--
> (if (null? this) that then)?:
>
> http://www.alu.org/humor/large-programs.html
>
> :)
Hmm, I thought we having an abstract discussion about the merits of Lisp-1
vs. Lisp-2, but you seem to have moved into the realm of concrete
implementations and onto another issue entirely.
Nevertheless, I would answer thusly:
If it can be considered easy to express operations on first-class functions
in CL, using FUNCALL and FUNCTION or #', then it can be considered at least
as easy to express tests of nil in Scheme, using null?.
Anton
From: Kenny Tilton
Subject: Re: Looking for examples of lisp-2's expressiveness
Date:
Message-ID: <3F2FB734.4010300@nyc.rr.com>
Anton van Straaten wrote:
> Kenny Tilton wrote:
>
>>>It's hard to see how something could be "much easier" to implement in
>>>lisp-2, since lisp-1 can express any lisp-2 program, as long as any
>>>conflicting names are changed so as not to conflict.
>>
>>Would you say the same thing about the famous nil qua false issue, since
>>(if this then that) can be expressed as--just guessing at the Scheme--
>>(if (null? this) that then)?:
>>
>> http://www.alu.org/humor/large-programs.html
>>
>>:)
>
>
> Hmm, I thought we having an abstract discussion about the merits of Lisp-1
> vs. Lisp-2, but you seem to have moved into the realm of concrete
> implementations and onto another issue entirely.
Just looking for an excuse to cite that bit. No really, the question is
"easier to implement". How can you say I started the concrete!?
>
> Nevertheless, I would answer thusly:
>
> If it can be considered easy to express operations on first-class functions
> in CL, using FUNCALL and FUNCTION or #', then it can be considered at least
> as easy to express tests of nil in Scheme, using null?.
Agreed, "as easy", as in "nowhere near". Look, you abstract guys need to
remember us humble application ditch-diggers have to use the shovels you
design. No more soup ladles, okay? yer talkin to a guy who will write a
macro so he can code:
(mkTask penalty-shot)
instead of:
(mkTask 'penalty-shot)
Ok, sorry for the lowbrow interruption, we now return you to your
regularly-scheduled Ivory Tower.
:)
--
kenny tilton
clinisys, inc
http://www.tilton-technology.com/
---------------------------------------------------------------
"Career highlights? I had two. I got an intentional walk from
Sandy Koufax and I got out of a rundown against the Mets."
-- Bob Uecker
Kenny Tilton wrote:
> Anton van Straaten wrote:
> > If it can be considered easy to express operations on first-class
functions
> > in CL, using FUNCALL and FUNCTION or #', then it can be considered at
least
> > as easy to express tests of nil in Scheme, using null?.
>
> Agreed, "as easy", as in "nowhere near". Look, you abstract guys need to
> remember us humble application ditch-diggers have to use the shovels you
> design. No more soup ladles, okay?
How did we get down this road, exactly? I have the feeling you're really
talking to someone other than me.
Anton
From: Kenny Tilton
Subject: Re: Looking for examples of lisp-2's expressiveness
Date:
Message-ID: <3F2FCA52.8020107@nyc.rr.com>
Anton van Straaten wrote:
> Kenny Tilton wrote:
>
>>Anton van Straaten wrote:
>>
>>>If it can be considered easy to express operations on first-class
>>
> functions
>
>>>in CL, using FUNCALL and FUNCTION or #', then it can be considered at
>>
> least
>
>>>as easy to express tests of nil in Scheme, using null?.
>>
>>Agreed, "as easy", as in "nowhere near". Look, you abstract guys need to
>>remember us humble application ditch-diggers have to use the shovels you
>>design. No more soup ladles, okay?
>
>
> How did we get down this road, exactly? I have the feeling you're really
> talking to someone other than me.
You actors are sosensitive. :) You wrote:
>
> It's hard to see how something could be "much easier" to implement in
> lisp-2, since lisp-1 can express any lisp-2 program, as long as any
> conflicting names are changed so as not to conflict.
I was trying to say, I like not worrying about conflicting names. And
while it might seem like a small thing, to me it is not. It is much
easier for me to write code when I do not have to think about that.
Perhaps because my style is to kinda just splat code out onto the screen
and see what sticks. And that is now nil vs false got dragged in. Small
thing? Not to me.
Then you wrote:
>
> Hmm, I thought we having an abstract discussion about the merits of Lisp-1
> vs. Lisp-2, but you seem to have moved into the realm of concrete
> implementations and onto another issue entirely.
Above I explained why I dragged in the nil/false thing. As for abstract
discussions, gee, am I the only one who keeps his eye on the OP during
long threads?
> I remember someone (Pascal Costanza?) once mentioned a code snippet
> that was much easier to implement in lisp-2 than in a hypothetical
> lisp-1 CL.
Mebbe I am off base, but if we ever unearth the Lost Code Snippet, what
makes me think the "much easier" will not be in the realm of the abstract?
Anyway, sorry for coming off as a heckler, I really thought I was on
topic. And yakking about this keeps me from having to wrestle the
Robocup trainer to the ground.
peace. out.
--
kenny tilton
clinisys, inc
http://www.tilton-technology.com/
---------------------------------------------------------------
"Career highlights? I had two. I got an intentional walk from
Sandy Koufax and I got out of a rundown against the Mets."
-- Bob Uecker
> > How did we get down this road, exactly? I have the feeling you're
really
> > talking to someone other than me.
>
> You actors are sosensitive. :)
Maybe 'dense' would be a better word. I honestly didn't know where you were
coming from, e.g. it didn't even remotely occur to me that you were getting
at anything like this:
> I was trying to say, I like not worrying about conflicting names. And
> while it might seem like a small thing, to me it is not. It is much
> easier for me to write code when I do not have to think about that.
> Perhaps because my style is to kinda just splat code out onto the
> screen and see what sticks.
I've addressed this in my response to Kent Pitman. I wasn't trying to claim
that all programmers would find it equally easy to implement either
approach, no matter what their current syntax preference and familiarity.
But Tayss was looking for code snippets to demonstrate the point. I don't
think, given pre-existing code snippets in both Lisp-1 and Lisp-2 style,
that it would be at all clear that one was "much easier to implement" than
the other. The only way that would be the case would be with some
assumptions about the programmer being asked to do the implementing. The
point that Tayss wanted to illustrate would not be illustrated by code
snippets.
> And that is now nil vs false got dragged in. Small thing? Not to me.
The original question talked about a "hypothetical lisp-1 CL", which would
presumably retain CL's nil semantics, so even with this drastic change, you
wouldn't have to worry about nil being de-falsified.
> As for abstract discussions, gee, am I the only one who keeps his eye on
> the OP during long threads?
I think I need to put my love of abstraction into the proper ditch-digging
context in which I use it. I design and code apps for a living, some fairly
complex financial services systems, using languages that you might shudder
to be in the same room with (starting with letters like 'J' and 'C').
Abstraction is an indispensable tool for making these applications
manageable. But you know that already, you use a cell abstraction which
you've implemented both with CLOS and with structure objects, demonstrating
the abstraction's nature as independent of any particular implementation.
As for the whole Ivory Tower thing, it's worth keeping in mind the kinds of
reasons McCarthy had for inventing Lisp, e.g. "a way of describing
computable functions much neater than the Turing machines or the general
recursive definitions used in recursive function theory. ... One
mathematical consideration that influenced LISP was to express programs as
applicative expressions built up from variables and constants using
functions. I considered it important to make these expressions obey the
usual mathematical laws allowing replacement of expressions by expressions
giving the same value."
Without that ivory-towerdom, you'd be programming in Perl today, but
probably a Perl without lexical scoping or garbage collection. Speaking for
myself, I like to keep an eye on those towers, on the off-chance they
produce something else useful.
Anton
From: Kenny Tilton
Subject: Re: Looking for examples of lisp-2's expressiveness
Date:
Message-ID: <3F2FEEA1.9060007@nyc.rr.com>
Anton van Straaten wrote:
Jackie Chan wrote:
>>And that is now nil vs false got dragged in. Small thing? Not to me.
>
>
> The original question talked about a "hypothetical lisp-1 CL", which would
> presumably retain CL's nil semantics, so even with this drastic change, you
> wouldn't have to worry about nil being de-falsified.
Right. That example was invoked at the level of "semantically
equivalent, syntactically non-equivalent things that look a lot worse."
That is, at a higher level of abstraction.
>
>
>>As for abstract discussions, gee, am I the only one who keeps his eye on
>>the OP during long threads?
>
>
> I think I need to put my love of abstraction into the proper ditch-digging
> context in which I use it. I design and code apps for a living, some fairly
> complex financial services systems,...
I better cut down on Ivory Tower cracks.
> As for the whole Ivory Tower thing, it's worth keeping in mind the kinds of
> reasons McCarthy had for inventing Lisp, <snip>
>
> Without that ivory-towerdom, you'd be programming in Perl today, but
> probably a Perl without lexical scoping or garbage collection. Speaking for
> myself, I like to keep an eye on those towers, on the off-chance they
> produce something else useful.
Ouch, invoking The Man Himself against me. This is gonna take some
bobbing and weaving.
OK, right, abstract roolz. I am not dissing the abstract, I am standing
up for not leaving the concrete out of the abstract debate. if an
abstract purification such as differentiating nil and false cocks things
up (I said "if", we don't need to beat that dead horse), then that is a
message from the gods of abstraction that the purification, as plausible
as it may seem, is in fact Wrong. I follow that rule myself when coding:
design changes must reduce the LOC, not grow it.
How's my footwork?
--
kenny tilton
clinisys, inc
http://www.tilton-technology.com/
---------------------------------------------------------------
"Career highlights? I had two. I got an intentional walk from
Sandy Koufax and I got out of a rundown against the Mets."
-- Bob Uecker
Kenny Tilton wrote:
> > As for the whole Ivory Tower thing, it's worth keeping in mind the kinds
of
> > reasons McCarthy had for inventing Lisp, <snip>
> >
> > Without that ivory-towerdom, you'd be programming in Perl today, but
> > probably a Perl without lexical scoping or garbage collection. Speaking
for
> > myself, I like to keep an eye on those towers, on the off-chance they
> > produce something else useful.
>
> Ouch, invoking The Man Himself against me. This is gonna take some
> bobbing and weaving.
>
> OK, right, abstract roolz. I am not dissing the abstract, I am standing
> up for not leaving the concrete out of the abstract debate.
My response related to abstraction came in part from the earlier
Dataflow/Animation/Laziness thread, where you last responded to me with
similar points about abstraction, ivory towers, and academia. I didn't get
around to responding to that, but thought I should address the issue, if I
am to be able to post messages in c.l.l. without being tarred and feathered
as an academic, for crimes against pragmatism. Monty Python would recognize
the logic here:
First C.L.L'er: We have found an academic. May we burn him?
Other C.L.L'ers: Burn him! Burn him! Burn him! Burn him! Burn him!
Bedevere: How do you know he is an academic?
First C.L.L'er: He defended Lisp-1!
Second C.L.L'er: He mentioned abstraction!
...etc...
> if an
> abstract purification such as differentiating nil and false cocks things
> up (I said "if", we don't need to beat that dead horse), then that is a
> message from the gods of abstraction that the purification, as plausible
> as it may seem, is in fact Wrong. I follow that rule myself when coding:
> design changes must reduce the LOC, not grow it.
I'll nibble at this: an alternative interpretation is that the purposes of
the language with the differentiated nil and false may be different than the
purposes of the language which conflates the two. For example, the purpose
of differentiating them may be to improve type discipline, which can make
for a better language from a functional programming perspective. Similarly,
one purpose for a single global namespace could also be to provide better
support for higher-order functions and first-class function values, also
with the goal of making a better functional language. Of course, not
everyone *wants* a better functional language, or a functional language at
all. But those who do want a better functional language understand and
accept the tradeoffs involved with that.
Making internal comparisons between a language which is being used
imperatively in practice, and a language with features designed to support
functional programming, is fairly meaningless. It's like comparing the
price of a McDonalds hamburger in Tennessee to the price in Thailand: if the
price in baht is a higher number than the price in dollars, does that mean
the hamburger is more expensive in Thailand? It would be naive to argue
that: you have to look at a broader context.
Aside from the question of relative price, taking the context into
consideration, you might find that you'd do better with Gaeng Keow Wan Gai
(green curry chicken) from a local restaurant, than a hamburger from a
foreign chain. But if you only like eating hamburger, you could reasonably
conclude that there's no point taking a culinary tour of Thailand.
Elsewhere in this thread are impassioned arguments for the importance of
one's preferences and familiarity with syntax, and by extension, with
languages. That works both ways: one's preferences may prevent one from
understanding the benefits to be had from alternative systems. A sure way
for this to happen is to compare micro-level features across languages and
conclude that the alternative is no good because the foreign micro-level
features don't work the way one is familiar with.
Anton
On Wed, Aug 06, 2003 at 02:57:16AM +0000, Anton van Straaten wrote:
> First C.L.L'er: We have found an academic. May we burn him?
> Other C.L.L'ers: Burn him! Burn him! Burn him! Burn him! Burn him!
> Bedevere: How do you know he is an academic?
> First C.L.L'er: He defended Lisp-1!
> Second C.L.L'er: He mentioned abstraction!
Third C.L.L'er: He captured me in a closure!
Bedevere: A closure?
Third C.L.L'er: I got returned...
--
; Matthew Danish <·······@andrew.cmu.edu>
; OpenPGP public key: C24B6010 on keyring.debian.org
; Signed or encrypted mail welcome.
; "There is no dark side of the moon really; matter of fact, it's all dark."
From: Kenny Tilton
Subject: Re: Looking for examples of lisp-2's expressiveness
Date:
Message-ID: <3F308E9E.8030603@nyc.rr.com>
Anton van Straaten wrote:
> Kenny Tilton wrote:
>>if an
>>abstract purification such as differentiating nil and false cocks things
>>up (I said "if", we don't need to beat that dead horse), then that is a
>>message from the gods of abstraction that the purification, as plausible
>>as it may seem, is in fact Wrong. I follow that rule myself when coding:
>>design changes must reduce the LOC, not grow it.
>
>
> I'll nibble at this: an alternative interpretation is that the purposes of
> the language with the differentiated nil and false may be different than the
> purposes of the language which conflates the two. For example, the purpose
> of differentiating them may be to improve type discipline, which can make
> for a better language from a functional programming perspective. Similarly,
> one purpose for a single global namespace could also be to provide better
> support for higher-order functions and first-class function values, also
> with the goal of making a better functional language. Of course, not
> everyone *wants* a better functional language, or a functional language at
> all. But those who do want a better functional language understand and
> accept the tradeoffs involved with that.
Maybe I am the abstractophile. I do not believe these choices are up to
us, I believe there are right answers that exist independent of the
artifacts erected atop them. An artifact that looks like hell arises
from conflating things which are different, or differentiating things
which are the same.
And if the distorting artifact, the choice to conflate or differentiate,
serves some higher goal such as a better functional language, then that
too is fundamentally Wrong.
Climbing down from Abstraction Peak, again, this is exactly what I watch
for when coding up some design idea. If i had been the designer of the
language that made a hash out of (cdr (assoc...)), I would have upon
noticing that concluded that nil and false were the same, even if I
could not make out how.
--
kenny tilton
clinisys, inc
http://www.tilton-technology.com/
---------------------------------------------------------------
"Career highlights? I had two. I got an intentional walk from
Sandy Koufax and I got out of a rundown against the Mets."
-- Bob Uecker
Kenny Tilton wrote:
> Maybe I am the abstractophile.
Finally, the truth emerges...
> I do not believe these choices are up to
> us, I believe there are right answers that exist independent of the
> artifacts erected atop them. An artifact that looks like hell arises
> from conflating things which are different, or differentiating things
> which are the same.
>
> And if the distorting artifact, the choice to conflate or differentiate,
> serves some higher goal such as a better functional language, then that
> too is fundamentally Wrong.
My broader point, which I perhaps didn't state as explicitly as I should
have, is that the higher goal presumably has benefits that outweigh some
other tradeoffs they might require. If that weren't the case, there'd be no
point. My Thailand culinary metaphor is still relevant here: you can't
measure the quality of food in Thailand using the McDonalds quality
inspector's checklist.
In addition, the perceived distortion may not even exist if things are done
in accordance with the philosophy of the system in which it's being
implemented. And/or, macro-level benefits may more than make up for
micro-level differences.
> Climbing down from Abstraction Peak, again, this is exactly what I watch
> for when coding up some design idea. If i had been the designer of the
> language that made a hash out of (cdr (assoc...)), I would have upon
> noticing that concluded that nil and false were the same, even if I
> could not make out how.
And you would have been wrong, because you would have been applying your
expectations from CL to a different language, and getting a meaningless
result, as I've said. Why would you be designing a language if your goal
were to duplicate CL?
To come to a meaningful conclusion, you'd also need to question whether e.g.
the type signature of assq makes sense, for example, or whether the program
being implemented makes sense. You might also look at the broader context
of programs in the language, their exception structure, and their handling
of type exceptions. Does assq handle exceptions in an appropriate way?
For example, (cdr (assq key a-list)) doesn't distinguish between keys that
exist but are associated with the value nil, and keys that don't exist.
Perhaps that's desired for the example in question, but it's not always the
case. It would be more meaningful to compare more substantial examples, and
see whether this alleged micro-level difference in fact still exists or is
compensated for in other ways, in more realistic programs.
If you were really set on having (cdr (assq key a-list)) work in the way
that your prior experience leads you to expect, all you'd have to do is to
have assq return a null pair, '(().()), on failure. Or, implement kenny-cdr
as (if (pair? x) (cdr x) '()), and write (kenny-cdr (assq key a-list)).
Either seems cleaner than conflating two distinct types for all programs and
all users of an entire language. If it doesn't seem cleaner to you, then
we're discussing preference, and your perceived 'distortion' is merely your
perspective.
The kenny-cdr solution, as unsatisfactory as it might seem to you,
nevertheless demonstrates an important point: by using appropriate
abstractions, often quite simple and small ones, you can get any behavior
you want, without impacting every other user of the language. That's why
scaling up these micro examples doesn't demonstrate a problem, because you'd
have to deliberately write poorly designed code to do so.
Finally, being unable to completely ignore the shortcomings of assq could be
considered a benefit. Consider the required Scheme wrapper as a "code
smell" indicating that something may be wrong. This perhaps goes to one of
the real issues here, which is that people tend to choose languages with a
level of discipline with which they're comfortable. Some languages with
rigorous statically-checked type systems can require a high degree of
discipline, too high for many people; other languages do "duck typing" and
convert values implicitly, sometimes giving unexpected results, which is too
weak for many people. There's a large and multi-dimensional spectrum in
between those two extremes.
All the poem really says is that the author is unhappy with a language which
has the discipline to point out that nil may not be an appropriate return
value for a function like assq. Which leads me to note that Scheme's assq
returns #f on failure, and the poem's use of (not (null? val)) is therefore
unnecessary and wrong.
Anton
Oops, I wrote:
> Which leads me to note that Scheme's assq
> returns #f on failure, and the poem's use of (not (null? val)) is
therefore
> unnecessary and wrong.
But of course, the poem was talking about an older dialect (T, apparently),
which seems to have been even stricter than modern Scheme, in that cond
didn't treat non-false values as true. My mouth is watering... ;)
Anton
From: Kenny Tilton
Subject: Re: Looking for examples of lisp-2's expressiveness
Date:
Message-ID: <3F30FED7.7060506@nyc.rr.com>
Pop quiz: If you call a tail a leg, how many legs has a horse?
(Answer below.)
Anton van Straaten wrote:
> Kenny Tilton wrote:
>
>>Maybe I am the abstractophile.
>
>
> Finally, the truth emerges...
Say it loud, say it proud!
>
>
>>I do not believe these choices are up to
>>us, I believe there are right answers that exist independent of the
>>artifacts erected atop them. An artifact that looks like hell arises
>>from conflating things which are different, or differentiating things
>>which are the same.
>>
>>And if the distorting artifact, the choice to conflate or differentiate,
>>serves some higher goal such as a better functional language, then that
>>too is fundamentally Wrong.
>
>
> My broader point, which I perhaps didn't state as explicitly as I should
> have, is that the higher goal presumably has benefits that outweigh some
> other tradeoffs they might require.
No, I totally got that. I am saying, "Ok, this crud satisfies Higher
Goal XYZ? Lose XYZ." No XYZ cannot justify crud, the crud exposes the
flaw in the XYZ intent.
I have tried to say a few different ways that over the decades I have
come to believe there are Absolute Right Answers for which we should
never stop looking. There is exactly one way to skin a cat.
Now that I can no longer tar you with the Ivory Tower thing, maybe my ad
homineum attacks can characterize you as a Lost In the Sixties,
permissive, anything-goes theoretical relativist!
Look, if you call a tail a leg, how many legs has a horse? Four. Calling
a tail a leg does not make it a leg.
If that weren't the case, there'd be no
> point. My Thailand culinary metaphor is still relevant here: you can't
> measure the quality of food in Thailand using the McDonalds quality
> inspector's checklist.
I am try to ignore this argument by analogy, but clearly this is about
relativism, diff-strokes-for-diff-folks,
you-say-potato-I-say-supersized-fries.
>
> In addition, the perceived distortion may not even exist if things are done
> in accordance with the philosophy of the system in which it's being
> implemented.
Hippy! Burn the hippy!
> And/or, macro-level benefits may more than make up for
> micro-level differences.
That is just laziness. I go through that every day. Faced with micro
crud in something macro wonderful like Cells (!), where Cells seem to be
demanding the crud, I step back and say, ok, what bonehead decision
makes this crud only /seem/ ineluctable. ie, I work out how to keep the
Cells but lose the crud.
You know, as soon as we rolled the most primitive example of Cells, we
knew it was wonderful. So I had to assume there was some Deep Fatal Flaw
which would appear soon enough. At which point living with Cells would
really be a huge aggravation and giveback of its apparent benefits. And
as much as I loved Cells, i was ready to ditch them if that happened.
I decided early on that Cells rooled because all the bumps which did
arise were easily resolved without losing the wonderfulness of Cells.
Usually cells became more powerful and simpler each time I got the hood up.
I'll give you philosophy. cartesian doubt. question everything. question
even the design metadecision to go all-xyz-all-the-time. never let a
past choice become an unquestioned absolute.
> And you would have been wrong, because you would have been applying your
> expectations from CL to a different language...
This may sound crazy, but no, I seriously believe that shorter is an
absolute measure of correctness. Forunately, even when I write something
that looks long, I can just sweep it under an unhygienic macro.
> To come to a meaningful conclusion, you'd also need to question whether e.g.
> the type signature of assq makes sense, for example, or whether the program
> being implemented makes sense. You might also look at the broader context
> of programs in the language, their exception structure, and their handling
> of type exceptions. Does assq handle exceptions in an appropriate way?
I am with you 100%, but I am a Buddhist, so I understand that my wants
and desires are the source of all my unhappiness. Look at these C++
gurus jumping up and down about dynamic languages and turning their
backs on strong static typing. They were admitted s.t.t bigots until
they found out it was not the Only Way. They knew all along that s.t.t.
was a royal pain in the ass, but they tolerated it for the higher
benefits (greater confidence in a program's correctness). Now they
discover test-driven development and kick s.t.t out of bed. It just
never occurred to them that there was another way to get correctness
without enduring s.t.t.
So watch out for those Higher Goals justifying crud. There must be a
better way, by my thinking. If not, again, lose that higher goal.
> If you were really set on having (cdr (assq key a-list)) work in the way
> that your prior experience leads you to expect, all you'd have to do is to
> have assq return a null pair, '(().()), on failure. Or, implement kenny-cdr...
Band-aid a bad design choice? A good programmer is measured by how they
react to bugs. Do they check to see if the bug is merely one
manifestation of some design flaw, or do they just make the one bug go
away?
You know my predilection for the abstract. I prefer questioning
underlying assumptions. Maybe it is my philosophy training. I'd make it
thru kenny-cdr and kenny-car and kenny-assq and then it would be
kenny-aw-fuck-it-i'm-going-back-to-cl.
>... without impacting every other user of the language.
There is One Right Answer. They need to be impacted.
:)
Meanwhile, god bless the Robocup designers for resolving the quandary of
whether to tokenize the ball with 'b or 'ball by using both, and by
sometimes encoding team names as "Yankees" and sometimes as 'Yankees.
Coming RSN: the release of RoboCells, a free (BSD?) Cells-based,
all-lisp-all-the-time starter RoboCup client for everyone's enjoyment.
--
kenny tilton
clinisys, inc
http://www.tilton-technology.com/
---------------------------------------------------------------
"Career highlights? I had two. I got an intentional walk from
Sandy Koufax and I got out of a rundown against the Mets."
-- Bob Uecker
> > My broader point, which I perhaps didn't state as explicitly as I should
> > have, is that the higher goal presumably has benefits that outweigh some
> > other tradeoffs they might require.
>
> No, I totally got that. I am saying, "Ok, this crud satisfies Higher
> Goal XYZ? Lose XYZ." No XYZ cannot justify crud, the crud exposes the
> flaw in the XYZ intent.
What if Goal XYZ results in a much shorter overall program, with all sorts
of other desirable properties? Besides, no real system is free of all
crud - more on this below.
> I have tried to say a few different ways that over the decades I have
> come to believe there are Absolute Right Answers for which we should
> never stop looking. There is exactly one way to skin a cat.
The problem with that is the same problem that religious fundamentalists run
into: once they think they've found the Absolute Right Answer, all thought
ceases, and questions must be stated within the prescribed framework, or be
dismissed as heresy. But you're aware of that, because you say:
> I'll give you philosophy. cartesian doubt. question everything. question
> even the design metadecision to go all-xyz-all-the-time. never let a
> past choice become an unquestioned absolute.
Fine, but this seems to contradict some of the other things you're saying.
Absolute Right Answers only exist within a context. Within some system -
like CL - there may very well be some things that can be considered Absolute
Right Answers. Although, the only ones we can be completely sure of are the
ones we can prove to be Right, or failing that, the ones we are unable to
disprove as being Right. But when you shift to another system, it is
utterly meaningless to apply the rules of a different system to the new
system. You might try to find a way to map rules from one system to
another, but that's fraught with dangers, some of which I have mentioned.
Other than Right Answers that can be proved or "all but proved", it's
impossible to measure Right Answers Absolutely. There are metrics one can
choose to apply, but they're fuzzy and subjective. To demonstrate this,
I'll pick one of your own examples: "shorter is an absolute measure of
correctness." I can show you plenty of examples of very concise programs
that are virtually incomprehensible, so this metric can't be taken to its
logical conclusion, it has to be applied with taste.
One application of "shorter is an absolute measure of correctness" would
immediately eliminate Lisp-2, since Lisp-2 programs are inevitably longer
than Lisp-1 programs, as I have shown in another post. You can deal with
this contradiction either by disclaiming Lisp-2 as incorrect, or
acknowledging that shorter is not an absolute measure of correctness.
> Now that I can no longer tar you with the Ivory Tower thing, maybe my ad
> homineum attacks can characterize you as a Lost In the Sixties,
> permissive, anything-goes theoretical relativist!
I believe in applying logic to our assumptions, and epistemologically,
trying to understand and be aware of the differences between degrees of
certainty of our knowledge. That leads to something approaching absolute
knowledge in some areas, something a bit less certain in other areas, and
utter relativism in some cases, because it involves honesty about what we
really do and don't know.
It's fine to believe you think you know some Absolute Right Answers, but if
you can't prove them, and someone else claims to have different, conflicting
Absolute Right Answers, and has equally strong evidence of that, then you're
kidding yourself about what you know. The other person might be right, or
you both might be right.
> Look, if you call a tail a leg, how many legs has a horse? Four. Calling
> a tail a leg does not make it a leg.
Good example! In a language which has no word for "leg", there might be a
word meaning something like "appendage", and depending on how that's
defined, a horse might have five of them. When talking to a native speaker
of that language, you need to be sure you're not incorrectly applying your
assumptions about how you've chosen to analyze the horse. Or, you might be
talking about a different planet, where the appendage found on a horse in
tail position :) is more like a leg than a tail. Now you have to start
getting into the definition of what a leg is, and mapping it onto a
different animal.
> I am try to ignore this argument by analogy, but clearly this is about
> relativism, diff-strokes-for-diff-folks,
> you-say-potato-I-say-supersized-fries.
Definitely not. Rather, I'm saying it's wrong to claim Absolute Rightness
for things for which you have no evidence other than your own preferences
and instinct.
> > And/or, macro-level benefits may more than make up for
> > micro-level differences.
>
> That is just laziness.
Not at all. Go write a program in Haskell. See how many things you run
into that seem like micro-level crud - having to do with dealing with the
type system, for example. But then look at the overall result, which is
likely to be very short and concise, which by your own standards, is a very
good thing. Now, redesign Haskell to eliminate the crud, but retain the
overall conciseness. You might find that tricky. If you succeed, you'll be
famous.
What I'm saying is that different systems have different tradeoffs, and that
what seems like crud to you in CL may be either a good thing somewhere else,
or a minor and irrelevant detail - or it may even be crud, but unavoidable
crud given the system in question. If you throw out a system because it
contains the slightest bit of crud, you'll be forced to throw out all
systems.
That last statement, btw, is as far as anyone knows, an Absolute Right
Answer, which derives from Goedel's Incompleteness Theorem. Gregory Chaitin
has even applied this directly to Lisp - see e.g.:
http://www.cs.auckland.ac.nz/CDMTCS/chaitin/lisp.html
The issue in question is that it's been shown that any consistent formal
system - including any computer language - contains truths that are, as
Chaitin puts it, "true for no reason" and "true by accident". (I'm eliding
Chaitin's enthusiastic use of exclamation marks.) Some - or perhaps all -
of the things that are true for no reason are what you call crud.
You hit on this issue, in fact, when you said earlier "I do not believe
these choices are up to us". You're right - we can make some choices, but
they have some inevitable consequences, so other choices we might have had
are eliminated. One of the choices that's not up to us, is that we can't
eliminate all crud from any system. So we're left to decide how to deal
with the crud: throw out a system or design because of the crud, decide we
can live with the crud, or find once we've adjusted our thinking to a new
system that most of what seemed like crud actually wasn't.
A friend of mine says of marriage, rather unromantically, that "you find the
person whose shit you can put up with". This is probably quite true of
language choices, too. The romance side of things is that you might pick a
language because of some Grand Goals in its overall design; but you've also
got to be able to accept the crud that comes along with that.
Looking with an outsider's perspective for crud in Lisp, many people decide
that the parentheses look like crud, and avoid the language as a result.
> I go through that every day. Faced with micro
> crud in something macro wonderful like Cells (!), where Cells seem to be
> demanding the crud, I step back and say, ok, what bonehead decision
> makes this crud only /seem/ ineluctable. ie, I work out how to keep the
> Cells but lose the crud.
I think that's fine, but I'm pointing out that it's an absolute law of the
conceptual universe - not just our physical universe - that
some crud can't be eliminated; and also that one system's crud may be
another system's transcendent insight. So you can't use the presence of
crud as an absolute test in all cases, and you especially can't naively
detect crud in systems you're not very familiar with.
> I am with you 100%, but I am a Buddhist, so I understand that my wants
> and desires are the source of all my unhappiness.
There's a lot of truth to that. As a designer, I often find that the things
that make systems difficult to implement are arbitrary requirements that
can - once identified - easily by realigned to simplify the task, without
losing anything of significance. Again, to me, this shows the dangers of
focusing on micro-issues, such as "we must get rid of this crud", at least
without paying careful attention to the context.
> Look at these C++
> gurus jumping up and down about dynamic languages and turning their
> backs on strong static typing. They were admitted s.t.t bigots until
> they found out it was not the Only Way. They knew all along that s.t.t.
> was a royal pain in the ass, but they tolerated it for the higher
> benefits (greater confidence in a program's correctness). Now they
> discover test-driven development and kick s.t.t out of bed. It just
> never occurred to them that there was another way to get correctness
> without enduring s.t.t.
Well yeah. The lesson in that is all the things I've been saying. "Only
Ways" are suspect.
> So watch out for those Higher Goals justifying crud. There must be a
> better way, by my thinking. If not, again, lose that higher goal.
The Higher Goals justify crud if, when compared to competing systems, the
system with Higher Goals still has benefits that can't be improved upon by
the competing systems. Some of the Higher Goals of Lisp justify the crud of
its parentheses, for example.
> You know my predilection for the abstract. I prefer questioning
> underlying assumptions. Maybe it is my philosophy training.
What does your philosophy training say about things that you think are
Absolute Right Answers, but for which you have no proof? Or do you
consider those things more along the lines of religious beliefs?
> I'd make it thru kenny-cdr and kenny-car and kenny-assq
> and then it would be kenny-aw-fuck-it-i'm-going-back-to-cl.
Sure, because you'd be trying to duplicate the system you were familiar
with, in another system. If you know you want to stick to the system you're
familiar with, then your choice is easy.
> >... without impacting every other user of the language.
>
> There is One Right Answer. They need to be impacted.
>
> :)
Hey, I can agree with that. CL is a nice example of the accumulation of
crud over decades, and could have done with a bit more of the refactoring
that is so fashionable today. Some people now refactor programs
mercilessly, why is it that we're so much more circumspect with programming
languages? If anything, the changes to programs required by changes to
programming languages are, with current capabilities and tools, more easily
automated than many other kinds of refactoring, so the problem is not
actually in transforming legacy code. The problem is in transforming legacy
users. And unfortunately, the One Right Answer of impacting the users seems
to be impractical to implement, much of the time.
> Coming RSN: the release of RoboCells, a free (BSD?) Cells-based,
> all-lisp-all-the-time starter RoboCup client for everyone's enjoyment.
Cool!
Anton
> One application of "shorter is an absolute measure of correctness" would
> immediately eliminate Lisp-2, since Lisp-2 programs are inevitably longer
> than Lisp-1 programs, as I have shown in another post.
Not to my satisfaction.
When there are two namespaces, there are, in effect, twice as many
names of any given length since names in a given context are being
used up only half as fast. That is, in a Lisp1, there are only 26
one-letter names, but in a Lisp2 there are 52 storage locations named
by one-letter names. And so on. No, both storage locations are not
general, so speaking in terms like "half" is probably misleading. But
on the whole, _I_ think "the good names" get used up less fast in a Lisp2
and one has to resort to clunkier names less often.
YMMV, but in any case I did remark when you made this claim before
that to do this reliably mechanically, you'd have to add prefixing,
which means the programs really wouldn't be shorter.
Within the margin of error of all this handwaving, it's surely just
a wash.
Kent M Pitman <······@world.std.com> writes:
> > One application of "shorter is an absolute measure of correctness" would
> > immediately eliminate Lisp-2, since Lisp-2 programs are inevitably longer
> > than Lisp-1 programs, as I have shown in another post.
>
> Not to my satisfaction.
>
> When there are two namespaces, there are, in effect, twice as many
> names of any given length since names in a given context are being
> used up only half as fast. That is, in a Lisp1, there are only 26
> one-letter names, but in a Lisp2 there are 52 storage locations named
> by one-letter names. And so on. No, both storage locations are not
> general, so speaking in terms like "half" is probably misleading. But
> on the whole, _I_ think "the good names" get used up less fast in a Lisp2
> and one has to resort to clunkier names less often.
You did not consider other alternatives here. I'm sure you know that
programs in Lisp1 are shorter because instead of variable name LIST
they use LST. And since lisp-like languages are all about list
processing, just this one case shortens Lisp1 programs so much that
the Lisp1 programmers can observe a measurable increase of correctness
of their programs.
(The not so humorous point is that instead of choosing different
not-less-descriptive names they may choose to use more cryptic names,
without sacrificing oh-so-important CPP (Characters Per Program)
metric.)
--
Janis Dzerins
If million people say a stupid thing, it's still a stupid thing.
Janis Dzerins <·····@latnet.lv> writes:
> Kent M Pitman <······@world.std.com> writes:
>
> > > One application of "shorter is an absolute measure of correctness" would
> > > immediately eliminate Lisp-2, since Lisp-2 programs are inevitably longer
> > > than Lisp-1 programs, as I have shown in another post.
> >
> > Not to my satisfaction.
> >
> > When there are two namespaces, there are, in effect, twice as many
> > names of any given length since names in a given context are being
> > used up only half as fast. That is, in a Lisp1, there are only 26
> > one-letter names, but in a Lisp2 there are 52 storage locations named
> > by one-letter names. And so on. No, both storage locations are not
> > general, so speaking in terms like "half" is probably misleading. But
> > on the whole, _I_ think "the good names" get used up less fast in a Lisp2
> > and one has to resort to clunkier names less often.
>
> You did not consider other alternatives here. I'm sure you know that
> programs in Lisp1 are shorter because instead of variable name LIST
> they use LST. And since lisp-like languages are all about list
> processing, just this one case shortens Lisp1 programs so much that
> the Lisp1 programmers can observe a measurable increase of correctness
> of their programs.
>
> (The not so humorous point is that instead of choosing different
> not-less-descriptive names they may choose to use more cryptic names,
> without sacrificing oh-so-important CPP (Characters Per Program)
> metric.)
Hmmmmmmmmmmmmmmmmmmmm.......
What a unixue point of view on circumstance-modified aesthetic.
Certainly something to think about.
Thanks, Janis!
Janis Dzerins <·····@latnet.lv> wrote in message news:<···············@gulbis.latnet.lv>...
> programs in Lisp1 are shorter because instead of variable name LIST
> they use LST. And since lisp-like languages are all about list
Capital letters are taller than lower case letters.
To distinguish LST from 1ST, the L should be capital.
So even if it's shorter, it's taller.
> > One application of "shorter is an absolute measure of correctness" would
> > immediately eliminate Lisp-2, since Lisp-2 programs are inevitably
longer
> > than Lisp-1 programs, as I have shown in another post.
>
> Not to my satisfaction.
>
> When there are two namespaces, there are, in effect, twice as many
> names of any given length since names in a given context are being
> used up only half as fast. That is, in a Lisp1, there are only 26
> one-letter names, but in a Lisp2 there are 52 storage locations named
> by one-letter names. And so on. No, both storage locations are not
> general, so speaking in terms like "half" is probably misleading. But
> on the whole, _I_ think "the good names" get used up less fast in a Lisp2
> and one has to resort to clunkier names less often.
That would only be true if the namespace of good names were seriously
restricted. I don't think that's true, but perhaps that falls into the YMMV
category.
Another aspect to this discussion is that if the comparison is to a Lisp1
with a good module system, then namespace management would be taken care of
by that. Such systems can effectively have as many namespaces as they have
modules, which seems to me a far better solution than having just one or
two.
> YMMV, but in any case I did remark when you made this claim before
> that to do this reliably mechanically, you'd have to add prefixing,
> which means the programs really wouldn't be shorter.
Not necessarily. A conversion program could accumulate a list of unique
names that need to be renamed and allow the user to specify new names. The
program could also validate that the newly-chosen names don't conflict,
asking for new ones otherwise.
> Within the margin of error of all this handwaving, it's surely just
> a wash.
The real point was that a system that allowed the tokens FUNCALL, FUNCTION
and #' to be globally removed without impacting behavior would seem, under a
naive shorter-is-better metric, to be better. The renaming could be
performed without changing name lengths at all, and the only thing that
would be impacted is readability. For the question of "shortness is
correctness", readability isn't an issue. This actually supports my point,
which is that shortness alone is not correctness, since other factors, such
as comprehensibility, must be considered.
Anton
"Anton van Straaten" <·····@appsolutions.com> writes:
> Not necessarily. A conversion program could accumulate a list of unique
> names that need to be renamed and allow the user to specify new names. The
> program could also validate that the newly-chosen names don't conflict,
> asking for new ones otherwise.
This is totally unacceptable in my book. While there are certainly cases
where modules don't fit together and this has to be done, it's the exception
not the rule. I think you'd here be changing it to be the rule.
You don't rename people's functions except in EXTREME circumstances.
Forgetting the issue of what the names are, the important thing about a
name is that it stays the same thing. If it changes, it's not really the
name--it's some temporary attribute or is the place you last left something.
> > Within the margin of error of all this handwaving, it's surely just
> > a wash.
>
> The real point was that a system that allowed the tokens FUNCALL, FUNCTION
> and #' to be globally removed without impacting behavior would seem, under a
> naive shorter-is-better metric, to be better.
I don't agree with this claim. It's a personal choice. I know there
are people that make this claim personally for themselves, and perhaps
that's all you are doing here, but it is not universally true that we
use these things grudgingly. I _prefer_ to see #' and FUNCTION and
FUNCALL rather than not. I don't just use them as an accomodation of
Lisp2... even though I also prefer short programs. I don't approve of
shortening programs to the point of information loss.
> The renaming could be performed without changing name lengths at
> all, and the only thing that would be impacted is readability. For
> the question of "shortness is correctness", readability isn't an
> issue. This actually supports my point, which is that shortness
> alone is not correctness, since other factors, such as
> comprehensibility, must be considered.
Which is why I don't like to see FUNCALL, etc. go away. I like the
information they make explicit... For me, comprehensibility is
diminished when these markers disappear.
I am banging on this because I have often over the years heard that people
have read these Lisp1/Lisp2 discussions and even my&RPG's paper on the
topic and they think that it's all just a "total win for Lisp1" and they
don't see that Lisp2 is argued for effectively. They ask me why it wasn't
a slam dunk to make the change since everyone appears to want it. So I've
found it important to answer in as many places as possible the apparent
claim that Lisp1 is the only way, the preferrable way, etc. with remarks
that make it clear each and every time that "it is just a choice" and
"there is no global sense of preference".
Your remarks keep making assertions that are not prefixed with "for me,"
or "IMO" or markers like that and that appear to be drifting off into
global truths, and I keep trying to veer them back to the middle.
Kent M Pitman wrote:
> "Anton van Straaten" <·····@appsolutions.com> writes:
>
> > Not necessarily. A conversion program could accumulate a list of unique
> > names that need to be renamed and allow the user to specify new names.
The
> > program could also validate that the newly-chosen names don't conflict,
> > asking for new ones otherwise.
>
> This is totally unacceptable in my book. While there are certainly cases
> where modules don't fit together and this has to be done, it's the
exception
> not the rule. I think you'd here be changing it to be the rule.
I'm not sure what you're getting at. It's only when there are conflicting
function and variable names in the same scope, that one or the other would
need to be renamed.
> You don't rename people's functions except in EXTREME circumstances.
> Forgetting the issue of what the names are, the important thing about a
> name is that it stays the same thing. If it changes, it's not really the
> name--it's some temporary attribute or is the place you last left
something.
I would expect that it would be variables being renamed, for the most part.
An example would be the punning copy-cons function you gave the other day -
the 'cons' parameter would need to be renamed. It could be renamed, e.g.,
to 'pair'.
> > > Within the margin of error of all this handwaving, it's surely just
> > > a wash.
> >
> > The real point was that a system that allowed the tokens FUNCALL,
FUNCTION
> > and #' to be globally removed without impacting behavior would seem,
under a
> > naive shorter-is-better metric, to be better.
>
> I don't agree with this claim. It's a personal choice. I know there
> are people that make this claim personally for themselves, and perhaps
> that's all you are doing here
OK, sorry, but you're completely missing my point. I'll recap: Kenny Tilton
said, "I seriously believe that shorter is an
absolute measure of correctness". I wanted to point out that this claim is
questionable. As a highly relevant example - perhaps *too* relevant - I
chose to use Lisp-1 vs. Lisp-2.
It is a demonstrable fact that any Lisp-2 program can be converted to a
Lisp-1 program of equal or shorter length. The only possible exception
would a program in which every single name in both function and variable
namespaces was used, but nothing like that has existed since the days when
some languages were limited to variable names of a single alphabetic
character and a single numeric digit. Discounting that possibilty, we're
left with the fact that the occurence of even a single FUNCALL or #' in a
Lisp2 program would mean that the equivalent Lisp1 program would be shorter.
Given the fact that I have just stated, then *by Kenny's proposition*,
Lisp-1 would be "absolutely more correct".
I think this is an invalid result which essentially disproves Kenny's
proposition, in a way that hits close to home. I wasn't saying that I
thought Lisp1 really was "more correct" - I was using that conclusion as
part of a proof by contradiction.
> but it is not universally true that we use these things grudgingly. I
_prefer_
> to see #' and FUNCTION and FUNCALL rather than not. I don't just use
> them as an accomodation of Lisp2... even though I also prefer short
> programs. I don't approve of shortening programs to the point of
> information loss.
I completely agree, and that was part of my point. I wrote: "I can show you
plenty of examples of very concise programs
that are virtually incomprehensible, so this metric can't be taken to its
logical conclusion, it has to be applied with taste."
> > The renaming could be performed without changing name lengths at
> > all, and the only thing that would be impacted is readability. For
> > the question of "shortness is correctness", readability isn't an
> > issue. This actually supports my point, which is that shortness
> > alone is not correctness, since other factors, such as
> > comprehensibility, must be considered.
>
> Which is why I don't like to see FUNCALL, etc. go away. I like the
> information they make explicit... For me, comprehensibility is
> diminished when these markers disappear.
I think that's fine. It's a preference. As someone who has come to
appreciate a highly functional programming style, it's not my preference.
But I don't see any problem with having different preferences.
> I am banging on this because I have often over the years heard that people
> have read these Lisp1/Lisp2 discussions and even my&RPG's paper on the
> topic and they think that it's all just a "total win for Lisp1" and they
> don't see that Lisp2 is argued for effectively.
I'm banging back because you seem to be misinterpreting what I'm saying
quite a bit, or extending it into areas about which I've said nothing. I
understand that you're speaking to a broader audience than me, but I'd
rather you didn't do so at the expense of the points I've been making.
> They ask me why it wasn't a slam dunk to make the change since
> everyone appears to want it. So I've found it important to answer
> in as many places as possible the apparent claim that Lisp1 is the
> only way, the preferrable way, etc. with remarks that make it clear
> each and every time that "it is just a choice" and "there is no global
> sense of preference".
OK, you apparently have a big stake in this issue. However, I think it is
clouding your perceptions of what I've been saying, and that's happened more
than once now.
> Your remarks keep making assertions that are not prefixed with "for me,"
> or "IMO" or markers like that and that appear to be drifting off into
> global truths, and I keep trying to veer them back to the middle.
I don't think that's true, as I've tried to explain.
Anton
I wrote:
> Kent wrote:
> > but it is not universally true that we use these things grudgingly.
> > I _prefer_ to see #' and FUNCTION and FUNCALL rather than
> > not. I don't just use them as an accomodation of Lisp2... even
> > though I also prefer short programs. I don't approve of shortening
> > programs to the point of information loss.
>
> I completely agree, and that was part of my point. I wrote: "I can
> show you plenty of examples of very concise programs that
> are virtually incomprehensible, so this metric can't be taken to its
> logical conclusion, it has to be applied with taste."
To avoid any further misunderstandings: when I said "I completely agree", I
was agreeing with Kent's last statements, "even though I also prefer short
programs. I don't approve of shortening programs to the point of
information loss."
As I said elsewhere, I'm not a fan of the use of FUNCALL, FUNCTION et al.,
so I wasn't agreeing with that part - which naturally means I don't believe
that their omission implies loss of important information. Purely to
explain my position, I'll say that the reason I think that, is that I
consider functions to be values like any other, so there's no more reason to
use FUNCTION than there would be to say (CAR (LIST MY-LIST)), i.e. we don't
annotate variable references with their types or type constructors. Similar
logic applies to FUNCALL. Like I said, that's just to explain my position.
Anton
"Anton van Straaten" <·····@appsolutions.com> writes:
> Like I said, that's just to explain my position.
Heh. I appreciate your adding such verbiage though I also gotta laugh.
One of my problems with this whole debate is that the meta-situation
mirrors the technical discussion in an odd way.
Lisp1 vs Lisp2 is a lot about the paradoxical little remark
There are two kinds of people in the world,
People who think there are two kinds of people in the world
and people who don't.
I claim that Lisp1 people find your position "obvious" and not
requiring strong justification because they often cannot see any other
way of doing thigns. That is, championing Lisp1 (a merging of
namespaces) often [obviously not always] comes with the odd frame of
mind that they also champion a merging of world views. In some (and I
perceive it as "many") such people, it's a particular "my point of
view is not only right but yours is so not right that it should be
stamped out" kind of attitude. An almost bigoted-ness. You neither have
to explain to a bigot nor to the people against whom he is bigoted what
his "reasons" are.
I claim that Lisp2 people find your position "obvious" and not requiring
strong justification because they routinely perceive that context matters,
and they can see your view as easily as their own. That is, championing
Lisp2 (a "there are multiple ways to view this" approach to naming) also
tends to selecte at the meta-level people who are used to letting others
have their own point of view. Such people are used to thinking that
sometimes one thing works and sometimes another thing works.
So my (admittedly non-scientific) table of preferences and behaviors
looks like:
\ supports Lisp1 Lisp2
\
understands \
+----------------+--------------+
Lisp1 | yes yes |
+----------------+--------------+
Lisp2 | no yes |
+----------------+--------------+
So I feel like Lisp2 people constantly need to explain themselves to
Lisp1 people, even though I've never heard Lisp1 people have to explain
themselves to Lisp2 people. Ironically, Lisp1 people often seem to
take this meta-circumstance as further proof that their point of view is
right, because they always see "lisp2 people trying to justify their
existence" and this reinforces their notion that "lisp2 is on trial"
while no one ever sees the lisp1 point of view substantially on trial
and consequently it seems "obviously right" to a great many people.
Obviously I don't mean to suggest that the mere fact of supporting
Lisp1 means I'm calling you (or anyone) personally a "Lisp1 bigot", so
please don't take this as any kind of personal attack. Nevertheless,
I do think it's worth taking note of patterns of group behavior
because sometimes they do add up to something, and also sometimes
recognizing the mass effect of group behavior helps to sensitize
people to things they have not previously been sensitive to. So this
is my personal attempt to characterize both the meta-discussion so you
and others can understand why I find it such an emotionally charged
debate.
Kent M Pitman wrote:
> So this is my personal attempt to characterize both the meta-discussion
> so you and others can understand why I find it such an emotionally
> charged debate.
I think I've gotten a pretty good idea by now, thank you.
However, it raises a question: does this mean that it's simply not possible
to have any discussions relating to Lisp1 and Lisp2 on c.l.l., no matter how
reasonable, unless they come to the conclusion that Lisp2 is superior? And
that any Lisp1-bashing must simply be silently accepted?
Because that's what seems to have been the case here. Everything I've been
saying from the beginning has been along the lines of "no, a Lisp2 dialect
is not objectively better than a Lisp1 dialect". I didn't really intend to
address the converse, although I've made my preference clear. Even taking
into account your apparent need to "speak to the gallery" on the broader
subject, the net effect is nevertheless that it doesn't appear possible to
enter this territory and have a meaningful discussion. If this were the
consistent behavior from a representative sample of the group, I might just
say oh well, c.l.l.'s a write-off, I'll go elsewhere. But that's not the
case here.
Earlier, you mentioned "It's unfortunate that no unified architecture exists
for Lisp/Scheme". But whatever your reasons and justifications, you're not
exactly helping to foster an environment in which discussion about such
things could take place.
BTW, I'd like to note that many Scheme users I know also use other languages
which do have separate function/variable namespaces. So your assumptions
about their assumptions about namespaces are questionable.
And you go ludicrously far with this: "championing Lisp2 (a "there are
multiple ways to view this" approach to naming) also tends to select at the
meta-level people who are used to letting others have their own point of
view."
Hmmph. Pity that meta-level selection didn't work out in your case.
Anton
"Anton van Straaten" <·····@appsolutions.com> writes:
> However, it raises a question: does this mean that it's simply not possible
> to have any discussions relating to Lisp1 and Lisp2 on c.l.l., no matter how
> reasonable, unless they come to the conclusion that Lisp2 is superior? And
> that any Lisp1-bashing must simply be silently accepted?
No, it just means that you probably won't get away with having a one-sided
discussion that only presents the benefits of what we don't do and not those
of what we do, or that only explore our negatives and not the negatives of
the opposition.
> Because that's what seems to have been the case here. Everything I've been
> saying from the beginning has been along the lines of "no, a Lisp2 dialect
> is not objectively better than a Lisp1 dialect".
Yes, but then you've presented only what looks to me like Lisp1-positive
info and have made a number of specific statements (which I have responded
to, no need to repeat) that seemed to suggest a one-sided point of view.
So whether you meant to or not, you were sounding like you were advocating
Lisp1. (If it makes you feel any better, I've gotten email from people
saying the original Lisp1/Lisp2 paper reads like a pro-Lisp1 paper and asking
if there are arguments against Lisp1 or in favor of Lisp2 ... :)
> I didn't really intend to
> address the converse, although I've made my preference clear. Even taking
> into account your apparent need to "speak to the gallery" on the broader
> subject, the net effect is nevertheless that it doesn't appear possible to
> enter this territory and have a meaningful discussion. If this were the
> consistent behavior from a representative sample of the group, I might just
> say oh well, c.l.l.'s a write-off, I'll go elsewhere. But that's not the
> case here.
What can I say? When you make statements that are conspicuously of
the "have you stopped beating your wife?" form that appears to address
one question but has a broken premise or incideental implication, then
you get people side-tracked.
I see the issue othe other way around: this is a long-decided issue of
the language and we can tell you why it is, but it's really pointless
to debate. Our own forum should be the one place we can come and just
take for granted that we won't be questioned other than just
incidentally on why is "lambda" called "lambda" or "car" called "car",
or why are strings not nul-terminated, or whatever. We can answer
these questions but to do much more (e.g., to re-open a debate on any
of these) is to set the entire community to discussing something it
doesn't _need_ to discuss. It's really incidental to real problems of
today, which ought to be "how can I take my good business idea and turn it
into business reality using Lisp?" or "how can I use Lisp to program things
I can't program in other languages?" or "how can I think about x or y thing
that I'm conceptualizing wrong because it appears to me to be a roadblock
to usage".
But questions that are intellectually no more exciting than "why does
'fast' mean 'not eat' as a verb, 'quickly' as an adverb, and 'speedy'
as an adjective?" just don't seem to me to help much. The answer is
"Because (a) that's the way we decided to do it and (b) while it is
confusing to the occasional newbie learning, it's never presented any
real problem in practice."
> Earlier, you mentioned "It's unfortunate that no unified architecture exists
> for Lisp/Scheme". But whatever your reasons and justifications, you're not
> exactly helping to foster an environment in which discussion about such
> things could take place.
IMO this is not a good environment for that to happen, nor any design
discussion, since it's "too many cooks" and since serious design
discussions need too much trivial back and forth for newsgroup to be a
good forum. Nevertheless, if you raised the issue in the abstract,
I'd discuss it. You didn't though. Your opening was not "How can I
interface these two things without perturbing their natural state?"
but rather "It looks to me like the difference is so unimportant that
mechanical rewrite would leave me with something just as usable."
That's to me like saying "The French language doesn't seem to me to be
out to do anything different than English, so I just advocate all
French text being translated to English and then the resulting
character set being simplified to not need all those little accent
marks." This is a multi-cultural forum. If you fail to respect the
various cultures here, someone will tend to speak up.
> BTW, I'd like to note that many Scheme users I know also use
> other languages which do have separate function/variable namespaces.
> So your assumptions about their assumptions about namespaces are
> questionable.
I acknowledged explicitly there were such people.
However, you can't invalidate an argument about someone having been
wronged by saying "I never saw it". No number of men saying "I've
never seen sexual discrimination in the workplace" discredits a single
woman saying "I have." -- just to take one of many examples.
The strict text of what you say seems to be remarking that there are
people who have a correct/tolerant theory, but the form of your statement
appears to suggest that you are implying there are no people who think
otherwise.
> And you go ludicrously far with this: "championing Lisp2 (a "there are
> multiple ways to view this" approach to naming) also tends to select at the
> meta-level people who are used to letting others have their own point of
> view."
Consider this: I didn't get this chip on my shoulder about Lisp1/Lisp2
issues from nowhere. The reason I am snippy about it (although I've tried
to be politely snippy, and to explain my meaning as best I can) is that
this has happened over and over and over across a great many years.
That there are people who don't do it doesn't mean I have been spared the
people who do. And I was trying to hypothesize why we are knee-deep in
threads about this here, while although I don't read comp.lang.scheme
normally, I'd just bet that someone doesn't arrive there every 3 or 4 months
asking "why isn't Scheme a Lisp2?" There is obviously some reason for the
asymmetry that people coming here over and over and over asking why CL
_is_ a Lisp2... You're welcome to suggest a reason why we have to endure
endless discussions of the same thing here.
> Hmmph. Pity that meta-level selection didn't work out in your case.
I have _no_ problem with Lisp1 people using Lisp1. I just don't understand
their need to come to a Lisp2 forum and raise the question. This entire
discussion is a counterfactual hypothetical about a language that most
Lisp dialetcs (Emacs Lisp, CL, ISLISP) are not. Dylan and Eulisp are not,
but they are in most other ways as well more closely dialects of Scheme
than Lisp IMO, and I consider the two languages importantly separate.
I have said many times that I think Scheme and Lisp are not the same language
exactly because their politics lean different ways and the constituents
of one are not generally successful nor happy discussing matters with the
constituents of the other...
Kent M Pitman <······@world.std.com> wrote in message news:<···············@shell01.TheWorld.com>...
> There is obviously some reason for the
> asymmetry that people coming here over and over and over asking why CL
> _is_ a Lisp2... You're welcome to suggest a reason why we have to endure
> endless discussions of the same thing here.
It is a funny phenomenon. In The Connection Machine's bibliography
entry for the Scheme standard, Hillis notes:
"[Scheme is] the lisp on which Common Lisp should have been based.
Includes lexical scoping, full funarg, and cleaner syntax and uses
value cell for function bindings."
Immortalized in print. Maybe I should one day host a lisp1/lisp2 page
with all the stuff I've waded through, plus perhaps a checklist of
things a potential flamewarrior should have some response to, just so
lifespans aren't wasted by pointing out the same counterarguments.
Perhaps also a list of languages, with how they handle functions. For
example, I've shipped projects in Python, and its lisp1-ishness
actually does lead to minor problems initially, but I've never known
anyone who wanted it different; ease of using the functional style is
an enormous plus. With Java it never comes up because the namespaces
are too small, and anyway no one can pass functions around without
enormous pain.
In article <···························@posting.google.com>,
··········@yahoo.com (Tayss) wrote:
> For
> example, I've shipped projects in Python, and its lisp1-ishness
> actually does lead to minor problems initially, but I've never known
> anyone who wanted it different; ease of using the functional style is
> an enormous plus.
But then again, Python doesn't have a macro system, right?
Lisp-1 causes more trouble in conjunction with macros than Lisp-2.
Pascal
Pascal Costanza <········@web.de> wrote in message news:<······························@news.netcologne.de>...
> But then again, Python doesn't have a macro system, right?
>
> Lisp-1 causes more trouble in conjunction with macros than Lisp-2.
Yes, I was just musing about other languages. The reasons why they
don't have problems with functions can easily be "lack of power," and
it can be instructive to see why it's easy to write off difficulties
if you're not comparing all the effects of one's changes to other
language features. (Well, instructive to me anyway.)
Kent M Pitman wrote:
> "Anton van Straaten" <·····@appsolutions.com> writes:
>
> > However, it raises a question: does this mean that it's simply not
possible
> > to have any discussions relating to Lisp1 and Lisp2 on c.l.l., no matter
how
> > reasonable, unless they come to the conclusion that Lisp2 is superior?
And
> > that any Lisp1-bashing must simply be silently accepted?
>
> No, it just means that you probably won't get away with having a one-sided
> discussion that only presents the benefits of what we don't do and not
those
> of what we do, or that only explore our negatives and not the negatives of
> the opposition.
I didn't think the original post was a one-sided discussion - it was arguing
for an equivalence, not a benefit of one over the other.
> Yes, but then you've presented only what looks to me like Lisp1-positive
> info and have made a number of specific statements (which I have responded
> to, no need to repeat) that seemed to suggest a one-sided point of view.
My subsequent points were responses to a plethora of anti-Lisp1, pro-Lisp2
comments you then made. I responded in order to defend my original post,
which entailed defending Lisp1.
What you're doing is making it difficult for anyone to claim parity for
Lisp1. You get to one-sidedly extol the virtues of Lisp2, but it seems as
though no possible response countering in favor Lisp1 would be acceptable to
you.
(I should note that you did earlier make an apparently token attempt at
describing an argument for preferring Lisp1, but it seemed suspiciously weak
and perhaps even chosen to be unattractive to your audience, e.g.
programming in a mathematical style.)
> What can I say? When you make statements that are conspicuously of
> the "have you stopped beating your wife?" form that appears to address
> one question but has a broken premise or incideental implication, then
> you get people side-tracked.
Another way to get people side-tracked is to post claims about entire groups
of people, like "Lisp1 people" and "Lisp2 people", as you did in your
next-to-last response. Even though you claimed only to be talking about
subsets of those groups, it seems to me quite close to the "almost
bigoted-ness" you accused "many Lisp1 people" of.
Yes, you were explaining your perspective on the meta-matter, but I'm saying
I find that explanation a little disturbing, especially when it extends e.g.
to the "almost bigoted-ness" of Lisp1 people, vs. Lisp2 people having
personality traits such as "used to letting others have their own point of
view". When claims reach that point, I'm afraid I'm going to need the
scientific studies to back them up. I don't think that usenet spats and
trolls should be extrapolated onto entire communities.
I erred in allowing your generalizations to annoy me, and as you say, asked
a kind of wife-beating question. I apologize. I should have stuck to my
point, but you did answer my real question, thank you.
> Nevertheless, if you raised the issue in the abstract,
> I'd discuss it. You didn't though.
I wasn't saying my current posts were attempting to discuss Lisp1/Lisp2
reconciliation. I was suggesting that if posts on the matter are
consistently met with vehemently anti-Lisp1 responses, it could create a
climate in which questions which you might consider more on-topic and
constructive might not be asked.
> Your opening was not "How can I
> interface these two things without perturbing their natural state?"
> but rather "It looks to me like the difference is so unimportant that
> mechanical rewrite would leave me with something just as usable."
> That's to me like saying "The French language doesn't seem to me
> to be out to do anything different than English, so I just advocate
> all French text being translated to English and then the resulting
> character set being simplified to not need all those little accent
> marks."
There's a large and erroneous leap in the above paragraph. Yes, I suggested
that "mechanical rewrite would leave me with something just as usable". But
to you, that is apparently "like saying ... I just advocate all French text
being translated to English". But I did *not* ever advocate an actual
translation! That's a leap you're making, and to me it clearly demonstrates
the problem here. You are extrapolating an opposing position to a point
where it is more easily attacked - perhaps not deliberately, but it has a
negative effect on the discussion, either way.
> This is a multi-cultural forum. If you fail to respect the
> various cultures here, someone will tend to speak up.
Seems to me you're at least as guilty of failing to respect a culture here -
it just so happens that it's not the dominant culture of this group.
> I see the issue othe other way around: this is a long-decided issue of
> the language and we can tell you why it is, but it's really pointless
> to debate. Our own forum should be the one place we can come and just
> take for granted that we won't be questioned other than just
> incidentally on why is "lambda" called "lambda" or "car" called "car",
> or why are strings not nul-terminated, or whatever. We can answer
> these questions but to do much more (e.g., to re-open a debate on any
> of these) is to set the entire community to discussing something it
> doesn't _need_ to discuss.
Did you read Tayss' description of his motivation for the question? It
seemed like a legitimate question, which I don't think falls into the
category you're describing. I think my response was a legitimate one. You
can always choose not to respond.
However, if you feel the need to perform spin control on this and probably
other issues, essentially what you're saying is "please don't say anything
that I need to exercise spin control on". You should not be surprised if
many people come along who do not conform to that expectation.
> Consider this: I didn't get this chip on my shoulder about Lisp1/Lisp2
> issues from nowhere. The reason I am snippy about it (although I've tried
> to be politely snippy, and to explain my meaning as best I can) is that
> this has happened over and over and over across a great many years.
I sympathize. I realize there isn't an easy answer, but I would point out
that how you react to these things is something you are capable of
exercising some control over. You've made great contributions to Lisp,
Scheme, and their communities, but that should not have to condemn you to a
lifetime of defending Lisp against petty misunderstandings or even attacks.
I'm sure there are plenty of other people here who are willing to play
defense, so that you don't need to respond on marginal issues. I'm equally
sure that your energy could be used on more productive things.
> That there are people who don't do it doesn't mean I have been spared
> the people who do. And I was trying to hypothesize why we are knee-deep
in
> threads about this here.
" *I* have been spared"? Aren't you taking it a bit personally? Or are you
referring to situations like public appearances? I'm imagining you being
mobbed by people demanding that you immediately produce hard evidence of the
superiority of Lisp2, while claiming in advance that nothing could possibly
convince them.
> You're welcome to suggest a reason why we have to endure
> endless discussions of the same thing here.
Based purely on this discussion, the tendency to broaden the discussion,
even when the "invader" is not trying to, is likely to create more
discussion, not less. I also think that responses of a personal, subjective
nature are unlikely to have much impact on someone with some other
prejudice.
Speaking from my own perspective, I must say if I see a claim that seems
counterfactual to me, about something in which I have an interest, I might
be inclined to respond. That, in fact, was more or less what happened in
this case - I didn't think what Tayss was looking for could exist, and I
said so. Claims that seem unsupportable to outsiders & lurkers could
certainly result in unwanted discussion. The only solution I see to this is
restraint, in both claims, and responses. (I had to restrain myself earlier
from responding to your footnote in another thread, "That must be why I like
Lisp2 so much. I don't want to find that type names named globally are
unavailable to me as variable names."
Perhaps a carefully reasoned FAQ about the issue would help mitigate such
questions. While your and Gabriel's paper on the subject is very thorough
and most informative, it's not geared towards providing quick answers to the
sorts of questions you'd like to avoid.
Having now given much more thought to this question than I ever imagined I'd
have to, I'd be willing to provide input on which Lisp2 arguments seem
convincing to a Lisp1-er, and which don't. :)
> I have _no_ problem with Lisp1 people using Lisp1. I just don't
understand
> their need to come to a Lisp2 forum and raise the question.
I guess I'd have to go back and read some of those threads. Sounds like
fun.
> This entire discussion is a counterfactual hypothetical about a language
> that most Lisp dialetcs (Emacs Lisp, CL, ISLISP) are not.
This discussion started as an attempt to demonstrate a way in which Lisp2
was more expressive. Unfortunately, I saw that possibility as
counterfactual. :)
For the record, repeating myself a bit, I'd like to say that I don't
consider myself anti-Lisp2. I just don't personally feel a need for dual
namespaces, and find the arguments for them to be clearly a matter of
preference, which is fine. I also feel, as I think I said previously, that
having a module system with namespace management matters far more than
whether the namespace within a given module is split. I do a lot of Java
work (what can I say, I must have made a wrong turn in my career somewhere),
but I don't make use of its dual method/variable namespace feature, whereas
I consider its very pragmatic class "module" and namespace system to be one
of its strongest points.
My position falls rather unavoidably into the category of your earlier
Lisp2'ers lament, which you summarized with:
> So I feel like Lisp2 people constantly need to explain themselves to
> Lisp1 people, even though I've never heard Lisp1 people have to
> explain themselves to Lisp2 people.
For the record, I'd be happy to explain myself, i.e. the Lisp2 vs. Lisp1
issues as I see them, as objectively as I am capable of being. I can even
bring an infinitesimal amount of Lisp2-cred to the table, having once
programmed ancient Lisp, OBLIST and all, on an IBM 370/158. Well, I assume
it was Lisp2 - I don't really remember. The problem with infinitesimally
small amounts is that it's apparently not always possible to determine for
sure whether they are positive or negative...
However, I would require transactional immunity in order to provide such an
explanation. This is the Star Trek moment where the captain has to agonize
over whether he should lower shields in order to transact some business with
a Romulan ship which seems to have its weapons system powered up. :)
> I have said many times that I think Scheme and Lisp are not the same
> language exactly because their politics lean different ways and the
> constituents of one are not generally successful nor happy discussing
> matters with the constituents of the other...
To quote the great statesman William Jefferson Clinton, indirectly
responsible for popularizing the notion of transactional immunity mentioned
above, here speaking on an oft-repeated theme of his:
"But in the end, most people figure out that these boxes with which we
navigate reality, as important as they are, are not as important as our
common humanity. And if we don't figure it out, then a whole lot of
experience is denied us, and a whole lot of wisdom never comes into our
spirits. ... And you have to basically tell people, 'Look, we respect your
differences, we'll celebrate them, but only if you acknowledge that our
common humanity is more important.'"
(from
http://www.berkeley.edu/news/features/2002/clinton/clinton-transcript.html )
Substitute "common humanity" for "common parentheses, lambda, car and cdr",
perhaps??
Anton
From: Paul F. Dietz
Subject: Re: Looking for examples of lisp-2's expressiveness
Date:
Message-ID: <lEGdnXEETcdnk6uiU-KYvw@dls.net>
Anton van Straaten wrote:
> What you're doing is making it difficult for anyone to claim parity for
> Lisp1. You get to one-sidedly extol the virtues of Lisp2, but it seems as
> though no possible response countering in favor Lisp1 would be acceptable to
> you.
Anton, please realize that CL users (and this is a CL newsgroup) largely don't
*want* Lisp1. We've been through this discussion countless times. It was
interesting years ago. It quickly became boring, and now it's just plain annoying.
If CL's namespaces are unacceptable to you, I suggest you go elsewhere.
Paul
> Anton, please realize that CL users (and this is a CL newsgroup) largely
Is this really a CL newsgroup? Quoting from the FAQ:
"Firstly, the newsgroup has evolved such that the main topic of
discussion is ANSI Common Lisp, though discussion about other lisp
variants is welcome within reasonable bounds."
So the main focus is CL, but the newsgroup encompasses Lisp-like
languages in general. Given that there is no other newsgroup for
Lisp-like languages (like comp.lang.functional as opposed to
comp.lang.ml) its entirely appropriate to post queries about Lisp-like
languages here.
PS> Also, yours is a cop-out answer. It basically says, "I've chosen
my religion, and I don't want to bother discussing it farther." While
that's a perfectly reasonable answer, it's unreasonable to invoke it
in a public forum whose sole purpose is for discussion. To make an
analogy, if you're a Christian absolutely set in your ways, there is
no point getting into a comparative religion discussion.
From: Paul F. Dietz
Subject: Re: Looking for examples of lisp-2's expressiveness
Date:
Message-ID: <8KednZJHcbTs6quiXTWJkg@dls.net>
Rayiner Hashem wrote:
> PS> Also, yours is a cop-out answer. It basically says, "I've chosen
> my religion, and I don't want to bother discussing it farther."
While I was not being fair with the previous poster, your use
of the word 'religion' is uncalled for. There are good practical
reasons to prefer Lisp-2 over Lisp-1, and these reasons don't
require any leaps of faith or divine inspiration to believe.
Paul
Paul F. Dietz wrote:
> While I was not being fair with the previous poster
Thanks for acknowledging that. I'm sorry if my response was a little
over-reactive. This sensitization thing can be catching!
Anton
> While I was not being fair with the previous poster, your use
> of the word 'religion' is uncalled for. There are good practical
> reasons to prefer Lisp-2 over Lisp-1, and these reasons don't
> require any leaps of faith or divine inspiration to believe.
>
The word religion was probably a bad choice. I really did not mean to
invoke the CL user stereotype. However, your response is very
revealing. Digging out the practical reasons to prefer Lisp-2 over
Lisp-1 is precisely why this thread took place!
Paul F. Dietz wrote:
> Anton van Straaten wrote:
>
> > What you're doing is making it difficult for anyone to claim parity for
> > Lisp1. You get to one-sidedly extol the virtues of Lisp2, but it seems
as
> > though no possible response countering in favor Lisp1 would be
acceptable to
> > you.
>
> Anton, please realize that CL users (and this is a CL newsgroup) largely
don't
> *want* Lisp1.
I fully realize that. I take it you haven't really followed the thread. To
recap briefly, in the interests of clarifying the situation for anyone else
who has been confused by the noise here, I was never trying to suggest that
CL users should want Lisp1. As I've pointed out, I originally responded to
a comment which seemed to be asking for the impossible. So far as this
thread has demonstrated anything, it demonstrated that my initial response
seems to have been correct, technically, if not politically. For the
record, my initial post can be reviewed here:
http://groups.google.com/groups?selm=o6JXa.34091%24Mc.2718483%40newsread1.pr
od.itd.earthlink.net
Subsequent responses, mainly to Kent Pitman, expand on my position.
Regarding this newsgroup, the FAQ I've seen for c.l.l. says "the newsgroup
has evolved such that the main topic of discussion is ANSI Common Lisp,
though discussion about other lisp variants is welcome within reasonable
bounds." Afaict, my post was acceptable.
> We've been through this discussion countless times. It was
> interesting years ago. It quickly became boring, and now it's just plain
annoying.
Which discussion is that? The discussion where someone tries to advocate
the use of Lisp1 - which was *not* what I was doing - or the discussion
where someone responds to a request with a factually-based and apparently
correct observation about its likelihood of success, and then finds himself
in the position of repeatedly defending himself against a variety of
tangential arguments based on unfounded assumptions about his intent?
Kent has made me painfully aware that some members of the CL community are
incredibly sensitized to this issue. I'll keep that in mind in future.
> If CL's namespaces are unacceptable to you, I suggest you go elsewhere.
I have repeatedly stated that CL's namespaces are quite acceptable to me.
If anything, the problem here seems to be the other way around - that any
mention of Lisp1, regardless of content or intent, triggers an immune
response. Your is a perfect example. Read the thread more carefully,
rather than picking on the first thing you see which leads you to think I'm
advocating that someone else should "want" Lisp1.
I suggest you also read the closing paragraphs of the message of mine you
responded to.
Anton
In article <······················@dls.net>,
"Paul F. Dietz" <·····@dls.net> wrote:
> Anton van Straaten wrote:
>
> > What you're doing is making it difficult for anyone to claim parity for
> > Lisp1. You get to one-sidedly extol the virtues of Lisp2, but it seems as
> > though no possible response countering in favor Lisp1 would be acceptable
> > to
> > you.
>
> Anton, please realize that CL users (and this is a CL newsgroup) largely
> don't
> *want* Lisp1. We've been through this discussion countless times. It was
> interesting years ago. It quickly became boring, and now it's just plain
> annoying.
>
> If CL's namespaces are unacceptable to you, I suggest you go elsewhere.
It seems to me that this discussion repeatedly suffers from a loss of
focus.
Tayss has asked for an example in which Lisp-2 turns out to make the
code simpler than Lisp-1. Anton has said that this is not possible.
Since it is generally hard to prove a negative statement by giving
examples, he has given a "meta-"rationale why he thinks that a mapping
between Lisp-1 code and Lisp-2 code is trivial (note: not trivial in the
sense of an automated transformation, but a trivial mapping that still
requires human intervention).
Since it easier to give concrete examples I have done another attempt to
find the example that I think Tayss was referring to. Here it is:
http://groups.google.com/groups?selm=aRLAa.18%24R02.36395%40news2.teluspl
anet.net
Pascal
P.S.: As far as I can see, Anton has never said that Lisp-1 is better
than Lisp-2, or that Lisp-2 is unacceptable. To the contrary.
P.P.S.: I think that a statement like "CL users don't want Lisp-1" is a
category error. Lisp-1 and Lisp-2 are implementation aspects to achieve
certain goals, in this case a certain level of coding convenience. What
both CL users and Schemers want is the coding convenience for their
respectively preferred programming styles. So on a certain level they
are after the same thing. It's important to note that in principle, it
doesn't matter how these goals are achieved.
Apparently, these goals are conflicting and irreconcilable, but I don't
think it has to be like that. It might be possible to better integrate
both programming styles in one Lisp dialect. This could be an
achievement, or at least clarify some things wrt Lisp-1/Lisp-2. To
repeat: I don't think that Lisp-N is the real issue here.
Pascal Costanza wrote:
> Tayss has asked for an example in which Lisp-2 turns out to make the
> code simpler than Lisp-1. Anton has said that this is not possible.
> Since it is generally hard to prove a negative statement by giving
> examples, he has given a "meta-"rationale why he thinks that a mapping
> between Lisp-1 code and Lisp-2 code is trivial (note: not trivial in the
> sense of an automated transformation, but a trivial mapping that still
> requires human intervention).
Thank you, Pascal, I could not have asked for a better summary.
> P.S.: As far as I can see, Anton has never said that Lisp-1 is better
> than Lisp-2, or that Lisp-2 is unacceptable. To the contrary.
Thanks again.
> P.P.S.: I think that a statement like "CL users don't want Lisp-1" is a
> category error. Lisp-1 and Lisp-2 are implementation aspects to achieve
> certain goals, in this case a certain level of coding convenience. What
> both CL users and Schemers want is the coding convenience for their
> respectively preferred programming styles. So on a certain level they
> are after the same thing. It's important to note that in principle, it
> doesn't matter how these goals are achieved.
>
> Apparently, these goals are conflicting and irreconcilable, but I don't
> think it has to be like that. It might be possible to better integrate
> both programming styles in one Lisp dialect. This could be an
> achievement, or at least clarify some things wrt Lisp-1/Lisp-2. To
> repeat: I don't think that Lisp-N is the real issue here.
I agree with all this. I've wondered whether some kind of more explicit
namespace management might not provide a solution that supports both
approaches with minimal effect on either. (Although there's also the rather
orthogonal "value space" issue.)
However, I haven't had a chance to think about it in any depth, nor have I
yet read Kent's thoughts on the matter (about which he wrote "The remnants
of my struggle ended up in http://www.nhplace.com/kent/Half-Baked/ for brave
people to peruse...")
If I come up with any ultimate solutions, I'll be sure to let everyone
know - perhaps in a cross-posted thread entitled "ANN: Lisp-2 vs Lisp-1
argument has been settled"... Oh, that's been used already? ;)
Anton
In article <····················@newsread1.prod.itd.earthlink.net>, "Anton
van Straaten" <·····@appsolutions.com> wrote:
> I agree with all this. I've wondered whether some kind of more explicit
> namespace management might not provide a solution that supports both
> approaches with minimal effect on either.
For one possible solution see:
http://www.flownet.com/gat/locales.pdf
particularly section 5.
(NOTE: the URL above is an early draft of a paper submitted to the 2003
Lisp conference.)
E.
In article <····················@newsread1.prod.itd.earthlink.net>,
"Anton van Straaten" <·····@appsolutions.com> wrote:
> I've wondered whether some kind of more explicit
> namespace management might not provide a solution that supports both
> approaches with minimal effect on either. (Although there's also the rather
> orthogonal "value space" issue.)
>
> However, I haven't had a chance to think about it in any depth, nor have I
> yet read Kent's thoughts on the matter (about which he wrote "The remnants
> of my struggle ended up in http://www.nhplace.com/kent/Half-Baked/ for brave
> people to peruse...")
Erann has some nice ideas in this regard by embedding this into the
locales concept borrowed from T. I think it could also be a good idea to
tie this to the package system of Common Lisp. If you were able to
declare a package as Lisp-1 you could integrate both Common Lisp and
Scheme code more easily. (but export/import of symbols would become a
little more tricky, I suppose)
I haven't quite understood Kent's "half-baked" idea yet, but I have only
skimmed through it superficially.
I have implemented a macro with-funcalls that allows you to mix Lisp-1
and Lisp-2. (On top of that I also provide a Schemish letrec macro.)
I have the feeling that all these ideas have a common unifying notion
but unfortunately I haven't seen the light yet...
> If I come up with any ultimate solutions, I'll be sure to let everyone
> know - perhaps in a cross-posted thread entitled "ANN: Lisp-2 vs Lisp-1
> argument has been settled"... Oh, that's been used already? ;)
Oh dear. :)
Pascal
In article <······························@news.netcologne.de>, Pascal
Costanza <········@web.de> wrote:
> Erann has some nice ideas in this regard by embedding this into the
> locales concept borrowed from T.
Described in http://www.flownet.com/gat/locales.pdf (also noted in another
post in this thread).
> I think it could also be a good idea to
> tie this to the package system of Common Lisp.
No, I don't think so. Packages and namespaces are completely orthogonal
to one another (a fact that my paper, I regret to say, does not make very
clear). Packages map strings to symbols. Namespaces map symbols (and
possibly other things as well) to values. The two have nothing to do with
one another, except that sometimes, because CL has no standardized module
system, packages are sometimes used (inappropriately IMHO) as erzatz
modules.
If anyone really wants to get into this discussion here we should probably
start a different thread.
E.
On Sun, 10 Aug 2003 14:06:12 -0700, ···@jpl.nasa.gov (Erann Gat) wrote:
> packages are sometimes used (inappropriately IMHO) as erzatz
> modules.
"ersatz" - one of the few English words borrowed from German
From: Kenny Tilton
Subject: Re: Looking for examples of lisp-2's expressiveness
Date:
Message-ID: <3F3392AC.1050505@nyc.rr.com>
Anton van Straaten wrote:
> Kent M Pitman wrote:
>>>The real point was that a system that allowed the tokens FUNCALL,
>>
> FUNCTION
>
>>>and #' to be globally removed without impacting behavior would seem,
>>
> under a
>
>>>naive shorter-is-better metric, to be better.
>>
>>I don't agree with this claim. It's a personal choice. I know there
>>are people that make this claim personally for themselves, and perhaps
>>that's all you are doing here
>
>
> OK, sorry, but you're completely missing my point. I'll recap: Kenny Tilton
> said, "I seriously believe that shorter is an
> absolute measure of correctness". I wanted to point out that this claim is
> questionable. As a highly relevant example - perhaps *too* relevant - I
> chose to use Lisp-1 vs. Lisp-2.
>
> It is a demonstrable fact that any Lisp-2 program can be converted to a
> Lisp-1 program of equal or shorter length. The only possible exception
> would a program in which every single name in both function and variable
> namespaces was used, but nothing like that has existed since the days when
> some languages were limited to variable names of a single alphabetic
> character and a single numeric digit. Discounting that possibilty, we're
> left with the fact that the occurence of even a single FUNCALL or #' in a
> Lisp2 program would mean that the equivalent Lisp1 program would be shorter.
>
> Given the fact that I have just stated, then *by Kenny's proposition*,
> Lisp-1 would be "absolutely more correct".
Must I include "all other things being equal" in every sentence I write?
:)
The context was the funny bit about what happens to (cdr (assq ...)) in
"T", where unless I am mistaken, the only benefit of the transformation
was that it made T happy. ie, all other things were equal.
I also talked about how I backed off a refactoring sweep if I found
myself adding code here and there to accommodate the refactoring; good
ones make code go away. (Did one last night--hellasweet!) ie, I am
fiddling with a perfectly good little function just to support the
refactoring (all things equal) and suddenly I am adding this and
checking that and decrementing something else .... goodbye design change!
btw, if you want to see a language where brevity /is/ close to being an
only-thing-considered attribute, try K:
http://www.kx.com/a/k/readme.txt
I mean, they also love "fast", but in one introductory doc they maintain
that shorter is better because (paraphrasing just a bit) there is less
air for bugs to breathe. Here is a short sample they chose to showcase
in the above URL:
/ options, cf. "one factor option model ...", Black, Derman, Toy
/ typical c program is many pages. difficult to write. and slower.
bdt:{[p;v] bn:{.5*+':0,x,0} / binomial step function
l:(-1+%%':p)*_exp v*(2*!:'x+1)-x:1_!#p / generate approximate lattice
l:{x:bn x;x%1+y*(+/x%1+y*)?z}\[,*p;l;1_ p] / fit wtd-discount exactly
(*l){x%bn y}':l} / wtd-disc to forward
bdt[*\3#%1.1;.1]
Yes, the inventor came from the land of APL.
Now I happen to think this particular example of shorter is a bad idea
as a rule (tho I could see how it could be fun for straight-line DB
crunching). Since you seem to be my spokesman <g>, how do you reconcile
my dislike of brevity in this case with the "shorter is an absolute
good" you offered on my behalf?
btw, I agree with KP -- tho I had never thought about it before because
I have never used an L1 -- that while it would be cool to just code:
(defun filter (stuff test) (test stuff))
...I kinda like being hit over the head with the funcall. Well, I could
hit my head with good variable names:
(defun filter (stuff test-fn) (test-fn stuff))
... but then I still have to worry about clashing with function names.
You know, this is funny. The rest of lisp-nyc has lost all faith in my
ability to produce a RoboCup client and have abandoned me (right, they
have killed the Kenny project) to work on porting a C++ client (and a
good one) to Lisp. Of course since I am the only one with a work ethic,
being a good soldier I have to do that, too.
We were looking at a bunch of enums: CMD_KICK, FLAG_T_R_30, etc. They
would look lovely as symbols, but the enummed values do not just
differentiate the different symbols to C, they also get used to index
into arrays. Since plists are old-school and I'm a 90s Lispnik, it took
me a while to realize my enum macro, which was expanding into a slew of
defconstants, could instead simply jam the numeric value into a property
on the symbol. then we could do something sick with the reader and have
[CMD_KICK} expand into (get 'CMD_KICK 'enum). (Right? I have never done
a read macro.)
Getting back to L1 v. L2, I was showing the group newbies (lisp-nyc has
attracted a few) aref and how bigLongArrayName[CMD_KICK} becomes:
(aref bigLongArrayName CMD_KICK) ([CMD_KICK] by by new scheme)
but now it occurs to me, ha!, ya big dummy, this is Lisp-2!:
(defun bigLongArrayName (cmd index2 index3)
(aref bigLongArrayName cmd index2 index3))
..and then:
(+ 42 (bigLongArrayName [CMD_KICK] x2 x3)
Isn't Lisp-2 great? Looks shorter than (aref ...) as well. :)
Meanwhile, I am darn close to having things arranged so I can work on
RoboCup The Lisp Way, even tho the soccer server does not support
"(new_game)". It does offer a trainer mode in which I can at least stop
and restart, I just cannot make the server forget a player once it has
been seen. I mean, i can get it off the field, but i cannot just say
"new_game" and add players, I have to reconnect to players it saw
before. But with that restriction, i will soon no longer have to bounce
the server (and monitor connection to the server) for every iterative test.
Game on!
--
kenny tilton
clinisys, inc
http://www.tilton-technology.com/
---------------------------------------------------------------
"Career highlights? I had two. I got an intentional walk from
Sandy Koufax and I got out of a rundown against the Mets."
-- Bob Uecker
Kenny Tilton wrote:
> > Given the fact that I have just stated, then *by Kenny's proposition*,
> > Lisp-1 would be "absolutely more correct".
>
> Must I include "all other things being equal" in every sentence I write?
> :)
Speaking as a wannabe academic, I'd rather you used the proper Latin,
ceteris paribus.
What I said originally was intended lightheartedly, to illustrate a similar
point to the the one you just made with the K language. I then had to
explicate my point in great detail for someone else, but I didn't originally
intend to make that much out of it. So no, no qualifiers necessary.
> Since you seem to be my spokesman <g>, how do you reconcile
> my dislike of brevity in this case with the "shorter is an absolute
> good" you offered on my behalf?
There's a difference between being your spokesman and being your logical
conscience. :)
But, I'd note that there are different kinds of conciseness. Using really
short names is one kind that can lead to overly cryptic code. The K example
seems to fall mainly into that realm. If you expanded each K token into a
descriptive word, it might be not much more concise than equivalent Lisp.
Short-name conciseness is a fairly trivial sort of conciseness that's not
particularly meaningful - actually, a little like the Lisp1/Lisp2
discussion, if all you're doing is renaming things, in an absolute sense,
you've made no real difference. So that's not conciseness so much as the
illusion of conciseness. The kind of conciseness you can get with macros is
much more significant. As your spokesman, I'd say that your Buddhist
instincts noticed the illusory nature of the concisenesss of K.
> btw, I agree with KP -- tho I had never thought about it before because
> I have never used an L1 -- that while it would be cool to just code:
>
> (defun filter (stuff test) (test stuff))
>
> ...I kinda like being hit over the head with the funcall. Well, I could
> hit my head with good variable names:
>
> (defun filter (stuff test-fn) (test-fn stuff))
>
> ... but then I still have to worry about clashing with function names.
When you've only worked with one style, it can be hard to imagine quite how
much of a non-issue something can be in another style. You learn how to
read & write code in the language you're using. Schemers don't spend *any*
time worrying about clashes with function names, as far as I've ever seen -
at least, no more time than you spend worrying about function names clashing
with other function names. The way I'd put it is that you just learn not to
do things like (cons (car cons) (cdr cons)), which doesn't seem like a loss
to me, but then I'm not a fan of pointless puns.
When I have some time, I'll post an explanation of what life is like in
Lisp1, and why it makes sense to use it in a language like Scheme.
One thing I'll note is that "being hit over the head with the funcall" might
not be as helpful if you're writing in a highly functional style, relying
heavily on higher order functions. Other languages that have separate
function/variable namespaces - like Java - tend not to support higher-order
functions very well at all, so they don't run into the issue. I'm not aware
of any functional languages that use dual namespaces, although it would be
interesting to see one. I don't think I've ever seen any CL code written in
a highly functional style - are there any examples out there? (Notice how I
tastefully refrained from saying "I've never seen any highly functional CL
code..." :)
> You know, this is funny. The rest of lisp-nyc has lost all faith in my
> ability to produce a RoboCup client and have abandoned me (right, they
> have killed the Kenny project)
I guess I have to help you out here: Omigod, they killed the Kenny project!
You bastards!
> to work on porting a C++ client (and a good one) to Lisp.
> Of course since I am the only one with a work ethic,
> being a good soldier I have to do that, too.
Sounds like typical club stuff... Good luck!
Anton
From: Kenny Tilton
Subject: Re: Looking for examples of lisp-2's expressiveness
Date:
Message-ID: <3F33E38D.4040409@nyc.rr.com>
Anton van Straaten wrote:
> Kenny Tilton wrote:
>
>>>Given the fact that I have just stated, then *by Kenny's proposition*,
>>>Lisp-1 would be "absolutely more correct".
>>
>>Must I include "all other things being equal" in every sentence I write?
>> :)
>
>
> Speaking as a wannabe academic, I'd rather you used the proper Latin,
> ceteris paribus.
Ooooh, I like it! Nice concise language. Hmmmm....
> .... As your spokesman, I'd say that your Buddhist
> instincts noticed the illusory nature of the concisenesss of K.
No, i didn't, but that's a nice spin. Tou're hired.
> ...I don't think I've ever seen any CL code written in
> a highly functional style - are there any examples out there?
I think my setf count is way below average for a Lispnik. I doubt I
reach "highly" status though, because I don't turn reasonable practices
into absolute dictators. Love that mud.
--
kenny tilton
clinisys, inc
http://www.tilton-technology.com/
---------------------------------------------------------------
"Career highlights? I had two. I got an intentional walk from
Sandy Koufax and I got out of a rundown against the Mets."
-- Bob Uecker
From: Kenny Tilton
Subject: Re: Looking for examples of lisp-2's expressiveness
Date:
Message-ID: <3F3659E5.9060804@nyc.rr.com>
btw...
Anton van Straaten wrote:
> Kenny Tilton wrote:
>>You know, this is funny. The rest of lisp-nyc has lost all faith in my
>>ability to produce a RoboCup client and have abandoned me (right, they
>>have killed the Kenny project)
>
>
> I guess I have to help you out here: Omigod, they killed the Kenny
project!
> You bastards!
I knew I could count on your literacy. Which means you know they can
kill Kenny as many times as they like, but they will still have to play
me at ILC 2003! TeamKenny lives on! If NYC can have two baseball teams
it can have two RoboCup teams!!
Those guys are like George Steinbrenner, just grabbing good players from
other teams, not developing them from scratch. That's why nobody likes
the Yankees, but everyone loves the 28-games-out and counting Mets.
I'll see those back-stabbing, C++-plagiarizing*, tulip-sniffing,
windmill-hugging**, non-Cells-using bastards on the .27 dot
active-matrix pitch and show them whose house they're in!
[Just trying to sell some tickets. <g>]
* No, it's a BSD-style license and folks are meant to build on each
other's efforts
** They are copying UVA TriLearn. As in "University of Amsterdam".
--
kenny tilton
clinisys, inc
http://www.tilton-technology.com/
---------------------------------------------------------------
"Career highlights? I had two. I got an intentional walk from
Sandy Koufax and I got out of a rundown against the Mets."
-- Bob Uecker
From: Kenny Tilton
Subject: C++ to Lisp Translator? [was Re: Looking for examples of lisp-2's expressiveness]
Date:
Message-ID: <3F365EE3.6000900@nyc.rr.com>
Kenny Tilton wrote:
> I'll see those back-stabbing, C++-plagiarizing*, tulip-sniffing,
> windmill-hugging**, non-Cells-using bastards on the .27 dot
> active-matrix pitch and show them whose house they're in!
>
> [Just trying to sell some tickets. <g>]
>
> * No, it's a BSD-style license and folks are meant to build on each
> other's efforts
>
> ** They are copying UVA TriLearn. As in "University of Amsterdam".
>
btw, it's 28k LOC. C++ but vanilla. It's actually kinda funny because I
see signs that it was originally a C client ported to C++. By the time
we have a Lisp version you'll be able to do an archaeological dig on the
damn thing.
The manual translation will be a huge drag and make it easy to introduce
a kazillion hard-to-find bugs. Does anyone know of a C++ to Lisp
translator? What with the coming ascendancy of Lisp we are going to need
one anyway.
I know cparse does headers. We also are looking at PCCTS:
http://www.empathy.com/pccts/
Not a translator, but it does the hard part, parsing the C++. We're
thinking step one is to suck in the C++ and get it parsed, then pretty
much just dump it out in sexpr form so the reader can pull it in and let
the interesting stuff be done in Lisp. That lets us run the C++>sexpr
thing once and forget it.
Hell, maybe we can even do a C++ interpreter.
:)
--
kenny tilton
clinisys, inc
http://www.tilton-technology.com/
---------------------------------------------------------------
"Career highlights? I had two. I got an intentional walk from
Sandy Koufax and I got out of a rundown against the Mets."
-- Bob Uecker
Kenny Tilton wrote:
> > ** They are copying UVA TriLearn. As in "University of Amsterdam".
> >
>
> btw, it's 28k LOC. C++ but vanilla. It's actually kinda funny because I
> see signs that it was originally a C client ported to C++. By the time
> we have a Lisp version you'll be able to do an archaeological dig on the
> damn thing.
>
> The manual translation will be a huge drag and make it easy to introduce
> a kazillion hard-to-find bugs. Does anyone know of a C++ to Lisp
> translator? What with the coming ascendancy of Lisp we are going to need
> one anyway.
>
> I know cparse does headers. We also are looking at PCCTS:
>
> http://www.empathy.com/pccts/
>
> Not a translator, but it does the hard part, parsing the C++. We're
> thinking step one is to suck in the C++ and get it parsed, then pretty
> much just dump it out in sexpr form so the reader can pull it in and let
> the interesting stuff be done in Lisp. That lets us run the C++>sexpr
> thing once and forget it.
I haven't used this and don't know what its status is, but maybe this could
help:
http://www.gccxml.org/HTML/Index.html
It uses the GCC front end to parse C++ and generate XML. I could imagine
(but don't know for sure) that using Lisp to suck in an XML representation
of the C++ code *might* get you to sexprs quicker than using a regular
parser API. OTOH, the XML representation is based on "GCC's internal
representation", and I don't know if it might be more granular than you care
about.
If you tell me where I can download that UVA code, I'll take a look. I've
been using C++ since the '80s, and I converted a fairly complex stockmarket
analysis program from C++ to Scheme (by hand), with excellent results. The
application is described here: http://www.appsolutions.com/HedgeFund/
> Hell, maybe we can even do a C++ interpreter.
>
> :)
Oh, sure! Wonder why no-one's ever done that before? :)
Anton
From: Kenny Tilton
Subject: Re: C++ to Lisp Translator? [was Re: Looking for examples of lisp-2's expressiveness]
Date:
Message-ID: <3F36A80C.6000507@nyc.rr.com>
Anton van Straaten wrote:
> I haven't used this and don't know what its status is, but maybe this could
> help:
> http://www.gccxml.org/HTML/Index.html
> It uses the GCC front end to parse C++ and generate XML. I could imagine
> (but don't know for sure) that using Lisp to suck in an XML representation
> of the C++ code *might* get you to sexprs quicker than using a regular
> parser API.
Yep.
> OTOH, the XML representation is based on "GCC's internal
> representation", and I don't know if it might be more granular than you care
> about.
We're thinking we move faster on a literal translation ("no thinking!"
is the team motto), so bring on them grains.
>
> If you tell me where I can download that UVA code, I'll take a look.
http://carol.wins.uva.nl/~jellekok/robocup/2002/index_en.html
down a page or two, in the section withe the heading "source".
> been using C++ since the '80s, and I converted a fairly complex stockmarket
> analysis program from C++ to Scheme (by hand), with excellent results. The
> application is described here: http://www.appsolutions.com/HedgeFund/
cool. were you converting from C++ to Scheme at the same time? That
would be a good Road to Lisp story:
http://www.cliki.net/The%20RtLS%20by%20Road
Thx for the parser info. I forwarded it to the bastards working on
TeamC++. :)
--
kenny tilton
clinisys, inc
http://www.tilton-technology.com/
---------------------------------------------------------------
"Career highlights? I had two. I got an intentional walk from
Sandy Koufax and I got out of a rundown against the Mets."
-- Bob Uecker
Anton van Straaten wrote:
> Kenny Tilton wrote:
>>Hell, maybe we can even do a C++ interpreter.
>>:)
> Oh, sure! Wonder why no-one's ever done that before? :)
I know you were joking, but these guys actually did it:
<http://root.cern.ch/root/Cint.html>
Their homepage says the interpreter covers 95% of Ansi C
and 85% of C++.
The interpreter is written in C and can interpret it self.
Their motivation? They wanted to write scripts in C/C++
and didn't like the edit/compile/link-cycle ...
I guess the lispny'cers can reduce the problem of
writing a C++-interpreter to writing a C-interpreter :-)
- and if one uses the C->bytecode compiler in the
C-intepreter EiC then one only lacks a VM .
<http://eic.sourceforge.net/overview/>
--
Jens Axel S�gaard
In article <················@nyc.rr.com>, Kenny Tilton
<·······@nyc.rr.com> wrote:
> I know cparse does headers. We also are looking at PCCTS:
>
> http://www.empathy.com/pccts/
If anyone actually gets this to compile under Unix I'd be very interested
to learn how you did it. The unix distro on this site seems to be very
old and have some pieces missing.
I also found this:
http://www.jguru.com/faq/view.jsp?EID=531848
"...C++ is pretty much impossible to parse by merely writing up its
grammar and running it through ANTLR, YACC or whatever tool. ... C++ is
just plain ambiguous as hell unless you have infinite lookahead."
Wonderful. And this is the language that we're building our IT
infrastructure on top of. :-(
E.
From: Joe Marshall
Subject: Re: Looking for examples of lisp-2's expressiveness
Date:
Message-ID: <65l1e0s5.fsf@ccs.neu.edu>
"Anton van Straaten" <·····@appsolutions.com> writes:
> It is a demonstrable fact that any Lisp-2 program can be converted to a
> Lisp-1 program of equal or shorter length.
If you GZIP the source, it'll be even shorter. It's a bit trickier to
type, though.
On Fri, Aug 08, 2003 at 04:13:43AM +0000, Anton van Straaten wrote:
> It is a demonstrable fact that any Lisp-2 program can be converted to a
> Lisp-1 program of equal or shorter length.
I disagree. Being forced to choose names such as 'type-var' instead of
'type' will make the program longer and will greatly outnumber the
usages of FUNCALL or #' in a typical CL program. Being able to fudge
variable names such as 'typ' or 'lst' does not count, because it leads
to a loss of clarity in all but the most common cases. I prefer the
proper name to be used where it can be, rather than descending into the
shortened-variable-name-hell that mars much code in the functional
languages like ML and Haskell (gotta love when TAs give you code with
stuff like 'ty' and 'db' all over it, not to mention the universal 'x'
and to make it even more clear 'xs').
--
; Matthew Danish <·······@andrew.cmu.edu>
; OpenPGP public key: C24B6010 on keyring.debian.org
; Signed or encrypted mail welcome.
; "There is no dark side of the moon really; matter of fact, it's all dark."
Kent M Pitman <······@world.std.com> wrote:
+---------------
| When there are two namespaces, there are, in effect, twice as many
| names of any given length since names in a given context are being
| used up only half as fast. That is, in a Lisp1, there are only 26
| one-letter names, but in a Lisp2 there are 52 storage locations named
| by one-letter names. And so on.
+---------------
"And so on", indeed! Given the near-universal naming conventions
followed by practitioners of CL for globals, one could even argue
that there are actually *104* [pardon the pun] storage locations
named by "one-letter" names... ;-} ;-}
-Rob
-----
Rob Warnock, PP-ASEL-IA <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
"Anton van Straaten" <·····@appsolutions.com> wrote in message news:<······················@newsread1.prod.itd.earthlink.net>...
> It's hard to see how something could be "much easier" to implement in
> lisp-2, since lisp-1 can express any lisp-2 program, as long as any
> conflicting names are changed so as not to conflict.
Beats me too, but I don't know if some emergent property turns out to
be pretty big. For example, the Pitman/RPG paper says lisp-1 might
interact badly with special variables. So there might be a bunch of
places where weird things can happen.
Reminds me of Alonzo Church teaching a class: "Once he had to use a
variant of a previously proved theorem, which differed only by a
change of notation. After a moment of silence, he turned to the class
and said, 'I could simply say "likewise," but I'd better prove it
again.'"
http://www.kokogiak.com/amazon/detpage.asp?sb=s&asin=0817638660&field-keywords=indiscrete+thoughts&schMod=books&type=
When I skimmed through the flames advocating lisp-1, it seemed the
lisp-1 arguments suffered because many tended to portray switching as
just some localized change. IMO.
Tayss wrote:
> I remember someone (Pascal Costanza?) once mentioned a code snippet
> that was much easier to implement in lisp-2 than in a hypothetical
> lisp-1 CL. I've been trying to search for it to no avail. Does
> anyone know any examples to think about?
Might the following have been the snippet in question? It's from the last
exciting Lisp1/Lisp2 discussion. Code is at the bottom of this message:
http://groups.google.com/groups?selm=aRLAa.18%24R02.36395%40news2.telusplane
t.net
Anton
In article <····················@newsread1.prod.itd.earthlink.net>,
"Anton van Straaten" <·····@appsolutions.com> wrote:
> Tayss wrote:
> > I remember someone (Pascal Costanza?) once mentioned a code snippet
> > that was much easier to implement in lisp-2 than in a hypothetical
> > lisp-1 CL. I've been trying to search for it to no avail. Does
> > anyone know any examples to think about?
>
> Might the following have been the snippet in question? It's from the last
> exciting Lisp1/Lisp2 discussion. Code is at the bottom of this message:
>
> http://groups.google.com/groups?selm=aRLAa.18%24R02.36395%40news2.telusplane
> t.net
It seems that it is still an open issue what "much easier" means, but
here is another suggestion:
AFAICT, a widely accepted idiom in the CL community is to give accessors
the same names as their respective slots. (Please correct me if I am
wrong.) Consider this example.
(defclass person ()
((name :accessor name :initarg :name)))
? (setf p (make-instance 'person :name "Pascal"))
#<person #xCE6576>
? (with-accessors ((name name)) p
name)
"Pascal"
How would you implement something similar to with-accessors/with-slots
with a Lisp-1 (say, in Swindle)? Especially if you still want to be able
to pass the accessors around as first-class functions inside a
wih-accessor/with-slot block?
(Note: I have picked this example because it is related to the argument
that the preference for Lisp-1/Lisp-2 is strongly connected to the
programming style one wants.)
Pascal
Pascal Costanza wrote:
> It seems that it is still an open issue what "much easier" means, but
> here is another suggestion:
>
> AFAICT, a widely accepted idiom in the CL community is to give accessors
> the same names as their respective slots. (Please correct me if I am
> wrong.) Consider this example.
>
> (defclass person ()
> ((name :accessor name :initarg :name)))
>
> ? (setf p (make-instance 'person :name "Pascal"))
>
> #<person #xCE6576>
>
> ? (with-accessors ((name name)) p
> name)
>
> "Pascal"
>
> How would you implement something similar to with-accessors/with-slots
> with a Lisp-1 (say, in Swindle)? Especially if you still want to be able
> to pass the accessors around as first-class functions inside a
> wih-accessor/with-slot block?
Here's a Swindle version of the above. I'm not an expert on Swindle's
tiny-clos implementation, so there may be other ways to do it:
(require (lib "swindle.ss" "swindle"))
(defclass person () (name :accessor name :initarg :name))
(define p (make person :name "Pascal"))
p
#(struct:swindleobj...)
(with-accessors p ((name name))
name)
"Pascal"
It looks as though Swindle makes some use of PLT Scheme's support for
multiple first-class namespaces, which gives the application control over
what it does with namespaces.
As far as passing the accessors around as 1st-class functions in a with-*
block, give me an example and I'll try it.
> (Note: I have picked this example because it is related to the argument
> that the preference for Lisp-1/Lisp-2 is strongly connected to the
> programming style one wants.)
Yes - along those lines, I tend not to use CLOS-like objects much, because
they don't really lend themselves to a functional programming style, which
I've come to prefer.
Anton
In article <····················@newsread1.prod.itd.earthlink.net>,
"Anton van Straaten" <·····@appsolutions.com> wrote:
> Here's a Swindle version of the above.
[...]
OK, looks good so far.
> As far as passing the accessors around as 1st-class functions in a with-*
> block, give me an example and I'll try it.
The following example might seem a little artificial, but I think
similar situations can occur in practice.
(defclass person ()
((name :accessor name :initarg :name)))
(setf p (make-instance 'person :name "Pascal"))
(with-accessors ((name name)) p
name)
(defun exec-and-print (fun p)
(print (funcall fun p)))
(with-accessors ((name name)) p
(print name)
(exec-and-print #'name p))
Here, the call of exec-and-print doesn't need the bindings of the
surrounding with-accessors block, but you get the idea (I hope ;).
Pascal
Pascal Costanza wrote:
> "Anton van Straaten" <·····@appsolutions.com> wrote:
>
> > Here's a Swindle version of the above.
> [...]
>
> OK, looks good so far.
>
> > As far as passing the accessors around as 1st-class functions in a
with-*
> > block, give me an example and I'll try it.
>
> The following example might seem a little artificial, but I think
> similar situations can occur in practice.
>
> (defclass person ()
> ((name :accessor name :initarg :name)))
>
> (setf p (make-instance 'person :name "Pascal"))
>
> (with-accessors ((name name)) p
> name)
>
> (defun exec-and-print (fun p)
> (print (funcall fun p)))
>
> (with-accessors ((name name)) p
> (print name)
> (exec-and-print #'name p))
>
>
> Here, the call of exec-and-print doesn't need the bindings of the
> surrounding with-accessors block, but you get the idea (I hope ;).
As expected, in Scheme this does require something additional to access the
top-level definition of 'name'. There are various alternatives. You can
pass a symbol instead of a function value in the last line, i.e.:
(with-accessors p ((name name))
(print name)
(exec-and-print 'name p))
...and have exec-and-print look that symbol up to obtain the procedure it
represents. An R5RS-standard way to do this would simply use eval, which
has the advantage that it works whether a symbol or a function value is
passed:
(define (exec-and-print fun p)
(print ((eval fun) p)))
With these changes, the above code works.
If you consider 'eval' too heavyweight, you could substitute a
implementation-specific namespace lookup, e.g. in PLT:
(define (exec-and-print fun p)
(print ((namespace-variable-value fun) p)))
This would limit exec-and-print to accepting symbols, so you'd need a cond
if you wanted it to accept function values also.
A more general way to solve this problem is to define an operation to
retrieve a top-level value from anywhere. I'll do it as a macro to avoid
the need for quoting the provided name:
(define-syntax top (syntax-rules () ((top name) (namespace-variable-value
'name)))
(with-accessors p ((name name))
(print name)
(exec-and-print (top name) p))
This is nice and general, can be used from anywhere, and makes it clear that
a top-level value is being referenced. In a sense, it works similarly to
using #', but being in a Lisp1, 'top' will return any top-level value,
function or otherwise. (Of course, you could add a typecheck if you wanted
to restrict it to function types for some reason).
A solution that appealed to my sense of perversity is to give Scheme a
FUNCALL operator, and define it like this:
(define (funcall fun . args)
(apply
(cond
((symbol? fun) (namespace-variable-value fun))
(else fun))
args))
So if you provide funcall with a symbol instead of a function, it looks it
up at the top level. Given that definition, exec-and-print can be left
alone, and the only change needed is to remove the # sign in the
with-accessors block.
Anton
In article <····················@newsread1.prod.itd.earthlink.net>,
"Anton van Straaten" <·····@appsolutions.com> wrote:
Thanks a lot for sketching the various alternatives in Scheme!
> As expected, in Scheme this does require something additional to access the
> top-level definition of 'name'. There are various alternatives. You can
> pass a symbol instead of a function value in the last line, i.e.:
>
> (with-accessors p ((name name))
> (print name)
> (exec-and-print 'name p))
>
> ...and have exec-and-print look that symbol up to obtain the procedure it
> represents. An R5RS-standard way to do this would simply use eval, which
> has the advantage that it works whether a symbol or a function value is
> passed:
>
> (define (exec-and-print fun p)
> (print ((eval fun) p)))
This has the disadvantage that you need to anticipate it in the
exec-and-print function.
> With these changes, the above code works.
>
> If you consider 'eval' too heavyweight, you could substitute a
> implementation-specific namespace lookup, e.g. in PLT:
>
> (define (exec-and-print fun p)
> (print ((namespace-variable-value fun) p)))
Same as above.
> This would limit exec-and-print to accepting symbols, so you'd need a cond
> if you wanted it to accept function values also.
>
> A more general way to solve this problem is to define an operation to
> retrieve a top-level value from anywhere. I'll do it as a macro to avoid
> the need for quoting the provided name:
>
> (define-syntax top (syntax-rules () ((top name) (namespace-variable-value
> 'name)))
>
> (with-accessors p ((name name))
> (print name)
> (exec-and-print (top name) p))
>
> This is nice and general, can be used from anywhere, and makes it clear that
> a top-level value is being referenced. In a sense, it works similarly to
> using #', but being in a Lisp1, 'top' will return any top-level value,
> function or otherwise. (Of course, you could add a typecheck if you wanted
> to restrict it to function types for some reason).
Looks ok.
So the Common Lisp version is easier to implement but it's left open to
interpretation whether this means "much easier". ;)
Pascal
Pascal Costanza writes:
> Thanks a lot for sketching the various alternatives in Scheme!
Sure, I'm happy to be able to provide something constructive.
> > (define (exec-and-print fun p)
> > (print ((eval fun) p)))
>
> This has the disadvantage that you need to anticipate it in the
> exec-and-print function.
I agree, I was simply starting with the most direct and standard solution.
> > A more general way to solve this problem is to define an operation to
> > retrieve a top-level value from anywhere. I'll do it as a macro to
avoid
> > the need for quoting the provided name:
> >
> > (define-syntax top (syntax-rules () ((top name)
(namespace-variable-value
> > 'name)))
> >
> > (with-accessors p ((name name))
> > (print name)
> > (exec-and-print (top name) p))
> >
> > This is nice and general, can be used from anywhere, and makes it clear
that
> > a top-level value is being referenced. In a sense, it works similarly
to
> > using #', but being in a Lisp1, 'top' will return any top-level value,
> > function or otherwise. (Of course, you could add a typecheck if you
wanted
> > to restrict it to function types for some reason).
>
> Looks ok.
>
> So the Common Lisp version is easier to implement but it's left open to
> interpretation whether this means "much easier". ;)
One question, though, is whether anything would really be lost by simply
naming things differently. That's where I see preference coming in. For
myself, I'm not crazy with having multiple things floating around, in the
same place, all named 'name'. I think it can create semantic overhead for a
human reader. I realize it's done in a way where you usually don't need to
worry about disambiguation, and I'm sure you get used to it, but that goes
both ways.
Another point is that something like my 'top' macro only needs to be written
once. If all that's required to bring the two different namespace
approaches into rough parity is a short macro or so, the expressiveness
argument doesn't fly. It would be different if extra effort were required
throughout a body of code.
Anton
In article <····················@newsread1.prod.itd.earthlink.net>,
"Anton van Straaten" <·····@appsolutions.com> wrote:
> > So the Common Lisp version is easier to implement but it's left open to
> > interpretation whether this means "much easier". ;)
>
> One question, though, is whether anything would really be lost by simply
> naming things differently. That's where I see preference coming in. For
> myself, I'm not crazy with having multiple things floating around, in the
> same place, all named 'name'. I think it can create semantic overhead for a
> human reader.
Obviously, it doesn't. I have seen this several times in CLOS code, and
I haven't heard any complaints about this yet.
(Perhaps this is an important thing we shouldn't overlook in such
discussions: There are people out there who tried both Lisp-1 and
Lisp-2, have chosen one or the other, perhaps for totally different
reasons than the Lisp-N-ness, and they simply don't have the problems
that "the other side" worries about.)
> I realize it's done in a way where you usually don't need to
> worry about disambiguation, and I'm sure you get used to it, but that goes
> both ways.
>
> Another point is that something like my 'top' macro only needs to be written
> once. If all that's required to bring the two different namespace
> approaches into rough parity is a short macro or so, the expressiveness
> argument doesn't fly. It would be different if extra effort were required
> throughout a body of code.
One could be nitpicking by saying that the top macro isn't portable
Scheme code, but this wouldn't be a good argument either because
Schemers don't seem to value portability that much.
I conclude two things from this example:
- Lisp-2 makes some code cumbersome (need to add funcalls and #'s), but
Lisp-1 makes other code equally cumbersome (need to add a top macro, or
devise funny names). With regard to coding convenience they are more or
less on par.
- Although I prefer Lisp-2 over Lisp-1, I wouldn't mind programming in a
Lisp-1 if I had to.
Anton: Thanks for helping me to understand the issues involved a little
bit better!
Pascal
Pascal Costanza wrote:
> "Anton van Straaten" <·····@appsolutions.com> wrote:
> > One question, though, is whether anything would really be lost by simply
> > naming things differently. That's where I see preference coming in.
For
> > myself, I'm not crazy with having multiple things floating around, in
the
> > same place, all named 'name'. I think it can create semantic overhead
for a
> > human reader.
>
> Obviously, it doesn't. I have seen this several times in CLOS code, and
> I haven't heard any complaints about this yet.
But perhaps you're more used to that, or the possibility of it. That's
really my point. Maybe it does create overhead, but maybe you get used to
it; or maybe it only creates overhead for someone used to something
different; or maybe I'm imagining it. It's tough to prove either way.
> (Perhaps this is an important thing we shouldn't overlook in such
> discussions: There are people out there who tried both Lisp-1 and
> Lisp-2, have chosen one or the other, perhaps for totally different
> reasons than the Lisp-N-ness, and they simply don't have the problems
> that "the other side" worries about.)
I agree - that's what I meant by where preference comes in. I should also
say familiarity, since obviously we're more comfortable with the familiar.
But issues like this should be far from being deciding factors, in choosing
to use or avoid a language or dialect, IMO. That would be a lot like
choosing not to use Lisp at all, because of parentheses - which of course, a
lot of people do, but are they right to do that?
There's an aspect of this discussion elsewhere in the thread that's been
somewhat amusing, where the idea of certain kinds of "pun" on function names
are greeted with horror, whereas we've just been discussing another kind of
pun on function names as being desirable. And strangely enough, the kind of
puns each dialect supports are exactly the kind of puns the users of that
dialect prefer! Spooky! ;)
A point about the overall discussion (not our friendly little subthread) is
that it's reasonable to choose to defend Lisp2 or Lisp1 because that's what
the language you use has, but it's something else entirely to extend that to
saying that one is so much better than the other that the other is, e.g.
"like walking through a minefield", as some have claimed. It seems to me
that what's happening is that a not-particularly-crucial feature that
happens to be different is being used as ammo, just because it is different.
> One could be nitpicking by saying that the top macro isn't portable
> Scheme code, but this wouldn't be a good argument either because
> Schemers don't seem to value portability that much.
I would put that differently. :) R5RS is clearly intended to be a
lowest-common-denominator standard, which truly does define a family of
languages. Portability is important, but not as important as the
flexibility to e.g. run Scheme on the JVM, in embedded environments, in
various flavors of compiler, and numerous other variants. In all of these
cases, there are certain minimum semantics you can rely on, and other things
which have to be achieved through implementation-specific means.
For example, one Scheme implementation I use is SISC, which runs on the JVM.
I make use of its ability to interact with Java objects, which results in
Scheme code which isn't even remotely portable to a non-Java platform - but
that's what I want, in that situation. But if portability is important to
you, there are various options, including using the various SRFIs, or a
portable library like SLIB.
> With regard to coding convenience they are more or less on par.
I thought I "proved" that in my original post! ;o)
> - Although I prefer Lisp-2 over Lisp-1, I wouldn't mind programming in a
> Lisp-1 if I had to.
Ditto. I don't see any fundamental problem in coding in a Lisp-2.
> Anton: Thanks for helping me to understand the issues involved a little
> bit better!
Thanks, it's been great to have a reasoned discussion about this!
Anton