Well, almost all this discussion comes pointless again because of the
high theological contents of the Old Lisp Beards moaning, sticking to
'the' implementation to justify... nothing but the implementation.
The implementation is loose, because it has evolved from interpretive
environments by means of hack upon hack, that plaster the holes, but
gives only loose semantics in the end. Contrary to what B. Margolin
once said, nothing has been thrown out since old Maclisp.
Eval (if one really wants that), macros (do *not* require eval but
only dynamic loading), dynamic loading and binding, re-binding and so
on can all live with clean semantics. Having control over the compiler
state, and having the compiler state interfere with the data
manipulated by the programs really interests nobody but pedants (to
show lovely void tricks) and old-beard implementors, still sweating
from their effort to get that jewel out. People really do not program
like that, and do not use Lisp for that. They use Lisp to solve
problems, and solving problems never requires the pointer masturbation
advocated by those so-called gurus!
Quitting,
V. Delacour
[The name of the game is now to find out who are the (respectable) old
beards, and who is the pedant. Your flames to /dev/null]
In article <······················@waxwing.parc.xerox.com> ········@waxwing.parc.xerox.com (Vincent Delacour) writes:
>
>
>Well, almost all this discussion comes pointless again because of the
>high theological contents of the Old Lisp Beards moaning, sticking to
>'the' implementation to justify... nothing but the implementation.
This counter-flamage from the Young Lisp Beard perspective. Religion is
definitely involved -- Lisp programmers look at the "programming problem" so
differently from how you do that communication seems impossible.
>
>The implementation is loose, because it has evolved from interpretive
>environments by means of hack upon hack, that plaster the holes, but
>gives only loose semantics in the end. Contrary to what B. Margolin
>once said, nothing has been thrown out since old Maclisp.
Things have been thrown out, just none of the "loose" bits. We keep trying to
make it looser and looser... There is an important difference between "loose"
semantics and "vague" semantics:
-- "loose" semantics allow the writing of programs whose meaning is
non-obvious.
-- "vague" semantics makes the meaning of programs ill-defined.
It is clear that the result of standardization should be non-"vague" semantics.
It is not so clear that semantics should be non-"loose".
Any language that allows non-trivial extension must have some "loose"
semantics. If the meaning of any construct is immediately obvious, then it is
not a new language construct at all. This is another way of observing that
any non-lobotomized macro mechanism will have some "loose" semantics.
However, there is such a thing as unnecessary (and undesirable) "looseness".
"loose" semantics can obscure the meaning of a program, so should not be used
for no reason.
It could be that you are claiming that the package system is "unnecessarily
loose". That is quite possibly true, but there weren't any better ideas at the
time the language was designed, and I still haven't seen any fully developed
better ideas. Do you have one?
[translations in brackets]
>Having control over the compiler
>state, and having the compiler state interfere with the data
>manipulated by the programs
[known as meta-programming]
>really interests nobody but pedants (to show lovely void tricks)
[Some people are interested in meta-programming as a way to write
mind-bending hacks.]
>and old-beard implementors, still sweating from their effort to get that jewel
>out.
[Solving real problems using meta-programming is so hard only wizards can do
it.]
I mostly agree with these translated statements, though I hope that through a
combination of better education and better tools, meta-programming will become
less difficult. It will always be somewhat difficult, since meta-programming
involves doing language design as a part of the problem solution, in the hope
that the power gained by a more expressive problem-specific language will
offset the cost of designing the extension.
>People really do not program like that, and do not use Lisp for that.
[Lisp Beards are not human.]
I challenge this claim. Many are decidedly peculiar, but recognizably human
nonetheless.
>They use Lisp to solve problems, and solving problems never requires the
>pointer masturbation advocated by those so-called gurus!
[Any problem has a solution that doesn't require meta-programming.]
I can agree with this vacuous translation, but I suspect that this isn't what
the author intended. If he means:
[meta-programming is never the best way to solve a problem]
then he is wrong.
Rob MacLachlan (···@cs.cmu.edu)
In article <······················@waxwing.parc.xerox.com> ········@waxwing.parc.xerox.com (Vincent Delacour) writes:
>Having control over the compiler
>state, and having the compiler state interfere with the data
>manipulated by the programs really interests nobody but pedants (to
>show lovely void tricks) and old-beard implementors, still sweating
>from their effort to get that jewel out. People really do not program
>like that, and do not use Lisp for that.
I think you're just not familiar with some of the complex applications that
Lisp is often used for.
Consider the Programmer's Apprentice project at MIT, in which an expert
system is used to assist writing and debugging programs. This is a classic
example of an application that requires just the sort of meta-programming
that Lisp excels at.
Or how about the interface between an editor and a Lisp runtime, with
operations such as finding the source code for a function. If the editor
and Lisp are in the same address space (as on a Lisp Machine), they can
share data structures; the symbols that are used as identifiers to the
runtime system are just data to the editor. And even if they're not
integrated this tightly, the editor can use some I/O channel to send symbol
names to the Lisp system, which will convert them to symbols in order to
look up and send back the requested information.
The first example is still an ongoing research project (as it has been
since the late 70's), but the second is done every day at many sites that
use Lisp. They both depend on Lisp's ability to treat program text as
data.
--
Barry Margolin
System Manager, Thinking Machines Corp.
······@think.com {uunet,harvard}!think!barmar
In article <······················@waxwing.parc.xerox.com> ········@waxwing.parc.xerox.com (Vincent Delacour) writes:
>
>Well, almost all this discussion comes pointless again because of the
>high theological contents of the Old Lisp Beards moaning, sticking to
>'the' implementation to justify... nothing but the implementation.
At least you've given up the idea that we could make the changes
you suggest "without affecting the taste of the language".
However, Lisp is pragmatic. It's people like Vincent who are
ideologues and who think there's only one right way to do things,
and that God Himself drew the One True Line between language and
environment.
>The implementation is loose, because it has evolved from interpretive
>environments by means of hack upon hack, that plaster the holes, but
>gives only loose semantics in the end. Contrary to what B. Margolin
>once said, nothing has been thrown out since old Maclisp.
I take it you haven't actually looked at MacLisp then.
> People really do not program
>like that, and do not use Lisp for that. They use Lisp to solve
>problems, and solving problems never requires the pointer masturbation
>advocated by those so-called gurus!
People use Lisp to implement other languages all the time,
and this would be much harder if Vincent had his way. That's
just one example.
BTW, flames of Vincent's sort are surprisingly common. I've
heard a number of people say things just as extreme. I just
hope they don't all come swarming around when the CL draft
standard is finally issued.
The irony of it is that there are now implementations of C and C++
that are much more like implementations of Lisp. But for some
reason no one flames the implementors of C interpreters and
interactive programming environments.
-- jd
In article <······················@waxwing.parc.xerox.com> ········@waxwing.parc.xerox.com (Vincent Delacour) writes:
Date: 27 Feb 92 00:06:42 GMT
From: ········@waxwing.parc.xerox.com (Vincent Delacour)
The implementation is loose, because it has evolved from interpretive
environments by means of hack upon hack, that plaster the holes, but
gives only loose semantics in the end. Contrary to what B. Margolin
once said, nothing has been thrown out since old Maclisp.
This is emphatically false. In fact, a number of things in
CLtL I were thrown out from the standard! Others were not
quite literally taken out, but were "deprecated", which means
are supported ONLY for compatibility and should not be regarded
as part of the language you program in.
But regardless of the accuracy of your claim, I disagree with
what I perceive to be the motivation behind it. We're *NOT* engaged
in designing some theoretical new language to be used only
by future programs written by future programmers. There is
a *HUGE* amount of existing code out there which must either
be allowed to continue to work, or be allowed to be easily
migrated.
*NOBODY* has *EVER* claimed that this is the language we would
design if existing programs did not have to use it. Indeed,
there are certainly many areas where the semantics is loose
because of the constraints of history. There are also areas
where the semantics has been greatly tightened as well, because
we do regard semantics as an important part of a language.
However, your charactarizations of the semantics of identifiers
in Lisp *AND* in other languages have been flawed. It appears
that you have interpreted our disagreement with your characterizations
as blanket defense of all aspects of CL's semantics.
Eval (if one really wants that),
Considering that the "program as data" aspect is what has always
been regarded as Lisp's single most defining aspect, I can't
imagine anyone calling a language without EVAL "Lisp"!
macros (do *not* require eval but only dynamic loading),
Macros don't require either one! EVAL does require that macros
be kept around, however. I have used statically-linked Lisps.
Including a package system, by the way.
dynamic loading and binding, re-binding and so
on can all live with clean semantics.
Having control over the compiler
state, and having the compiler state interfere with the data
manipulated by the programs really interests nobody but pedants (to
show lovely void tricks) and old-beard implementors, still sweating
from their effort to get that jewel out.
I have no idea what this is refering to. If it's still
packages, why the sudden terminology shift to ill-defined
terms? And if it's packages, we've already shown you that
packages do NOT interfere with data manipulated by the programs.
People really do not program
like that, and do not use Lisp for that. They use Lisp to solve
problems, and solving problems never requires the pointer masturbation
advocated by those so-called gurus!
People *DO* use packages. People *DO* use them in ways like
what I described to you earlier, and do manage to manage to
have static bindings of names to variables. A few people haven't
gotten the message (because DEFPACKAGE wasn't a standard part
of the language before), and tried to use things in a way
which DOES cause problems, but those are diminishing, and not
an essential characteristic of the language.
Of course, I'm not sure that's what you're talking about here.
Quitting,
V. Delacour
[The name of the game is now to find out who are the (respectable) old
beards, and who is the pedant. Your flames to /dev/null]
I am not aware of a connection between pedantry and respectability.
There's many a respectable old prof with a tendency toward pedancy.
In my opinion, your insistance that Lisp must follow your model of
how it should work to be the very epitome of pedantry.
That doesn't mean that you haven't been honest and or unrespectable,
and I think that members of this group have been more than generous
with their time and patience in trying to explain things.
In return, you've been extremely rigid in your thinking and unwilling
to try looking at things in different ways, or to acknowledge that
there may be more than one set of concerns in designing a language, or
or to look again at whether you could perform your desired static
analysis on Common Lisp if it constrained by a well-defined set of
well-established principles of good Common Lisp programming.
I think that this is the real source of your dissatisfaction, and
not really the language. Your preconceived approach doesn't work
without modification, and so it is the language that must change.
It's very easy to get into this sort of mode of thinking. I'm in
the process right now of reevaluating my approach to representing
some knowledge in a knowledge representation system, when I came
up against some ways that the system has a different approach than
I originally thought.
This may all seem like pompous pedantry to you, or even arrogance.
Well, maybe it even is. But I'm including it in the hopes that
it might be helpful to you how it looks from my viewpoint.
If not, well, I've looked like a fool often enough, I suppose I'll
survive being an arrogant pompous pedant.
In article <·················@taunton.crl.dec.com> ···@taunton.crl.dec.com (Bob Kerns) writes:
>In article <······················@waxwing.parc.xerox.com> ········@waxwing.parc.xerox.com (Vincent Delacour) writes:
>
> Eval (if one really wants that),
>
>Considering that the "program as data" aspect is what has always
>been regarded as Lisp's single most defining aspect, I can't
>imagine anyone calling a language without EVAL "Lisp"!
>
This statement is made from time to time, but I thought I should point
out that Scheme has no eval but many people consider it to be lisp.
To be fair, I should add that some Schemers consider this to be a feature
and others a bug, so opinion on this issue is not unanimous.
--
Doug Quale
·····@saavik.cs.wisc.edu
In article <······················@daffy.cs.wisc.edu> ·····@saavik.cs.wisc.edu (Douglas E. Quale) writes:
>This statement is made from time to time, but I thought I should point
>out that Scheme has no eval but many people consider it to be lisp.
I was wondering whether someone would point that out.
>To be fair, I should add that some Schemers consider this to be a feature
>and others a bug, so opinion on this issue is not unanimous.
Note also that while the official Scheme definition doesn't have EVAL, just
about every Scheme *implementation* does.
--
Barry Margolin
System Manager, Thinking Machines Corp.
······@think.com {uunet,harvard}!think!barmar
In article <·················@taunton.crl.dec.com> ···@taunton.crl.dec.com (Bob Kerns) writes:
Eval (if one really wants that),
Considering that the "program as data" aspect is what has always
been regarded as Lisp's single most defining aspect, I can't
imagine anyone calling a language without EVAL "Lisp"!
Vincent's extreme statements seem to have inspired extreme responses.
Defining "Lisp" is a little like defining "game"; no one property can
serve to make it or break it, including this one. To cite two
examples, neither Scheme nor EuLisp have EVAL in the language,
although most implementations have it in the environment. Yet it
would be arguing in bad faith to claim that these two dialects were
not Lisp.
As RWK certainly knows, and would say if he weren't riled up, there are
any number of properties usually associated with Lisp, including but
not limited to:
* Extensive runtime libraries defining operations on lists, tables,
strings, vectors, and other datatypes.
* Late binding.
* Object rather than variable typing.
* Run-time creation of functions.
* Powerful macro mechanism.
* Simple syntax using parentheses.
* Code can be treated as data - as input to macro expanders, for example.
* Data can be treated as code (eg, EVAL).
* Powerful programming environments.
-- Harley Davis
--
------------------------------------------------------------------------------
nom: Harley Davis ILOG S.A.
net: ·····@ilog.fr 2 Avenue Gallie'ni, BP 85
tel: (33 1) 46 63 66 66 94253 Gentilly Cedex, France
In article <··················@passy.ilog.fr> ·····@passy.ilog.fr (Harley Davis) writes:
As RWK certainly knows, and would say if he weren't riled up, there are
any number of properties usually associated with Lisp, including but
not limited to:
* Extensive runtime libraries defining operations on lists, tables,
strings, vectors, and other datatypes.
* Late binding.
* Object rather than variable typing.
* Run-time creation of functions.
* Powerful macro mechanism.
* Simple syntax using parentheses.
* Code can be treated as data - as input to macro expanders, for example.
* Data can be treated as code (eg, EVAL).
* Powerful programming environments.
I forgot one of the most important:
* Garbage collection.
-- Harley Davis
--
------------------------------------------------------------------------------
nom: Harley Davis ILOG S.A.
net: ·····@ilog.fr 2 Avenue Gallie'ni, BP 85
tel: (33 1) 46 63 66 66 94253 Gentilly Cedex, France
In article <··················@passy.ilog.fr> ·····@passy.ilog.fr (Harley Davis) writes:
From: ·····@passy.ilog.fr (Harley Davis)
Date: 2 Mar 92 12:41:57 GMT
In article <·················@taunton.crl.dec.com> ···@taunton.crl.dec.com (Bob Kerns) writes:
Eval (if one really wants that),
Considering that the "program as data" aspect is what has always
been regarded as Lisp's single most defining aspect, I can't
imagine anyone calling a language without EVAL "Lisp"!
Vincent's extreme statements seem to have inspired extreme responses.
Defining "Lisp" is a little like defining "game"; no one property can
serve to make it or break it, including this one. To cite two
examples, neither Scheme nor EuLisp have EVAL in the language,
although most implementations have it in the environment. Yet it
would be arguing in bad faith to claim that these two dialects were
not Lisp.
Actually, I don't consider Scheme to be Lisp. It's
Lisp Family, but it's different enough to be considered
a separate language, not just a dialect, in my way of
categorizing things. (I won't get upset if you divide
things up differently).
Lack of EVAL is just one of the reasons.
I haven't decided how to categorize EuLisp; I don't know
enough about it.
Anyway, you gave a good list. In particular, what I was
getting at with my remark about EVAL is the following two
items from it:
* Code can be treated as data - as input to macro expanders, for example.
* Data can be treated as code (eg, EVAL).