I was trying to puzzle out why MAKUNBOUND removes the value from
the current dynamic binding rather than completely removing the
binding, allowing an earlier binding to "show through"[1].
The best explanation I came up with was that since one of the uses for
dynamic variables (per the PROGV dictionary entry) is to implement
interpreters that use dynamic binding, you might want MAKUNBOUND to
behave inside an embedded interpreter the same as it does at the
top-level--to cause the variable made unbound to reliably be unbound,
within the extent of the current binding, regardless of whether
there happens to be another binding higher up the stack.
Thus you could write code like this:
(defun my-interpreter (global-variables global-values code)
(progv global-variables global-values (eval code)))
without worrying that if code included a call to MAKUNBOUND of one of
the variables in global-variables, that that variable would suddenly
take on some random value from a binding established by one of
my-interpreters callers.
Is that more or less the point of MAKUNBOUND's behavior, vis a vis
nested bindings?
-Peter
[1] That is why, the LET form below gets an UNBOUND-VARIABLE error
rather than evaluating to 10:
(defvar *x*)
(let ((*x* 10)) (let ((*x* 20)) (makunbound '*x*) *x*))
--
Peter Seibel ·····@javamonkey.com
The intellectual level needed for system design is in general
grossly underestimated. I am convinced more than ever that this
type of work is very difficult and that every effort to do it with
other than the best people is doomed to either failure or moderate
success at enormous expense. --Edsger Dijkstra
Peter Seibel <·····@javamonkey.com> writes:
> I was trying to puzzle out why MAKUNBOUND removes the value from
> the current dynamic binding rather than completely removing the
> binding, allowing an earlier binding to "show through"[1].
Because dynamic bindings are not multiple bindings.
The spec is written vaguely as to whether implementations are shallow
or deep bound, but that's a latter day event.
If you are trying to understand the historical reason for what it does,
you should know that the culture in which MAKUNBOUND arose was Maclisp,
and Maclisp was shallow bound.
In a lexical binding, each 'value cell' is unique, generated on a
per-lexical-contour basis. MAKUNBOUND can't be used on a lexical binding
because there is no way to name it as data--lexical bindings can only be
named by variables, and there is no special form for making something
unbound. MAKUNBOUND works on symbols, and symbols have a value cell, and
dynamic bindings [in Maclisp and other old dialects from which CL
culturally descends, in contrast to Interlisp and its spaghetti stack,
from which CL does not descend] always use that cell. Binding a special
variable doesn't create a new binding object, it swaps the old value onto
the stack and leaves the _same_ binding object in effect, so that accesses
are fast (a single memory reference to a known location) since it's assumed
there may be many reads in a short time. There's a cost for process-swapping
for each special because the stack has to be walked and specials have to be
reset to their global values. I believe Roger Corman worked out a scheme
for doing what amount to per-process value cells to improve the process
swapping speed (presumably at the expense of space).
Furthermore, MAKUNBOUND was never intended to work on special bindings.
It simply does work on special bindings. It was intended to work on symbols
and there was no way to make it not work on special bindings. Removing
the binding was a meaningless concept historically, but worse, it has little
point. Stylistically, you should never MAKUNBOUND a special that you know
to have been locally rebound. MAKUNBOUND is an operator that is available
for establishing footholds and for manipulating global environments, it has
nothing to do with the use you are trying to find for it.
| The best explanation I came up with was that since one of the uses for
| dynamic variables (per the PROGV dictionary entry) is to implement
| interpreters that use dynamic binding, you might want MAKUNBOUND to
| behave inside an embedded interpreter the same as it does at the
| top-level--to cause the variable made unbound to reliably be unbound,
| within the extent of the current binding, regardless of whether
| there happens to be another binding higher up the stack.
To my knowledge this has never been a consideration.
| Is that more or less the point of MAKUNBOUND's behavior, vis a vis
| nested bindings?
No. The point was to legitimize the implementation of MAKUNBOUND in which
the global cell and the symbol-value of a symbol are the same. MAKUNBOUND is
an operation on symbols, not on variables; special variables happen to reside
in symbols, but you cannot substitute equals for equals in English text and
get meaningful truth. (The classic case in philosophy of language is that
if you know that the morning star is venus, it does not prove that you know
the evening star is venus, even though the morning star and evening star are
the same thing.)
Implementationally, there is an equivalent. But from the point of view of
purpose/intent, there is a world of difference.
Kent M Pitman <······@world.std.com> writes:
> Peter Seibel <·····@javamonkey.com> writes:
>
> > I was trying to puzzle out why MAKUNBOUND removes the value from
> > the current dynamic binding rather than completely removing the
> > binding, allowing an earlier binding to "show through"[1].
>
> Because dynamic bindings are not multiple bindings.
I'm pretty sure I understand what you mean by that. Given that, how do
you describe what:
(let ((x 10))
(declare (special x)
...
does? Going by the dictionary entry of LET I'd say it "create[s a] new
variable binding" but I gather you would not. Or maybe you would?
> The spec is written vaguely as to whether implementations are
> shallow or deep bound, but that's a latter day event.
>
> If you are trying to understand the historical reason for what it does,
> you should know that the culture in which MAKUNBOUND arose was Maclisp,
> and Maclisp was shallow bound.
Yes. That is exactly what I was trying to do. Thanks for the info.
-Peter
--
Peter Seibel ·····@javamonkey.com
The intellectual level needed for system design is in general
grossly underestimated. I am convinced more than ever that this
type of work is very difficult and that every effort to do it with
other than the best people is doomed to either failure or moderate
success at enormous expense. --Edsger Dijkstra
Peter Seibel <·····@javamonkey.com> writes:
> Kent M Pitman <······@world.std.com> writes:
>
> > Peter Seibel <·····@javamonkey.com> writes:
> >
> > > I was trying to puzzle out why MAKUNBOUND removes the value from
> > > the current dynamic binding rather than completely removing the
> > > binding, allowing an earlier binding to "show through"[1].
> >
> > Because dynamic bindings are not multiple bindings.
>
> I'm pretty sure I understand what you mean by that. Given that, how do
> you describe what:
>
> (let ((x 10))
> (declare (special x)
> ...
>
> does? Going by the dictionary entry of LET I'd say it "create[s a] new
> variable binding" but I gather you would not. Or maybe you would?
Whether it creates a new binding or not is not relevant to understanding
why MAKUNBOUND does what it does.
Since it is permissible to use deep binding, it might or might not
create a different binding cell. From the point of view of the user,
it is sufficient to think of a new binding as created, but it is not
necessary to think that way. I happen to model it as "always giving
me the same binding cell as all other special bindings of X" while
others do just the opposite (assume it gives me a new binding cell).
Since either shallow or deep binding is permissible, only the LCD of
the possible effects of these is permissible, and this leads one to
believe that one must not remove the binding upon MAKUNBOUND since
that is not possible in one of the possible implementation. If
MAKUNBOUND could remove the binding, it would expose the binding
scheme as deep binding, and that would make code non-portable;
therefore, it doesn't do this, even in deep binding where it could.
However, that was not your question. Your question was why MAKUNBOUND
does what it does, and the answer to that comes before this permission
to do deep binding was added.
This is like analyzing cracked rock by coming up with a theory of which
fault shift happened first. It's not commutative.
I have a serious problem with the way you are asking your questions because
you appear to be asking a question that the superficial text of your question
is not asking, and when I answer the question that you have typed, you
appear to be saying that you want a different question answered.
You seem to suppose that there is a necessary link between why MAKUNBOUND
does what it does, and there is not.
> > The spec is written vaguely as to whether implementations are
> > shallow or deep bound, but that's a latter day event.
> >
> > If you are trying to understand the historical reason for what it does,
> > you should know that the culture in which MAKUNBOUND arose was Maclisp,
> > and Maclisp was shallow bound.
>
> Yes. That is exactly what I was trying to do. Thanks for the info.
Then I don't understand why you asked the above question.
Kent M Pitman <······@world.std.com> writes:
> Peter Seibel <·····@javamonkey.com> writes:
> I have a serious problem with the way you are asking your questions
> because you appear to be asking a question that the superficial text
> of your question is not asking, and when I answer the question that
> you have typed, you appear to be saying that you want a different
> question answered.
Sorry. I was asking a *new* question that something you said raised.
In answering the question I typed, you also answered the question I
was actually asking. Perfectly. Thanks.
To be more precise about my new question, I was reacting to the phrase
"dynamic bindings are not multiple bindings". Taking that in the
context of this thread, and in some other threads I found on google
where you talked about shallow vs. deep binding, I think I understood
what you meant by it. I think I understand even better after this
latest post. But it did raise for me the new question: how do you,
Kent Pitman, describe what LET does when it's creating a binding for a
dynamic variable? Or however you'd describe it if not as "creating a
binding for a dynamic variable." And I'd still be interested to know.
The reason--to be perfectly clear--that I'm asking *this* question is
to get another data point about how people who know what they're
talking about use the terminology around binding, variables, etc.
because I haven't yet been able to formulate a consistent and
easy-to-explain terminology to use in explaining some of these
concepts to non-Lisp programmers. That's all.
-Peter
--
Peter Seibel ·····@javamonkey.com
The intellectual level needed for system design is in general
grossly underestimated. I am convinced more than ever that this
type of work is very difficult and that every effort to do it with
other than the best people is doomed to either failure or moderate
success at enormous expense. --Edsger Dijkstra
Peter Seibel <·····@javamonkey.com> writes:
> how do you,
> Kent Pitman, describe what LET does when it's creating a binding for a
> dynamic variable?
I don't use the noun binding at all. I don't like the term.
I sometimes use bind as a verb but prefer not to use it as a noun
if I can help it.
I just say that it creates (or delineates) a dynamic contour in which
the variable can be used.
(I sometimes also sometimes mention that accessing the SYMBOL-VALUE of
the variable name is the same as referencing a thusly-named variable,
and that doing MAKUNBOUND on the variable is the same as making the
SYMBOL-VALUE be 'unbound' (implicitly also making the variable whose
dynamic contour is active be unbound).)
If it's a lexical variable, then it creates (or delineates) a lexical
contour in which the variable can be used.
(I sometimes go to trouble to mention that even though symbols name
variables, symbols otherwise have nothing to do with lexical
variables, and there is no way at runtime to use a symbol to refer to
a lexical variable. That is, compilation (or semantic analysis)
"compiles away" lexical names. A further consequence of this inability
to name these variables at runtime is that no function can possibly
make them unbound nor read their value. They are utterly private,
which is their entire point.)
> Or however you'd describe it if not as "creating a
> binding for a dynamic variable." And I'd still be interested to know.
This terminology is implementational. It's bad for people to think this
way. It talks about a data structure the user cannot see or manipulate.
This is fine for people making meta-circular interpreters or formal
semantics but it's really lousy for teaching, IMO.
> The reason--to be perfectly clear--that I'm asking *this* question is
> to get another data point about how people who know what they're
> talking about use the terminology around binding, variables, etc.
> because I haven't yet been able to formulate a consistent and
> easy-to-explain terminology to use in explaining some of these
> concepts to non-Lisp programmers. That's all.
I'm at a loss to figure out what is so hard. What explanation were you
using and what problem was resulting?
Kent M Pitman <······@world.std.com> writes:
> Peter Seibel <·····@javamonkey.com> writes:
>
> > how do you, Kent Pitman, describe what LET does when it's creating
> > a binding for a dynamic variable?
>
> I don't use the noun binding at all. I don't like the term. I
> sometimes use bind as a verb but prefer not to use it as a noun if I
> can help it.
Interesting. Part of the problem I was trying to avoid in explaining
Lisp variables, was the confusion I've seen in a couple threads that
went back and forth over "a binding is the value", "no, a binding is
the *location* of the value". Perhaps just not using the term at all
is the best way to cut that Gordian knot.
> I'm at a loss to figure out what is so hard. What explanation were
> you using and what problem was resulting?
Well, the explanation I naturally wanted to use tended toward using
"variable" and "binding" (both as nouns) to denote two different
concepts. But then I got hung up on the variable glossary entry that
defined a variable *as* a binding. Based on what you said in another
thread, probably it was getting hung up on that detail was the real
problem. I was trying to avoid using established terms of art in an
idosyncratic way; the real problem seems to have been that I over
estimated how "established" some of these terms actually are.
-Peter
--
Peter Seibel ·····@javamonkey.com
The intellectual level needed for system design is in general
grossly underestimated. I am convinced more than ever that this
type of work is very difficult and that every effort to do it with
other than the best people is doomed to either failure or moderate
success at enormous expense. --Edsger Dijkstra
In article <··············@javamonkey.com>,
Peter Seibel <·····@javamonkey.com> wrote:
>Kent M Pitman <······@world.std.com> writes:
>
>> Peter Seibel <·····@javamonkey.com> writes:
>>
>> > how do you, Kent Pitman, describe what LET does when it's creating
>> > a binding for a dynamic variable?
>>
>> I don't use the noun binding at all. I don't like the term. I
>> sometimes use bind as a verb but prefer not to use it as a noun if I
>> can help it.
>
>Interesting. Part of the problem I was trying to avoid in explaining
>Lisp variables, was the confusion I've seen in a couple threads that
>went back and forth over "a binding is the value", "no, a binding is
>the *location* of the value". Perhaps just not using the term at all
>is the best way to cut that Gordian knot.
Yes. The term is used in both ways, depending on context. Technically, a
binding is the association between a name and a location where a value can
be held, but in many informal contexts this technicality is not important.
Saying "X is bound to 3" is a shorthand for "X is bound to a location that
currently holds 3". Whether you need to make the distinction depends on
whether you're discussing the values of variables or the behavior of
closures.
Also, lexical and special bindings are pretty different, so it can be
confusing that the same term is used for both. The value/location
distinction goes away in this case, since there's just one location: the
symbol's (conceptual) value cell.
--
Barry Margolin, ··············@level3.com
Genuity Managed Services, a Level(3) Company, 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.
In article <···············@paloalto-snr1.gtei.net>, Barry Margolin
<··············@level3.com> wrote:
> Also, lexical and special bindings are pretty different, so it can be
> confusing that the same term is used for both.
And that the same languages constructs are used to create both.
E.
[I'd like to take a stab at this, giving the point of view of this
implementor, at least. Your article is as good as any to respond
to, because it seems to be the simplest statement that comes as close
to my view as any other]
Barry Margolin <··············@level3.com> writes:
> In article <··············@javamonkey.com>,
> Peter Seibel <·····@javamonkey.com> wrote:
> >Kent M Pitman <······@world.std.com> writes:
> >
> >> Peter Seibel <·····@javamonkey.com> writes:
> >>
> >> > how do you, Kent Pitman, describe what LET does when it's creating
> >> > a binding for a dynamic variable?
> >>
> >> I don't use the noun binding at all. I don't like the term. I
> >> sometimes use bind as a verb but prefer not to use it as a noun if I
> >> can help it.
> >
> >Interesting. Part of the problem I was trying to avoid in explaining
> >Lisp variables, was the confusion I've seen in a couple threads that
> >went back and forth over "a binding is the value", "no, a binding is
> >the *location* of the value". Perhaps just not using the term at all
> >is the best way to cut that Gordian knot.
[One must be careful when using the word "location" - that term
automatically becomes translated in peoples' minds as "memory address",
and it is a little more than that in this context (note that the spec
is careful _not_ to mention the word "location", but instead refers to
it as "that which the name denotes"). I often think of the other side
of the binding as a location (i.e. memory-address), but when I do, I
must take into consideration that it is a conceptual simplification.
In reality, the "location" is a memory address _in_ a variable namespace
or binding context.]
> Yes. The term is used in both ways, depending on context. Technically, a
> binding is the association between a name and a location where a value can
> be held, but in many informal contexts this technicality is not important.
> Saying "X is bound to 3" is a shorthand for "X is bound to a location that
> currently holds 3". Whether you need to make the distinction depends on
> whether you're discussing the values of variables or the behavior of
> closures.
Yes. The watchword here is association. If one pictures graph theory,
a binding is an edge, and the two vertices are the name at one end, and
"that which the name denotes" on the other end. When either of the
vertices are removed, the binding ceases to exist.
> Also, lexical and special bindings are pretty different, so it can be
> confusing that the same term is used for both. The value/location
> distinction goes away in this case, since there's just one location: the
> symbol's (conceptual) value cell.
I disagree slightly with this, but mostly because I think of it in a
slightly more general terminology, where I don't have to think of
lexical and special bindings as that much different.
Here is my own theory:
I haven't seen (but sorry if I missed it) much attention paid to the
definition of "bound"; mostly people have been concentrating on the
definition of "binding". If you look at "bound", there are actually
three senses:
1. adj, v.t. (description of an association, with the rest of the
definition delegated to "binding")
2. adj. "Having a local binding which _shadows_ (2) another." An
example is given of *print-escape*, clearly an example of
special binding.
3. v.t. "The past tense of bind." (which in turns, means to establish
a binding (or association) for the variable).
Note also that "variable" and "binding" are completely circular definitions,
and they mean the same thing in the context of a specific namespace (i.e.
the "variable" namespace).
So in fact, we can use the terms "binding" and "variable" more or less
interchangably.
Lexical variables are relatively easy to understand, because there is
usually a name (before compilation, at least, although the compiler can
also perserve the name after the compilation under high debug), and that
which the name denotes is just a location in memory that is isolated in
its lexical contour. An easy way to think of a compiled variable is a
location on the stack.
Kent made a statement that got me thinking about whether a variable
remains a variable/binding if the compiler actually removes the name -
since a binding depends in part on a name, and since a variable is a
binding, does the binding actually go away? I actually think not;
when the name is thrown away, the binding simply changes names; in our
debugger a local variable which has had its name thrown away still has
a numbered name: (local 0, local 1, etc.) so I don't see any inconsistency
there.
Dynamic variables are a little harder, because altghough we know better,
we tend to think of specials as variables. But really, the variable,
or binding, is the assocoation of the name (i.e. the special _symbol_),
and that which it denotes... Now some will automatically complete my
sentence and say "of course, that is the value cell of the symbol".
But that is an incorrect completion; it assume a strict shallow-binding
implementation (which most of us are used to seeing). However, in a
deep binding situation, The symbol need not have a value cell at all;
all associations are made as symbol/value assocations on the stack.
Also, thinking about the "value cell" gives no leeway to other styles
of implementation:
- Allegro CL's new "wide-binding" approach has a value cell _per_
_thread_, all active at the same time.
- As I understand it, Corman Lisp (and perhaps other lisps) take
the approach that a symbol's value is the nth location of the
thread-specific data, so the association is done with an index
into thread-specific data.
Finally, there is the subject of this thread: what is special [sic]
about MAKUNBOUND? I actually say that it is not at all a special case,
but a reference to "bound(2)" which defines a local binding which
shadows another. Each binding can be thought of as stacked on top
of each other, and MAKUNBOUND affects the binding which is currently
visible.
Question: Should MAKUNBOUND lift the binding stack and expose the
next shadowed binding, if any? I think that the answer is "no",
and I believe all shallow-binding implementations agree with me,
although I have never seen MAKUNBOUND operate on a deep-binding
implementation. I submit as an argument that a better name for
a function which would actually remove a shadowing of a bound(2)
variable would have been called UNBIND rather than MAKUNBOUND.
It would be semantically difficult, and that is why I believe it
is not offered, whether the decision was conscious or not.
Now, how can a binding be removed without also removing the shadowing
of the next binding? By having a binding that isn't one. If you
consider a binding as an edge associating two vertices (the name and
that which the name is associated) then the easiest way to remove the
binding is to remove one of the vertices. Implementationally, we
usually do that with a special Lisp Object, "the unbound value", which
is by _definition_ not possible as a vertex in the graph. Thus, the
association is broken, and the variable is (in the current dynamic
context) "unbound". Hoiwever, implementationally the edge still
exists, and thus still shadows the previous binding.
I was going to try to draw some ascii-art pictures, but that might
just confuse things. I _think_ that I have been clear, but of course
it is only clear in my own head; hopefully I have communicated that
clarity clearly :-)
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
Duane Rettig <·····@franz.com> wrote:
+---------------
| - As I understand it, Corman Lisp (and perhaps other lisps) take
| the approach that a symbol's value is the nth location of the
| thread-specific data, so the association is done with an index
| into thread-specific data.
+---------------
I had a side conversation with Roger after his talk at ILC 2002, and
came away from it with the following understanding [which may be fuzzy
in some of the details, but I think it's approximately correct]:
As Duane says, in Corman Lisp there's a global count of symbols
(or rather, symbols that are ever referenced as variables, rather
than functions), and there's a per-thread table of that size.
But what's in the per-thread table isn't the "symbol's value"
per se, but a *pointer* (or indirection) to the location with
the symbol's value (truly a binding!). Now by default, this points
to the usual global value cell of the interned symbol (that is,
global variables are by default bound to the value cell of the
symbols which name them), but when a special variable is dynamically
bound then the indirection points to a hidden per-thread location
containing the current dynamic binding.
[Note that it's an implemention choice as to whether further nested
dynamic bindings push/pop the dynamic *value* onto some thread-local
per-variable stack or allocate new locations and push/pop the *bindings*
to those location onto the stack -- in either case the user-visible
effect would be the same. Seems to me it would be simpler and more
consistent to do the latter, but...]
So if there is no active dynamic binding current for some variable
in a given thread, references to that variable see the "global" value
which is visible to *all* threads -- well, all threads that have no
active dynamic binding for it. So a (setq foo <whatever>) is seen
by all such threads, but if the thread doing the SETQ has a current
active dynamic binding for "foo" then the modification is seen only
by that thread. Or something like that...
Anyway, the cost of the scheme is (1) a vector "N" long per thread
[where "N" is the number of global variables that the compiler has
ever seen LET-bound or LAMBDA-bound] and (2) one additional level
of indirection when accessing special variables.
[I'm handwaving details about how "N" gets bumped up at run-time
when you dynamically bind a special variable that was never bound
before, and how the per-thread table get grown as needed. (Lazily,
one hopes...)]
-Rob
-----
Rob Warnock, PP-ASEL-IA <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
In article <···············@shell01.TheWorld.com>, Kent M Pitman
<······@world.std.com> wrote:
> I don't use the noun binding at all. I don't like the term.
Then how would you explain what a lexical closure is?
E.
···@jpl.nasa.gov (Erann Gat) writes:
> In article <···············@shell01.TheWorld.com>, Kent M Pitman
> <······@world.std.com> wrote:
>
> > I don't use the noun binding at all. I don't like the term.
>
> Then how would you explain what a lexical closure is?
It's something (usually a function) that creates/delineates/captures
the active lexical variables so they will be available at another time.
(There is the possibility that the captured variables will have been
reassigned before such use if other code that does such assignment is
lexically apparent and gets used in the interim.)
Is there something about lexical variables that this description does
not (pardon the pun) capture?
In article <···············@shell01.TheWorld.com>, Kent M Pitman
<······@world.std.com> wrote:
> ···@jpl.nasa.gov (Erann Gat) writes:
>
> > In article <···············@shell01.TheWorld.com>, Kent M Pitman
> > <······@world.std.com> wrote:
> >
> > > I don't use the noun binding at all. I don't like the term.
> >
> > Then how would you explain what a lexical closure is?
>
> It's something (usually a function) that creates/delineates/captures
> the active lexical variables so they will be available at another time.
>
> (There is the possibility that the captured variables will have been
> reassigned before such use if other code that does such assignment is
> lexically apparent and gets used in the interim.)
>
> Is there something about lexical variables that this description does
> not (pardon the pun) capture?
No, that's fine, you're just using the word "variable" as a synonym for
"binding" (which is OK since they are in fact synonyms in CL).
E.
In article <··············@javamonkey.com>,
Peter Seibel <·····@javamonkey.com> wrote:
>Kent M Pitman <······@world.std.com> writes:
>
>> Peter Seibel <·····@javamonkey.com> writes:
>>
>> > I was trying to puzzle out why MAKUNBOUND removes the value from
>> > the current dynamic binding rather than completely removing the
>> > binding, allowing an earlier binding to "show through"[1].
>>
>> Because dynamic bindings are not multiple bindings.
>
>I'm pretty sure I understand what you mean by that. Given that, how do
>you describe what:
>
> (let ((x 10))
> (declare (special x)
> ...
>
>does? Going by the dictionary entry of LET I'd say it "create[s a] new
>variable binding" but I gather you would not. Or maybe you would?
Local special declarations didn't exist in Maclisp. The behavior of
MAKUNBOUND was simply copied from Maclisp in as straightforward a fashion
as possible. There wasn't a deep analysis of what the best semantics of
this obscure combination of features should do.
--
Barry Margolin, ··············@level3.com
Genuity Managed Services, a Level(3) Company, 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.
In article <···············@shell01.TheWorld.com>, Kent M Pitman
<······@world.std.com> wrote:
> Peter Seibel <·····@javamonkey.com> writes:
>
> > I was trying to puzzle out why MAKUNBOUND removes the value from
> > the current dynamic binding rather than completely removing the
> > binding, allowing an earlier binding to "show through"[1].
>
> Because dynamic bindings are not multiple bindings.
This is apparently at odds with what the spec says, and you do newcomers a
grave disservice by saying this without explaining exactly why what you
are telling them is at odds with the spec.
> The spec is written vaguely as to whether implementations are shallow
> or deep bound, but that's a latter day event.
The spec is entirely unambiguous that LET "create[s] new variable
bindings" (whether or not they are dynamic or lexical).
I'm going to hazard a guess as to what your answer is going to be in an
attempt to short-circuit some of the confusion.
The statements "LET creates new bindings" and "dynamic bindings are not
multiple bindings" are not necessarily at odds with each other. In a
shallow-binding implementation there is only a single value cell for each
symbol, which serves as the (one) binding for that symbol as both a global
and a dynamic variable. When you dynamically bind a symbol you do create
a new binding for it, but that new binding is used to hold the *old* value
of the dynamic variable. The new (current) value goes in the (one)
symbol-value slot. Therefore, the statement that "dynamic bindings *are*
not (necessarily) multiple bindings" is, strictly speaking, correct.
However, IMO it is unnecessarily confusing because it is also true that
dynamic binding involves multiple bindings even in a shallow-bound
implementation.
I reiterate my position that special variables are a horrible design for
dynamic binding because they are perennially and hopelessly confusing to
newcomers.
E.
···@jpl.nasa.gov (Erann Gat) writes:
> I reiterate my position that special variables are a horrible design for
> dynamic binding because they are perennially and hopelessly confusing to
> newcomers.
People have used them for years successfully. I always encourage people
who don't agree with the design to either not use the feature or not use
the language.
The reason why I think specials are so important is that they are an
artifact of the world, not the language. By incorporating them into
the language, we make it possible for the language to do the best
possible job of compiling them. If we removed them from the language,
people would still do the same thing. They would just do it (even
more) badly and in a manner that was opaque to the compiler and
impossible to usefully optimize.
A fundamental difference between Lisp and Scheme is this. The Scheme
community first wants to take a manner of expression, make sure it can
be compiled, sometimes even make sure it has no competing modes of
thought (even if this means that it will be mired perpetually in
mudslinging because there are inevitably competing modes of thought).
The Lisp community aggressively grabs ideas that people are using, whether
or not we know every last thing about how to exploit them, and pulls them
into the common language. This is how CLOS, conditions, pathnames, and
even s-expressions (code as data, data as code) got into the language.
We don't always know if we'll be able to make something efficient, etc.
but we make an a commitment to try. We don't always know that it's the
best notation, but we realize that sometimes decisions that are merely
arbitrary are called for, because all competing decisions are also
arbitrary and only the will to move forward arbitrariliy will break
deadlock. And sometimes we add things that people keep doing, just because
they keep doing it.
Scheme has tried to keep specials out, but it keeps
coming back to the concept in various forms because dynamic state matters
and programmers need _some_ way to address it. Lisp has instead embraced
a notation for talking about them and has engaged public dialog _through
use_ in order to find the right path. We did the same for conditions,
as I explained in the personal footnote at the end of my latest conditions
paper:
http://www.nhplace.com/kent/Papers/Condition-Handling-2001.html#footnote
We in Lisp learn through doing. Other languages learn through not doing,
allowing the Ivory Tower to experiment and waiting for them to roll out
The Truth when it is ready. I like how we do things, and that's why I stay
with this community. If you don't like how we do things, maybe this is
not the community for you.
A lot of what you like best in T, like locales, is due to a series of
arguments between me and Jonathan Rees. He wanted to provide certain
capabilities and I wanted to provide a certain set of "ways of saying
things". Locales arose because Jonathan insisted that "global" was a
bankrupt concept and I insisted that "people like global as a metaphor".
What resulted was a compromise that "felt global" but really wasn't,
allowing people to keep the metaphor but shun the detail. Because (I
believe) people will insist on saying things how they want to say them,
no matter what language designers tell them. Just as surely as people will
say "ain't" or "huh" or "yeah" when English teachers insist these are not
words, as surely as people will use "they" as the impersonal singular
article when English teachers insist English has none and that the
construction should be done without, as surely as people will use "kid"
to refer to "children" because it's a shorter and more convenient word
when English teachers insist that "kids" are "baby goats" and that one must
use "child" and "children". Languages evolve as their communities need,
and language designers that don't go with the flow get rolled over.
I think special variables are what people want to use. Whether they want
a LET+DECLARE syntax or they want DYNAMIC-LET is minor, and can be fixed
with macros if someone disagrees. But the basic set of operations that
are _wanted_ are well-understood. The real question is only whether the
designers/implementors will be stubborn and say "I know what you want but
for your own good I will not give it to you". We haven't done that, and
I think that's good.
We _did_ do that for dynamic functions, but we were not denying a capability,
only a syntax. You can criticize that, as Pascal Costanza has recently
done. I hope he is appeased in finding that it's only syntax and not
semantics that are missing. If it were semantics, I think he'd have a good
criticism. But even so, I think a criticism of the form "x is missing" is
a much better criticism than "x is present but i don't like it". CL
accomodates multiple points of view, and we have resigned ourselves to the
latter criticism--it's the price of tolerance.
It may interest you to know that I personally prefer to think of specials as
cells (objects) that can be looked up in a global table and that when you
do a special incantation will put those cells into the lexical value.
I prefer the notion of specials as data objects and not as language glue,
and I think of specials in my mind as a kind of symbol macro that does a
transformation like:
(defvar *x*)
...
(let ((*x* ...))
... *x* ...)
turns to
(let ((#1=#:x-init ...))
(let ((#2=#:*x* (get-special-cell '*x*)))
(call-with-special-binding #2# #1#
#'(lambda ()
(symbol-macrolet ((*x* (cell-value #2#)))
... *x* ...)))))
or something thereabouts (I just wrote this freehand without checking it).
But my point is that while this expresses the mechanism I think of as going
on within a special binding, I am happy not to have to _do_ this kind of
stuff in typical programming because it would just make simple programs
look ugly. The syntax we've chosen is not my first choice. But it's
"good enough" for people trying to get real work done and in spite of its
little glitches. So I live with it until something better is proposed and
adopted by community acclamation. Life is short and arguing over a better
way to express this is not how I want to spend mine.
But my bottom line point is that I'm not pushing the present notation
because it's my personal choice. I'm pushing it because I myself have
settled for it as "good enough" and I think you can, too, if you want to.
If there is a barrier, it's not "whether it will be good enough" it's
"whether you want to". At least, that's my default assumption until you
show a material problem. To quote from X3J13/86-020 (the X3J13 charter):
Whenever there is a proposal for the standard to differ from Common
Lisp: The Language, the committee shall weigh both future costs of
adopting (or not adopting) a change and costs of conversion of
existing code. Aesthetic criteria shall be a subordinate
consideration.
Source: http://nhplace.com/kent/CL/x3j13-86-020.html
I consider this the best decision ANSI CL ever made. Without this
single decision, we'd never have completed the standard. I credit
Susan P. Ennis (of Amoco, of all things, if I remember right) for
having blugeoned us into putting together this kind of thing. The
whole idea of a charter at all seemed at the time to be just so much
red tape. But when you later see how individual personalities can
cause disagreements that spin out of control, you realize the
importance of these things. A committee without a charter is like a
complicated Prolog program without 'cut'.
So if you don't like the aesthetics of CL, all I can say is "that was
(explicitly) not our primary concern".
In article <···············@shell01.TheWorld.com>, Kent M Pitman
<······@world.std.com> wrote:
> ···@jpl.nasa.gov (Erann Gat) writes:
>
> > I reiterate my position that special variables are a horrible design for
> > dynamic binding because they are perennially and hopelessly confusing to
> > newcomers.
>
> People have used them for years successfully.
That in no way contradicts my position. People have successfully used all
manner of hopelessly confusing things. (Look at C++.) That does not
change the fact that they are hopelessly confusing..
> I always encourage people
> who don't agree with the design to either not use the feature or not use
> the language.
Yes, I know. That attitude (which seems to be rather prevalent) is IMO
one of the reasons that Lisp has been stagnant for ten years, which is in
turn is one of the reasons that I am no longer able to use it despite the
fact that I very much want to. Different is not necessarily better, but
better is necessarily different.
> The reason why I think specials are so important is that they are an
> artifact of the world, not the language.
Are *specials* an artifact of the world, or are dynamically bound
variables an artifact of the world? These are not the same thing.
I am not arguing for eliminating the capability. I am arguing for
changing the implementation. Or at the very least for recognizing that
the current implementation is confusing and coming up with a coherent
explanation for newcomers. When the spec says "LET introduces new
bindings" and then the person who wrote the spec says that LET "might or
might not create a different binding cell" and "dynamic bindings are not
multiple bindings" what is a newcomer to make of this?
> By incorporating them into
> the language, we make it possible for the language to do the best
> possible job of compiling them. If we removed them from the language,
> people would still do the same thing. They would just do it (even
> more) badly and in a manner that was opaque to the compiler and
> impossible to usefully optimize.
Like I said, I am not arguing for their removal. I am arguing for a
different API. Or at the very least better documentation of the existing
one.
> If you don't like how we do things, maybe this is
> not the community for you.
...
> Languages evolve as their communities need,
> and language designers that don't go with the flow get rolled over.
Do you see the irony in the juxtaposition of these two statements? On the
one hand you say, "If you don't like it, don't try to effect change, just
leave." And on the other hand you correctly observe that languages that
don't evolve die. How do you expect Common Lisp to evolve if every
proposal for change is met with the response, "If you don't like it here,
go use Scheme."?
> I think special variables are what people want to use. Whether they want
> a LET+DECLARE syntax or they want DYNAMIC-LET is minor, and can be fixed
> with macros if someone disagrees. But the basic set of operations that
> are _wanted_ are well-understood. The real question is only whether the
> designers/implementors will be stubborn and say "I know what you want but
> for your own good I will not give it to you". We haven't done that, and
> I think that's good.
Like I said, I am not arguing for the removal of the capability. I am
arguing for packaging and marketing the capability differently.
> We _did_ do that for dynamic functions, but we were not denying a capability,
> only a syntax. You can criticize that, as Pascal Costanza has recently
> done. I hope he is appeased in finding that it's only syntax and not
> semantics that are missing.
I think you (and many other people in the CL community) are really
approaching this with a bad attitude. You interpret Pascal's idea in a
negative way, as a critique of a flaw in the language. But I believe that
Pascal's intent (Pascal, if you're reading this correct me if I'm wrong)
was to say: here's this thing over the in the Java world (AOP) that
everyone's getting all excited about (and putting lot of effort into) --
look how much easier it is to do exactly the same thing in Lisp.
Pascal has been remarkably resilient against this sort of negative
reaction from the CL community (he weathered an amazing rush of abuse when
he first arrived here). I doubt most people are as resilient as he is, so
I think we quietly lose a lot of people with this attitude that any
critique of the language is an attack and must be met with a defensive
response. Pascal doesn't need appeasement. He needs encouragement and a
pat on the back.
> It may interest you to know that I personally prefer to think of specials as
> cells (objects) that can be looked up in a global table and that when you
> do a special incantation will put those cells into the lexical value.
And the point that I'm making is that the freedom that CL gives to people
to think about this language feature in different ways is a bad thing if
your goal is to get new people to use and understand it.
> But my bottom line point is that I'm not pushing the present notation
> because it's my personal choice. I'm pushing it because I myself have
> settled for it as "good enough" and I think you can, too, if you want to.
I can and I have. That is not the issue. This isn't about me. This is
about all those anonymous lurkers who poke their nose in here, see all the
confusion, and decide they have better things to do than to try to sort it
all out.
> So if you don't like the aesthetics of CL, all I can say is "that was
> (explicitly) not our primary concern".
I'm not arguing with this. I'm saying that it's time to apply Gat's first
law: all extreme positions are wrong. Just because it's not a primary
concern doesn't mean it's no concern. The amount of effort spent just on
this newsgroup trying to explain special variables to newbies over and
over and over again is prima facie evidence that this particular aesthetic
decision has practical negative consequences that warrant revisiting the
issue.
E.
Erann Gat <···@jpl.nasa.gov> wrote:
Re special / dynamically scoped variables:
> I am not arguing for eliminating the capability. I am arguing for
> changing the implementation. Or at the very least for recognizing that
Do you have something concrete in mind? (Are those blueprints I see in
your backpocket?)
Cheers,
-- Nikodemus
In article <··············@midnight.cs.hut.fi>, Nikodemus Siivola
<········@kekkonen.cs.hut.fi> wrote:
> Erann Gat <···@jpl.nasa.gov> wrote:
>
> Re special / dynamically scoped variables:
>
> > I am not arguing for eliminating the capability. I am arguing for
> > changing the implementation. Or at the very least for recognizing that
>
> Do you have something concrete in mind? (Are those blueprints I see in
> your backpocket?)
Yes, I have previously proposed a backwards-compatible extension to Common
Lisp that addresses these problems. I have also written two drafts of a
newbies guide to these issues. See:
http://groups.google.com/groups?selm=gat-2902001653240001%40milo.jpl.nasa.gov
and the subsequent discussion, and:
http://groups.google.com/groups?selm=gat-0911021704350001%40192.168.1.51
E.
···@jpl.nasa.gov (Erann Gat) writes:
> In article <··············@midnight.cs.hut.fi>, Nikodemus Siivola
> <········@kekkonen.cs.hut.fi> wrote:
>
> > Erann Gat <···@jpl.nasa.gov> wrote:
> >
> > Re special / dynamically scoped variables:
> >
> > > I am not arguing for eliminating the capability. I am arguing for
> > > changing the implementation. Or at the very least for recognizing that
> >
> > Do you have something concrete in mind? (Are those blueprints I see in
> > your backpocket?)
>
> Yes, I have previously proposed a backwards-compatible extension to Common
> Lisp that addresses these problems. I have also written two drafts of a
> newbies guide to these issues. See:
>
> http://groups.google.com/groups?selm=gat-2902001653240001%40milo.jpl.nasa.gov
This proposal uses a very ill-advised syntax for someone who is into
purity and ease of explanation.
Its use of SYMBOL-VALUE is visually very confusing since it looks
setf-like but doesn't evaluate its argument. It uses the $x reader
macro sometimes to mean (SYMBOL-VALUE 'X) and sometimes (SYMBOL-VALUE
X). The readmacro seems to know the right way to expand for its
context in code. [It also forces you to write (eq x '$ ) to avoid
an error if you do (eq x '$). This is a simple bug. It also returns a
$ in the wrong package. This is a simple bug, too.]
It tries to integrate destructuring with pattern matching but ends up
creating a number of special cases.
It uses a LOOP-like syntax but doesn't do LOOP-like destructuring.
> and the subsequent discussion, and:
>
> http://groups.google.com/groups?selm=gat-0911021704350001%40192.168.1.51
This "introduction" contains 3 references to unfortunate design, 7
references to avoiding confusion, 2 references to things you imagine
will surprise people and need to be avoided, 3 references to things
being complicated, and 1 reference to things being esoteric. There is
a use of "flexible" and a use of "powerful" but they are in a
qualified context: "But in Lisp, variables are a much richer and more
powerful concept. And more complicated."
I might suggest that your tone is as big an obstacle to Lisp's
acceptance as many of the other obstacles you routinely rail against.
I really would not choose you as our ambassador. Seriously. It's
possible to teach these concepts in an upbeat way. If your students
don't come out with a positive attitude, it's probably the undertones
of the terminology you yourself are offering them, which drips of
"you should accept this only grudgingly, if at all".
Also, it's a bad teaching technique (one I have independently
complained at others about in other contexts) to take a new student
and show them something to be surprised and dismayed about, and then
to peel back. e.g.,
| A beginner's initiation into this state of affairs invariably comes when
| he or she one day as an expedient types (defvar x 1) and then spends the
| rest of the day (or week) trying to figure out why her code is suddenly
| exhibiting mysterious bugs.
If this is introductory text, tell the beginner how to proceed so that
this doesn't happen. Don't tell them what would result from lack of
direction. If you lead them down this path, they will do it and it will
be your fault.
The statement "A symbol can only be interned in one package at a time."
is wrong.
The statement "Scheme symbols only have one binding at a time: the
value binding.)" is also wrong. Scheme symbols do not have bindings at
all. Scheme variables have bindings. There is only one namespace in
which bindings is looked up. But bindings are not a property of the
symbol. Further, the use of "time" in this case is curious and potentially
confusing. (lambda (x) (lambda (y) (+ x y))) is a function that yields
other functions. Each of these functions will have a closed value for X.
There can be two such functions at the same time, and they will each have
variables named X, each of which has a binding at the same time. You need
to clarify what 'time' means. It doesn't have anything to do with binding.
I think it has to do with namespace, which is an utterly unrelated concept.
You offer:
| (Editorial comment: IMO, if you're going to have the concept of
| a pervasively special variable and acknowledges that a typographical
| convention is necessary in order to avoid confusion, then you ought
| to build that typographical convention into the language design. It
| should be the case that all variables whose names start with an asterisk
| are automatically declared special, and all names that don't start with
| an asterisk are automatically lexical.)
but this might as well say
"If you're going to accomodate history, you ought to first rewrite all
legacy applications to not have any uncomfortable truths and additionally
you ought to get rid of all notion of ever supporting expressions
like (eval '(+ x y)) and force people to write (eval '(+ *x* *y*))."
I'm not a big fan of people making criticisms of the language design
without investigating the reasons behind it. I also think that ill-informed
criticisms are best stored in containers other than introductory material
for new people.
In article <···············@shell01.TheWorld.com>, Kent M Pitman
<······@world.std.com> wrote:
[Many criticisms of my BIND proposal.]
If I corrected these problems would you support the proposal?
> I might suggest that your tone is as big an obstacle to Lisp's
> acceptance as many of the other obstacles you routinely rail against.
You really think I have that kind of influence? Do you think that if I
wrote something more upbeat about Lisp that the world would suddenly flock
to Lisp's door? (I'd gladly do it. Perhaps I'd start with something like
http://www.flownet.com/gat/papers/lisp-java.pdf.) Or do my powers of
persuasion only work to drive people away? (What a bummer.)
> I really would not choose you as our ambassador. Seriously.
I really was not offering myself up as a candidate. Seriously. I am not
speaking here as someone who aspires to be a spokesman for Lisp. I aspire
to be a *customer* (again). At the moment there are serious obstacles in
my way, not least of which is the fact that Lisp is widely perceived to be
dead. And judging by what I hear at the CRACL meetings my situation is
far from unique.
> It's possible to teach these concepts in an upbeat way. If your students
> don't come out with a positive attitude, it's probably the undertones
> of the terminology you yourself are offering them, which drips of
> "you should accept this only grudgingly, if at all".
The feedback I've gotten about "The Idiot's Guide..." has been largely
positive. From beginners it has been overwhelmingly positive. But that
is beside the point.
You responded to Pascal's dynamic-function-binding proposal with criticism
because you misunderstood his motivation. Perhaps there is a similar
misunderstanding at work here. Let me be very explicit about this. I am
interested in the following issues:
1. Is Common Lisp's lack of popularity a problem? (It certainly is for
me. I am unable to use it because it is widely perceived by my peers as
dead.)
2. Assuming that Common Lisp's lack of popularity is a problem, what can
(or should) be done about it (if anything)?
I am interested in addressing that second question, and I address it under
the following assumptions:
1. Neither the simple passage of time nor a handful of successful CL
applications will cause CL to become significantly more popular than it is
today. History supports this assumption. Therefore, if CL is to become
more popular *something* about it must change.
2. CL can only grow more popular by attracting new users. (This is a
tautology.) It is therefore more likely to become popular if barriers to
entry are removed.
3. There are some technical issues that new CL users appear to become
perennially confused about, special variables (and related issues having
to do with bindings and lexical closures) seem to be chief among these.
This is bad because 1) it's a barrier to entry and 2) lots of time is
wasted trying to explain these issue to newcomers on c.l.l. again and
again and again and again.
Therefore, trying to remove this barrier by simplifying the design of CL
in this respect seems to be a fruitful place to pursue the kind of change
that is a necessary (but perhaps not sufficient) condition to change CL's
popularity. That is why I wrote the BIND proposal, and the Idiot's guide.
Note that the intended audience for these two are very different. The
BIND proposal was not written for newcomers.
I'd be interested in your reaction to all this. I think our disagreements
will be more productive if we know whether we disagree about motives or
methods.
> Also, it's a bad teaching technique (one I have independently
> complained at others about in other contexts) to take a new student
> and show them something to be surprised and dismayed about, and then
> to peel back. e.g.,
>
> | A beginner's initiation into this state of affairs invariably comes when
> | he or she one day as an expedient types (defvar x 1) and then spends the
> | rest of the day (or week) trying to figure out why her code is suddenly
> | exhibiting mysterious bugs.
The intended audience for that quote was not beginners (which I thought
would be obvious, since I am speaking *about* beginners in the third
person).
BTW, I wrote "The Idiot's Guide..." not so much because I think I'm
particularly qualified to write it, but because I saw a need and thought
that it would be better to step up to the plate than just complain about
it. Likewise, I think if would be better if you don't like what I came up
with to offer up an alternative of your own.
> "If you're going to accomodate history, you ought to first rewrite all
> legacy applications to not have any uncomfortable truths
There is a difference between accommodating history and being bound by
it. If we always "accommodated history" to the extent that you seem to
imply that you want here we'd all still be programming in or Lisp 1.5 (or
Fortan 1).
> and additionally
> you ought to get rid of all notion of ever supporting expressions
> like (eval '(+ x y)) and force people to write (eval '(+ *x* *y*))."
[···@alvin tinyscheme-1.27]$ ./scheme
TinyScheme 1.27
> (define x 1)
x
> (define y 2)
y
> (eval '(+ x y))
3
>
Funny, that seems to work OK.
> I'm not a big fan of people making criticisms of the language design
> without investigating the reasons behind it. I also think that ill-informed
> criticisms are best stored in containers other than introductory material
> for new people.
Ill informed, eh? I have been programming in Lisp for 20 years. I have
read a significant fraction of all the books that have ever been written
on the topic. I may not be the brightest bulb, but I'm no idiot either.
If I am ill-informed then at what point do you think it would not be out
of line to suggest that the fault might not lie entirely with me?
E.
···@jpl.nasa.gov (Erann Gat) writes:
> In article <···············@shell01.TheWorld.com>, Kent M Pitman
> <······@world.std.com> wrote:
>
> [Many criticisms of my BIND proposal.]
>
> If I corrected these problems would you support the proposal?
No.
(a) If you leave the existing stuff, it only adds to complexity.
And if you don't, it's seriously incompatible.
(b) It's needlessly complex and incompatible in many ways with existing
operators, rather than capitalizing on an existing syntax.
(c) I would support the introduction of dynamic-bind or dynamic-let or
whatever it is that Eulisp and I think also ISlisp has. (too lazy to
look it up). At least that operator has a couple of communities
behind it.
> > I might suggest that your tone is as big an obstacle to Lisp's
> > acceptance as many of the other obstacles you routinely rail against.
>
> You really think I have that kind of influence?
I mean with the people you touch. I wasn't make a statistical argument.
Then again, I don't think the thing we're comparing to is nearly the big
deal you do, so make sure you're comparing the right thing to the right thing.
> Do you think that if I
> wrote something more upbeat about Lisp that the world would suddenly flock
> to Lisp's door?
Who knows. All I know is that if you're going to write an intro piece for
anyone, it should be upbeat. Or else you're just driving away whoever
does read it. You presumably know how many people you intend to sway.
But whether that's one or ten thousand, the energy is wasted if your body
language is just going to say "don't bother".
> (I'd gladly do it. Perhaps I'd start with something like
> http://www.flownet.com/gat/papers/lisp-java.pdf.) Or do my powers of
> persuasion only work to drive people away? (What a bummer.)
I'm not saying anything about your powers of persuasion. I'm not even sure
I'm competent to judge. The world is a varied place and each of us has access
to different groups. What I was saying was that leading with negativity
doesn't strike me as a winning argument.
> > I really would not choose you as our ambassador. Seriously.
>
> I really was not offering myself up as a candidate. Seriously.
I was really only speaking local to this particular work, and I
probably misworded myself. I'm not sure there is a single unique
position open for this role. I think we are each ambassadors in our
own way. I guess what I meant was I wouldn't pick a piece of this style.
> I am not speaking here as someone who aspires to be a spokesman for
> Lisp. I aspire to be a *customer* (again). At the moment there are
> serious obstacles in my way, not least of which is the fact that
> Lisp is widely perceived to be dead. And judging by what I hear at
> the CRACL meetings
I don't know what CRACL is.
> my situation is far from unique.
Maybe someone will post notes.
> > It's possible to teach these concepts in an upbeat way. If your students
> > don't come out with a positive attitude, it's probably the undertones
> > of the terminology you yourself are offering them, which drips of
> > "you should accept this only grudgingly, if at all".
>
> The feedback I've gotten about "The Idiot's Guide..." has been largely
> positive. From beginners it has been overwhelmingly positive. But that
> is beside the point.
>
> You responded to Pascal's dynamic-function-binding proposal with criticism
> because you misunderstood his motivation. Perhaps there is a similar
> misunderstanding at work here. Let me be very explicit about this. I am
> interested in the following issues:
>
> 1. Is Common Lisp's lack of popularity a problem? (It certainly is for
> me. I am unable to use it because it is widely perceived by my peers as
> dead.)
We've discussed this offline some. Without compromising the detail of
private communications, is it safe to simply summarize by saying you
haven't exactly been given a list of 5 things that if you fix,
everyone will rally around Lisp and apologize for having had
misgivings? Given that this is so, is it rational to continue to
expend resources solving what might reasonably be called more of an
emotional than a technical problem? Is it realistic to say we could,
even if we became Scheme, go to people and say "we're pretty now, can
you use us?" Surely they know Scheme exists and they are not flocking
to that either. So why will "adding a layer of simplicity around our
existing core" be any more likely to yield success?
> 2. Assuming that Common Lisp's lack of popularity is a problem, what can
> (or should) be done about it (if anything)?
This is a reasonable question, although it may not have a single overarching
answer. There may be communities worth pursuing and others not, IMO.
I long ago gave up trying to push CL on everyone. My sense is that the
degree to which my Slashdot article was accepted by many who did not expect
to accept it did not come from how I presented Lisp per se, but rather how
I presented my attitude toward other languages. That is, numerous people
seemed to approach Lisp better when I acknowledged that it was reasonable
for them to use their own preferred languages when they wanted. They didn't
want me to tell them they were doing the wrong thing for applications they
were comfortable solving already. They were at that point not threatened
by Lisp and were able to consider it as a new tool for solving things they
were not already able to solve. And in this light, they were not afraid of
its strangeness, in part because familiarity would have led them to believe
they didn't need to leave their own language, and lack of familiarity gave
them hope there was another approach they had not thought of.
As such, I'm not convinced that CL's popularity is about the naming of
car/cdr, etc. I think it's more about its perceived lack of foreign function
interfaces, of ability to make and use DLLs, etc., its lack of RPC or
RMI or HTML or graphics or sound support. Things that make it unable to be
a good citizen in a heterogeneous environment. I don't think anyone cares
a wit about special variables in this context--I think that's totally in
the noise as far as acceptance of CL.
> I am interested in addressing that second question, and I address it under
> the following assumptions:
>
> 1. Neither the simple passage of time nor a handful of successful CL
> applications will cause CL to become significantly more popular than it is
> today. History supports this assumption. Therefore, if CL is to become
> more popular *something* about it must change.
Yes. It must address issues that define the modern workplace. Handy support
for hash tables or a clearer definition of what it is to bind a variable
does not characterize the modern workplace.
> 2. CL can only grow more popular by attracting new users. (This is a
> tautology.) It is therefore more likely to become popular if barriers to
> entry are removed.
C and C++ have the world's most godawful syntax and people are able to
learn and use those. I don't think syntax or the need to apply obscure
rules are a barrier. If anything, the lack of funny little rules to occupy
the minds of those trying to learn it is an obstacle. (Only half-joking.)
> 3. There are some technical issues that new CL users appear to become
> perennially confused about, special variables (and related issues having
> to do with bindings and lexical closures) seem to be chief among these.
> This is bad because 1) it's a barrier to entry and 2) lots of time is
> wasted trying to explain these issue to newcomers on c.l.l. again and
> again and again and again.
While I don't doubt this can happen, I don't see this as a material reason
not to use CL.
> Therefore, trying to remove this barrier by simplifying the design of CL
> in this respect seems to be a fruitful place to pursue the kind of change
> that is a necessary (but perhaps not sufficient) condition to change CL's
> popularity. That is why I wrote the BIND proposal, and the Idiot's guide.
As we speak, the speed of processors is growing faster and faster. Size is
no longer an issue. I heard someone on gnu.emacs.help the other day say that
speed no longer matters because machines are so fast that even running
compiled doesn't matter. Not everyone shares this view, but we are at a
cross-roads where the problems of old are not the problems of new.
> Note that the intended audience for these two are very different. The
> BIND proposal was not written for newcomers.
If you think this is compatible, you can make a library that does this and
let people use it if they want.
I'd rather keep the language fixed, and I'd rather keep such things to the
realm of 'personal choice' if at all possible. Destabilizing the language
is expensive.
> I'd be interested in your reaction to all this. I think our disagreements
> will be more productive if we know whether we disagree about motives or
> methods.
Both, I think.
> > Also, it's a bad teaching technique (one I have independently
> > complained at others about in other contexts) to take a new student
> > and show them something to be surprised and dismayed about, and then
> > to peel back. e.g.,
> >
> > | A beginner's initiation into this state of affairs invariably comes when
> > | he or she one day as an expedient types (defvar x 1) and then spends the
> > | rest of the day (or week) trying to figure out why her code is suddenly
> > | exhibiting mysterious bugs.
>
> The intended audience for that quote was not beginners (which I thought
> would be obvious, since I am speaking *about* beginners in the third
> person).
>
> BTW, I wrote "The Idiot's Guide..." not so much because I think I'm
> particularly qualified to write it, but because I saw a need and thought
> that it would be better to step up to the plate than just complain about
> it. Likewise, I think if would be better if you don't like what I came up
> with to offer up an alternative of your own.
I am, quite honestly, spending time working on that.
> > "If you're going to accomodate history, you ought to first rewrite all
> > legacy applications to not have any uncomfortable truths
>
> There is a difference between accommodating history and being bound by
> it. If we always "accommodated history" to the extent that you seem to
> imply that you want here we'd all still be programming in or Lisp 1.5 (or
> Fortan 1).
There may come a time when we have the resources to do a new dialect.
But for now, I'd personally rather not unless something is shown to be
bankrupt. The right thing, I claim, is for you to carve out a subset
or a compatible library. Both of these can be done without affecting
the standard. In effect, Paul Graham does this in his books, since he
doesn't like some things about ANSI CL and does like others. I think
his attempts to spawn a new Lisp community are counterproductive, but
at the point where he dissociates himself from our community and goes
off to do it, that's his business and no longer mine.
> > and additionally
> > you ought to get rid of all notion of ever supporting expressions
> > like (eval '(+ x y)) and force people to write (eval '(+ *x* *y*))."
>
> [···@alvin tinyscheme-1.27]$ ./scheme
> TinyScheme 1.27
> > (define x 1)
> x
> > (define y 2)
> y
> > (eval '(+ x y))
> 3
> >
>
> Funny, that seems to work OK.
But what if I don't want x and y to be special forever after?
> > I'm not a big fan of people making criticisms of the language
> > design without investigating the reasons behind it. I also think
> > that ill-informed criticisms are best stored in containers other
> > than introductory material for new people.
>
> Ill informed, eh? I have been programming in Lisp for 20 years. I have
> read a significant fraction of all the books that have ever been written
> on the topic. I may not be the brightest bulb, but I'm no idiot either.
> If I am ill-informed then at what point do you think it would not be out
> of line to suggest that the fault might not lie entirely with me?
The ANSI CL spec did what it did for the purpose of satisfying its charter.
All languages should be critiqued in light of the community they serve. Your
remarks were intolerant of our goal and seemed to suggest that you
knew better.
Almost NO language design decision is good or bad in the abstract. The
decisions Scheme has made are mostly good for it and bad for us, and ours
are mostly good for us and bad for them. Sometimes we've made mistakes.
Sometimes the Scheme committee has made mistakes. But the mistakes are not
"we did x" or "we failed to do x" where x is a "must do" or "must not do"
thing for all languages. Rather, the mistakes are things that are
internally inconsistent between the design and the goals. And I think
ANSI CL has been pretty true to its goals. Most things I can think of
as wrong are things that could be added as layers, and I think that's the
way to go because it allows each user to guage how important "getting work
done" is and how important "rewriting programs to conform to the latest
trendy way to say the same old thing" is. CL grew out of a desire to not
be gratuitously rewriting programs. It didn't mean to stop the design of
languages--it merely meant to be a place for people to go who did not want
to be held continually hostage to others' desire to do that. Nothing other
than resources keeps you from designing your own--but if you lack the
resources, I don't think it's appropriate to say "therefore the community
should spend its resources changing for me, so that I don't have to pay".
Because then we all pay for what I think many of us don't want.
So far, for all the little nitpicks people have about CL, no one has pointed
at something fatal about it. It stands now not stagnant (the term I think
you used) but stable (my preferred spin). It doesn't need to change.
In article <···············@shell01.TheWorld.com>, Kent M Pitman
<······@world.std.com> wrote:
> ···@jpl.nasa.gov (Erann Gat) writes:
>
> > In article <···············@shell01.TheWorld.com>, Kent M Pitman
> > <······@world.std.com> wrote:
> >
> > [Many criticisms of my BIND proposal.]
> >
> > If I corrected these problems would you support the proposal?
>
> No.
I didn't think so.
> (a) If you leave the existing stuff, it only adds to complexity.
> And if you don't, it's seriously incompatible.
It is obviously not seriously incompatible, as I was able to implement
almost all of it entirely within the existing language. There is only one
tiny aspect of the proposal that requires a language change, and that one
is 100% backwards-compatible.
> (c) I would support the introduction of dynamic-bind or dynamic-let or
> whatever it is that Eulisp and I think also ISlisp has. (too lazy to
> look it up). At least that operator has a couple of communities
> behind it.
That would be fine. Do you have a proposal?
The truth is, I don't really care very much about BIND per se. What I
care about is that we get ourselves some process by which we as a
community introduce, debate, and adopt changes.
> What I was saying was that leading with negativity
> doesn't strike me as a winning argument.
I agree, but the "Idiot's Guide" was not written to advance an argument.
It was written to educate.
> > I am not speaking here as someone who aspires to be a spokesman for
> > Lisp. I aspire to be a *customer* (again). At the moment there are
> > serious obstacles in my way, not least of which is the fact that
> > Lisp is widely perceived to be dead. And judging by what I hear at
> > the CRACL meetings
>
> I don't know what CRACL is.
Campaign for Real Ale and Common Lisp. The Los Angles Lisp user's group.
Google is your friend.
> We've discussed this offline some. Without compromising the detail of
> private communications, is it safe to simply summarize by saying you
> haven't exactly been given a list of 5 things that if you fix,
> everyone will rally around Lisp and apologize for having had
> misgivings?
Nothing I have communicated to you has been confidential, so feel free to
share anything you like that I've written to you in private. No, I don't
have a list of 5 things. All I have is a belief that something has to
change, and someone has to start somewhere.
> Given that this is so, is it rational to continue to
> expend resources solving what might reasonably be called more of an
> emotional than a technical problem?
Of course. You say "might reasonably be called more of an emotional
problem" as if you thought that was somehow an impolite thing to suggest.
Of course it's an emotional problem and not a technical problem. That
doesn't make it any less of a problem, or any less worthy of being solved.
> Is it realistic to say we could,
> even if we became Scheme, go to people and say "we're pretty now, can
> you use us?" Surely they know Scheme exists and they are not flocking
> to that either. So why will "adding a layer of simplicity around our
> existing core" be any more likely to yield success?
Like I said, it's not about BIND per se. It's about change (even more to
the point, it's about trying to establish a *process* for change). BIND
is just a straw man, a concrete proposal to use to try to work out a
process.
> > 2. Assuming that Common Lisp's lack of popularity is a problem, what can
> > (or should) be done about it (if anything)?
>
> This is a reasonable question, although it may not have a single overarching
> answer. There may be communities worth pursuing and others not, IMO.
>
> I long ago gave up trying to push CL on everyone.
Me too. My goal is only to make it possible for me to make a living using
Lisp (preferably Common Lisp) without having to move to Boston.
> As such, I'm not convinced that CL's popularity is about the naming of
> car/cdr, etc. I think it's more about its perceived lack of foreign function
> interfaces, of ability to make and use DLLs, etc., its lack of RPC or
> RMI or HTML or graphics or sound support. Things that make it unable to be
> a good citizen in a heterogeneous environment. I don't think anyone cares
> a wit about special variables in this context--I think that's totally in
> the noise as far as acceptance of CL.
I completely agree. But we're not making any progress on these issues either.
> Yes. It must address issues that define the modern workplace. Handy support
> for hash tables or a clearer definition of what it is to bind a variable
> does not characterize the modern workplace.
Again, I completely agree. And again I say we don't seem to be making any
progress.
If you disagree, if you think we are making progress, would you please
point me to what you consider that progress to be?
> > 2. CL can only grow more popular by attracting new users. (This is a
> > tautology.) It is therefore more likely to become popular if barriers to
> > entry are removed.
>
> C and C++ have the world's most godawful syntax and people are able to
> learn and use those. I don't think syntax or the need to apply obscure
> rules are a barrier. If anything, the lack of funny little rules to occupy
> the minds of those trying to learn it is an obstacle. (Only half-joking.)
C and C++ are the market leaders. They have leverage that we don't have.
The fact that people have incentives to overcome the obstacles erected by
C++'s godawful syntax does not change the fact that they are in fact
obstacles. But C++ has enough other strengths that these obstacles are
surmountable.
The truth is that special variables are almost certainly not a
make-or-break issue for Lisp either. But it's an easy problem to fix.
Why not fix it?
> > 3. There are some technical issues that new CL users appear to become
> > perennially confused about, special variables (and related issues having
> > to do with bindings and lexical closures) seem to be chief among these.
> > This is bad because 1) it's a barrier to entry and 2) lots of time is
> > wasted trying to explain these issue to newcomers on c.l.l. again and
> > again and again and again.
>
> While I don't doubt this can happen, I don't see this as a material reason
> not to use CL.
It isn't. The material reason not to use CL is that no one uses CL. This
is a positive-feedback loop of doom, a self-fulfilling prophecy. The only
way out is to find those people who are not already convinced that Lisp is
a waste of time and get them to use it. Those people, I believe, make
their decisions on a host of factors, which includes how hard they
perceive Lisp is to learn. The first thing they encounter is the weird
syntax. That's usually strike one. Then the next thing they usually run
into is defvar. That often becomes strike two. I don't know what strike
three usually is because most newbies don't stick around c.l.l. long
enough to let us know.
> I'd rather keep the language fixed, and I'd rather keep such things to the
> realm of 'personal choice' if at all possible. Destabilizing the language
> is expensive.
Then I wonder what you envision as Lisp's future. Do you think it will
experience a renaissance? If so, what will drive it? If the language
doesn't change, why will Lisp suddenly rally now, when its competitive
edge has been eroded (not eliminated, but other languages have certainly
closed the gap in the last ten years)?
If not, if you think Lisp will just chug along as it has, are you OK with
that? Are you making a comfortable living using Lisp? Are you OK knowing
that there are lots of people out there who would like to use Lisp but
can't?
> > BTW, I wrote "The Idiot's Guide..." not so much because I think I'm
> > particularly qualified to write it, but because I saw a need and thought
> > that it would be better to step up to the plate than just complain about
> > it. Likewise, I think if would be better if you don't like what I came up
> > with to offer up an alternative of your own.
>
> I am, quite honestly, spending time working on that.
That's great. I look forward to reading it.
> There may come a time when we have the resources to do a new dialect.
> But for now, I'd personally rather not unless something is shown to be
> bankrupt. The right thing, I claim, is for you to carve out a subset
> or a compatible library.
No, because the problem is not that Common Lisp is broken, the problem is
that I can't use it at all (except as a hobby). No amount of private
hacking can solve that problem.
> Both of these can be done without affecting the standard.
Right, but I don't see any way to solve *my* problem without affecting the
standard. (That effect could be to extend it, not necessarily to change
it in non-backwards-compatible ways.)
> In effect, Paul Graham does this in his books, since he
> doesn't like some things about ANSI CL and does like others. I think
> his attempts to spawn a new Lisp community are counterproductive, but
> at the point where he dissociates himself from our community and goes
> off to do it, that's his business and no longer mine.
Right. I'm also pursuing that strategy in parallel. But I have no
illusions about how hard this is, and so I don't have high hopes for
success. (That doesn't stop me from trying.) But because I don't have
high hopes for success (for either my effort or Arc, which seems so far to
be just a reinvention of Scheme) I still hope to make the CL community
realize - speaking as a *customer* now - that change is in *your best
interests*.
> > > and additionally
> > > you ought to get rid of all notion of ever supporting expressions
> > > like (eval '(+ x y)) and force people to write (eval '(+ *x* *y*))."
> >
> > [···@alvin tinyscheme-1.27]$ ./scheme
> > TinyScheme 1.27
> > > (define x 1)
> > x
> > > (define y 2)
> > y
> > > (eval '(+ x y))
> > 3
> > >
> >
> > Funny, that seems to work OK.
>
> But what if I don't want x and y to be special forever after?
What on earth are you talking about? That was Scheme. There are no
special variables. EVAL works nonetheless. (Actually "what if I don't
want x and y to be special forever after?" is *my* line! :-)
> All languages should be critiqued in light of the community they serve. Your
> remarks were intolerant of our goal and seemed to suggest that you
> knew better.
Well, 1) I am part of the community you serve and 2) I do believe that
some of your goals and design decisions, while valid at the time, are now
counterproductive and ought to be revisited. But all this is secondary to
my larger point which is that even if you got everything right the first
time, it is prima facie not working. If it were, Yahoo would not have
spent however many millions it did converting Yahoo Store from Lisp to
C++. JPL would be writing its next generation spacecraft software in Lisp
instead of C++. There would be more than three job openings posted at
http://franz.com/careers/jobs/outside/.
> but if you lack the
> resources, I don't think it's appropriate to say "therefore the community
> should spend its resources changing for me, so that I don't have to pay".
I am not saying that. I am saying: the community should spend its
resources changing. Period. End of story. Not for me. Not so I don't
have to pay. But so that I *can* pay (with my employer's money)!
> So far, for all the little nitpicks people have about CL, no one has pointed
> at something fatal about it.
I can count its major users on the fingers of one hand. That's fatal.
> It stands now not stagnant (the term I think
> you used) but stable (my preferred spin). It doesn't need to change.
Is your business ready to open a branch office in Los Angeles?
It is ironic that we are at loggerheads about this because I think we both
want the same thing: for CL to be a commercial success so that we can make
money using it. I don't see how that's going to happen without change.
E.
···@jpl.nasa.gov (Erann Gat) wrote in message news:<····················@192.168.1.51>...
> Then I wonder what you envision as Lisp's future. Do you think it will
> experience a renaissance? If so, what will drive it?
Moore's law.
········@yahoo.com (Eric Smith) writes:
>> Then I wonder what you envision as Lisp's future. Do you think it
>> will experience a renaissance? If so, what will drive it?
>
> Moore's law.
Unlikely. Lisp is faster than a lot of more popular languages
today. Perfomance doesn't seem to be the problem (prejudices
concerning performance may be, but they will not go away just because
of Moore's law).
Henrik
Henrik Motakef <··············@web.de> writes:
> ········@yahoo.com (Eric Smith) writes:
>
> >> Then I wonder what you envision as Lisp's future. Do you think it
> >> will experience a renaissance? If so, what will drive it?
> >
> > Moore's law.
>
> Unlikely. Lisp is faster than a lot of more popular languages
> today. Perfomance doesn't seem to be the problem (prejudices
> concerning performance may be, but they will not go away just because
> of Moore's law).
The memory usage of most lisp implementations was a real problem until
quite recently, so I'd say that the increase in the standard amount
of installed RAM has made lisp much more usable for mainstream
applications during the last 5 years. (My lisp applications now
typically uses about 32MB of RAM, which is acceptable today, but
which could have been problematic 3 or 4 years ago).
In fact, I think lisp is in a better position than ever. I've used
common lisp for 'business critical' server applications for 4 years
now, and recently I've developed a GUI application with a lot of
happy users. This application is developed on linux and delivered
in both linux and windows versions, thanks to Xanalys' CAPI GUI
library. And as you might have noticed, Xanalys has announced a beta
Mac OS X version, which will make it possible to release my application
for Mac OS X too, with almost no extra programming effort.
It's more fun than ever to be a lisp programmer, and I actually
think we'll see an increase in usage and popularity!
(But I don't think I want Common Lisp to be _the_ most popular language,
just think what certain big software companies could do to it...)
--
(espen)
Espen Vestre wrote:
> The memory usage of most lisp implementations was a real problem until
> quite recently, so I'd say that the increase in the standard amount
> of installed RAM has made lisp much more usable for mainstream
> applications during the last 5 years.
The increase in overall computer speed also increases the rate
at which lisp implementations can be modified, by allowing
faster and more frequent build/test cycles.
Paul
From: Tim Bradshaw
Subject: Re: MAKUNBOUND and nested bindings?
Date:
Message-ID: <ey33cjogpct.fsf@cley.com>
* Paul F Dietz wrote:
> The increase in overall computer speed also increases the rate
> at which lisp implementations can be modified, by allowing
> faster and more frequent build/test cycles.
But Lisp build/test cycles have been faster than C build/test cycles
for ... well, for ever.
--tim
Espen Vestre <·····@*do-not-spam-me*.vestre.net> writes:
> (But I don't think I want Common Lisp to be _the_ most popular language,
> just think what certain big software companies could do to it...)
Heh.
In article <··············@merced.netfonds.no>, Espen Vestre
<·····@*do-not-spam-me*.vestre.net> wrote:
> In fact, I think lisp is in a better position than ever. I've used
> common lisp for 'business critical' server applications for 4 years
Would you be willing to make some details of your experience available so
the rest of us can cite your experience as a success story?
> (But I don't think I want Common Lisp to be _the_ most popular language,
Neither do I. I just want it to be popular enough so that I can use it again.
E.
···@jpl.nasa.gov (Erann Gat) writes:
> > In fact, I think lisp is in a better position than ever. I've used
> > common lisp for 'business critical' server applications for 4 years
>
> Would you be willing to make some details of your experience available so
> the rest of us can cite your experience as a success story?
Sure. I presented a 'success story talk' on the server stuff I did for
my previous employer on the ELUGMs in 1998 and 1999, and on the
JLUGM-2000. You can download the paper from the JLUGM proceedings
page:
http://jp.franz.com/jlug/en/jlugm2000/
(I don't have a paper available on my current stuff, but I'll probably
put something together soon)
--
(espen)
Espen Vestre <·····@*do-not-spam-me*.vestre.net> writes:
> Henrik Motakef <··············@web.de> writes:
>
> > ········@yahoo.com (Eric Smith) writes:
> >
> > >> Then I wonder what you envision as Lisp's future. Do you think it
> > >> will experience a renaissance? If so, what will drive it?
> > >
> > > Moore's law.
> >
> > Unlikely. Lisp is faster than a lot of more popular languages
> > today. Perfomance doesn't seem to be the problem (prejudices
> > concerning performance may be, but they will not go away just because
> > of Moore's law).
>
> The memory usage of most lisp implementations was a real problem until
> quite recently, so I'd say that the increase in the standard amount
> of installed RAM has made lisp much more usable for mainstream
> applications during the last 5 years. (My lisp applications now
> typically uses about 32MB of RAM, which is acceptable today, but
> which could have been problematic 3 or 4 years ago).
Well, this really depends on the implementation. For Unix CLs, I
think this has been an acceptable memory usage (for non-pipeline
tools) for at least 8 years. But it's been quite possible to run Lisp
in more memory-starved situations. From "Getting Started with MCL":
MCL 4.0 Memory Requirements
The MCL 4.0 size resource is set for a *generous* partition showing
approximately 4.8 mb with virtual memory and 5.1 mb without.
[emphasis mine]
> It's more fun than ever to be a lisp programmer, and I actually
> think we'll see an increase in usage and popularity!
>
> (But I don't think I want Common Lisp to be _the_ most popular language,
> just think what certain big software companies could do to it...)
I'm in 100% agreement here.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
···@fallingrocks.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
> But it's been quite possible to run Lisp
> in more memory-starved situations. From "Getting Started with MCL":
Don't tell me: 12 years ago I programmed computational linguistics
software in MCL on a Mac SE (8Mhz 68k) with only 2,5 MB RAM (in
total!)- and it wasn't painful at all! I deliberately said 'most lisp
implementations', and the exception I had in mind was MCL.
--
(espen)
In article <··············@merced.netfonds.no>, Espen Vestre
<·····@*do-not-spam-me*.vestre.net> wrote:
> ···@fallingrocks.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
>
> > But it's been quite possible to run Lisp
> > in more memory-starved situations. From "Getting Started with MCL":
>
> Don't tell me: 12 years ago I programmed computational linguistics
> software in MCL on a Mac SE (8Mhz 68k) with only 2,5 MB RAM (in
> total!)- and it wasn't painful at all! I deliberately said 'most lisp
> implementations', and the exception I had in mind was MCL.
And just because there's not enough memory to *run* Lisp doesn't
necessarily mean you can't *use* Lisp. In the 80's and 90's, Lisp (and
MCL in particular) was widely used to write compilers for embedded control
languages that compiled to native code for 8-bit processors with as little
as a few hundred bytes of RAM.
E.
Espen Vestre wrote:
> In fact, I think lisp is in a better position than ever.
I strongly second this. There are many factors in the "real world" that
support the notion that Lisp has the chance to rise again, at least from
my point of view. There are many trends in the field of software
engineering that obviously just reinvent Common Lisp in the sense of
Greenspun's tenth rule:
+ Metaprogramming is currently becoming a mainstream approach (AOP, GP,
and the like).
+ .NET tries to find a "mother of all languages".
+ Extreme Programming is a driving factor that seems to convince people
that dynamic typing can be better than static typing.
...to name just a few. The interesting part is that these are approach
that considerably different in nature in that they try to tackle very
different things. It's only a matter of time for someone to rediscover
that they all have a common substrate.
Pascal
--
Pascal Costanza University of Bonn
···············@web.de Institute of Computer Science III
http://www.pascalcostanza.de R�merstr. 164, D-53117 Bonn (Germany)
Henrik Motakef <··············@web.de> wrote in message news:<··············@interim.henrik-motakef.de>...
> today. Perfomance doesn't seem to be the problem (prejudices
> concerning performance may be, but they will not go away just because
> of Moore's law).
Moore's law is a continuous process, not a
sudden event. The higher up the curve we
get, the higher the ratio of the power and
utility of Lisp to those of other languages.
When it finally reaches the point where it
becomes glaringly obvious and can no longer
be denied, there may be a herd effect, like
that keeping people away from Lisp now,
causing it to suddenly become many times more
popular than it ever was before. And even
then, Moore's law would continue, eventually
bringing a future we can hardly imagine.
Whether most of us can earn a living from Lisp
right now has nothing to do with whether we
could in the past, nor with whether we can in
the future. At each point on the Moore's law
curve, the conditions are different. The only
thing that seems sure is that once it finally
becomes easy to earn a living from Lisp, it
should continue after that to get easier and
easier. Whether the time is ripe yet is not
knowable until some time after large numbers of
people are indeed earning their livings from
Lisp so we would have a history of such success.
···@jpl.nasa.gov (Erann Gat) writes:
> > (c) I would support the introduction of dynamic-bind or dynamic-let or
> > whatever it is that Eulisp and I think also ISlisp has. (too lazy to
> > look it up). At least that operator has a couple of communities
> > behind it.
>
> That would be fine. Do you have a proposal?
This is what ISLISP does, and I think maybe Eulisp does, too.
(defmacro dynamic (x)
`(symbol-value ',x))
(defmacro dynamic-let (bindings &body forms)
`(let ,bindings
(declare (special ,@(mapcar #'car bindings)))
,@forms))
Here is an example from the ISLISP specification:
(defun foo (x)
(dynamic-let ((y x))
(bar 1)))
(defun bar (x)
(+ x (dynamic y)))
(foo 2)
=> 3
Note, btw, that it's not an accident that ISLISP can be implemented
entirely using existing CL operations. I implemented a compatibility
package for ISLISP in ANSI CL prior to the close of ANSI CL, just to
assure that we were able to accept the concepts of ISLISP _without
further change to the language_. This was what caused us to introduce
the LAMBDA and DEFINE-SYMBOL-MACRO macros. But that was all that was
missing.
> The truth is, I don't really care very much about BIND per se. What I
> care about is that we get ourselves some process by which we as a
> community introduce, debate, and adopt changes.
I don't agree. I think we should not be seeking a reason to make change
unless we have something we can't live with. I think we can live with
what we have for quite some time. When we can't live with it, that is,
a compelling technical reason for change, I will be the first to advocate
a process. But when 'problems' like this can reasonably be fixed with a
simple defmacro, we do NOT need change.
> > Is it realistic to say we could,
> > even if we became Scheme, go to people and say "we're pretty now, can
> > you use us?" Surely they know Scheme exists and they are not flocking
> > to that either. So why will "adding a layer of simplicity around our
> > existing core" be any more likely to yield success?
>
> Like I said, it's not about BIND per se. It's about change (even more to
> the point, it's about trying to establish a *process* for change). BIND
> is just a straw man, a concrete proposal to use to try to work out a
> process.
The design of Common Lisp made us do a very important little piece of
what I originally thought was needless red tape and what I eventually came
to respect as very important mental work (for which I credit Larry Masinter):
Separate the problem description from the proposal.
For example, a proposal of the form "We don't have EQUALP hash tables."
can only be answered by "adding EQUALP hash tables", so odds are that it
really doesn't describe the problem and is more likely someone's pet way
of forcing a particular end. Had EQUALP hash tables been added through
such a process (and they weren't, because they were added in CLTL, not the
X3J13 cleanup process) we might not have them. We might instead have had
a problem description like "People will want case-insensitive hashing" and/or
"People will want type-insensitive numeric hash tables." Because the only
uses of EQUALP hash tables that _I_ make are where I want to use = or
STRING-EQUAL. And I'm not sure these were ever considered.
So you probably want a place to submit your BIND proposal, but I'm not
speaking at that level. I'm speaking at the meta level.
You see the thing that's wrong as "CL is missing a path to change" but you
actually don't have a change you care about. Let me not misquote, just
repeat what you said precisely:
>> Like I said, it's not about BIND per se. It's about change
Because of this, I think you don't really need this. So far, all of the
things you want can be accomodated WITHIN the language. And that is what
the language was designed for. The only things I can think of that cannot
be accomodated within the language can be added by vendors as EXTENSIONS
and still don't require a change in the language.
You are just needlessly rousing rabble and for now I think you are being
very ineffective about it so it doesn't worry me. But if you ever got
efficient at it, it would be unhelpful to the community--not because the
community needs to resist change, but because the need for change needs to
arise out of the "need" not the "absent process for change".
Moreover, as you said yourself, change does not imply better. Yes, as you
noted, better implies change. But you first have to show that better is
needed. Because the kind of better that requires change has not been
demonstrated. The bogus argument you are making is just as possible to
apply to Scheme--that to be better it must change. Scheme design moves at
a glacial pace, and a lot of people want more things in it. But as with
CL, its user community is happy with the core--the core is not the problem.
Saying that to become better, it must change bogusly introduces the fear that
it is not becoming better. You need to first introduce a metric of goodness
that explains when "good enough" will ever be achieved, why it has not
been achieved now, etc. I think it's aimed at what the Linux community
calls FUD (Fear, Uncertainty, and Doubt) and not at any clear material end.
And I think we don't need that.
> > > 2. Assuming that Common Lisp's lack of popularity is a problem, what can
> > > (or should) be done about it (if anything)?
> >
> > This is a reasonable question, although it may not have a single
> > overarching answer. There may be communities worth pursuing and
> > others not, IMO.
> >
> > I long ago gave up trying to push CL on everyone.
>
> Me too. My goal is only to make it possible for me to make a living using
> Lisp (preferably Common Lisp) without having to move to Boston.
Why preferably Common Lisp given that you appear to dislike it so,
AND given that you seem to think that Common Lisp is not wanted
where you are. Why not make a new dialect that (a) changes what you
want to change for whatever reasons you want [there's no sin in change,
even gratuitous change, if you do it without foisting it on the unwilling],
and (b) has a new name that is not tainted in whatever way you perceive
it to be tainted? I don't really think Paul Graham is doing the right thing
with Arc, but he's certainly entitled to do what he's doing.
I am NOT just trying to blow you off with this remark. My point is that
the EASIEST way to do design and the quickest path to success is to free
yourself of the baggage of compatibility. Most of your arguments are about
how compatibility doesn't matter, and you're trying to make these arguments
to people to whom compatibility does matter. The way you get compatibility
not to matter is NOT to convince others it doesn't, but to blow off those
who think it does. That is not a concensus process, it's a selfish personal
act accompanied by the hope others will follow.
CL itself did not begin by the community deciding to do CL. It began by
a few key individuals in the community deciding CL would be needed. The sell
for the community itself was trickier. Each individual had to decide whether
to follow and a lot of that deciding happened _after_ CL was designed, not
before. Part of what convinced them was the completion of the design (not
a sure thing at the outset), the appearance of implementations (since no one
wants to program in a non-existent language), and the overcoming of apparent
problems in those implementations (it doesn't look fast enough, it has bugs,
etc.). Setting out on your own is risky, but that's the price of leadership.
Rousing people to want to set out with you increases the risk to the
community that it will invest in a failure. Languages are not well-designed
by committees. It's better for an individual with a single-minded view to
get things mostly right (as Steele did with CL, and as Sussman/Steele did with
Scheme) and _then_ allow people to fiddle if that's even desired. But most
of the community is happy waiting and watching rather than sharing your risk
even if what you are doing is the path they want. Their presence increases
risk of failure ("too many cooks") AND increases their risk of not getting
work done in the interim.
> > As such, I'm not convinced that CL's popularity is about the
> > naming of car/cdr, etc. I think it's more about its perceived
> > lack of foreign function interfaces, of ability to make and use
> > DLLs, etc., its lack of RPC or RMI or HTML or graphics or sound
> > support. Things that make it unable to be a good citizen in a
> > heterogeneous environment. I don't think anyone cares a wit about
> > special variables in this context--I think that's totally in the
> > noise as far as acceptance of CL.
>
> I completely agree. But we're not making any progress on these
> issues either.
Progress on this does not require changes to the base language.
Honestly, I think any vendor who thought changes were needed would just
make and document the changes they needed. Suggestions for changes are
taken most seriously from vendors. Their willingness to deviate from a
published standard is a credential that speaks to the issue.
As in the case of Franz and its case sensitivity issues. [No, no,
please let's not actually discuss that issue per se. I just want to
cite it as a willful deviation.] However, user pressure back on a
vendor to do things compatibly also plays in, and there was huge
screaming of "this is unnecessary". Also--I, as a user, have
suggested a technique that I think finally solves Franz's problem in
this area in a compatible way, so I _think_ a language change was not
needed and they have come out with or will be coming out with a change
that makes things compatible and conforming again. But whether or not
that's so, my point for here is just that the need for change has a much
higher bar than you are suggesting. And while Franz has, in my
estimation, pushed hardest against the existing spec, they have not yet
stopped saying they are committed to conformance.
Trial by fire, in other words, for a vendor that deviates--the community
will judge when that is reasonable, but they will NOT respect (I claim)
a vendor that doesn't conform merely because it needs an extra macro
(e.g., BIND). They will say "Make your own package, write the defmacro,
let those who choose to use it use it and leave the rest of us alone."
Just my guess.
> > Yes. It must address issues that define the modern workplace.
> > Handy support for hash tables or a clearer definition of what it
> > is to bind a variable does not characterize the modern workplace.
>
> Again, I completely agree. And again I say we don't seem to be making any
> progress.
Progress does not require a change in the spec. It requires extension.
Extension can be done compatibly.
> If you disagree, if you think we are making progress, would you please
> point me to what you consider that progress to be?
Irrelevant.
> > > 2. CL can only grow more popular by attracting new users. (This is a
> > > tautology.) It is therefore more likely to become popular if barriers to
> > > entry are removed.
> >
> > C and C++ have the world's most godawful syntax and people are able to
> > learn and use those. I don't think syntax or the need to apply obscure
> > rules are a barrier. If anything, the lack of funny little rules to occupy
> > the minds of those trying to learn it is an obstacle. (Only half-joking.)
>
> C and C++ are the market leaders. They have leverage that we don't have.
C++ became market leaders in the presence of CL.
> The fact that people have incentives to overcome the obstacles erected by
> C++'s godawful syntax does not change the fact that they are in fact
> obstacles. But C++ has enough other strengths that these obstacles are
> surmountable.
The problems of the 'fragile base class' (need to recompile entire
world when a minor change is made in one class) and of the improper
conceptual application of methods (based on static typing rather than
dynamic typing) are 'surmountable' but the syntax for special
variables in Common Lisp is not 'surmountable'?
> The truth is that special variables are almost certainly not a
> make-or-break issue for Lisp either. But it's an easy problem to fix.
> Why not fix it?
Because it is not broken.
Because creating a mechanism for change is gratuitous when nothing is
broken.
Because you appear to be looking for a playground, and a stable
language is not a playground. Especially not this one, which was created
exactly to protect itself from people like you. REALLY. CL was created
exactly because there _was_ a frequency of change and people who were doing
real applications (DARPA, in particular) were tired of having tinkerers
break things every week. A fixed target for development was required
for serious investment.
> > > 3. There are some technical issues that new CL users appear to become
> > > perennially confused about, special variables (and related issues having
> > > to do with bindings and lexical closures) seem to be chief among these.
> > > This is bad because 1) it's a barrier to entry and 2) lots of time is
> > > wasted trying to explain these issue to newcomers on c.l.l. again and
> > > again and again and again.
> >
> > While I don't doubt this can happen, I don't see this as a material reason
> > not to use CL.
>
> It isn't. The material reason not to use CL is that no one uses CL. This
> is a positive-feedback loop of doom, a self-fulfilling prophecy. The only
> way out is to find those people who are not already convinced that Lisp is
> a waste of time and get them to use it. Those people, I believe, make
> their decisions on a host of factors, which includes how hard they
> perceive Lisp is to learn. The first thing they encounter is the weird
> syntax. That's usually strike one. Then the next thing they usually run
> into is defvar. That often becomes strike two. I don't know what strike
> three usually is because most newbies don't stick around c.l.l. long
> enough to let us know.
If all that is needed to make people use CL is to add a few macros, add the
few macros and call it something else and see if people flock to your new
dialect. You don't need anyone's help.
> > I'd rather keep the language fixed, and I'd rather keep such things to the
> > realm of 'personal choice' if at all possible. Destabilizing the language
> > is expensive.
>
> Then I wonder what you envision as Lisp's future.
Layered standards. I want to finally BUILD something.
The electronics industry did not move ahead by constantly redesigning
the semantics of the transistor. They moved ahead by constantly
reimplementing a fixed semantics. Even the instruction set of the PC
is not god's gift to the universe, but vendors don't redesign it on
every rev or they'd lose their base--they instead leave it as is
because it's "good enough" and they focus on improving the engineering
and encouraging people to build stuff. People talk about tagged
architectures, and there are reasons to believe they'd be good to
have, but the money is not made on tagged architectures, it's made on
churning the untagged ones. This suggests that absolute goodness of
the underlying design is not the barrier to success. The market is
full of examples of things that succeed over other technically
superior things. You have done no work to show that any of the
changes you are suggesting will have (a) a material effect on growing
our community size and (b) no material ill effect on the community
size.
> Do you think it will experience a renaissance?
I don't concern myself with this. I think matters have improved. I think
they have improved by concerning ourselves with commercial issues and
stopping being language design tinkerers.
I used to say at old-Harlequin, which always had little technical
projects starting new things going all the time, and very little
working on marketing the result of anything: no more people to start
things, only people to finish things. What CL lacks is not a good base.
The base has been done to death. It's fine. What CL lacks, if anything,
is finished applications. And what is stopping people from getting there
is NOT special variables. Except perhaps in the sense that it's too much
fun for some people to tinker on special variables (or anything else)
and too little fun to work on finished applications.
> If so, what will drive it? If the language
> doesn't change, why will Lisp suddenly rally now, when its competitive
> edge has been eroded (not eliminated, but other languages have certainly
> closed the gap in the last ten years)?
This is a false argument. It suggests something is wrong with the
language. If you think something is wrong with it, USE SOMETHING
ELSE. The people who are using it are not, primarily, complaining
that the language is wrong. They are asking for tools atop it. They
need it to connect/deploy with the world.
> If not, if you think Lisp will just chug along as it has, are you OK with
> that?
Yes.
> Are you making a comfortable living using Lisp?
I don't think I'd be making a better living using other languages.
My present financial difficulties are not Lisp-related. Lisp allows
me to get by on less resources better than other languages would.
> Are you OK knowing that there are lots of people out there who
> would like to use Lisp but can't?
They are not kept from doing so by the semantics of the special variables.
> [...] the problem is not that Common Lisp is broken, the problem is
> that I can't use it at all (except as a hobby). No amount of private
> hacking can solve that problem.
This is not caused by special variables either.
> > Both of these can be done without affecting the standard.
>
> Right, but I don't see any way to solve *my* problem without affecting the
> standard. (That effect could be to extend it, not necessarily to change
> it in non-backwards-compatible ways.)
I don't think your problem would be solved by changing the standard.
It might be solved by changing the name of the language, and by
writing a parser to disguise the syntax.
Re-selling a language with such a thin veneer might require a special
intellectual property agreement with whatever vendor you used as the
underlying base, or might be possible to do regardless if you have free
software, but is probably doable either way.
> > In effect, Paul Graham does this in his books, since he
> > doesn't like some things about ANSI CL and does like others. I think
> > his attempts to spawn a new Lisp community are counterproductive, but
> > at the point where he dissociates himself from our community and goes
> > off to do it, that's his business and no longer mine.
>
> Right. I'm also pursuing that strategy in parallel. But I have no
> illusions about how hard this is, and so I don't have high hopes for
> success. (That doesn't stop me from trying.) But because I don't have
> high hopes for success (for either my effort or Arc, which seems so far to
> be just a reinvention of Scheme) I still hope to make the CL community
> realize - speaking as a *customer* now - that change is in *your best
> interests*.
Whether you mean to be or not, I think you are just lonely. And I think
you are trying to rally support by raising the level of discontent with
CL. I don't think this is going to help our tiny community. If you're
"lucky", it will fragment us. If you're not, it will have no effect at
all and things will lumber along as they are. I don't see either of these
outcomes as better. If you were offering a _done_ language for our
fragmented community to go to, I might consider that ok. But if people
who might write applications (the one thing that will materially change
our market position) jump ship just because they feel left out of language
design and want to tinker themselves, this will not be a good outcome.
> > All languages should be critiqued in light of the community they
> > serve. Your remarks were intolerant of our goal and seemed to
> > suggest that you knew better.
>
> Well, 1) I am part of the community you serve
This is not clear. You are just one person. One can't judge the US
political system on the basis of a single terrorist [not to make too
strong an analogy, I'm not accusing you of being a terrorist :-)]. By
community, I meant aggregate bodies. I did mean to informally
characterize you as statistically in the tiny minority, at least
that's my belief.
I also think the community is not determined by who shows up and says
"serve me". I think the community determined by who the language
designers say they seek to serve. CL sought to serve people who want
commercial stability, and it placed aesthetics secondary. You
continually push against stability and hawk aesthetics. That means,
in my mind, you are not our target customer. That's not an official
statement of policy; just a personal observation.
> and 2) I do believe that some of your goals and design decisions,
> while valid at the time, are now counterproductive and ought to be
> revisited.
Then it's time to make your own set of goals. And here's a piece of
advice: don't use 'goals' and 'design decisions' in an 'and'. These
are not siblings. One should drive the other. Either criticize the
design decisions and realize as a dependent issue that the goals are
wrong or criticize the goals and then revisit the design decisions.
But don't try to do both at once. It will lead you to conceptual
conflicts of interest.
> But all this is secondary to
> my larger point which is that even if you got everything right the first
> time, it is prima facie not working.
There's heaps of free software out there so you don't have to start
from scratch. The defense department and the NSF are constantly
offering grants for people who can help move the world forward. Even
SBA loans are available. If this is what you think would fix things,
you don't have to start from scratch.
And ethere is Paul Graham's Arc effort. You could join forces with him.
> If it were, Yahoo would not have
> spent however many millions it did converting Yahoo Store from Lisp to
> C++.
Are you kidding? This is just an issue of some person with a staff of C++
programmers and experience in managing trying to save his job. Of course
they did this. I'd have been surprised if they didn't.
> JPL would be writing its next generation spacecraft software in Lisp
> instead of C++.
Ditto.
> There would be more than three job openings posted at
> http://franz.com/careers/jobs/outside/.
Do you seriously suggest that a semantic change to the language will fix
this? There was a war for who would be the commodity language and we lost.
We did not lose for purely technical reasons, although the time at which
the war was fought was not our strongest time, and we did lose for _some_
technical reasons that have largely since been fixed. (Implementational
issues--lack of ability to compile things like DLLs, to talk to COM and
CORBA, etc.) But the war is not to be re-fought. Industry has moved on.
There is little to no likelihood that we will win for reasons not technical.
There is no point to spinning our wheels trying. It's better to work with
the niche we have of people who see the value.
Suppose we were books and we had lost the war for literacy to not just
'movies' (which at least include thoughtful pieces like Casa Blanca that
deal with romance and war and virtue and ethics) but 'pop movies' (which
mostly are just mind candy like The Matrix). Would we be saying "If only
we wrote better books, people would come back on their knees apologizing?"
The fact is that some people still read and a lot of people are just lost.
Books are being "reimplemented" as movies. But that's not to say that books
are wrong. They just have a niche market now. Literate folks. Probably
in the future people won't be literate since interfaces will talk and no
one will need to read. Maybe audio books will rise anew. But it won't help
to make all books just contain text like "and then the guy spun into the air
and froze there and bullets stopped and the room spun giving you this cool
view of the scene from all angles". It will be better if books just go on
serving the people who care about them, and not lose that audience ALSO.
Those who like books don't want books to become movies. They like them
because they are different than movies.
> > but if you lack the
> > resources, I don't think it's appropriate to say "therefore the community
> > should spend its resources changing for me, so that I don't have to pay".
>
> I am not saying that. I am saying: the community should spend its
> resources changing. Period. End of story. Not for me. Not so I don't
> have to pay. But so that I *can* pay (with my employer's money)!
You haven't even begun to make a credible case. IMO, and it's just one
opinion, you're expending energy suggesting change on the basis of
trivialities, and losing your credibility before you begin because you're
making it appear you don't understand what a good reason for change is
and because you're making it possible that if you later suggest change is
needed that you're just doing it again for contrived reasons in order to
bootstrap a change process for its own sake rather than because it's needed.
> > So far, for all the little nitpicks people have about CL, no one
> > has pointed at something fatal about it.
>
> I can count its major users on the fingers of one hand. That's fatal.
No it's not. That's a sign of life. It is neutral in meaning and subject
to spin. It's a positional indicator, not vector gradient information.
The community has had many fewer users in the past and is presently on
the upswing. Probably not to compete with C/C++, but for a healthy
community.
> > It stands now not stagnant (the term I think
> > you used) but stable (my preferred spin). It doesn't need to change.
>
> Is your business ready to open a branch office in Los Angeles?
Not yet. But that's not a metric of success for me.
> It is ironic that we are at loggerheads about this because I think
> we both want the same thing: for CL to be a commercial success so
> that we can make money using it.
I agree with this remark. I just think the things you are suggesting
will squeeze the precious lifeblood out of a small but vaiable community.
But I also don't have the same metric of financial success. I care only
about self-sustaining. As long as Lisp continues to be available, I'm
happy. Since there are free software offerings, whatever else I may say
about them, this fact is reasonably assured. It is impossible for Lisp
to "go away". (As such, my needs for Lisp is trivially assured, although
I am "not free" to offer products in all the ways I would like to--there
are still ways ("servers") that I can use free software commercially.)
I prefer to use commercial offerings if I can because they offer me more
freedom than the so-called free stuff does, but if those go away, I'll cope.
Nevertheless, while I share your goal, we differ in one important respect:
I do not see the sky as falling. The situation is not NEARLY as dire as it
was a decade ago.
> I don't see how that's going to happen without change.
It's going to happen by focusing on commercial success and changing only
where the only thing standing between us and commercial success is change.
Otherwise, it's a bad expenditure of tight resources.
OK, Kent, you've convinced me that this is a bad idea. I am hereby
dropping it. I'd like to clarify a few things though:
In article <···············@shell01.TheWorld.com>, Kent M Pitman
<······@world.std.com> wrote:
> Why preferably Common Lisp given that you appear to dislike it so,
I don't dislike it. I have spent most of my career programming in CL. I
have made significant career sacrifices in order to be able to continue to
program in CL. And now I fear I may have burned a few bridges here in a
failed attempt to try to continue to be able to program in CL. I am
actually quite offended that anyone even remotely familiar with my record
could think that I dislike CL.
> Why not make a new dialect that (a) changes what you
> want to change for whatever reasons you want [there's no sin in change,
> even gratuitous change, if you do it without foisting it on the unwilling],
> and (b) has a new name that is not tainted in whatever way you perceive
> it to be tainted? I don't really think Paul Graham is doing the right thing
> with Arc, but he's certainly entitled to do what he's doing.
Like I said (and as you well know because I hired you to help me with it)
I am pursuing this avenue as well. But I am not doing this because I want
to. I am doing it beause I do not have any other viable choice (other
than becoming a C++ programmer).
> > I completely agree. But we're not making any progress on these
> > issues either.
>
> Progress on this does not require changes to the base language.
I never said it did.
> > > Yes. It must address issues that define the modern workplace.
> > > Handy support for hash tables or a clearer definition of what it
> > > is to bind a variable does not characterize the modern workplace.
> >
> > Again, I completely agree. And again I say we don't seem to be making any
> > progress.
>
> Progress does not require a change in the spec. It requires extension.
> Extension can be done compatibly.
And 90% of the BIND proposal could be done compatibly (as evidenced by the
fact that the proposal contained an implementation). The remaining 10%
could be done with a backwards-compatible extension.
> > If you disagree, if you think we are making progress, would you please
> > point me to what you consider that progress to be?
>
> Irrelevant.
Why?
> The problems of the 'fragile base class' (need to recompile entire
> world when a minor change is made in one class) and of the improper
> conceptual application of methods (based on static typing rather than
> dynamic typing) are 'surmountable' but the syntax for special
> variables in Common Lisp is not 'surmountable'?
I never said the problems caused by special variables were insurmountable.
> If all that is needed to make people use CL is to add a few macros, add the
> few macros and call it something else and see if people flock to your new
> dialect. You don't need anyone's help.
For the nth time: what I need is to be able to answer the question "who
uses it?" (And I need the answer to be something other than "a handful of
universities.") I can't do that by myself.
> What CL lacks, if anything,
> is finished applications. And what is stopping people from getting there
> is NOT special variables. Except perhaps in the sense that it's too much
> fun for some people to tinker on special variables (or anything else)
> and too little fun to work on finished applications.
No. What CL lacks is users. The lack of applications is a consequence of
the lack of users (which is to say, programmers), not the root problem.
> > Are you OK knowing that there are lots of people out there who
> > would like to use Lisp but can't?
>
> They are not kept from doing so by the semantics of the special variables.
I never said they were.
> > > Both of these can be done without affecting the standard.
> >
> > Right, but I don't see any way to solve *my* problem without affecting the
> > standard. (That effect could be to extend it, not necessarily to change
> > it in non-backwards-compatible ways.)
>
> I don't think your problem would be solved by changing the standard.
Yes, you've convinced me that I was wrong about this.
> Whether you mean to be or not, I think you are just lonely. And I think
> you are trying to rally support by raising the level of discontent with
> CL.
It is rather lonely being a Lisper at JPL. But my intention was not to
raise the level of discontent or to fragment the community. If that was
the effect of what I did, I'm sorry.
> I also think the community is not determined by who shows up and says
> "serve me". I think the community determined by who the language
> designers say they seek to serve.
Franz, Harlequin, Digitool and Hypermeta have all accepted my money at one
time or another. That is IMO enough of a credential for me to consider
myself at least one time to have been part of the community.
> The community has had many fewer users in the past and is presently on
> the upswing.
I see no evidence of this, but if someone could provide me with some data
that would help me out a lot.
> > It is ironic that we are at loggerheads about this because I think
> > we both want the same thing: for CL to be a commercial success so
> > that we can make money using it.
>
> I agree with this remark. I just think the things you are suggesting
> will squeeze the precious lifeblood out of a small but vaiable community.
OK. You have made a convincing argument, I respect your views, and so I
am dropping it.
I would like it understood that my motives were not to cause trouble. My
proposal may have been misguided, but it was not malicious.
> Nevertheless, while I share your goal, we differ in one important respect:
> I do not see the sky as falling. The situation is not NEARLY as dire as it
> was a decade ago.
Once again, some data to support this would be very helpful to me. From
where I sit things appear to be much more dire than they were ten years
ago.
E.
···@jpl.nasa.gov (Erann Gat) writes:
> > I also think the community is not determined by who shows up and
> > says "serve me". I think the community determined by who the
> > language designers say they seek to serve.
> Franz, Harlequin, Digitool and Hypermeta have all accepted my money
> at one time or another.
(Note, though, that the work HyperMeta is doing for you is not
exactly "programming in CL", certainly not 'per se'. Rather, speaking
loosely, we are working with you as you explore non-CL-ish alternatives.
So mention of us is perhaps a bad example.)
Also, and importantly, I'm NOT trying to make you feel like an outcast
personally. I'm making serious suggestions that I think would make
you happier. I'm trying to merely explain why people are not rushing
to cater to you. It's a business decision. Yes, those companies
(including mine) have taken your money, but that doesn't mean those
companies have committed to going your way. It means that every time
they make a decision, they have to decide "is it worth risking losing
you", or is the bulk of money in another direction. And the fact is
that every time I post to this newsgroup a statement in opposition to
what you're saying, I have to risk losing you as a customer, too.
That's not my desire. Just a known risk.
That is, you might read my remarks as hypocritical because I have both
suggested you're not part of the market and I've taken your money.
Another way to read it, though, is that I am doubly serious. Because
I am risking receiving no further money from you in order to make my
point. I consider making my point to be sufficiently important that I
am willing to risk that. And don't think I don't think of this issue
every time I respond. My credibility in this market is about all I
have to my name some days, and I just can't say I agree with you
merely because you are a customer. If you understood how empty my
bank account was right now, you'd understand just how seriously that
means I feel what I am saying.
Look, a lot of friends come to me with personal troubles. I'm not the
sort to tell them (as some people do) what _I_ would do in their
circumstance. I am not them, and most people would not go my way.
What I try to do when they have troubles is listen to what they are
saying to me, and tell them what I hear. Sometimes people are bad at
hearing themselves. So I just repeat back to them what they are
saying in different words, hoping that it will help them do what some
little voice in them is saying. I know you think you like CL, but
there are cues all over everything you write that say you are unhappy
with it. You want it to be what it is not.
If someone came to me and said "I really love Fred (or Sally,
depending on their gender and preference), but I wish he were a
business executive instead of a school teacher." I'm going to say
"Are you sure you love this person? You want to change him to be
something else before you are satisfied. Is that what love is?" If
someone says "I love Fred (or Sally), but I seem to prefer spending
time with Bill (or Jane)." In my experience, usually the primary
assertion is just something one is "used to saying" or a way they are
used to thinking about themselves, and usually the recurring action or
nagging thought is a little voice crying out in them saying "Consider
a change." That doesn't mean the change will be right. But it means
you have a choice to make and it's you, not me, who keeps coming back
to the need for that choice. Loud and clear we hear you say "Do x or
this is no good." If this was no good, you'd be gone. So maybe this
really isn't no good and you're lousy at articulating what you like.
Or maybe this is no good, in which case you do not belong here. This
is not ME making these assertions. I'm telling you what I hear you
telling me.
Something is not intolerable if you merely say it. It's intolerable
if you refuse to tolerate it. Something is not valueless if you find
value in it. It's valueless if you find it devoid of value.
Something is not inferior to something else if you still continue to
use it in preference to the something else. It is inferior if you
stop using it because of the something else.
The reason I sometimes disappear from comp.lang.lisp is to make the
point that some things that happen here are intolerable. It is an
unfortunate truth that I cannot make that point while staying and
tolerating...
> I would like it understood that my motives were not to cause trouble. My
> proposal may have been misguided, but it was not malicious.
I have not suggested that your proposal is malicious.
I do think that with all the energy you spend on the things you do take
up, that you could be doing more good in other ways.
I cited the example of the so-called "Idiot's Guide" as an example.
It takes work to write an intro. But you are both moving things ahead
and setting them back (IMO) by choosing the approach you do, which
reinforces the standard myths by repeating them. At least some of your
reader may never have heard of those myths, and your intro should not be
the first time.
At old-Symbolics, a report was commissioned of how expensive it was to
merely receive a release of new software from Symbolics. Not how much
we charge people, but how much do they pay out of pocket to accept the
release in terms of having to upgrade code.
One of the releases was estimated to cost multiple tens of thousands
of dollars per customer to accept. That is, between ten and a hundred
thousand dollars. Why? That was the release that was going to change
the element-type of strings from integer to character. Just that one
change was to cost, across the community, money on the order of a
million dollars. Maybe half a million. Maybe 5 or ten million. I'm
not sure what the size of the installed base was. But that wasn't
money someone was going to make (except the consultants doing the
changes and/or the employees who were already on staff who would do
the changes rather than something else), it was money that was just
"down the tubes" and did not contribute to any product rolling out.
It was deemed that this was a necessary cost, but we tried to get all
of ANSI CL's incompatible changes in on that release so that we
wouldn't have to do that to customers again. It was eye-opening to me
and others to think in terms of cost to the community of a "helpful
change".
I believe ANY change to the standard will cost "lost millions". After
that, the incremental cost of change will be less.
You have expressed the view that there is a desire not to make change.
That's right. For exactly that reason. CERTAINLY it is the case that
if we make one change, others will be easier. In part because some
can piggy back on the first incompatibility. Someone's already going
to hire a programmer to fix legacy applications that won't recompile,
so they might as well pay that programmer to do a few extra things.
But every time we churn the market, there's a big cost again. And I
don't want to see that happen. Because those are dollars lost to
Lisp. Lost not in the sense that they aren't spent on Lisp
programmers, but lost in the sense that they aren't spent on making
Lisp succeed in the business world so that even larger dollars will
flow our way. If there was a million dollars to be had paying Lisp
programmers for anything, I'd rather see it spent on making something
than maintaining something that used to work but now has been
gratuitously changed.
As such, I think the best thing that can be done is to try to work in
good faith toward using CL compatibly. Stress it. Find out if it
really can't stand up. The reports so far are promising. There are a
few areas that are not as good as they could be, but so far the flaws
have not been shown to be fatal.
> > Nevertheless, while I share your goal, we differ in one important
> > respect: I do not see the sky as falling. The situation is not
> > NEARLY as dire as it was a decade ago.
>
> Once again, some data to support this would be very helpful to me. From
> where I sit things appear to be much more dire than they were ten years
> ago.
During the onset AI Winter, the chief problem was that we had spent so
many years rolling in dough that we had not had to keep track of what
the real world wanted. LispMs were sold by saying "abandon all other
things. come use this. do things on our terms." Customers did and we
lost track of the needs of the heterogeneous environment. When AI
Winter struck, we were diverged a lot and we didn't have the idea that
we neeed to compile "linkable libraries", the common thing that all
other languages yielded. People almost didn't recognize a 'fasl' file
as anything meaningful. Even those who did recognize it couldn't use
it. Also, Lisp was big and at the time needed to be small. Lisp was
expensive and needed to be cheaper. We had lots to do and vendors had
no money to do it with, so it took a long time.
The vendors focused on things that mattered. The need for statically
linkable libraries yielded to a need for DLLs, and several vendors met that
challenge. CORBA came up and was met. COM was met. Vendors added and
tuned multitasking support. Users demanded interfaces that were color.
Vendors added that. Users wanted window toolkits (other than CLIM). CAPI
and Common Windows and the MCL toolkit (not sure its name) all addressed
the need for native application interfaces. We didn't shrink Lisp's size
hugely (a few vendors did some tricks to help a little) but we held constant
on size while most other programs and languages grew big, so we came into
line with the norm and are probably now smaller than normal or at risk of
soon being so.
Users complaining about low cost options were met with free(as in beer)
versions of LispWorks and Allegro, and numerous free(as in gnu) other
whole implementations. Plus Corman appeared and added an extra low-cost
commercial option.
At one time, there was only CL-HTTP but now there are so many web options
that it's hard to say we're not web competitive.
At one time, we couldn't get 50 people to attend a LUV (Lisp Users and Vendors)
meeting. Recently, we had 150 people show up in San Francisco. And users
groups have been having calls for people in all kinds of local places (which
I think will be a really good thing because the lack of budget and will to
travel is more likely the barrier to a single-big-conference than is a
pervasive disinterest in Lisp).
Various people have gotten together libraries and web sites. There are more
online tutorials than there were.
In spite of sometimes dire claims that there was only one remaining Lisp
'vendor', there are lots of sources of Lisp and lots of libraries and
lots of people interested in still talking about things.
Response to my interview on Slashdot was quite positive. Go read the
responses and see what you think. Sure, some number of committed folks
just schmoozing. But quite a number of people saying "hmm, maybe it's
time for another look". Various people have cited that interview as
having raised their awareness that maybe things have changed. I'm not
saying that one interview made some big difference--but I'm saying as a
kind of barometer of public opinion, people out there are not as negative
about Lisp today as I've seen them in the past.
A lot of the change in attitude I'd attribute to Java. Java has made
GC popular again, and actually probably improved people's desire for a
working one. Heh. It has also made people aware of the need for
integers bigger than so-called ints. And it has improved the
understanding of 'message passing' / 'genericity'. It has popularized
some data structures that matter to us. While it's statically typed
in some ways, it's dynamically typed in others, and this is to our
benefit. It has introspection. It even has a primitive condition
system (more powerful than other languages, not as good as ours) Not
to say these things are all done right, but this introduces the
ability for us to merely say "we have a better way" on a topic people
have seen, rather than a missionary project of teaching people they
want the feature in question.
Lisp was ahead of its time and was a bit of a memory glutton. With 80gb
disks around, few begrudge a few megabytes any more. That's a major thing
all in itself.
I don't know why you don't see any of these as positive unless you've just
been in one place for too long.
In article <···············@shell01.TheWorld.com>, Kent M Pitman
<······@world.std.com> wrote:
> ···@jpl.nasa.gov (Erann Gat) writes:
>
> > > I also think the community is not determined by who shows up and
> > > says "serve me". I think the community determined by who the
> > > language designers say they seek to serve.
>
> > Franz, Harlequin, Digitool and Hypermeta have all accepted my money
> > at one time or another.
>
> (Note, though, that the work HyperMeta is doing for you is not
> exactly "programming in CL", certainly not 'per se'. Rather, speaking
> loosely, we are working with you as you explore non-CL-ish alternatives.
> So mention of us is perhaps a bad example.)
I'm just going by your definition. You said that the community is defined
by "who the language designers say they seek to serve." You are one of
the language designers and you have sought to serve me. (Well, actually I
sought you out, but you agreed to serve me.) That makes me a member of
the community on the definition you gave.
In fact, I can only think of two definitions that would exclude me from
the Common Lisp community: a requirement that one be currently programming
in CL, or a requirement that one refrain from advocating changes to the
standard. (And on the latter view, I am no longer advocating changes to
the standard so I hope you'll have me back :-)
> Also, and importantly, I'm NOT trying to make you feel like an outcast
> personally.
That may not be your intent, but you are having that effect. Using
phrases like "the language was designed to protect itself against people
like you" doesn't exactly make me feel welcome. I understand what you
were trying to convey (I think) but you took me to task for the damage
I've done for putting negative spins on things. That train runs both
ways.
> I'm making serious suggestions that I think would make
> you happier. I'm trying to merely explain why people are not rushing
> to cater to you.
Making suggestions and explaining are two very different things. The only
suggestions I remember hearing from you in this discussion is that I go
use Scheme, which again could be interpreted as a thinly veiled, "Get
lost. You are not welcome here."
> It's a business decision. Yes, those companies
> (including mine) have taken your money, but that doesn't mean those
> companies have committed to going your way.
Of course not. All I expected was a respectful hearing.
> That is, you might read my remarks as hypocritical because I have both
> suggested you're not part of the market and I've taken your money.
Indeed.
> Another way to read it, though, is that I am doubly serious. Because
> I am risking receiving no further money from you in order to make my
> point.
FWIW, nothing you have said in this thread has had any negative impact on
my desires to work with you in the future. (In fact I appreciate your
candor.)
> If you understood how empty my
> bank account was right now, you'd understand just how seriously that
> means I feel what I am saying.
Your sincerity was never in doubt.
> Look, a lot of friends come to me with personal troubles.
I don't know what prompted you to say that, but these aren't personal
troubles, they are professional troubles, and I am not your friend (which
is not to say that I wouldn't like to be, but we hardly know each other,
and you haven't been particularly friendly). I am your customer, perhaps
your colleague if I may be so bold. And you don't know me. At best you
know my usenet persona.
> I know you think you like CL, but
> there are cues all over everything you write that say you are unhappy
> with it. You want it to be what it is not.
You are absolutely wrong about this.
> I do think that with all the energy you spend on the things you do take
> up, that you could be doing more good in other ways.
Well, I'm not really spending all that much energy on this. But I am and
always have been open to suggestions. (And please don't suggest that I go
use Scheme. I don't want to use Scheme. T maybe, but not Scheme.)
> I believe ANY change to the standard will cost "lost millions". After
> that, the incremental cost of change will be less.
>
> You have expressed the view that there is a desire not to make change.
> That's right. For exactly that reason.
Your argument applies only to non-backwards-compatible changes.
Backwards-compatible changes do not incur this cost. And a blind
resistance to change irresepective of whether or not they are
backwards-compatible and irresepctive of any potential benefits also has a
cost.
[Snip]
> I don't know why you don't see any of these as positive unless you've just
> been in one place for too long.
All of this sounds very positive, and a lot of it is news to me. From
where I sit the situation seems much bleaker (and has for some years now).
But what you tell me is encouraging. I am reassessing my position in
light of this new information.
E.
···@jpl.nasa.gov (Erann Gat) writes:
> In article <···············@shell01.TheWorld.com>, Kent M Pitman
> <······@world.std.com> wrote:
>
> > I believe ANY change to the standard will cost "lost millions". After
> > that, the incremental cost of change will be less.
> >
> > You have expressed the view that there is a desire not to make change.
> > That's right. For exactly that reason.
>
> Your argument applies only to non-backwards-compatible changes.
> Backwards-compatible changes do not incur this cost.
Backwards-compatible changes do not require change at all.
Extensions can be added as layers. Being monotonic in nature,
they are by definition not changes.
> And a blind resistance to change irresepective of whether or not
> they are backwards-compatible and irresepctive of any potential
> benefits also has a cost.
My resistence is not blind. I at no time have said "the standard must
never be changed". I have said that the cost is very high and that the need
must be equally high in order to justify it.
Btw, there is an additional cost. Opening the standard to change is _not_
a controlled process. It would be a free-for-all. You expect that somehow
if changes were made, they'd all be ok with you. But many things you
_like_ might change, too. Change due to open design is not a
predictable process.
The best advice I ever heard on this came from an attendee of X3J13 from
(then) NBS (now NIST), who said that standards processes are not design
processes and you must not confuse the two. You want come to the table
with something nearly right and propose it for adoption only when you're
pretty sure it's going to be accepted "as is" or close to it. We simply
got lucky in the ANSI CL process that we did not wreck the language.
When I say "go design your own language" I am not trying to be mean
nor tell you to get lost. I am saying "this is the intended way".
Only a completed and tested design should be accepted for moving
forward. Because it can be evaluated in its entirety. If you bring
in a half-done thing and think a committee can fix it, you're deluding
yourself. What is needed is a single-minded vision of where to go.
That's not a guarantee the community will accept it, but it's the minimal
requirement for the community considering it (IMO).
Left to their own devices, everyone will want to dabble. And that's just
dangerous. Everyone wants to leave their mark. Everyone has a hobby horse.
And everyone, because of much deployed code, is now conscious of how any
change will affect them personally.
They say for this same reasons it's a _bad_ idea to have a second
constitutional convention in the US. Not that it's not easy to come up
with a reason why some changes would improve things--but because getting
the good changes that the process might offer is not guaranteed. Simply
opening a democratic process does not guarantee an outcome.
I watched in unsurprised horror a few years back when the Libertarian
party was having a meeting and wanted to break for lunch. Some wanted
a 30 minute lunch and some a 45 minute lunch. Before they knew it,
someone had invoked parliamentary process and it took more than 15
minutes to resolve the matter. (I don't even remember which way it
came out, but you see the problem.) Once the process had begun,
everyone could see that it was doomed to lose, but respect for process
meant they were all obliged to stand there and suffer through it.
Because to admit that process could be avoided by simple application
of fiat was a dangerous precedent. The moral? Keep things informal
as long as you can...
In article <···············@shell01.TheWorld.com>, Kent M Pitman
<······@world.std.com> wrote:
> ···@jpl.nasa.gov (Erann Gat) writes:
>
> > In article <···············@shell01.TheWorld.com>, Kent M Pitman
> > <······@world.std.com> wrote:
> >
> > > I believe ANY change to the standard will cost "lost millions". After
> > > that, the incremental cost of change will be less.
> > >
> > > You have expressed the view that there is a desire not to make change.
> > > That's right. For exactly that reason.
> >
> > Your argument applies only to non-backwards-compatible changes.
> > Backwards-compatible changes do not incur this cost.
>
> Backwards-compatible changes do not require change at all.
> Extensions can be added as layers. Being monotonic in nature,
> they are by definition not changes.
Suppose I want to be able to write:
(defun foo (x (special y)) ...
or
(defun foo (x &special y) ...
or something like that instead of
(defun foo (x y)
(declare (special y))
I can only implement that sort of thing myself with extreme difficulty
(because I have to change *all* of the forms that use lambda lists, not
just defun).
Then there are examples of things that are simply impossible to do by the
user despite CL's extreme flexibility. For example, if I want (setq x 1)
at top level without a defvar to *not* pervasively declare X to be
special. Or if I want real global lexicals (or guaranteed local lexicals
for that matter). Or undefvar, or undefine-symbol-macro.
All of these would be backwards-compatible modifications, but they can
only be implented with extreme difficulty (if at all) without vendor
support. So to be able to write portable code that relies on these
behaviors the standard would need to be augmented.
I would consider the examples above to be "changes", and I think most
other people would too. But if calling them extensions would make them
more pallatable then that's fine with me. The point is, these are things
that I want that I can't implement myself. (BTW, the reason I want these
two things is not because I desperately need them, but because I think it
would make CL easier to learn and thus more accessible to newcomers and
thus more viable in the long term.)
E.
···@jpl.nasa.gov (Erann Gat) writes:
> Suppose I want to be able to write:
>
> (defun foo (x (special y)) ...) or (defun foo (x &special y) ...)
>
> or something like that instead of [...]
>
> I can only implement that sort of thing myself with extreme difficulty
> (because I have to change *all* of the forms that use lambda lists, not
> just defun).
<···························@TheWorld.com>This is just not so.
(defpackage "GOV.NASA.JPL.GAT.DEFINERS"
(:use "CL")
(:shadow "DEFUN")
(:export "DEFUN"))
(in-package "GAT-TOOLS")
(defmacro defun (name lambda-list &body decls-doc-forms)
`(defun ,name ...etc.))
The reason you are asked to do this is that someone else may want to extend
DEFUN differently and someone else may not want to at all. There has to be
a way to allow all of that to co-reside, and the only rational way of doing
it is to say each user gets his own sandbox.
The theory of the language is that you should not be able to foist your
design on me, nor I mine on you, exactly in order to allow distributed
development of modules without having to coordinate among all those people.
It may be the case that you did not _know_ you could do this. (I doubt
that, but it's possible.) It may be the case that you don't _like_ doing
it this way. But it is, in point of fact, not true that you are unable to
do what you want.
If what you are saying is that you want to have the change made uniformly,
then indeed you have to shadow a bunch of things. But the fact is that if
the language itself changed, the amount of work would be _more_ than you
doing it privately, it's just that you personally would not bear that cost
so you would maybe be happier. On the other hand, if everyone else in the
universe were allowed to make their favorite private change and foist it
on you, then they would be happy not to bear that cost that you would bear,
and you might become less happy.
I myself in my libraries redefine several system functions. I do this by,
effectively, making a "COM.HYPERMETA.LISP" package that is my own sandbox
and in which no one can tell me what to do. That means no one is relying on
my code except if they have volunteered to. That means I can do as I like.
And I do.
> THEN there are examples of things that are simply impossible to do by the
> user despite CL's extreme flexibility. For example, if I want (setq x 1)
> at top level without a defvar to *not* pervasively declare X to be
> special. Or if I want real global lexicals (or guaranteed local lexicals
> for that matter). Or undefvar, or undefine-symbol-macro.
There is only one implementation that does this and I believe it's on a
switch. I _thought_ someone had finally changed it to not do that.
I think simple market pressure works fine here. And anyway, it's free
software--I thought that meant you were free to fix it?
I implement real global lexicals for HyperMeta.
UNDEFVAR is an issue of 'environment'. But I think you _could_ shadow an
appropriate set of operators to make DEFVAR do what you want. It doesn't
look to me to be an impossible task. Is it hard? Perhaps. But it's doable.
And however hard it is, it's more easily doable than in most other languages.
> All of these would be backwards-compatible modifications, but they can
> only be implented with extreme difficulty (if at all) without vendor
> support.
You're welcome to contact me offline if you want me to hire me to
write you the code and I'll make you an estimate.
> So to be able to write portable code that relies on these
> behaviors the standard would need to be augmented.
If your premise were true, it might.
> I would consider the examples above to be "changes", and I think most
> other people would too. But if calling them extensions would make them
> more pallatable then that's fine with me.
Calling them extensions reminds me that there are ways to do it within
the given set of operators.
> The point is, these are things
> that I want that I can't implement myself.
This is why there are consultants.
> (BTW, the reason I want these
> two things is not because I desperately need them, but because I think it
> would make CL easier to learn and thus more accessible to newcomers and
> thus more viable in the long term.)
I am not sure I agree. If you have someone learning something else than
what's in the standard, I'm not sure you're on the road to learn CL.
But even so, I also think that teaching usually dictates what environment
to use. I don't think portable teaching tools are necessary. I think it's
fine for a teaching tool to run in only one environment that happens to offer
what the teacher needs. Even just teaching people the IDE and/or typical
mode of interaction for each implementation would be a whole course in itself.
In article <···············@shell01.TheWorld.com>, Kent M Pitman
<······@world.std.com> wrote:
> ···@jpl.nasa.gov (Erann Gat) writes:
>
> > Suppose I want to be able to write:
> >
> > (defun foo (x (special y)) ...) or (defun foo (x &special y) ...)
> >
> > or something like that instead of [...]
> >
> > I can only implement that sort of thing myself with extreme difficulty
> > (because I have to change *all* of the forms that use lambda lists, not
> > just defun).
>
> This is just not so.
It is so, and the fact that you think it is not so indicates that you have
missed the point.
First, I never said that it was impossible, only that it was hard. I know
how to shadow symbols and make my own private defun in my own private
package. (We would make more progress here if you would stop trying to
interpret everything I say on the assumption that I am an idiot.) The
problem is that it's not just DEFUN that has to change, it's FLET and
LABELS and MULTIPLE-VALUE-BIND etc. etc. Yes, I could do all that. In
fact, I do have my own private macro package. Actually I have several of
them. One lets me write T code. Another makes CL look like Oaklisp.
Still another is a sandbox I use to play around with design ideas for
Ciel.
But a private package does not serve my purpose because:
The reason I want these things is not because I desperately need
them, but because I think it would make CL easier to learn and
thus more accessible to newcomers and thus more viable in the
long term.
Now, I could be wrong about that. Perhaps these changes would not make CL
easier to learn. Maybe there are no real difficulties for newcomers
learning CL, or maybe whatever difficulties there might be do not really
have any significant effect on CL's popularity (or lack thereof). But we
don't have any real data on this (except for the continual rehashing of
these issues in c.l.l.)
Absent any real data, it is not reasonable to rule out a priori the
possibility that there might be some aspects of CL that are unnecessary
barriers to entry for newcomers, that this has a material impact on the
viability of the language, and there ought to be a process to propose,
discuss, and adopt changes that address these issues. This has to be done
as a community because:
> If you have someone learning something else than
> what's in the standard, I'm not sure you're on the road to learn CL.
I agree. That is why I want these changes (not necessarily my changes,
but any changes designed to streamline the language to make it more
accessible to beginners) to have some official standing.
E.
···@jpl.nasa.gov (Erann Gat) writes:
> The reason I want these things is not because I desperately need
> them, but because I think it would make CL easier to learn and
> thus more accessible to newcomers and thus more viable in the
> long term.
>
> Now, I could be wrong about that. Perhaps these changes would not make CL
> easier to learn.
Not that these things are decisions cast in stone forever, but we in X3J13
took up the issue of teachabilty and decided it was not a goal of the
standard to handle this. That is, we felt the right way for teaching to
go was for each teacher to offer their own subset and teaching order.
We did not want an institutionalized teaching strategy because (a) it would
be hard to change if it were wrong and (b) we were reasonably sure there
were multiple conflicting strategies for teaching and that we could neither
converge on a good one nor should we single out one over another.
> Absent any real data, it is not reasonable to rule out a priori the
> possibility that there might be some aspects of CL that are unnecessary
> barriers to entry for newcomers, that this has a material impact on the
> viability of the language, and there ought to be a process to propose,
> discuss, and adopt changes that address these issues.
Such processes, if they are fair, cannot be defined to converge. They are
not even guaranteed to take you in the direction of somethin useful.
I said many times in the X3J13 process that any one of us could have designed
a better language than the committee did. The more people got involved, the
more weird things became.
> This has to be done as a community because:
>
> > If you have someone learning something else than
> > what's in the standard, I'm not sure you're on the road to learn CL.
This isn't the only way to learn things. Subsetting does not involve this.
> I agree. That is why I want these changes (not necessarily my changes,
> but any changes designed to streamline the language to make it more
> accessible to beginners) to have some official standing.
This is ultimately what you want. The dignity of "official standing".
And this is where I politically disagree with you and will for as long
as we have this discussion. I personally believe the day is past
where we should foist official standing on people. The good thing
about layered standards is that people can elect them or not. The
whole community does not have to agree. Agreement is a
synchronization problem (int he sense of the world-multiprocessor
scenario); you want to do one giant "without interrupts" and cons a
new standard, and that is just not proper. It is too hard to do in
modern fast-changing society, and is wholly unncessary other than to
satisfy personal egos. It improper to force people to agree. It is
better to have multiple, incompatible ways of doing things than to
force a single community to do things one way. I know we did this for
the core language, and we got some value from it, but I insist that
this is a bad paradigm for moving forward. You don't have to agree
with me. But if you don't and you keep pushing against me on this,
you'll just go round and round with me on this point. We used to do
things differently because (a) we had to bootstrap a community at all
and (b) we needed things to fit in small address spaces where having
multiple solutions was an unfair use of space. In the modern world,
linking in several libraries to do the same thing is just not as big a
deal. The value of personal freedom greatly outweighs the value of
community conformity.
So, if anything, I will retract my remark quoted by you in the last
post where I said that it mattered if something was not CL-ish. Things
will be inherently drifting from the core. That's part of what happens
in free markets. Trying to impose global control of how evolution
occurs is not reasonable.
In article <···············@shell01.TheWorld.com>, Kent M Pitman
<······@world.std.com> wrote:
> This is ultimately what you want. The dignity of "official standing".
I suppose, though that puts a more authoritarian spin on it than I would
like. I would rather say that I want a mechanism for the community to be
able to speak with a unified voice. like I said to the other poster who
said that people should bring finished proposals to the table: I want to
know where the table is.
> And this is where I politically disagree with you and will for as long
> as we have this discussion.
Yes, I get that. Time will tell if you are right. I hope you are.
E.
···@jpl.nasa.gov (Erann Gat) writes:
> In article <···············@shell01.TheWorld.com>, Kent M Pitman
> <······@world.std.com> wrote:
>
> > This is ultimately what you want. The dignity of "official standing".
>
> I suppose, though that puts a more authoritarian spin on it than I would
> like. I would rather say that I want a mechanism for the community to be
> able to speak with a unified voice. like I said to the other poster who
> said that people should bring finished proposals to the table: I want to
> know where the table is.
The community is not of one mind. To make it speak with unified voice
is to make some people get outvoted and tell them they cannot do what they
want to do.
Democracy = Tyranny of the Majority
The only difference between my position and this is to say that the people
who are in the minority, rather than us pretending that they have to knuckle
under (when they also have the right to just slink away angry, after all)
can also have what they want. That the world is big enough to accomodate
us both, by making us focus on community consensus ONLY when a tool is
missing that would enable the creation of private tools.
> > And this is where I politically disagree with you and will for as long
> > as we have this discussion.
>
> Yes, I get that. Time will tell if you are right. I hope you are.
Me too. ;)
···@jpl.nasa.gov (Erann Gat) writes:
> I agree. That is why I want these changes (not necessarily my changes,
> but any changes designed to streamline the language to make it more
> accessible to beginners) to have some official standing.
This might be your plan, or if it's not, I'm sure someone's told you
this before, but I'll add my two cent here: if you have a cohesive
vision of where you think Lisp should go, probably the most effective
way to promote it is to write a demonstration implementation. If you
have a dialect that's backwards-compatible, runs well on at least one
major CL implementation, and is portable (or at least relatively easy
to port); then you can try to get existing Lispers to try it. Once
you have a significant user base, *then* I'd worry about trying to
make your changes official -- until then, as you said in another
thread, I'm not sure there's a table to bring your changes to. If you
can convince other Lispers, the group can make a table.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
In article <···············@apocalypse.OCF.Berkeley.EDU>,
···@apocalypse.OCF.Berkeley.EDU (Thomas F. Burdick) wrote:
> if you have a cohesive
> vision of where you think Lisp should go, probably the most effective
> way to promote it is to write a demonstration implementation.
and Kent Pitman writes:
> That the world is big enough to accomodate
> us both, by making us focus on community consensus ONLY when a tool is
> missing that would enable the creation of private tools.
You are both still missing the point. This is not about capabilities.
Here's what this is about:
From Coby Beck (in another thread):
> The following are examples of reasonable and compliant behaviour:
>
> 1 > (setq foo 4)
> 4
> 2 > foo
> Error: The variable FOO is unbound.
>
> 1 > (setq bar 4)
> Error: Attempt to bind undeclared variable BAR
>
> The following are still examples of compliant behaviour, though more
> inconvenient:
>
> 1 > (setq foo 4)
> Error: Segmentation fault
> (lisp freezes and you must reboot)
>
> 1 > (setq foo 4)
> 4
> 2 > (+ 5 foo)
> 37
> 3 >
Coby is correct that all of these are compliant. Whether or not they are
reasonable is a matter of opinion.
BTW,
> write a demonstration implementation
I am working on one, but that's beside the point.
E.
···@jpl.nasa.gov (Erann Gat) writes:
> In article <···············@apocalypse.OCF.Berkeley.EDU>,
> ···@apocalypse.OCF.Berkeley.EDU (Thomas F. Burdick) wrote:
>
> > if you have a cohesive
> > vision of where you think Lisp should go, probably the most effective
> > way to promote it is to write a demonstration implementation.
>
> and Kent Pitman writes:
>
> > That the world is big enough to accomodate
> > us both, by making us focus on community consensus ONLY when a tool is
> > missing that would enable the creation of private tools.
>
> You are both still missing the point. This is not about capabilities.
> Here's what this is about:
I don't think I'm missing the point. You're not proposing just a CL
implementation, you're proposing a new Lisp dialect. If you pitch it
as such, I think educated Lispers will view it differently than if you
said, "here's a CL implementation where such-and-such undefided things
having such-and-such results". I think Coby Beck brought up the
example he did exactly because he's sphisticated enough in this realm
to discriminate between "conforming implementation" and "dialect".
> > write a demonstration implementation
>
> I am working on one, but that's beside the point.
I don't think it is. After all, where did Common Lisp come from?
Zeta Lisp, SPICE Lisp, and Scheme were all vitally important to its
creation. Outside of the Lisp world, look at FORTRAN 77. I know that
both divergent FORTRAN IV implementations, and experimental
proto-FORTRAN 77 dialects were important to its eventual
standardization. I'd think of your effoerts (and Paul Graham's) as
being potential contributors to an eventual CL-2020 standard, the
result of the fairly well-defined, triumphant CL-2010 dialect.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
In article <···············@conquest.OCF.Berkeley.EDU>,
···@conquest.OCF.Berkeley.EDU (Thomas F. Burdick) wrote:
> ···@jpl.nasa.gov (Erann Gat) writes:
>
> > In article <···············@apocalypse.OCF.Berkeley.EDU>,
> > ···@apocalypse.OCF.Berkeley.EDU (Thomas F. Burdick) wrote:
> >
> > > if you have a cohesive
> > > vision of where you think Lisp should go, probably the most effective
> > > way to promote it is to write a demonstration implementation.
> >
> > and Kent Pitman writes:
> >
> > > That the world is big enough to accomodate
> > > us both, by making us focus on community consensus ONLY when a tool is
> > > missing that would enable the creation of private tools.
> >
> > You are both still missing the point. This is not about capabilities.
> > Here's what this is about:
>
> I don't think I'm missing the point. You're not proposing just a CL
> implementation, you're proposing a new Lisp dialect.
There are degrees of newness. If I take CL and write a macro, have I
created a new Lisp dialect? How about if I write a macro that shadows a
symbol in the commono-lisp package? Two symbols? Half of them? All of
them? What if I hack the reader so that what used to be symbols now read
as instances of a mydialect::symbol class? All of these things can be
done entirely within Common Lisp. At what point do I transition from
simply taking advantage of Lisp's ability to be customized to having a
"new dialect"?
> If you pitch it
> as such, I think educated Lispers will view it differently than if you
> said, "here's a CL implementation where such-and-such undefided things
> having such-and-such results". I think Coby Beck brought up the
> example he did exactly because he's sphisticated enough in this realm
> to discriminate between "conforming implementation" and "dialect".
No. It's much simpler than that. All I am trying to accomplish is to
convince people that in the eyes of most non-lispers (and at least one
Lisper), trying to defend the result of:
(setq x 1)
x
being anything other than 1 makes us look like fools.
Here's an analogy. The very first C program I ever wrote (this was around
1980 or so, pre-ANSI C, pre-Common-Lisp) was something like:
main () {
char *s = "Hello world\n";
printf(s);
}
It worked fine. The second C program I write was:
main () {
char *s;
gets(s);
printf(s);
}
I ran the program, typed "Hello" and the program wrote back "Hello".
I typed "Goodbye" and the program dumped core.
I went back to Lisp and didn't write another C program for ten years.
It is not much of a stretch to imagine an analogous story: A newcomer
tries Lisp for the first time, types (setq x 1), and watches the program
dump core (or generate an error, or whatever). (Then when he asks about
this on c.l.l. the answer he gets is that 1) this is correct behavior and
2) if he doesn't acknowledge this he's an idiot and a troll.)
The point I am trying to make is that (speaking as a customer now) the
Lisp community would do itself a favor by dispensing with some of these
bizzare initation rituals.
> > > write a demonstration implementation
> >
> > I am working on one, but that's beside the point.
>
> I don't think it is.
Yes, it is, and if you think it isn't then you haven't understood the
point. (And I'm the authority on this because I'm the last word on what
my point is.)
I don't want to change CL to make it more functional. CL has all the
functionality I need (and then some). I want to change CL because I want
to make it more accessible, and I want to do that because I want more
people to use it, and I want to do that so that I can use it.
There are things I want to be different for my own personal use, but those
things I just change. I don't need to bother anybody else about those.
But changes for the purpose of improving accessibility must be done
collectively.
> After all, where did Common Lisp come from?
> Zeta Lisp, SPICE Lisp, and Scheme were all vitally important to its
> creation. Outside of the Lisp world, look at FORTRAN 77. I know that
> both divergent FORTRAN IV implementations, and experimental
> proto-FORTRAN 77 dialects were important to its eventual
> standardization. I'd think of your effoerts (and Paul Graham's) as
> being potential contributors to an eventual CL-2020 standard, the
> result of the fairly well-defined, triumphant CL-2010 dialect.
Do you understand now why this is a completely separate issue?
E.
Erann Gat <···@jpl.nasa.gov> wrote:
> done entirely within Common Lisp. At what point do I transition from
> simply taking advantage of Lisp's ability to be customized to having a
> "new dialect"?
Just thinking out loud:
* When you start calling it something else then Common Lisp.
* When it diverges enough that it makes sense to hack the
underlying implementation to support the new stuff.
* When it "seems" different.
> (setq x 1)
> x
> being anything other than 1 makes us look like fools.
I don't think Mr. C is a characteristic example. The concept is simple The
rules are simple. It may have far-ranging-subtler-than-you-think implications,
but what doesn't.
And the "same thing" applies to C, Java, SmallTalk, Pascal -- to name a few.
The "same thing" is that variables/bindings arent't created implicitly. You
have to say declare them in one way or another.
> tries Lisp for the first time, types (setq x 1), and watches the program
> dump core (or generate an error, or whatever). (Then when he asks about
> this on c.l.l. the answer he gets is that 1) this is correct behavior and
> 2) if he doesn't acknowledge this he's an idiot and a troll.)
From what I've seen they get told "Don't do that. You need to DEFVAR it
first...".
It is only much later when they have established themselves as trolls or idiots
do people start suspecting the truth. What have I missed?
> Lisp community would do itself a favor by dispensing with some of these
> bizzare initation rituals.
I'm not sure what you mean -- I mean I know what you *mean*, but I don't know
what you refer to. From my point of view the Lisp community should stop kicking
itself.
'rm -rf' is a bizarre initiation, being told things at face value is
called honest. Granted, it gets a bit hot in here every once in a while, but
this is usenet. It's been hot in here since the golden age.
Cheers,
-- Nikodemus
In article <··············@midnight.cs.hut.fi>, Nikodemus Siivola
<········@kekkonen.cs.hut.fi> wrote:
> > (setq x 1)
> > x
> > being anything other than 1 makes us look like fools.
>
> I don't think Mr. C is a characteristic example. The concept is simple The
> rules are simple. It may have far-ranging-subtler-than-you-think implications,
> but what doesn't.
>
> And the "same thing" applies to C, Java, SmallTalk, Pascal -- to name a few.
>
> The "same thing" is that variables/bindings arent't created implicitly. You
> have to say declare them in one way or another.
But the fact of the matter is that you don't have to declare them. Every
CL implementation I know of allows you to do top level setq's.
You're right, the issues are subtle. But I believe we would attract more
newcomers by hiding those subtleties from them as long as possible rather
than thrusting them in their face as part of their first experience with
the language. Memory allocation issues are subtle too, and one of Lisp's
strengths is that it hides all those subtleties very effectively.
E.
···@jpl.nasa.gov (Erann Gat) writes:
> But the fact of the matter is that you don't have to declare them. Every
> CL implementation I know of allows you to do top level setq's.
Right. And it's very useful interactively. But I'm _very_ glad not to
see this in code.
In article <···············@shell01.TheWorld.com>, Kent M Pitman
<······@world.std.com> wrote:
> ···@jpl.nasa.gov (Erann Gat) writes:
>
> > But the fact of the matter is that you don't have to declare them. Every
> > CL implementation I know of allows you to do top level setq's.
>
> Right. And it's very useful interactively. But I'm _very_ glad not to
> see this in code.
Excuse me? What exactly am I writing when I use Lisp interactively? It
looks an awful lot like code to me.
BTW, if you haven't already noticed, take a look at all the trouble Mark
Conrad is having over this very issue over in the recreational common lisp
thread.
E.
···@jpl.nasa.gov (Erann Gat) writes:
> In article <··············@midnight.cs.hut.fi>, Nikodemus Siivola
> <········@kekkonen.cs.hut.fi> wrote:
>
> > > (setq x 1)
> > > x
> > > being anything other than 1 makes us look like fools.
What sort of cr4zy lisp are you using?
/usr/local/cmucl/lib/cmucl/lib
; Loading #p"/home/mommer/.cmucl-init".
CMU Common Lisp 18e, running on f0r4st3r0
With core: /usr/local/cmucl/lib/cmucl/lib/lisp.core
Dumped on: Thu, 2003-04-03 15:47:12+02:00 on orion
See <http://www.cons.org/cmucl/> for support information.
Loaded subsystems:
Python 1.1, target Intel x86
CLOS 18e (based on PCL September 16 92 PCL (f))
* (setq x 1)
;
; Warning: This variable is undefined:
; X
;
1
* x
1
*
While we are at it:
Why is it that this is undefined behaviour? Would it not be totally
logical and unproblematic to say, (setq x 1) sets simbol-value of x to
1 without declaring it special??
It works, it does what you expect ... why is it "undefined"?
And while we are at it: I've never made any sense of cmucls default
behaviour of declaring special any var you setq-ed on the
toplevel. Why is that supposed to be a feature?
Regards,
Mario
Helu
* Mario S. Mommer <··············@cupid.igpm.rwth-aachen.de>:
| /usr/local/cmucl/lib/cmucl/lib
| ; Loading #p"/home/mommer/.cmucl-init".
Presumably youre setting EXT:*TOP-LEVEL-AUTO-DECLARE* to NIL here.
| * (setq x 1)
| ; Warning: This variable is undefined:
| Why is it that this is undefined behaviour? Would it not be totally
| logical and unproblematic to say, (setq x 1) sets simbol-value of x to
| 1 without declaring it special??
No. Saying that would make no sense (to me, at least). According to
the hyperspec: symbol-value cannot access the value of a lexical
variable. If X is not lexical, it has to be a dynamic variable or a
constant variable. X is in the top level. It is not lexical as youre
referring to the symbol value. It has to be dynamic.
| It works, it does what you expect ... why is it "undefined"?
Because you did not declare it to be a toplevel dynamic variable
(using defvar or somesuch) like the spec wanted you to.
| And while we are at it: I've never made any sense of cmucls default
| behaviour of declaring special any var you setq-ed on the
| toplevel.
Heh. I cant make sense of any _other_ behaviour, because I dont know
WTF a top level lexical variable means. Especially at a REPL. I think
confusion is best avoided by having a null lexical environment at the
top level.
| Why is that supposed to be a feature?
It makes the best of what the spec requires and what people like me
do at the REPL: I type setq instead of defvar - small convenience I
guess.
Just another data point: When I was a newbie learning lisp, I found
CL's dynamic variables to be a most natural, intuitive, logical
concept, contrary to the experience of some folk seem to be voicing
this time.
Regards
Madhu
--
Open system or closed system, enlightenment or ideology, those are the
vquestions. "John C. Mallery" <····@ai.mit>
Madhu <·······@meer.net> writes:
> Helu
>
> * Mario S. Mommer <··············@cupid.igpm.rwth-aachen.de>:
> | /usr/local/cmucl/lib/cmucl/lib
> | ; Loading #p"/home/mommer/.cmucl-init".
>
> Presumably youre setting EXT:*TOP-LEVEL-AUTO-DECLARE* to NIL here.
Yes. I don't want to declare something special by accident.
> | Why is it that this is undefined behaviour? Would it not be totally
> | logical and unproblematic to say, (setq x 1) sets simbol-value of x to
> | 1 without declaring it special??
>
> No. Saying that would make no sense (to me, at least). According to
> the hyperspec: symbol-value cannot access the value of a lexical
> variable. If X is not lexical, it has to be a dynamic variable or a
> constant variable. X is in the top level. It is not lexical as youre
> referring to the symbol value. It has to be dynamic.
X is just a symbol, independently of wheter it denotes a lexical or a
special variable. It has a symbol value, and a p-list, among other
things.
> | It works, it does what you expect ... why is it "undefined"?
>
> Because you did not declare it to be a toplevel dynamic variable
> (using defvar or somesuch) like the spec wanted you to.
What I was wondering about is why such an obvious use was left
"undefined". I am aware of what the hyperspec says.
> | And while we are at it: I've never made any sense of cmucls default
> | behaviour of declaring special any var you setq-ed on the
> | toplevel.
>
> Heh. I cant make sense of any _other_ behaviour, because I dont know
> WTF a top level lexical variable means. Especially at a REPL. I think
> confusion is best avoided by having a null lexical environment at the
> top level.
It has nothing to do with toplevel lexicals. It is accessing the
symbol value of a symbol which hasn't been declared as the name of a
special.
(setq x 1) =(why not, whenever x is not defined,
default to)=> (set 'x 1) ==> (setf (symbol-value x) 1)
My answer to why not (after having slept twice over it) would be:
because it opens the door to nasty errors. But then the question
arises again: why did the standarizers leave it undefined?
> Open system or closed system, enlightenment or ideology, those are the
> vquestions. "John C. Mallery" <····@ai.mit>
^ li'll typo spotted :-)
Helu
* Mario S. Mommer <··············@cupid.igpm.rwth-aachen.de> :
| X is just a symbol, independently of wheter it denotes a lexical or a
| special variable. It has a symbol value, and a p-list, among other
| things.
...
| It has nothing to do with toplevel lexicals. It is accessing the
| symbol value of a symbol which hasn't been declared as the name of a
| special.
...
| (setq x 1) =(why not, whenever x is not defined,
| default to)=> (set 'x 1) ==> (setf (symbol-value x) 1)
Here's what I think:
SETQ (like DEFVAR etc) deals conceptually with `variables' not
just symbols. You use SET, SYMBOL-VALUE etc for `symbols'
vs. SETQ etc. for `variables' -- I think this distinction may
help simplify learning and remembering CL's rules --
regardless of the fact that variables are `implemented' by
symbols, (although you CANNOT explicitly access the SYMBOL-VALUE
of a lexical variable <:)
| My answer to why not (after having slept twice over it) would be:
| because it opens the door to nasty errors. But then the question
| arises again: why did the standarizers leave it undefined?
Personally I dont find this a problem at all, and think things
are good enough as they are. However, last week KMP posted an
article on another thread:
`Re: Recreational Common Lisp :)'
<···············@shell01.TheWorld.com>
that includes 2 references and gives some reasons.
Regards
Madhu
--
| > Open system or closed system, enlightenment or ideology, those are
| > the questions. "John C. Mallery" <····@ai.mit>
| ^ li'll typo spotted :-)
(ah yes. had to rebind the worn out M- key)
In article <··············@cupid.igpm.rwth-aachen.de>,
Mario S. Mommer <········@yahoo.com> wrote:
> Why is it that this is undefined behaviour? Would it not be totally
> logical and unproblematic to say, (setq x 1) sets simbol-value of x to
> 1 without declaring it special??
>
> It works, it does what you expect ... why is it "undefined"?
Because of the important difference between declaring a variable with an
initial value and setting a variable. Examples with very short names are
not good illustrations in the respect. Here is another example.
(let ((current-base-value 0))
...
(setf curent-base-value 1)
...)
You want this to signal at least a warning, right?
Pascal
Pascal Costanza <········@web.de> writes:
> Because of the important difference between declaring a variable with an
> initial value and setting a variable. Examples with very short names are
> not good illustrations in the respect. Here is another example.
>
> (let ((current-base-value 0))
> ...
> (setf curent-base-value 1)
> ...)
>
> You want this to signal at least a warning, right?
Strange. It looks perfectly legitimate (and clhs-legal, too) to me.
Mario
From: Tim Bradshaw
Subject: Re: MAKUNBOUND and nested bindings?
Date:
Message-ID: <ey3fznk5zpe.fsf@cley.com>
* Mario S Mommer wrote:
> Strange. It looks perfectly legitimate (and clhs-legal, too) to me.
Precisely, it does look OK, but it isn't. These problems are hard to
spot, and that's why you *really want* the system to complain
vigorously!
--tim
Mario S. Mommer wrote:
> Pascal Costanza <········@web.de> writes:
>>(let ((current-base-value 0))
>> ...
>> (setf curent-base-value 1)
>> ...)
>>
>>You want this to signal at least a warning, right?
>
>
> Strange. It looks perfectly legitimate (and clhs-legal, too) to me.
...but it has a typo! (Intentionally so - this is the point of my
example. ;)
Pascal
--
Pascal Costanza University of Bonn
···············@web.de Institute of Computer Science III
http://www.pascalcostanza.de R�merstr. 164, D-53117 Bonn (Germany)
Pascal Costanza <········@web.de> writes:
> Mario S. Mommer wrote:
> > Pascal Costanza <········@web.de> writes:
>
> >>(let ((current-base-value 0))
> >> ...
> >> (setf curent-base-value 1)
> >> ...)
> >>
> >>You want this to signal at least a warning, right?
> > Strange. It looks perfectly legitimate (and clhs-legal, too) to me.
>
> ...but it has a typo! (Intentionally so - this is the point of my
> example. ;)
I have to say: you got me. Point taken! :-)
Mario.
Mario S. Mommer <········@yahoo.com> writes:
> Pascal Costanza <········@web.de> writes:
> > Because of the important difference between declaring a variable
> > with an initial value and setting a variable. Examples with very
> > short names are not good illustrations in the respect. Here is
> > another example.
> >
> > (let ((current-base-value 0))
> > ...
> > (setf curent-base-value 1)
> > ...)
> >
> > You want this to signal at least a warning, right?
>
> Strange. It looks perfectly legitimate (and clhs-legal, too) to me.
You'll want to look at the example more closely. (Hint: If there's a
typo it might be intentional.)
Edi.
From: Tim Bradshaw
Subject: Re: MAKUNBOUND and nested bindings?
Date:
Message-ID: <ey3fznn0yr4.fsf@cley.com>
* Mario S Mommer wrote:
> Why is it that this is undefined behaviour? Would it not be totally
> logical and unproblematic to say, (setq x 1) sets simbol-value of x to
> 1 without declaring it special??
No. Because, like most things that seem to be `useful' without much
thought, it actually makes writing large programs much harder.
Imagine this in a 20,000 line program:
in file A:
(defvar ask-user-before-deleting-files nil)
in file B:
(defun setup-safe-behaviour ()
...
(setf ask-user-before-deleting-giles t)
...)
And now where are your files?
--tim
In article <····················@k-137-79-50-101.jpl.nasa.gov>, Erann Gat wrote:
>
> But the fact of the matter is that you don't have to declare them. Every
> CL implementation I know of allows you to do top level setq's.
>
> You're right, the issues are subtle. But I believe we would attract more
> newcomers by hiding those subtleties from them as long as possible rather
> than thrusting them in their face as part of their first experience with
> the language. Memory allocation issues are subtle too, and one of Lisp's
> strengths is that it hides all those subtleties very effectively.
>
Allow me to give you the perspecive of another relative Lisp newbie. I
never ran into problems with toplevel setq's, defvar, etc. This is
probably because I seldom use global variables in the first place. Also
from skimming CL books and FAQs I gathered the general impression that
there was a catch somewhere, but as I said it didn't bother me.
Then I happened upon your "idiot's guide to special variables" post, and
all the bits of information floating around in my brain neatly fell into
place. It does a nice job of explaining the relevant concepts and pointing
out where the potential problems are.
Updating your guide and making it available on the Common Lisp Cookbook
page is a worthwhile effort, and will be generally helpful. It might help
to write a shorter version to include in the comp.lang.lisp FAQ (hmm, the
FAQ doesn't seem to be maintained...), even if it only says "don't use
setq at the top level, even if it seems to work. Don't worry about why
yet, just trust us. Play with lisp some more, then when you want to learn
more go read the idiot's guide." But do change the part about defvar being
evil, this makes very bad PR :-) Imagine whet the reader will think: wow,
this Lisp guru just said Lisp is evil! Run away!
It may be that Lisp needs to evolve. I suspect that effecting this won't
be easy. In the meantime your goal (and mine -- I am tired of hearing the
sneers of my coworkers when I mention Lisp :-) of making it more popular
will certainly be furthered by making helpful tutorials available to
newbies.
--
Eric Daniel
-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----== Over 80,000 Newsgroups - 16 Different Servers! =-----
In article <············@corp.newsgroups.com>, Eric Daniel
<···········@barberic.vancouver.wa.us> wrote:
> Then I happened upon your "idiot's guide to special variables" post, and
> all the bits of information floating around in my brain neatly fell into
> place. It does a nice job of explaining the relevant concepts and pointing
> out where the potential problems are.
Thanks!
> But do change the part about defvar being evil, this makes very bad PR :-)
There's a second draft of the Guide without this diatribe:
http://groups.google.com/groups?selm=gat-0911021704350001%40192.168.1.51
> Imagine whet the reader will think: wow,
> this Lisp guru just said Lisp is evil! Run away!
Well, 1) I'm not a Lisp guru and 2) I only said a tiny part of it was evil
and 3) there's a rich tradition of hyperbole in computer science.
But your point is well taken.
E.
"Eric Daniel" <···········@barberic.vancouver.wa.us> wrote in message
·················@corp.newsgroups.com...
> It may be that Lisp needs to evolve. I suspect that effecting this won't
> be easy. In the meantime your goal (and mine -- I am tired of hearing the
> sneers of my coworkers when I mention Lisp :-) of making it more popular
> will certainly be furthered by making helpful tutorials available to
> newbies.
There is nothing standing in _your_ way to evolving "Lisp". Lisp
evolves everytime someone writes code that is useful and functional.
New ways and functionality are added. But do not expect that you
need to influence and convince others to do the changing for you.
It has evolved to the point it has, by being _extensively_
used, tested, re-written and re-written. So the only way for it to evolve
is to undergo evolutionary pressures, and that means writing real
world programs in real world uses.
As for your insecurity of hearing the sneers from others, you
do not need to take on their problems. Just step away and
shake off their irrational attitudes. I know its hard not being
part of the herd, but when will you step away? Are you just
waiting for the herd to say its OK to use Lisp? I certainly
hope not. If you need a new Lisp herd, I am sure co-operative
internet Lisp groups can be gelled to pressure Lisp
in (perhaps new) evolutionary directions.
Wade
In article <····················@news1.telusplanet.net>, Wade Humeniuk wrote:
> As for your insecurity of hearing the sneers from others, you
> do not need to take on their problems. Just step away and
> shake off their irrational attitudes. I know its hard not being
> part of the herd, but when will you step away? Are you just
> waiting for the herd to say its OK to use Lisp? I certainly
> hope not. If you need a new Lisp herd, I am sure co-operative
> internet Lisp groups can be gelled to pressure Lisp
> in (perhaps new) evolutionary directions.
I wasn't clear. What I meant was the same as other people have said in ths
thread, that is, until people at my workplace work accept lisp, I won't be
able to use it for work for anything that I expect someone else to review
or maintain.
--
Eric Daniel
-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----== Over 80,000 Newsgroups - 16 Different Servers! =-----
From: Tim Bradshaw
Subject: Re: MAKUNBOUND and nested bindings?
Date:
Message-ID: <ey3k7cx64px.fsf@cley.com>
* Wade Humeniuk wrote:
> There is nothing standing in _your_ way to evolving "Lisp". Lisp
> evolves everytime someone writes code that is useful and functional.
> New ways and functionality are added. But do not expect that you
> need to influence and convince others to do the changing for you.
> It has evolved to the point it has, by being _extensively_ used,
> tested, re-written and re-written. So the only way for it to evolve
> is to undergo evolutionary pressures, and that means writing real
> world programs in real world uses.
I'd like to agree strongly with this. It really is not very hard to
change CL in many (not quite all) major ways. As an example, I'm not
very happy with various aspects of the package system, and as a result
all *my* large programs live in a world where DEFPACKAGE has a number
of additional features, such as the ability to clone packages, define
`conduit' packages and so on. All these are done in portable CL. I
have further hacks which support ACL-style relative package names and
per-package nicknames which are not portable, but generally require
only a very small amount of digging in the implementation. I also
have (but don't use, in practice) per-form package switching code, so
you can say (I forget the syntax) ·@my-package(this form is read in
MY-PACKAGE). And just lots of other hacks. The great majority of
these things are portable either in the `rely only on ANSI CL' or
`abstract things which all implementations provide' sense. If I
wanted to use them I now have lexical top-level variables, even.
So there really is nothing to stop you evolving Lisp: certainly the
lack of a standard for what you want to do is not stopping you, and if
you think it is then you are confused.
In fact, I'm fairly seriously considering presenting a paper at the
Lisp conference this year where I essentially put forward a cleaned-up
version of (the interface to) my package hacks as something which
people could implement as an extension. *That's* the way things
should work in my opinion - an implementation, or preferably several,
first, then a `standard'.
--tim
Tim Bradshaw <···@cley.com> writes:
> I also
> have (but don't use, in practice) per-form package switching code, so
> you can say (I forget the syntax) ·@my-package(this form is read in
> MY-PACKAGE).
Hmmm. IIRC the Lisp Machine had something like this built in. You
could add a package prefix to any form, not just symbols. So you could
then write something like
my-package:(this form your-package:read in my-package)
which would read in the form with a quick change to the package for
reading. I wonder why that didn't make it into CL? Was it just that it
wasn't supported much outside the Lisp Machines or was there some other
reason that made it undesirable?
--
Thomas A. Russ, USC/Information Sciences Institute ···@isi.edu
From: Tim Bradshaw
Subject: Re: MAKUNBOUND and nested bindings?
Date:
Message-ID: <ey3ptmn98uq.fsf@cley.com>
* Thomas A Russ wrote:
> Hmmm. IIRC the Lisp Machine had something like this built in. You
> could add a package prefix to any form, not just symbols. So you could
> then write something like
> my-package:(this form your-package:read in my-package)
yes, the description of my code (http://www.tfeb.org/lisp/hax.html)
explicitly says that I nicked it from Genera...
I don't know why it's not in CL.
--tim
Kent M Pitman <······@world.std.com> writes:
> <···························@TheWorld.com>This is just not so.
Sorry about the stray reference. That's my laptop doing mouse-right when
I am trying to hit spacebar.
"Kent M Pitman" <······@world.std.com> wrote in message
····················@shell01.TheWorld.com...
> At old-Symbolics, a report was commissioned of how expensive it was to
> merely receive a release of new software from Symbolics. Not how much
> we charge people, but how much do they pay out of pocket to accept the
> release in terms of having to upgrade code.
>
> One of the releases was estimated to cost multiple tens of thousands
> of dollars per customer to accept. That is, between ten and a hundred
> thousand dollars. Why? That was the release that was going to change
> the element-type of strings from integer to character. Just that one
> change was to cost, across the community, money on the order of a
> million dollars. Maybe half a million. Maybe 5 or ten million.
>
Since the source code was avail. the user could implement the change at a
low cost provided that the user was a Lisp programmer. And, who else would
even want to use a Lispm? The big selling point to people who like Lisp is
all the Lisp code that comes with one. This is another reason I choose to
get a used one.
Most other systems implement the OS in hairy assembler code, or
pointery C code.
I like exploring the Lispm OS to see how an OS not just a Lispm OS any OS
could be built.
"Franz Kafka" <Symbolics _ XL1201 _ Sebek _ Budo _ Kafka @ hotmail . com> writes:
> "Kent M Pitman" <······@world.std.com> wrote in message
> ····················@shell01.TheWorld.com...
>
> > At old-Symbolics, a report was commissioned of how expensive it was to
> > merely receive a release of new software from Symbolics. Not how much
> > we charge people, but how much do they pay out of pocket to accept the
> > release in terms of having to upgrade code.
> >
> > One of the releases was estimated to cost multiple tens of thousands
> > of dollars per customer to accept. That is, between ten and a hundred
> > thousand dollars. Why? That was the release that was going to change
> > the element-type of strings from integer to character. Just that one
> > change was to cost, across the community, money on the order of a
> > million dollars. Maybe half a million. Maybe 5 or ten million.
>
> Since the source code was avail. the user could implement the change at a
> low cost provided that the user was a Lisp programmer.
You miss my point. The change was ALREADY made. There was no work to the
implementation required. But users had tons of their own code that was
broken by the change -- that is, code that would not compile or would not
load in the new release. This had to be upgraded. In some cases, the
programmer who had written the code was not still on staff and that meant
ramping up a replacement just to keep existing code working.
> And, who else would even want to use a Lispm? The big selling point
> to people who like Lisp is all the Lisp code that comes with
> one. This is another reason I choose to get a used one.
User code did not come with the release. User code was written by users.
From: Tim Bradshaw
Subject: Re: MAKUNBOUND and nested bindings?
Date:
Message-ID: <ey3wuh0fa5a.fsf@cley.com>
* Kent M Pitman wrote:
> You miss my point. The change was ALREADY made. There was no work to the
> implementation required. But users had tons of their own code that was
> broken by the change -- that is, code that would not compile or would not
> load in the new release. This had to be upgraded. In some cases, the
> programmer who had written the code was not still on staff and that meant
> ramping up a replacement just to keep existing code working.
I think this is an important point. Relating to this is one of the
OSS myths, which applies equally to any distributed-with-source
system. The myth is that because you have the source, you don't get
screwed by the vendor making incompatible changes. The truth is that
because you have the source, you have the option, at extremely high
cost, of undoing any screwage caused by incompatible changes. For
instance: if someone changes gcc on me such that my programs won't
compile, then I do have the option of hacking the gcc sources to `fix'
this change (I also have the option of not accepting the new version,
but I have that for non distributed-with-source software too). How
much does doing that cost me? Well, really a lot, because the gcc
sources are very hairy, and I need to continue paying this cost for
every new release that comes out. So in practice I just change my
code. The other alternative is to pay money to the gcc maintainers to
not put in these incompatible changes, or make them switchable. Which
is, of course, just what you do for non distributed-with-source
systems. Indeed, the non-monopolistic vendors are very good at not
changing things incompatibly (there are programs compiled for SunOS 4
which still run on Solaris 7/8/9), because customers care.
--tim
Tim Bradshaw <···@cley.com> writes:
> The myth is that because you have the source, you don't get
> screwed by the vendor making incompatible changes. The truth is that
> because you have the source, you have the option, at extremely high
> cost, of undoing any screwage caused by incompatible changes.
Sort of. Remember this was software that included a re-microcoding of
the machine for some cases, and might or might not have been
synchronized with hardware upgrades in other cases. Changing
something as low-level as array access in a tagged machine is not
something that the casual user has any realistic hope of undoing by
changes of their own... And even if they do it--if they're developing
code for others to use, they can't trust the code they've developed
for others to run correctly unless the people they deliver to also
make this ultra-pervasive change. Frankly, they're better off not
upgrading if this is their chosen path.
(Then again, I seem to recall that Stallman made the change to the LMITI
systems in a less harsh way, so that you could either extract characters
or numbers from string arrays. Symbolics should have done this, but didn't.
Sources didn't make Stallman do the right thing here. What really mattered
was that (a) he had probably seen Symbolics' mistake and had hindsight
in his favor and (b) he's a clever guy, notwithstanding all the controversial
politics, and sometimes one clever guy does better than another, for
whatever reason.)
"Franz Kafka" <Symbolics _ XL1201 _ Sebek _ Budo _ Kafka @ hotmail . com> wrote:
> "Kent M Pitman" <······@world.std.com> wrote in message
> ····················@shell01.TheWorld.com...
>
>> At old-Symbolics, a report was commissioned of how expensive it was to
>> merely receive a release of new software from Symbolics. Not how much
>> we charge people, but how much do they pay out of pocket to accept the
>> release in terms of having to upgrade code.
>>
>> One of the releases was estimated to cost multiple tens of thousands
>> of dollars per customer to accept. That is, between ten and a hundred
>> thousand dollars. Why? That was the release that was going to change
>> the element-type of strings from integer to character. Just that one
>> change was to cost, across the community, money on the order of a
>> million dollars. Maybe half a million. Maybe 5 or ten million.
>
> Since the source code was avail. the user could implement the change
> at a low cost provided that the user was a Lisp programmer.
No, I don't think you understand what was happening here.
It's not a question of "having users who are Lisp programmers;" it's a
question of having system changes that impose code changes on those
that already have software deployed.
The point is that if Symbolics makes a change to functions' behaviour
that leads to already-deployed systems having to change to cope with
those changes, there is some cost to "fixing broken code."
That is, Symbolics changes functions FOO, BAR, and FROBOZZ, and you,
the user, have to revise your own programs A, B, and C to conform to
the new behaviour. And this has some cost.
It's just the same as if Microsoft deploys a new version of Win32 that
breaks some code, forcing developers to revise /their/ code.
It's just the same as if Linus Torvalds puts a change into the Linux
kernel that causes existing code to break, forcing developers to
revise /their/ code.
Or if the GNOME/KDE graphical infrastructure projects do new releases,
requiring some recoding to use the new functionality.
The issue has very little to do with Lisp; it can occur just as easily
with other sorts of systems, and has NOTHING to do with licensing
costs, and only a little to do with the language being used.
> And, who else would even want to use a Lispm? The big selling point
> to people who like Lisp is all the Lisp code that comes with
> one. This is another reason I choose to get a used one.
> Most other systems implement the OS in hairy assembler code, or
> pointery C code.
> I like exploring the Lispm OS to see how an OS not just a Lispm OS
> any OS could be built.
What you're talking about are other issues that have little to do with
what Kent is talking about.
Changing Common Lisp to conform with your expectations would lead to a
/huge/ cost of existing code breaking, which is a sufficiently
staggering cost to pretty successfully prevent most changes to it.
--
output = reverse(········@" "enworbbc")
http://cbbrowne.com/info/lisp.html
"So you don't want to hear about my ideas for Cliche Programming?
(Basically, the unit of abstraction is a Stereotype; instances of
Stereotypes interact by exchanging Hype.)" -- Peter Lewerin
Kent M Pitman wrote:
...other good stuff, then:
> A lot of the change in attitude I'd attribute to Java. Java has made
> GC popular again, and actually probably improved people's desire for a
> working one. Heh. It has also made people aware of the need for
> integers bigger than so-called ints. And it has improved the
> understanding of 'message passing' / 'genericity'. It has popularized
> some data structures that matter to us. While it's statically typed
> in some ways, it's dynamically typed in others, and this is to our
> benefit. It has introspection. It even has a primitive condition
> system (more powerful than other languages, not as good as ours) Not
> to say these things are all done right, but this introduces the
> ability for us to merely say "we have a better way" on a topic people
> have seen, rather than a missionary project of teaching people they
> want the feature in question.
Good point. Python at a much smaller scale is also unwittingly drawing
people towards Lisp, and as you say creating the demand for that which
CL supplies in spades.
>
> Lisp was ahead of its time and was a bit of a memory glutton. With 80gb
> disks around, few begrudge a few megabytes any more. That's a major thing
> all in itself.
>
> I don't know why you don't see any of these as positive unless you've just
> been in one place for too long.
I guess those who have led the charge in vain for so long are entitled
to a little battle fatigue. I've whined myself before about others'
negativity, but hey, maybe this is a Good Thing. Someone comes to CLL
and finds us engaged in honest self-scrutiny, not lockstep rah-rah CL
evangelism.
What we need now are testimonials and advocacy not from the old guard
but from the young tigers discovering now the oldest new language on the
block. Especially folks who turned to Lisp /after/ doing good things in
C/C++/Java/Python. I'm one of those (young only in that I have less than
ten years Lisp experience), and Lispnyc has been joined by another. Here
are some more data points:
http://www.cliki.net/YoungLispers
[Anyone young or new to Lisp not already up there, plz add your story ASAP.]
A perhaps subtle point is that new Lispniks don't just like CL, they
flip over it. And we know that that is not infatuation, that is simply
an accurate assessment of CL's superiority.
With an edge like that, with obstacles like expensive RAM removed, and
with the establishment in disarray ("C++! No, Java! Hang on, Perl! Wait,
Python!") what can stop CL?
M$ stopped the Mac by providing (eventually) a similar-enuff GUI
experience in a DOS sit-atop, aka Windows, sufficiently close that other
barriers to switching sufficed to protect their monopoly. Will some
current established player steal Lisp's thunder? With untyped variables,
interactivity, macros, GFs, MI, specials, while being compiled and
stable and backed by an ANSI standard? I can't think of one.
--
kenny tilton
clinisys, inc
http://www.tilton-technology.com/
---------------------------------------------------------------
"Everything is a cell." -- Alan Kay
In article <················@nyc.rr.com>,
Kenny Tilton <·······@nyc.rr.com> wrote:
> A perhaps subtle point is that new Lispniks don't just like CL, they
> flip over it. And we know that that is not infatuation, that is simply
> an accurate assessment of CL's superiority.
Yesss - and they also work behind the scenes to do something about
increasing the popularity of Common Lisp. I also agree with Kenny that
the scrutiny the community applies to its language is a good thing. We
learn a lot from discussions about, for example, new proposals for
special variables. The question whether Common Lisp still lives up to
its promise is a legitimate one, and it's a good idea that we learn
about some arguments that we can use in discussions outside of c.l.l.
> With an edge like that, with obstacles like expensive RAM removed, and
> with the establishment in disarray ("C++! No, Java! Hang on, Perl! Wait,
> Python!") what can stop CL?
exactly
> M$ stopped the Mac by providing (eventually) a similar-enuff GUI
> experience in a DOS sit-atop, aka Windows, sufficiently close that other
> barriers to switching sufficed to protect their monopoly. Will some
> current established player steal Lisp's thunder? With untyped variables,
> interactivity, macros, GFs, MI, specials, while being compiled and
> stable and backed by an ANSI standard? I can't think of one.
There are some signs that surprising things may happen. For example, Don
Box (an influential guy in the Microsoft world, AFAIK) has started to
like dynamic typing. Here is a quote from his weblog at http://www.gotdotnet.com/team/dbox/default.aspx#nn2003-05-03T11:15:53Z
:::
: 2003-05-03 - Yes, Bob, I too want to work in a dynamically typed
language
: Bob Martin's post on statically typed languages reminds me of both
Chris' and my own�migration from the C++ view of typing to a less static
view of the world.
�
: I agree with Bob that having language support for dynamic typing is a
real boon to productivity.
�
: I'm not so sure that test driven development (TDD) is the only tool
for making dynamic typing "industrial strength."� I think we (the
industry that is) can do more if/when enough people wake up from the
Java-induced haze.
�
: Maybe Bob should come up to Redmond and help us out!
:::
As far as I understand this is mainly an effect of the popularity of
Extreme Programming.
So let me dream a little: In a year, or so, Microsoft has extended .NET
in a way that Smalltalk can be fully implemented on top of it. Since
Apple always tries to stay ahead of its competition in technological
terms, they will buy Digitool and make Macintosh Common Lisp their
answer to MS Smalltalk. Then everybody can buy an Apple PowerBook
including a full Common Lisp implementation with a Cocoa bridge, and
have the coolest machine that ever existed on this planet! ;-)
Pascal
Pascal Costanza wrote:
> There are some signs that surprising things may happen. For example, Don
> Box (an influential guy in the Microsoft world, AFAIK) has started to
> like dynamic typing. Here is a quote from his weblog at http://www.gotdotnet.com/team/dbox/default.aspx#nn2003-05-03T11:15:53Z
Nice find! I followed it to the article to which /he/ was reacting:
From http://www.artima.com/weblogs/viewpost.jsp?thread=4639 (but
heavily snipped ...):
" I've been a statically typed bigot for quite a few years....When C++
came out, I was an avid adopter, and rabid enforcer of strong typing. I
scoffed at the smalltalkers who whined about the loss of flexibility. ...
"Four years ago I got involved with Extreme Programming. ....
"About two years ago I noticed something. I was depending less and less
on the type system for safety. My unit tests were preventing me from
making type errors. ...
"... So I tried writing some applications in Python, and then Ruby (well
known dynamically typed languages). I was not entirely surprised when I
found that type issues simply never arose. ...
"I also realized that the flexibility of dynamically typed langauges
makes writing code significantly easier. Modules are easier to write,
and easier to change. There are no build time issues at all. Life in a
dynamically typed world is fundamentally simpler.
"Now I am back programming in Java because the projects I'm working on
call for it. But I can't deny that I feel the tug of the dynamically
typed languages. I wish I was programming in Ruby or Python, or even
Smalltalk.
"... Will we all be programming in a dynamically typed language in 2010?"
Check out the full article, then check out the responses. Wow.
Wow #2 is that Lisp does not get mentioned (until very recently <g>),
tho someone did provide a link to Graham's 100yr piece.
--
kenny tilton
clinisys, inc
http://www.tilton-technology.com/
---------------------------------------------------------------
"Everything is a cell." -- Alan Kay
Pascal Costanza <········@web.de> writes:
> Since
> Apple always tries to stay ahead of its competition in technological
> terms, they will buy Digitool and make Macintosh Common Lisp their
> answer to MS Smalltalk.
then Apple would have to admit that they were terribly wrong when they
closed down MCL and their other lisp activites years ago...
--
(espen)
Espen Vestre wrote:
> Pascal Costanza <········@web.de> writes:
>
>
>>Since
>>Apple always tries to stay ahead of its competition in technological
>>terms, they will buy Digitool and make Macintosh Common Lisp their
>>answer to MS Smalltalk.
>
>
> then Apple would have to admit that they were terribly wrong when they
> closed down MCL and their other lisp activites years ago...
I guess that's why they never brought back Steve Jobs, even tho he could
have helped rejuvenate Apple... oh, hang on. :)
--
kenny tilton
clinisys, inc
http://www.tilton-technology.com/
---------------------------------------------------------------
"Everything is a cell." -- Alan Kay
From: Tim Bradshaw
Subject: Re: MAKUNBOUND and nested bindings?
Date:
Message-ID: <ey3smrof9z4.fsf@cley.com>
* Kenny Tilton wrote:
> I guess that's why they never brought back Steve Jobs, even tho he
> could have helped rejuvenate Apple... oh, hang on. :)
I've always assumed that what happened there was that NeXT (and hence
Jobs) actually bought Apple, it's just that they didn't have the money
to do that so it looked like it was the other way around. Certainly
in technical terms that seems to have been what happened.
--tim
Kent M Pitman <······@world.std.com> writes:
A minor nitpick on one of the most interesting threads in a while...
> Users complaining about low cost options were met with free(as in beer)
> versions of LispWorks and Allegro, and numerous free(as in gnu) other
> whole implementations.
Please don't lump all the free implementations into the gnu camp.
CMUCL is 90% public domain, 10% BSD'ish--in fact, people have taken
the entire implementation and commercialized it:
http://www.scieneer.com. "Free (as in gnu)" sounds to me like "Free
(as in Cuba)"...
Gabe Garza
Gabe Garza <·······@ix.netcom.com> writes:
> Kent M Pitman <······@world.std.com> writes:
>
> A minor nitpick on one of the most interesting threads in a while...
>
> > Users complaining about low cost options were met with free(as in beer)
> > versions of LispWorks and Allegro, and numerous free(as in gnu) other
> > whole implementations.
>
> Please don't lump all the free implementations into the gnu camp.
> CMUCL is 90% public domain, 10% BSD'ish--in fact, people have taken
> the entire implementation and commercialized it:
> http://www.scieneer.com. "Free (as in gnu)" sounds to me like "Free
> (as in Cuba)"...
Ah. I didn't mean to do that. To be honest, I didn't know the facts
you're citing, so I appreciate the correction... and I'm very happy to hear
there's diversity in this regard.
"Kent M Pitman" <······@world.std.com> wrote in message ····················@shell01.TheWorld.com...
>
<lots of good comments removed>
Thank you Kent for your time and effort put into that post. I agree and
appreciate what you have said.
Wade
Kent M Pitman <······@world.std.com> wrote:
> community that it will invest in a failure. Languages are not well-designed
> by committees. It's better for an individual with a single-minded view to
> get things mostly right (as Steele did with CL, and as Sussman/Steele did with
> Scheme) and _then_ allow people to fiddle if that's even desired. But most
This is actually a point that should be made more often and loudly.
There is a general tendency to resent "design by committee", and far too often
CL is perceived as having been designed by a committee. Common Lisp resources
could make a stronger point of having both a single designer *and* a standard
finalized by a committee.
I don't recall ever seeing this articulated anywhere bisble to eyes of the
casually interested.
Cheers,
-- Nikodemus
Kent M Pitman <······@world.std.com> writes:
>> Then I wonder what you envision as Lisp's future.
> Layered standards.
That would definitely be a good thing, IMHO. There isn't going to be a
new ANSI Common Lisp anytime soon, if we want one or not. That
shouldn't stop us from going forward in areas where this is possible.
The question is, how do we get such a thing going? Substandards.org
doesn't seem to be too successful, to say the least. I recently
noticed the Standards page at the ALU cliki
(http://alu.cliki.net/Standards). What's up with that? (And, by the
way, what's up with ALU anyway? The only trace of it's existence are
the ILCs, or so it seems. Is there any kind of activity? Should there
be?)
Regards
Henrik
Henrik Motakef <··············@web.de> writes:
> > Layered standards.
> The question is, how do we get such a thing going? Substandards.org
> doesn't seem to be too successful, to say the least.
Well, it's just delayed in starting. The nightmare of my house and
how some bad decisions about renovation has consumed all of my life
savings (including retirement accounts) is hardly worth going into in
detail here. But it's winding down and I hope to return to Lispy
endeavors soon, something that I haven't had time to do for quite a
lot of months because of the intrusion of stupid administrative
issues. Anyone with money to contribute toward getting substandard.org
going is welcome to contact me about that.
Henrik Motakef <··············@web.de> writes:
> The question is, how do we get such a thing going? Substandards.org
> doesn't seem to be too successful, to say the least. I recently
> noticed the Standards page at the ALU cliki
> (http://alu.cliki.net/Standards). What's up with that? (And, by the
The Standards page at the ALU cliki is, I think, a convincing
demonstration that Kent's right when he says that people should bring
finished proposals to the table rather than attempting to design
through consensus.
-dan
--
http://www.cliki.net/ - Link farm for free CL-on-Unix resources
In article <··············@noetbook.telent.net>, Daniel Barlow
<···@telent.net> wrote:
> people should bring finished proposals to the table
Fine. Where is the table?
E.
On Wed, 07 May 2003 21:07:36 +0200, Henrik Motakef <··············@web.de>
wrote:
> (http://alu.cliki.net/Standards). What's up with that? (And, by the
> way, what's up with ALU anyway? The only trace of it's existence are
> the ILCs, or so it seems. Is there any kind of activity? Should there
> be?)
Yes, there is some activity. More on this when information becomes
available.
Paolo
--
Paolo Amoroso <·······@mclink.it>
···@jpl.nasa.gov (Erann Gat) writes:
> 1. Is Common Lisp's lack of popularity a problem? (It certainly is for
> me. I am unable to use it because it is widely perceived by my peers as
> dead.)
>
> 2. Assuming that Common Lisp's lack of popularity is a problem, what can
> (or should) be done about it (if anything)?
I bet the best way for it to become popular would be for it to become
popular. Honest: whatever there is in the way of lisp adoption on a
large scale, I don't see evidence that supports that difficulty in
mastering special variables is the main reason.
> I am interested in addressing that second question, and I address it under
> the following assumptions:
>
> 1. Neither the simple passage of time nor a handful of successful CL
> applications will cause CL to become significantly more popular than it is
> today. History supports this assumption. Therefore, if CL is to become
> more popular *something* about it must change.
>
> 2. CL can only grow more popular by attracting new users. (This is a
> tautology.) It is therefore more likely to become popular if barriers to
> entry are removed.
>
> 3. There are some technical issues that new CL users appear to become
> perennially confused about, special variables (and related issues having
> to do with bindings and lexical closures) seem to be chief among these.
> This is bad because 1) it's a barrier to entry and 2) lots of time is
> wasted trying to explain these issue to newcomers on c.l.l. again and
> again and again and again.
To point 3 I have to reiterate that I don't think that any complexity
in CL is the problem. And if it is, I would look at pathnames and at
the lack of a standard "make"-like tool closer than at special
variables. If you want to attract more users, how about contributing to
the free lisps? Writing a C00l portable editor?
> Therefore, trying to remove this barrier by simplifying the design of CL
> in this respect seems to be a fruitful place to pursue the kind of change
> that is a necessary (but perhaps not sufficient) condition to change CL's
> popularity. That is why I wrote the BIND proposal, and the Idiot's guide.
Folks here routinely complain about the lack of slick portable free
GUI toolkits, encapsulation, and (sometimes) about the lack of native
multithreding, and you think the specials are the problem? Huh?
> BTW, I wrote "The Idiot's Guide..." not so much because I think I'm
> particularly qualified to write it,
I'm not so sure you are saying what you want to say... ;)
> Ill informed, eh? I have been programming in Lisp for 20 years. I have
> read a significant fraction of all the books that have ever been written
> on the topic. I may not be the brightest bulb, but I'm no idiot either.
> If I am ill-informed then at what point do you think it would not be out
> of line to suggest that the fault might not lie entirely with me?
I've not been into this business for so long (and the post isn't
addressed to me either), but in any case I would say you get the
statistics wrong. Specials definately *aren't* keeping people off. I've
not heard that once. When people say they don't want to use lisp, they
offer the following explanations:
1. It is not popular (In the circular tradition of lisp, I would offer
"because it's not popular" as an explanation)
2. It is slow. (myth)
3. It is too big; too much to master (a matter of taste).
4. No nice libraries for tons of different things. (not so much of a
myth)
5. Don't like them parens; too much of them. (A matter of taste, and
in any case, you need a good editor)
6. You folks (cll) aren't nice to newbies. (This year things have
gotten notably better)
7. Cannot make stand-alone executables (A matter of taste and of
implementation)
There are some points here that can be adressed in a straight-forward
way that would help a lot more than what you propose.
Regards,
Mario.
In article <·················@cupid.igpm.rwth-aachen.de>, Mario S. Mommer
<········@yahoo.com> wrote:
> To point 3 I have to reiterate that I don't think that any complexity
> in CL is the problem. And if it is, I would look at pathnames and at
> the lack of a standard "make"-like tool closer than at special
> variables.
You gotta start somewhere. Have you written a proposal for improvements
to pathnames, or for a standard make utility?
> If you want to attract more users, how about contributing to
> the free lisps? Writing a C00l portable editor?
I don't think I have the expertise to do that. I've never written an editor.
> > Therefore, trying to remove this barrier by simplifying the design of CL
> > in this respect seems to be a fruitful place to pursue the kind of change
> > that is a necessary (but perhaps not sufficient) condition to change CL's
> > popularity. That is why I wrote the BIND proposal, and the Idiot's guide.
>
> Folks here routinely complain about the lack of slick portable free
> GUI toolkits, encapsulation, and (sometimes) about the lack of native
> multithreding, and you think the specials are the problem? Huh?
I didn't say that. I think that the lack of change is the main problem.
I'm using specials as a test case to try to figure out how to effect
change -- any change -- in Common Lisp, indeed to see if it is even
possible.
> > BTW, I wrote "The Idiot's Guide..." not so much because I think I'm
> > particularly qualified to write it,
>
> I'm not so sure you are saying what you want to say... ;)
Why? I'm pretty sure I meant what I wrote. I do not consider myself a
Lisp expert (at least not by the standard of expertise in this
newsgroup). (Neither do I consider myself an ill-informed newbie.)
> I've not been into this business for so long (and the post isn't
> addressed to me either), but in any case I would say you get the
> statistics wrong. Specials definately *aren't* keeping people off.
That may be, but I still maintain that people do get confused about them.
Whether this puts them off CL or not is debatable, and also beside the
point.
> I've
> not heard that once. When people say they don't want to use lisp, they
> offer the following explanations:
>
> 1. It is not popular (In the circular tradition of lisp, I would offer
> "because it's not popular" as an explanation)
>
> 2. It is slow. (myth)
>
> 3. It is too big; too much to master (a matter of taste).
>
> 4. No nice libraries for tons of different things. (not so much of a
> myth)
>
> 5. Don't like them parens; too much of them. (A matter of taste, and
> in any case, you need a good editor)
>
> 6. You folks (cll) aren't nice to newbies. (This year things have
> gotten notably better)
>
> 7. Cannot make stand-alone executables (A matter of taste and of
> implementation)
>
> There are some points here that can be adressed in a straight-forward
> way that would help a lot more than what you propose.
Fine. Which of these do you think we ought to address first, and where is
your proposal for how to address it?
E.
···@jpl.nasa.gov (Erann Gat) writes:
> In article <·················@cupid.igpm.rwth-aachen.de>, Mario S. Mommer
> <········@yahoo.com> wrote:
>
> > To point 3 I have to reiterate that I don't think that any complexity
> > in CL is the problem. And if it is, I would look at pathnames and at
> > the lack of a standard "make"-like tool closer than at special
> > variables.
>
> You gotta start somewhere. Have you written a proposal for improvements
> to pathnames, or for a standard make utility?
Asdf and makesystem do quite a fine job, IMHO.
I don't want to risk the black helicopter thing again, so I'll leave it
like that regarding pathnames. Seriously, though, pathnames are
probably one of those things where a decent howto could help far more
than a complete refurbishment. The title, though, shouldn't be:
"Pathnames for the totally whacky"
> > If you want to attract more users, how about contributing to
> > the free lisps? Writing a C00l portable editor?
>
> I don't think I have the expertise to do that. I've never written an editor.
there's always a first time :)
> > Folks here routinely complain about the lack of slick portable free
> > GUI toolkits, encapsulation, and (sometimes) about the lack of native
> > multithreding, and you think the specials are the problem? Huh?
>
> I didn't say that. I think that the lack of change is the main problem.
> I'm using specials as a test case to try to figure out how to effect
> change -- any change -- in Common Lisp, indeed to see if it is even
> possible.
Someone here suggested a POSIX interface, and wasn't met with flak
fire. A nice standard multi-threading API would be way cool too, for
instance. I think the work needed for "fixing" specials is huge in
relation to the benefit gained.
> > I've not been into this business for so long (and the post isn't
> > addressed to me either), but in any case I would say you get the
> > statistics wrong. Specials definately *aren't* keeping people off.
>
> That may be, but I still maintain that people do get confused about them.
> Whether this puts them off CL or not is debatable, and also beside the
> point.
Is it? Wasn't that your whole point? Let's change specials so that
people flock to CL?
> > I've
> > not heard that once. When people say they don't want to use lisp, they
> > offer the following explanations:
> >
> > 1. It is not popular (In the circular tradition of lisp, I would offer
> > "because it's not popular" as an explanation)
> >
> > 2. It is slow. (myth)
> >
> > 3. It is too big; too much to master (a matter of taste).
> >
> > 4. No nice libraries for tons of different things. (not so much of a
> > myth)
> >
> > 5. Don't like them parens; too much of them. (A matter of taste, and
> > in any case, you need a good editor)
> >
> > 6. You folks (cll) aren't nice to newbies. (This year things have
> > gotten notably better)
> >
> > 7. Cannot make stand-alone executables (A matter of taste and of
> > implementation)
> >
> > There are some points here that can be adressed in a straight-forward
> > way that would help a lot more than what you propose.
>
> Fine. Which of these do you think we ought to address first, and where is
> your proposal for how to address it?
My candidate would be point 4. That is where the meat is. Write nice
libs, with nice docs, and everything should work out fine on the long
run.
Many fine libs lack docs, so if you are no wizard in the area the lib
cares about, you can help there. There are quite a lot of things to do
and improve that can make a real tangible difference for the people
already using CL. Lots of potential positive impact for anyone caring
to take the trouble.
Regards,
Mario.
In article <··············@cupid.igpm.rwth-aachen.de>, Mario S. Mommer
<········@yahoo.com> wrote:
> > > If you want to attract more users, how about contributing to
> > > the free lisps? Writing a C00l portable editor?
> >
> > I don't think I have the expertise to do that. I've never written an
editor.
>
> there's always a first time :)
At my age one begins to realize that life is far too short to do
everything that one would like to do, or even just all the worthwhile
things, even for the first time.
> > > I've not been into this business for so long (and the post isn't
> > > addressed to me either), but in any case I would say you get the
> > > statistics wrong. Specials definately *aren't* keeping people off.
> >
> > That may be, but I still maintain that people do get confused about them.
> > Whether this puts them off CL or not is debatable, and also beside the
> > point.
>
> Is it? Wasn't that your whole point? Let's change specials so that
> people flock to CL?
No. My point is: let's change specials because people get confused about
them, lots of time gets wasted explaining them, and they are a barrier to
entry. Whether they are a *decisive* barrier I don't know. Probably
not. But changing them is easy (easier than documenting them -- I know
because I've done both), I saw what I thought was a good answer, so I
thought I'd try for what seemed to me to be low-lying fruit.
E.
From: Nils Goesche
Subject: Re: Popularity (was Re: MAKUNBOUND and nested bindings?)
Date:
Message-ID: <lyk7d2629h.fsf@cartan.de>
···@jpl.nasa.gov (Erann Gat) writes:
> In article <··············@cupid.igpm.rwth-aachen.de>, Mario S. Mommer
> <········@yahoo.com> wrote:
>
> > Is it? Wasn't that your whole point? Let's change specials so that
> > people flock to CL?
>
> No. My point is: let's change specials because people get confused
> about them, lots of time gets wasted explaining them, and they are a
> barrier to entry.
I am just thinking about how much time of my life I've wasted
explaining integrals to students...
Regards,
--
Nils G�sche
"Don't ask for whom the <CTRL-G> tolls."
PGP key ID 0x0655CFA0
On Wed, 07 May 2003 01:47:20 -0700, ···@jpl.nasa.gov (Erann Gat) wrote:
> In article <·················@cupid.igpm.rwth-aachen.de>, Mario S. Mommer
> <········@yahoo.com> wrote:
[...]
> > not heard that once. When people say they don't want to use lisp, they
> > offer the following explanations:
> >
> > 1. It is not popular (In the circular tradition of lisp, I would offer
> > "because it's not popular" as an explanation)
[...]
> Fine. Which of these do you think we ought to address first, and where is
> your proposal for how to address it?
I propose to address 1. because it is easy. Adding more entries to these
pages might help:
http://alu.cliki.net/Industry%20Application
http://alu.cliki.net/Research%20Organizations
http://alu.cliki.net/Success%20Stories
http://alu.cliki.net/Evaluate%20Lisp
http://alu.cliki.net/Consultant
It's cheap, it doesn't take much time, and it doesn't hurt anyway.
Paolo
--
Paolo Amoroso <·······@mclink.it>
Mario S. Mommer <········@yahoo.com> writes:
> 6. You folks (cll) aren't nice to newbies. (This year things have
> gotten notably better)
Hmm. I wonder how long this works out. Without Erik filtering out trolls
by exposing them I already see that I have to do more work myself scoring
the threads.
Nicolas.
"Nicolas Neuss" <·············@iwr.uni-heidelberg.de> wrote in message
···················@ortler.iwr.uni-heidelberg.de...
> Mario S. Mommer <········@yahoo.com> writes:
>
> > 6. You folks (cll) aren't nice to newbies. (This year things have
> > gotten notably better)
>
> Hmm. I wonder how long this works out. Without Erik filtering out trolls
> by exposing them I already see that I have to do more work myself scoring
> the threads.
Nobody said thinking for yourself was easy.
--
Coby Beck
(remove #\Space "coby 101 @ bigpond . com")
"Coby Beck" <·····@mercury.bc.ca> writes:
> "Nicolas Neuss" <·············@iwr.uni-heidelberg.de> wrote in message
> ···················@ortler.iwr.uni-heidelberg.de...
> > Mario S. Mommer <········@yahoo.com> writes:
> >
> > > 6. You folks (cll) aren't nice to newbies. (This year things have
> > > gotten notably better)
> >
> > Hmm. I wonder how long this works out. Without Erik filtering out trolls
> > by exposing them I already see that I have to do more work myself scoring
> > the threads.
>
> Nobody said thinking for yourself was easy.
Why are you implying that Nicolas was/is not thinking?
How do you know he just come to the conclusion that
if Erik was engaging them they were probably people
he did not want to spend time with? And he came to
this decision by thinking about it?
Or did the psychic friends hot line call him up
and tell him what to do?
I also find it disturbing that just because someone
posted an opinion that you do not like you feel free
to insult him and attack him, personally. You in no
way addressed his point that from a certain POV Erik
made a very good "SPAM filter" for some of us here.
marc
"Marc Spitzer" <········@optonline.net> wrote in message
···················@bogomips.optonline.net...
> "Coby Beck" <·····@mercury.bc.ca> writes:
>
> > "Nicolas Neuss" <·············@iwr.uni-heidelberg.de> wrote in message
> > ···················@ortler.iwr.uni-heidelberg.de...
> > > Hmm. I wonder how long this works out. Without Erik filtering out
trolls
> > > by exposing them I already see that I have to do more work myself
scoring
> > > the threads.
> >
> > Nobody said thinking for yourself was easy.
>
> I also find it disturbing that just because someone
> posted an opinion that you do not like you feel free
> to insult him and attack him, personally.
The irony meter just pinged again.
> You in no
> way addressed his point that from a certain POV Erik
> made a very good "SPAM filter" for some of us here.
Your SPAM filter should be local to your machine and not prevent *anything*
from reaching me. I will configure my own killfile. This is my point
entirely.
--
Coby Beck
(remove #\Space "coby 101 @ bigpond . com")
"Coby Beck" <·····@mercury.bc.ca> writes:
> "Marc Spitzer" <········@optonline.net> wrote in message
> ···················@bogomips.optonline.net...
> > "Coby Beck" <·····@mercury.bc.ca> writes:
> >
> > > "Nicolas Neuss" <·············@iwr.uni-heidelberg.de> wrote in message
> > > ···················@ortler.iwr.uni-heidelberg.de...
> > > > Hmm. I wonder how long this works out. Without Erik filtering out
> trolls
> > > > by exposing them I already see that I have to do more work myself
> scoring
> > > > the threads.
> > >
> > > Nobody said thinking for yourself was easy.
> >
> > I also find it disturbing that just because someone
> > posted an opinion that you do not like you feel free
> > to insult him and attack him, personally.
>
> The irony meter just pinged again.
Yea right. But you did not respond to my statement above.
So let me ask it again, why did you attack Nicolas when
he did not attack you? What prompted you hostile behavior?
Was the fact that he did not agree with you the reason he
must be attacked?
>
> > You in no
> > way addressed his point that from a certain POV Erik
> > made a very good "SPAM filter" for some of us here.
>
> Your SPAM filter should be local to your machine and not prevent *anything*
> from reaching me. I will configure my own killfile. This is my point
> entirely.
Erik never prevented anything from reaching you, infact
you could claim that he was the cause of more stuff reaching
you.
Personaly I do not use a killfile, its too much like hiding
from things I do not like.
marc
"Marc Spitzer" <········@optonline.net> wrote in message
···················@bogomips.optonline.net...
> "Coby Beck" <·····@mercury.bc.ca> writes:
> > "Marc Spitzer" <········@optonline.net> wrote in message
> > ···················@bogomips.optonline.net...
> > > "Coby Beck" <·····@mercury.bc.ca> writes:
> > > > "Nicolas Neuss" <·············@iwr.uni-heidelberg.de> wrote in
message
> > > > ···················@ortler.iwr.uni-heidelberg.de...
> > > > > Hmm. I wonder how long this works out. Without Erik filtering
out
> > trolls
> > > > > by exposing them I already see that I have to do more work myself
> > > > > scoring the threads.
> > > >
> > > > Nobody said thinking for yourself was easy.
> > >
> > > I also find it disturbing that just because someone
> > > posted an opinion that you do not like you feel free
> > > to insult him and attack him, personally.
> >
> > The irony meter just pinged again.
>
> Yea right. But you did not respond to my statement above.
I'm sorry you're disturbed.
> So let me ask it again, why did you attack Nicolas when
> he did not attack you?
I did not attack Nicolas.
> What prompted you hostile behavior?
I was not being hostile.
> Was the fact that he did not agree with you the reason he
> must be attacked?
I disagree that he must be attacked.
> Personaly I do not use a killfile, its too much like hiding
> from things I do not like.
Nor do I. Unless this sub-thread takes a more useful turn, I will not be
replying again.
--
Coby Beck
(remove #\Space "coby 101 @ bigpond . com")
Marc Spitzer wrote:
> You in no
> way addressed his point that from a certain POV Erik
> made a very good "SPAM filter" for some of us here.
A spam filter needs to fulfil two requirements:
+ It should filter out messages that I want to be filtered out.
+ It should not filter out messages that I don't want to be filtered out.
I don't want to see a spam filter installed that I regard as ineffective
in both regards.
Pascal
--
Pascal Costanza University of Bonn
···············@web.de Institute of Computer Science III
http://www.pascalcostanza.de R�merstr. 164, D-53117 Bonn (Germany)
Pascal Costanza <········@web.de> writes:
> Marc Spitzer wrote:
>
> > You in no
> > way addressed his point that from a certain POV Erik
> > made a very good "SPAM filter" for some of us here.
>
> A spam filter needs to fulfil two requirements:
>
> + It should filter out messages that I want to be filtered out.
>
> + It should not filter out messages that I don't want to be filtered out.
>
> I don't want to see a spam filter installed that I regard as
> ineffective in both regards.
Or worse, a spam filter that produces spam of its own.
Mario S. Mommer <········@yahoo.com> writes:
> Or worse, a spam filter that produces spam of its own.
Periodically over the years, I've tried writing spam filters for my
own use. One of these would classify e-mail in one of four
categories: known-spam, probably-spam, probably-good, and known-good.
Due to a typo, it would send me multiple mails notifying me of each
probable spam message. That got fixed fast.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
Pascal Costanza <········@web.de> writes:
> Marc Spitzer wrote:
>
> > You in no
> > way addressed his point that from a certain POV Erik
> > made a very good "SPAM filter" for some of us here.
>
> A spam filter needs to fulfil two requirements:
>
> + It should filter out messages that I want to be filtered out.
>
> + It should not filter out messages that I don't want to be filtered out.
>
> I don't want to see a spam filter installed that I regard as
> ineffective in both regards.
opinions differ and I liked reading his flames, they were quite
well written.
marc
>
>
> Pascal
>
> --
> Pascal Costanza University of Bonn
> ···············@web.de Institute of Computer Science III
> http://www.pascalcostanza.de R�merstr. 164, D-53117 Bonn (Germany)
Marc Spitzer <········@optonline.net> writes:
> Pascal Costanza <········@web.de> writes:
>
> > Marc Spitzer wrote:
> >
> > > You in no
> > > way addressed his point that from a certain POV Erik
> > > made a very good "SPAM filter" for some of us here.
> >
> > A spam filter needs to fulfil two requirements:
> >
> > + It should filter out messages that I want to be filtered out.
> >
> > + It should not filter out messages that I don't want to be filtered out.
> >
> > I don't want to see a spam filter installed that I regard as
> > ineffective in both regards.
>
> opinions differ and I liked reading his flames, they were quite
> well written.
Indeed they were, at times.
However, as someone who does not have much time to spend on reading
news, I would have very much appreciated being able to read a
comp.lang.lisp where most of the traffic was about lisp, rather than
about Erik's critiques of others. To satisfy my need for the latter I
should like to read alt.erik.naggum.flames, or similar.
Some thought on popularity factors from the perspective of a
relative newcomer. In no particular order:
1. The perceived tension between CL and Scheme communities. I don't
think we should work towards integration, but better understanding
and communication.
I'm sort of looking forwads to the day when Scheme people recommend
CL as better alternative to Java / C++, and CL people suggest
Scheme instead of Haskell / ML...
2. Lisp is neither dead nor 50 years old! I think that a major
turnoff for some people is the way Lisp is characterized as old and
stable since the 1950's, which it obiously is not.
I think it would make more sense to speak of Common Lisp as a *new*
language, because even though the standard is soon ten years old, I
have understood that the wide availablity of high-quality compilers
is something that has happened in the last 5 years.
Maybe I have misunderstood, but the point stands: don't call Lisp
old. Call the implementations fresh. Don't say "You have been blind
for all your life", say "You probably haven't heard of the current
generation of compilers", or "Oh, thats pre-ANSI..." When someone
says "Lisp is dead.", say "Yeah, but Common Lisp rocks.", don't
start a sermon on the dialects.
The Lisp-Java comparison paper is solid dynamite up to the point
where it starts wondering "Theoretically Lisp is good. So what's
wrong in practise?": I might respectfully suggest a second edition
with major portions of the analysis removed, or reconducting the
study and having a non-lisper write the analysis.
3. I think the something along the lines of the cirCLe initiative
is on the right track. Someone has to make a stand for which
defsystem, which socket library, which posix-interface, which GUI
toolkit, etc. to adopt on the open source side.
I think that the problem most non-comers have with the library
extensions is not their lack, but the fact that there are so
many. Choise is a good thing, but some sort of community-adoption
would make things easier.
Also, as has been stated a number of times, something like the
Scheme SRFI's would be nice. Can someone enlighten me as to how did
the Scheme community set up the process?
Cheers,
-- Nikodemus
"Erann Gat" <···@jpl.nasa.gov> wrote in message
·························@k-137-79-50-101.jpl.nasa.gov...
>
> > I always encourage people
> > who don't agree with the design to either not use the feature or not use
> > the language.
>
> Yes, I know. That attitude (which seems to be rather prevalent) is IMO
> one of the reasons that Lisp has been stagnant for ten years, which is in
> turn is one of the reasons that I am no longer able to use it despite the
> fact that I very much want to. Different is not necessarily better, but
> better is necessarily different.
Then just leave Erann, your negative and nitpicking attitude is wearing
very thin. You have CL, you have a language you can go and write
your dream language in, just get off the pot.
Wade
In article <·······················@news2.telusplanet.net>, "Wade
Humeniuk" <····@nospam.nowhere> wrote:
> "Erann Gat" <···@jpl.nasa.gov> wrote in message
> ·························@k-137-79-50-101.jpl.nasa.gov...
> >
> > > I always encourage people
> > > who don't agree with the design to either not use the feature or not use
> > > the language.
> >
> > Yes, I know. That attitude (which seems to be rather prevalent) is IMO
> > one of the reasons that Lisp has been stagnant for ten years, which is in
> > turn is one of the reasons that I am no longer able to use it despite the
> > fact that I very much want to. Different is not necessarily better, but
> > better is necessarily different.
>
> Then just leave Erann, your negative and nitpicking attitude is wearing
> very thin. You have CL, you have a language you can go and write
> your dream language in, just get off the pot.
You miss the point. I can't use CL because it is perceived by my peers to
be a dead language.
And if you don't like my "nitpicking" no one is forcing you to read my posts.
E.
"Erann Gat" <···@jpl.nasa.gov> wrote in message ·························@192.168.1.51...
> > Then just leave Erann, your negative and nitpicking attitude is wearing
> > very thin. You have CL, you have a language you can go and write
> > your dream language in, just get off the pot.
>
> You miss the point. I can't use CL because it is perceived by my peers to
> be a dead language.
>
> And if you don't like my "nitpicking" no one is forcing you to read my posts.
I hardly read them already, I just tune in once in a while to see if anything
new is happening. Well, its not, you are still being a victim. Your last
advice is OK, I will forgo reading your posts even more, just like your
colleagues seem to have stopped listening to you at work.
Wade
In article <···············@shell01.TheWorld.com>,
Kent M Pitman <······@world.std.com> wrote:
> The real question is only whether the
> designers/implementors will be stubborn and say "I know what you want but
> for your own good I will not give it to you". We haven't done that, and
> I think that's good.
>
> We _did_ do that for dynamic functions, but we were not denying a capability,
> only a syntax. You can criticize that, as Pascal Costanza has recently
> done. I hope he is appeased in finding that it's only syntax and not
> semantics that are missing.
I am puzzled that you still say that I have criticized anything wrt
dynamic functions. I haven't. To the contrary - I was excited that I
could implement "aspect-oriented dynamic functions" in 25 lines code in
the original (unpublished) version, and I clearly state this in my paper
as an advantage of Common Lisp.
Wrt appeasement: Schemers could say the same thing about dynamically
scoped variables. But that's not the point.
I guess it was probably much clearer what to use dynamic variables for
than in the case of dynamic functions when they were standardized. The
real point of my paper is neither that the concept of dynamic functions
exist, nor how easy or hard it is to implement it (that's only a
sidenote wrt the workshop that it is submitted to), nor even that people
have already used it in one way or the other. The real point is the
connection to the stuff the AOP community is doing, and that the
discovery of this connection might lead to a better understanding of
both AOP and the uses of dynamically scoped functions. (For example, one
could start to reread all the papers on AOP and try to relate it to DSF,
and this could perhaps lead to new insights.)
In this context it's really important that DSF have also something like
call-next-function - this is the bit that turns DSF into a full AOP
construct. Again, the point is neither whether this existed before, nor
that it is trivial to implement, nor whether people have already used it
without knowing that they do something AOPish.
More often than not, progress is just made by finding good names for
common patterns, not only by inventing something spectacularly new. And
this is where ANSI CL really shines. [1]
Pascal
[1] As a sidenote, that's what the whole design patterns idea is
actually about. Design patterns are not about doing complicated stuff in
inferior languages, but it's about finding good names for common, well,
patterns. In Lisp you can even turn them into first-class language
constructs...
Pascal Costanza <········@web.de> writes:
> I am puzzled that you still say that I have criticized anything wrt
> dynamic functions.
Sorry. I hate mischaracterizing others' opinions, so I apologize if I
did that. If I recall, you began by asking about us having abandoned
them, etc. I think I took that as critical, but I see I missed your spin.
> I haven't. To the contrary - I was excited that I
> could implement "aspect-oriented dynamic functions" in 25 lines code in
> the original (unpublished) version, and I clearly state this in my paper
> as an advantage of Common Lisp.
Good.
> More often than not, progress is just made by finding good names for
> common patterns, not only by inventing something spectacularly new. And
> this is where ANSI CL really shines. [1] [...]
> [1] As a sidenote, that's what the whole design patterns idea is
> actually about. Design patterns are not about doing complicated stuff in
> inferior languages, but it's about finding good names for common, well,
> patterns. In Lisp you can even turn them into first-class language
> constructs...
I agree.
In article <···············@shell01.TheWorld.com>,
Kent M Pitman <······@world.std.com> wrote:
> > I am puzzled that you still say that I have criticized anything wrt
> > dynamic functions.
>
> Sorry. I hate mischaracterizing others' opinions, so I apologize if I
> did that. If I recall, you began by asking about us having abandoned
> them, etc. I think I took that as critical, but I see I missed your spin.
Apology accepted.
Pascal
From: Nils Goesche
Subject: Re: MAKUNBOUND and nested bindings?
Date:
Message-ID: <ly1xzc6idt.fsf@cartan.de>
···@jpl.nasa.gov (Erann Gat) writes:
> In article <···············@shell01.TheWorld.com>, Kent M Pitman
> <······@world.std.com> wrote:
>
> > Peter Seibel <·····@javamonkey.com> writes:
> >
> > > I was trying to puzzle out why MAKUNBOUND removes the value from
> > > the current dynamic binding rather than completely removing the
> > > binding, allowing an earlier binding to "show through"[1].
> >
> > Because dynamic bindings are not multiple bindings.
>
> This is apparently at odds with what the spec says, and you do
> newcomers a grave disservice by saying this without explaining
> exactly why what you are telling them is at odds with the spec.
...
> I reiterate my position that special variables are a horrible design
> for dynamic binding because they are perennially and hopelessly
> confusing to newcomers.
I don't think special variables are so confusing for newcomers. They
are also very easy to use, which indicates that the design is probably
quite right. Following the discussions on comp.lang.lisp I am getting
the impression that the only ones who regularly get majorly confused
by special variables are wizards trying to explain them :-)
Most people here know what special variables do, how they work and how
they are implemented. But there are lots of incompatible ways of
explaining them. What is a variable? What is a binding? What is an
environment? These are quite established and well-defined terms in
abstract programming language semantics, but there are several,
slightly different ways of using them to describe Lisp's semantics.
Everybody has his own abstract model of Lisp's semantics, sometimes
more, sometimes less complete. As the languages these models describe
are (hopefully) all ``isomorphic��, it doesn't really matter which
model you use; there is no definite True Way of abstractly modelling
Lisp.
And things get even more complicated because of the particular
blurriness between code and data. When we talk about a piece of Lisp
data which represents Lisp code, and we use terms like ``variable��
and ``environment��, we are talking on a very abstract, high level
about the semantic meaning of the code. That the code is represented
by Lisp data is rather insignificant. If somebody all of a sudden
brings MAKUNBOUND into the discussion, however, all those abstract
notions and interpretations lose their meaning. Suddenly we are
thinking about a symbol not as a form, a variable that is textually
represented by the symbol, but as a physical piece of Lisp data which
is about to be physically manipulated. This will have certain
consequences even on the higher, semantic levels, of course, but only
somewhat ``after the fact�� -- we violently remove the symbol's value,
then we rub our eyes and try to figure out what the consequences for
our environments and the subsequent code are, and whether we can
describe what just happened in abstract, mathematical, semantic
terms. If anyone cares about those, that is. Any such explanation,
such interpretation in semantic terms will look artificial and weird,
because MAKUNBOUND lives in a much lower level and probably was never
intended to make much sense in high, semantic ivory towers.
I love this, and I don't think it's horrible at all :-)
Regards,
--
Nils G�sche
"Don't ask for whom the <CTRL-G> tolls."
PGP key ID 0x0655CFA0
In article <··············@cartan.de>, Nils Goesche <······@cartan.de> wrote:
> ···@jpl.nasa.gov (Erann Gat) writes:
>
> > In article <···············@shell01.TheWorld.com>, Kent M Pitman
> > <······@world.std.com> wrote:
> >
> > > Peter Seibel <·····@javamonkey.com> writes:
> > >
> > > > I was trying to puzzle out why MAKUNBOUND removes the value from
> > > > the current dynamic binding rather than completely removing the
> > > > binding, allowing an earlier binding to "show through"[1].
> > >
> > > Because dynamic bindings are not multiple bindings.
> >
> > This is apparently at odds with what the spec says, and you do
> > newcomers a grave disservice by saying this without explaining
> > exactly why what you are telling them is at odds with the spec.
>
> ...
>
> > I reiterate my position that special variables are a horrible design
> > for dynamic binding because they are perennially and hopelessly
> > confusing to newcomers.
>
> I don't think special variables are so confusing for newcomers.
The fact that this topic comes up regularly in this N.G. is prima facie
evidence that they are.
> Following the discussions on comp.lang.lisp I am getting
> the impression that the only ones who regularly get majorly confused
> by special variables are wizards trying to explain them :-)
That is small comfort to someone who wants the language to see more
widespread use.
> Most people here know what special variables do, how they work and how
> they are implemented.
Yes. My concern is not with them. My concern is how we as a community
present ourselves to newcomers.
> But there are lots of incompatible ways of
> explaining them. What is a variable? What is a binding? What is an
> environment? These are quite established and well-defined terms in
> abstract programming language semantics, but there are several,
> slightly different ways of using them to describe Lisp's semantics.
> Everybody has his own abstract model of Lisp's semantics, sometimes
> more, sometimes less complete. As the languages these models describe
> are (hopefully) all ``isomorphic��, it doesn't really matter which
> model you use; there is no definite True Way of abstractly modelling
> Lisp.
And I'm saying we should come up with one. The fact that we don't have a
coherent story to tell is hurting us.
> I love this, and I don't think it's horrible at all :-)
"Horribly confusing" is not the same as "horrible."
E.
Kent M Pitman <······@world.std.com> writes:
> MAKUNBOUND works on symbols, and symbols have a value cell, and
> dynamic bindings [in Maclisp and other old dialects from which CL
> culturally descends, in contrast to Interlisp and its spaghetti
> stack, from which CL does not descend] always use that cell.
Why did Interlisp use a spaghetti stack? From googling around, it
seems to be so that closures can capture the dynamic environment. Is
that correct?
Lars Brinkhoff <·········@nocrew.org> writes:
> Kent M Pitman <······@world.std.com> writes:
> > MAKUNBOUND works on symbols, and symbols have a value cell, and
> > dynamic bindings [in Maclisp and other old dialects from which CL
> > culturally descends, in contrast to Interlisp and its spaghetti
> > stack, from which CL does not descend] always use that cell.
>
> Why did Interlisp use a spaghetti stack? From googling around, it
> seems to be so that closures can capture the dynamic environment. Is
> that correct?
That's always been my assumption, too, but I never used it so I can't
say for sure.
Note that one of the early papers on Scheme by Steele is called
"Macaroni Is Better Than Spaghetti" [SIGPLAN Notices, v12, #8, August 1977,
says Ken Dickey in another post on this group 11 years ago]
and (if memory serves) talks about
lexical closures in the same metaphor. Probably (but this is beyond
the limit of my memory) he was contrasting them with the dynamic
closures that Interlisp offered.
According to a post by me only 4 years ago, ``It's on obscure paper
but was, I think, the original reference to doing the algol thing
"right" in lisp and was a foundational part of scheme's genesis, I
think.''
Kent M Pitman <······@world.std.com> writes:
> Peter Seibel <·····@javamonkey.com> writes:
>
> > I was trying to puzzle out why MAKUNBOUND removes the value from
> > the current dynamic binding rather than completely removing the
> > binding, allowing an earlier binding to "show through"[1].
>
> Because dynamic bindings are not multiple bindings.
I can say for sure that as a beginner, I was confused for some time
about this. Using the hyperspec and some books, at first I thought the
specials were like globals, but then:
(defvar *x* 'first) => *x*
*x* => FIRST
(let ((*x* 'second)) *x*) => SECOND
*x* => FIRST ; still
Here the let establishes a new binding with the same name, I could
understand that, after someone explained that the specials also uses
multiple bindings implemented in a stack-like way. But:
(symbol-value '*x*) => FIRST
(let ((*x* 'second)) (symbol-value '*x*)) => SECOND
(symbol-value '*x*)) => FIRST
There is only one symbol *x*, right? And then:
(let ((*x* 'second)) (setf *x* 'third) (symbol-value '*x*)) => THIRD
(symbol-value '*x*)) => FIRST
If you count out that there are no lexicals in the top level, and
ignore the effects of scope and extent, this looks quite like the same
behaviour as lexicals have to me. Today I learned that there are in
fact multiple places also for specials, but the difference is that the
new value is stored in the symbol's value cell, and the old value is
stacked/stashed away. This is very well, but it looks more like an
implementation issue, or a performance issue, and not really useful
for understanding how the specials behave as an abstraction.
Well, possibly, if you have a variable that is not proclaimed special,
only declared special somewhere, and then have a lexical binding that
hides it, you can still get hold of the value of the special binding
by symbol-value, like in:
(let ((x 3))
(declare (special x))
(let ((x 5))
(values x (symbol-value 'x)))) => 5 3
Because of my (hopefully now gone) confusion about this, and other
issues like this, I am grateful for the discussions of this type
initiated by Peter Seibel.
--
Hilsen
Johan Ur Riise
This is what truly distinguishes dynamic/specials from lexicals:
CL-USER 9 > (defvar *x* 'first)
*X*
CL-USER 10 > (defun foo () *x*)
FOO
CL-USER 11 > (let ((*x* 'second))
(foo))
SECOND
CL-USER 12 > *x*
FIRST
Johan Ur Riise wrote:
...
> (let ((*x* 'second)) (setf *x* 'third) (symbol-value '*x*)) => THIRD
> (symbol-value '*x*)) => FIRST
>
> If you count out that there are no lexicals in the top level, and
> ignore the effects of scope and extent, this looks quite like the same
> behaviour as lexicals have to me
...
Jeff Caldwell <·····@yahoo.com> writes:
> This is what truly distinguishes dynamic/specials from lexicals:
>
> CL-USER 9 > (defvar *x* 'first)
> *X*
>
> CL-USER 10 > (defun foo () *x*)
> FOO
>
> CL-USER 11 > (let ((*x* 'second))
> (foo))
> SECOND
>
> CL-USER 12 > *x*
> FIRST
>
>
>
> Johan Ur Riise wrote:
> ...
>
> > (let ((*x* 'second)) (setf *x* 'third) (symbol-value '*x*)) => THIRD
> > (symbol-value '*x*)) => FIRST
> >
> > If you count out that there are no lexicals in the top level, and
> > ignore the effects of scope and extent, this looks quite like the same
> > behaviour as lexicals have to me
I think the observation was that the property of special variables
saving and restoring their values looked a lot like the behavior of
lexical variables in nested scopes.
You can, for example, get the above behavior with lexical variables as
follows:
* (let ((x 'first))
(let ((x 'second))
(print x))
x)
SECOND
FIRST
*
To me, at least, this is the point of special variables, and what
makes them different from purely global variables. In other words,
globals are dangerous, because any random code can diddle with them
and wreak havoc. Lexicals are safer, but you can't use them to set
global parameters. Specials have the property of providing bindings
for any free variables that reference them, as well as automatically
saving and restoring values when you want that behavior. You don't
have to remember to do it yourself.
The fundamental difference between special and lexical variables is
that free variables when lexical get closed over their bindings while
free variables when special find their bindings on a (conceptual)
stack.
Here is my example that shows the fundamental difference between how
special and lexical variables work:
First, with special declarations:
* (let ((x 'first))
(declare (special x))
(flet ((foo () (print x)))
(foo)
(let ((x 'second))
(declare (special x)) ; Without this x is lexical here.
(foo))
(foo)
(values)))
FIRST
SECOND
FIRST
*
Second, without:
* (let ((x 'first))
(flet ((foo () (print x)))
(foo)
(let ((x 'second))
(foo))
(foo)
(values)))
; Note: Variable X defined but never used.
FIRST
FIRST
FIRST ;
*
CMU Lisp notes that the (let ((x 'second)) ...) in the second example
creates an unused variable. This illustrates lexical closures ---
foo's free variable will no longer take a new binding.
--
Fred Gilham ······@csl.sri.com
It is also well to note that there are probably not ten hand-grenades
in the entire philosophical community. -- John Lange
From: Christopher C. Stacy
Subject: Re: MAKUNBOUND and nested bindings?
Date:
Message-ID: <uk7d3nrxv.fsf@dtpq.com>
When I started learning MACLISP back in 1979, with a few years
of FORTRAN, BASIC, and APL (and "survey" exposure to a few other
languauges) under my belt, I thought that dynamic variables in Lisp
were really obvious and the right thing. I mention this here simply
so that the record will reflect that not every newbie is troubled by
this concept.
On Tue, 06 May 2003 00:00:33 GMT, Peter Seibel <·····@javamonkey.com>
wrote:
>I was trying to puzzle out why MAKUNBOUND removes the value from
>the current dynamic binding rather than completely removing the
>binding, allowing an earlier binding to "show through"[1].
>
>The best explanation I came up with
Another explanation could be to think of (MAKUNBOUND FOO) as
equivalent to
(SETQ FOO (the-unbound-object-that-causes-a-reference-error))
Since SETQ doesn't 'completely remove a binding', neither does
MAKUNBOUND.