In the form:
(let ((x 1))
(let ((x 2))
(let ((x 3))
(print x))
(print x))
(print x))
would you say there are three variables or one variable? (Or something
else?)
How about in this case:
(defvar *x*)
(let ((*x* 1))
(let ((*x* 2))
(let ((*x* 3))
(print *x*))
(print *x*))
(print *x*))
-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> wrote in message
···················@javamonkey.com...
> In the form:
>
> (let ((x 1))
> (let ((x 2))
> (let ((x 3))
> (print x)) ;; x=3
> (print x)) ;; x=2
> (print x)) ;; x=1
;; I think--I could be wrong.
>
> would you say there are three variables or one variable? (Or something
> else?)
>
> How about in this case:
>
> (defvar *x*)
>
> (let ((*x* 1))
> (let ((*x* 2))
> (let ((*x* 3))
> (print *x*))
> (print *x*))
> (print *x*))
Same thing. The local var redefines the global var.
Global vars. should not be used.
>
> -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
>
"Franz Kafka" <Symbolics _ XL1201 _ Sebek _ Budo _ Kafka @ hotmail . com>
wrote in message ·······················@news02.roc.ny.frontiernet.net...
>
> "Peter Seibel" <·····@javamonkey.com> wrote in message
> ···················@javamonkey.com...
> > (defvar *x*)
> >
> > (let ((*x* 1))
> > (let ((*x* 2))
> > (let ((*x* 3))
> > (print *x*))
> > (print *x*))
> > (print *x*))
> Same thing. The local var redefines the global var.
No it does not. There is no "local var". Each LET establishes a new
dynamic binding for *x*
> Global vars. should not be used.
Never say never.
--
Coby Beck
(remove #\Space "coby 101 @ bigpond . com")
> >
> > -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
> >
>
>
From: Tim Bradshaw
Subject: Re: How would you describe this?
Date:
Message-ID: <ey3u1c940od.fsf@cley.com>
* Peter Seibel wrote:
> In the form:
> (let ((x 1))
> (let ((x 2))
> (let ((x 3))
> (print x))
> (print x))
> (print x))
> would you say there are three variables or one variable? (Or something
> else?)
Three bindings of X
> (let ((*x* 1))
> (let ((*x* 2))
> (let ((*x* 3))
> (print *x*))
> (print *x*))
> (print *x*))
Three (presumably!) special bindings of *X*
--tim
Tim Bradshaw <···@cley.com> writes:
> * Peter Seibel wrote:
> > In the form:
> > (let ((x 1))
> > (let ((x 2))
> > (let ((x 3))
> > (print x))
> > (print x))
> > (print x))
>
> > would you say there are three variables or one variable? (Or something
> > else?)
>
> Three bindings of X
I thought you (or someone) might say that. So, given that there are
three bindings, how many variables would you say there are?
>
> > (let ((*x* 1))
> > (let ((*x* 2))
> > (let ((*x* 3))
> > (print *x*))
> > (print *x*))
> > (print *x*))
>
> Three (presumably!) special bindings of *X*
Presumably nothing; you snipped the DEFVAR I put in. ;-)
-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
From: Tim Bradshaw
Subject: Re: How would you describe this?
Date:
Message-ID: <ey31xzdf43n.fsf@cley.com>
* Peter Seibel wrote:
> I thought you (or someone) might say that. So, given that there are
> three bindings, how many variables would you say there are?
I wouldn't, because I really only talk (and think) about bindings, but
if pushed, I'd say 3 (but only one variable & binding are visible at
once).
> Presumably nothing; you snipped the DEFVAR I put in. ;-)
Oops.
+ Peter Seibel <·····@javamonkey.com>:
| I thought you (or someone) might say that. So, given that there are
| three bindings, how many variables would you say there are?
Look up "Variable" in the CLHS glossary and tell us what you think.
--
* Harald Hanche-Olsen <URL:http://www.math.ntnu.no/~hanche/>
- Debating gives most of us much more psychological satisfaction
than thinking does: but it deprives us of whatever chance there is
of getting closer to the truth. -- C.P. Snow
Harald Hanche-Olsen <······@math.ntnu.no> writes:
> + Peter Seibel <·····@javamonkey.com>:
>
> | I thought you (or someone) might say that. So, given that there are
> | three bindings, how many variables would you say there are?
>
> Look up "Variable" in the CLHS glossary and tell us what you think.
I did, before I posted my question. Based on the glossary entry, I'd
say there are three variables (and three bindings, as "variable" is
defined as "a binding"). But I've also observed that there's a fair
bit of confusion around these terms so I hoped to see how other folks
actually use them.
Along these same lines, does it bother anyone else that a "binding"
(and thus a "variable") is defined as "an association between a name
and that which the name denotes" yet the "bindings" created at runtime
for lexical variables have no names associated with them? I.e. when
the form:
(let ((x 10)) (print x))
is evaluated, I understand that most folks would say a new "binding"
is created to hold the value 10. But there is no name associated with
that "binding". There *was* a name associated with the source code
that caused the compiler to emit code that created a binding but I
wouldn't describe the "binding" that is created at runtime as "an
association between a name and that which the name denotes."
-Peter
P.S. For those of you who haven't seen my other disclaimers in this
and other recent, related threads, I'm only asking these annoying,
persnickety, pedantic questions because I'm writing about this stuff
for new Lisp programmers. I'm trying to find the best way to describe
things that gives my readers both a good mental model of various Lisp
concepts *and* a vocabulary for talking about Lisp that other Lispers
understand. I'd hate for one of my readers to post here, using the
vocabulary I've given them, and have them get flamed for using what
folks here consider established terminology incorrectly.
--
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
Just think of
> (let ((x 10)) (print x))
>
as being bound in the local lexical environment.
A Lexical closure makes sure that if you name your var x. or car,
cdr, or the name of an other function or var. used else ware it
will not get captured.
It is equiv. to a local var. in C,C++, or Pascal.
I think it is like saying
((lambda (x) (print x) 10)
Peter Seibel wrote:
> P.S. For those of you who haven't seen my other disclaimers in this
> and other recent, related threads, I'm only asking these annoying,
> persnickety, pedantic questions because I'm writing about this stuff
> for new Lisp programmers. I'm trying to find the best way to describe
> things that gives my readers both a good mental model of various Lisp
> concepts *and* a vocabulary for talking about Lisp that other Lispers
> understand.
Well, your intention is admirable (no condescension, really, it is
impressive to see the care you are taking with this excellent project),
but... only the Lisp priesthood can even understand the distinctions for
which you seek definition. Hey, it's your tutorial, but FWIW methinks
you have lost the way if you think this stuff matters to newbies. I went
for years very productively in CL before running into the surprising
behavior of specials, and years more before someone turned me on to
their power.
I am reminded of the New Math, which tried to solve the problem of
teaching math effectively by introducing up front the theoretical
foundations of math. To six year olds. One example was that 3/2 and 1.5
were different numerals for the same number.
un-hunh. Is it nap time yet?
--
kenny tilton
clinisys, inc
http://www.tilton-technology.com/
---------------------------------------------------------------
"Everything is a cell." -- Alan Kay
Kenny Tilton <·······@nyc.rr.com> writes:
> I am reminded of the New Math, which tried to solve the problem of
> teaching math effectively by introducing up front the theoretical
> foundations of math. To six year olds. One example was that 3/2 and
> 1.5 were different numerals for the same number.
Heh. I used to get so bored in math that I'd exploit the new math to
keep me awake in just the way you describe. Consider this long division,
which was the sort of thing I'd pull and that my probably-equally-bored
teacher was both intelligent and lenient enough to tolerate:
9 -1 == 9(-1) == 90 - 1 == 89
+---------
7 | 6 2 3
- 6 3
-----
-1 3 == (-1)3 = -10 + 3 == -7 --+
|
-7 <--------------------------+
- -7
-------
0
But mostly I agree with you that these things are the kind of things
that smart people will probably find out about on their own anyway, and
do not necessarily do anything more than confuse students. Indeed, if
the instructor doesn't understand the new math enough to be prepared for
people to really use it (e.g., as above), it compounds the problem because
it adds just enough rope for the student to get into trouble without
verifying that the teacher will be able to rescue them.
Lisp itself is often accused of offering too many options--too many
different ways to write things. For some, that's a criticism of the
language, but I think the language intends to be that way, and that
it's a double-edged issue. The presence of many options doesn't mean
every programming style has to use them all or that every teaching
text needs to mention them all.
Lisp tends to attract good programmers, and those programmers are
characterized by self-discipline, so they mostly don't run into that,
or else they get past it. But I think a larger community can and
should be reached by giving narrower instructions to students--telling
them to do things a certain way rather than offering them really
super-general tools. Because this will leave things out, there will be
disputes about which things should be left out. But that's ok--let the
teaching texts compete on the goodness of what they include/exclude... or
let them show that there are multiple 'good' ways of doing it.
As to super-generality, there's an enabling power in Scheme's SICP
approach, but only if you're capable of taking it in. Even recursion
is dicey for a lot of people, even though those same people can
understand simple iteration just fine. And I have a real problem with
people trying to force alternate ways of thinking on people who aren't
asking for it. I have no problem at all with teaching texts that are
narrow and prescriptive of a conservative style, just as you (Kenny)
suggest. Let people seek advanced texts if they want alternate ways
of thinking... including any kind of calculus of 'bindings' or other
meta-objects or whatever...
One more aside, only because it vaguely relates, and it's rare for a
forum to come up where I might mention this: When I got to 8th grade,
they were teaching us some sort of sentence analysis stuff call
"morpheme trees" (we were learning the Roberts English Series then,
but the Oregon English Series had the same bizarre approach). I
quickly scanned the textbook and decided I didn't like it. I went to
my teacher and explained that I thought this analysis was probably
primarily useful to linguists, since it could decode language but it
couldn't be used in the other direction to encode valid sentences. (It
would too easily produce non-sentences.) Since I felt most people
were not destined to be linguists, it seemed to be an inappropriate
path to be trying to pretend they were. I offered to let her use my
5th grade notes on "sentence diagramming", which I alleged was better
able to do composition as well as decomposition. Weirdly enough, she
decided I was right and she taught from my diagramming notes for the
rest of the year. (I have to assume it wasn't just on my suggestion
alone that made the difference; she probably hated this new stuff,
too, and was looking for an excuse not to use it.) But anyway, it was
a case of preferring something that catered to the mainstream student,
and I think it was a good choice. It's an unnecessary luxury and/or
pain (depending on your point of view) to assume everyone would have
been happier with the linguists'-eye-view of stuff, and it's just selfish
of the minority to impose it on the majority. It doesn't mean one or
the other of these is a "better formulation" -- but it does suggest
that one or the other is "better for a given purpose".
In article <···············@shell01.TheWorld.com>,
Kent M Pitman <······@world.std.com> wrote:
> SNIP
>As to super-generality, there's an enabling power in Scheme's SICP
What is SICP an acronym for? And, if not obvious from
that, what does it *mean*, ie, what *is* that approach?
>approach, but only if you're capable of taking it in. Even recursion
>is dicey for a lot of people, even though those same people can
>understand simple iteration just fine. And I have a real problem with
>people trying to force alternate ways of thinking on people who aren't
>asking for it.
Scheme again: it seems like *all* scheme "true believers", at
least those who write books or teach classes, *demand* that
you understand continuations as "the rest of the program-execution".
To this day, I have never understood that -- *way* too abstract
for me, almost sounding like some religious issue, eg the "trinity"
or some such.
Perhaps if they'd describe how it actually *worked*, how you'd
*implement* it, with a few state, stack, and heap diagrams,
and how they changed through the usage of the thing --
then maybe *I* could understand it.
What always surprised me was that no one else seemed
to have any difficulty with the "rest of execution" concept;
what's that, left side, right side, or maybe for me, no
side at all?
Anyway, we sure cannot all understand the same way, via the
same metaphors.
>I have no problem at all with teaching texts that are
>narrow and prescriptive of a conservative style, just as you (Kenny)
>suggest. Let people seek advanced texts if they want alternate ways
>of thinking... including any kind of calculus of 'bindings' or other
>meta-objects or whatever...
>
>One more aside, only because it vaguely relates, and it's rare for a
>forum to come up where I might mention this: When I got to 8th grade,
>they were teaching us some sort of sentence analysis stuff call
>"morpheme trees" (we were learning the Roberts English Series then,
>but the Oregon English Series had the same bizarre approach). I
>quickly scanned the textbook and decided I didn't like it. I went to
>my teacher and explained that I thought this analysis was probably
>primarily useful to linguists, since it could decode language but it
>couldn't be used in the other direction to encode valid sentences. (It
>would too easily produce non-sentences.) Since I felt most people
>were not destined to be linguists, it seemed to be an inappropriate
>path to be trying to pretend they were. I offered to let her use my
>5th grade notes on "sentence diagramming", which I alleged was better
>able to do composition as well as decomposition. Weirdly enough, she
Bright kid, this Pitman!
Now, why doesn't *he* write a lisp book or two, not just
about lisp syntax, etc, but also with lots of examples
from his own work, bugs he had and tracked-down and fixed,
and how he did that, and problems where he wasted good time
choosing the wrong path, and how he finally realized that,
and how he figured out a cleaner approach.
So as to provide the reader with a vicarious path through
his own thinking, giving the reader, from merely reading
the book, some almost-real "actual experience".
Being that none of us are getting any younger, he'd better
get started ASAP.
------
What a contribution that would be!
>decided I was right and she taught from my diagramming notes for the
>rest of the year. (I have to assume it wasn't just on my suggestion
>alone that made the difference; she probably hated this new stuff,
>too, and was looking for an excuse not to use it.) But anyway, it was
>a case of preferring something that catered to the mainstream student,
>and I think it was a good choice. It's an unnecessary luxury and/or
>pain (depending on your point of view) to assume everyone would have
>been happier with the linguists'-eye-view of stuff, and it's just selfish
>of the minority to impose it on the majority. It doesn't mean one or
>the other of these is a "better formulation" -- but it does suggest
>that one or the other is "better for a given purpose".
David Combs
·······@panix.com (David Combs) writes:
> To this day, I have never understood that -- *way* too abstract
> for me, almost sounding like some religious issue, eg the "trinity"
> or some such.
>
> Perhaps if they'd describe how it actually *worked*, how you'd
> *implement* it, with a few state, stack, and heap diagrams,
> and how they changed through the usage of the thing --
> then maybe *I* could understand it.
Well, leaving aside implementation and programming style issues, it's
a simple concept that perhaps we can get across just for the sake of
discussion. Just because we don't have the operators doesn't mean it
isn't useful terminology.
And, moreover, it is precisely what you just said. :) So let me restate
what you said in case it helps you get it.
When you perform an operation, there is a thing you plan to do next with
the resulting value (or, more generally, the resulting program state, but
for simplicity of explanation consider the program to be pure functional,
so that the resulting state is just "a value is now available").
So when you do (f (g x) (h x)) you're really saying ``compute (g x) and
then there will be "something to do next", then compute (h x) and there
will again be "something to do next", and so on.'' The traditional
formulation is in terms of a stack machine as in:
push x on stack
call g
put result on stack
push x on stack
call h
put result on stack
call f
The act of doing what's next is the act of popping stack in a stack
machine, since the stack contains information about pending operations.
But the stack can only be unwound once. And the stack is not a real
data structure in Lisp so it's hard to talk about in terms that we're
used to.
A continuation, then, is just a functional rendition of the same concept,
A projection of the stack into terms that are meaningful as data
structure in Lisp, independent of implementation. The continuation model
says that in the above, what you plan to do when you compute (g x)
is functionally described by
(lambda (g-result) (f g-result (h x)))
and what you plan to do when you've computed (h x) is functionally
described by
(lambda (val) (f g-result val))
where this is a closure over the g-result computed earlier, and so on.
Note that in some sense, though, I've oversimplified because in Lisp
if I type
Lisp> (+ (* 3 4) 5)
the continuation of the (* 3 4) is not just (lambda (val) (+ val 5))
but is in fact
(lambda (val)
(print (+ val 5))
(repl))
That is, I'm going to print the result of doing the computation and I'm
going to continue the read-eval-print loop. A continuation, then,
represents the whole "pending program state".
Scheme allows you to insert an actual operator that obtains this function
at any given point, since it can be dynamically computed. This is about
the same as copying the stack so that, if you wanted, you could return
more than once. (This gets into immediate philosophical questions about
how overpowerful this is.)
I gotta say I really dislike the formulation they chose, and prefer the
older form. What they now write as:
(call-with-current-continuation
(lambda (my-continuation) ...))
used to be, long ago,
(catch my-continuation
...)
where catch [sometimes called "full catch", to distinguish it from Lisp's
catch, which unwinds the stack and can only be used once] gave you a
functional value in my-continuation such that if you called it, it did a
throw-like thing, but you could save it and call it more than once. so
(print (catch my-continuation
(+ 3 (my-continuation (* 4 5)))))
would print 20. I find this somehow easier to read than
(print (call-with-current-continuation
(lambda (my-continuation)
(+ 3 (my-continuation (* 4 5))))))
[Note, too, that in Lisp2 style, if it helps, this is
(print (call-with-current-continuation
(lambda (my-continuation)
(+ 3 (FUNCALL my-continuation (* 4 5))))))
That is, my-continuation is just a variable, not a function name.]
But you can pick your poison, since you can always make a macro.
If you wanted to define THROW, you'd do
(define (throw x y) (x y))
in Scheme notation or
(defun throw (escape-function value)
(funcall escape-function value))
in CL notation.
I'm going to use THROW here, in caps, just to emphasize the fact of
the function call to an escape procedure because that's easier for
our community to read, and I'm writing to our community here. (But
these are just functions and don't have to be THROWn, they CAN just
be called.)
Anyway, the real point is that you can do all kinds of crazy things
with continuations like:
(let ((do-it (CATCH escape
(print (CATCH ready-to-print
(THROW escape ready-to-print))))))
(do-it 1)
(do-it 2))
and you'll see 1 and 2 get printed because it will effecively
return from the ready-to-print catch tag twice.
In modern Scheme you'd write that expression more like:
(let ((do-it (call-with-current-continuation
(lambda (escape)
(print (call-with-current-continuation
(lambda (ready-to-print)
(escape ready-to-print))))))))
(do-it 1)
(do-it 2))
which I find utterly opaque personally. I can see wanting to expose
the implementation for some initial explanation purposes, but I can't
see wanting to slug through it day in and day out.
This extremely powerful (some say overpowerful, in the same sense as GO
is overpowerful for its lack of structure) operator can be used to
implement things like backtracking, coroutining, etc.
> What always surprised me was that no one else seemed
> to have any difficulty with the "rest of execution" concept;
> what's that, left side, right side, or maybe for me, no
> side at all?
>
> Anyway, we sure cannot all understand the same way, via the
> same metaphors.
I hope the above helps as a brief intro tot he issues.
If not, please feel free to highlight the point at which I lost you.
Please also say which notation you prefer.
Kent M Pitman <······@world.std.com> writes:
> (let ((do-it (CATCH escape
> (print (CATCH ready-to-print
> (THROW escape ready-to-print))))))
> (do-it 1)
> (do-it 2))
(do-it 2) will not be reached: (do-it 1) jumps back to the
beginning, and do-it is then bound to whatever print returns,
which likely causes an error when (do-it 1) is evaluated again.
I tried to write a working version but it seemed to need
lambdas, and then it felt rather pointless to involve
continuations in that at all.
Kalle Olavi Niemitalo <···@iki.fi> writes:
> Kent M Pitman <······@world.std.com> writes:
>
> > (let ((do-it (CATCH escape
> > (print (CATCH ready-to-print
> > (THROW escape ready-to-print))))))
> > (do-it 1)
> > (do-it 2))
>
> (do-it 2) will not be reached: (do-it 1) jumps back to the
> beginning, and do-it is then bound to whatever print returns,
> which likely causes an error when (do-it 1) is evaluated again.
>
> I tried to write a working version but it seemed to need
> lambdas, and then it felt rather pointless to involve
> continuations in that at all.
Oh, you're right of course. I knew I had too few conditionals in there.
They usually do this with conditionals, by setting up do-it only if it's
not already set up. Bleah. Well, chalk this up to why I think it's a
wholly bizarre way to program. Maybe it's more like
(let ((i 0) (do-it nil))
(let ((temp (CATCH escape
(print (CATCH ready-to-print
(THROW escape ready-to-print))))))
(unless do-it (setq do-it temp))
(unless (> i 2) (do-it (incf i)))))
I think this should print 1 then print 2 then finally exit. You can
tell I don't have a Scheme in front of me to just try this. Anyway,
assuming I'm even close to right, this gives me a chance to illustrate
the general shape of backtracking and/or iteration, sort of...
Thanks so much for your probably-unique explanation of
continuations!
Maybe you'd want to post it to some scheme newsgroup,
as well as sending it, as "what do you think of this
way of explaining it", to those SICP authors and other
scheme-beleiving cs-professors.
Ditto for the other explanations.
---
Is anything but simple; give me some time to
digest it a bit, and I'll come back with some
questions.
Thanks much to you and all other participants!
David
David Combs wrote:
>>As to super-generality, there's an enabling power in Scheme's SICP
>
>
> What is SICP an acronym for? And, if not obvious from
> that, what does it *mean*, ie, what *is* that approach?
It's one of the classics and it's online:
<http://mitpress.mit.edu/sicp/full-text/book/book.html>
>>approach, but only if you're capable of taking it in. Even recursion
>>is dicey for a lot of people, even though those same people can
>>understand simple iteration just fine. And I have a real problem with
>>people trying to force alternate ways of thinking on people who aren't
>>asking for it.
>
>
> Scheme again: it seems like *all* scheme "true believers", at
> least those who write books or teach classes, *demand* that
> you understand continuations as "the rest of the program-execution".
>
> To this day, I have never understood that -- *way* too abstract
> for me, almost sounding like some religious issue, eg the "trinity"
> or some such.
>
> Perhaps if they'd describe how it actually *worked*, how you'd
> *implement* it, with a few state, stack, and heap diagrams,
> and how they changed through the usage of the thing --
> then maybe *I* could understand it.
You don't need to understand continuations. You need to be able
to recognize an iterative computation (called linear recursion)
in book. And that's not hard.
<http://mitpress.mit.edu/sicp/full-text/book/book-Z-H-11.html#%_sec_1.2.1>
Then see chapter 4 and 5 to see how to implement a simple interpreter
and a compiler:
<http://mitpress.mit.edu/sicp/full-text/book/book-Z-H-25.html#%_chap_4>
<http://mitpress.mit.edu/sicp/full-text/book/book-Z-H-30.html#%_chap_5>
Oh - the garbage collection discussion reminds of this footnote:
This may not be true eventually, because memories may get large enough
so that it would be impossible to run out of free memory in the
lifetime of the computer. For example, there are about 3� 1013,
microseconds in a year, so if we were to cons once per microsecond we
would need about 1015 cells of memory to build a machine that could
operate for 30 years without running out of memory. That much memory
seems absurdly large by today's standards, but it is not physically
impossible. On the other hand, processors are getting faster and a
future computer may have large numbers of processors operating in
parallel on a single memory, so it may be possible to use up memory
much faster than we have postulated.
--
Jens Axel S�gaard
From: Joe Marshall
Subject: Re: How would you describe this?
Date:
Message-ID: <he738dvb.fsf@ccs.neu.edu>
Jens Axel S�gaard <······@jasoegaard.dk> writes:
> Oh - the garbage collection discussion reminds of this footnote:
>
> This may not be true eventually, because memories may get large enough
> so that it would be impossible to run out of free memory in the
> lifetime of the computer. For example, there are about 3� 10^13,
> microseconds in a year, so if we were to cons once per microsecond we
> would need about 10^15 cells of memory to build a machine that could
> operate for 30 years without running out of memory. That much memory
> seems absurdly large by today's standards, but it is not physically
> impossible. On the other hand, processors are getting faster and a
> future computer may have large numbers of processors operating in
> parallel on a single memory, so it may be possible to use up memory
> much faster than we have postulated.
These days, 1 microsecond is a long time. Somewhere on the order of
50 ns would be more like it, so your machine would run out of RAM in a
year and a half.
Joe Marshall <···@ccs.neu.edu> writes:
> Jens Axel S�gaard <······@jasoegaard.dk> writes:
>
> > Oh - the garbage collection discussion reminds of this footnote:
> >
> > This may not be true eventually, because memories may get large
> > enough so that it would be impossible to run out of free memory
> > in the lifetime of the computer. For example, there are about
> > 3� 10^13, microseconds in a year, so if we were to cons once
> > per microsecond we would need about 10^15 cells of memory to
> > build a machine that could operate for 30 years without running
> > out of memory. That much memory seems absurdly large by
> > today's standards, but it is not physically impossible. On the
> > other hand, processors are getting faster and a future computer
> > may have large numbers of processors operating in parallel on a
> > single memory, so it may be possible to use up memory much
> > faster than we have postulated.
>
> These days, 1 microsecond is a long time. Somewhere on the order of
> 50 ns would be more like it, so your machine would run out of RAM in a
> year and a half.
Depends on what OS you use. With Microsoft's patented `bluescreen gc,'
serious amounts of memory are quite efficiently freed at intervals
much more frequent than a year and a half apart, so that you might
actually never find that 'running out of memory' is a problem you have
to confront. ;)
Incidentally, speaking of MTBF, while Lisp Machines were often run for
many months without needing to boot, it was common to voluntarily boot
them more often because another user was going to take it over. As a
consequence of the short usage time, there were people who (especially
in the early days, before the GC had been heavily tuned) just disabled
the GC entirely (immediately getting twice the usable memory in
exchange for having done so) and just ran the risk of running out of
space. I seem to recall that one could run somewhere between a few
hours and a few days this way, depending on what you were doing.
Also, while the normal incremental GC needed 50% of memory to
implement an oldspace/newspace division, there was later added (on
Symbolics machines anyway) an "Immediate" GC that could stop all
processes for a time in order to have total control of the machine and
I think it needed only 10-15% of memory to do this, so if you decided
you'd made a horrible error by running without the incremental GC, it
was possible in some cases to rescue yourself, at the cost of losing
total control of your machine for sometimes an hour or two.
Re: Lisp Machine GC.
I also recall some people at the lab essentially implementing their own
version of a stop and copy GC: They would save the state of their
computation to disk and reboot the machine. It turned out that for them
writing the file and rebooting was significantly faster than running a
full Lispm GC.
--
Thomas A. Russ, USC/Information Sciences Institute ···@isi.edu
In article <················@nyc.rr.com>,
Kenny Tilton <·······@nyc.rr.com> wrote:
>Peter Seibel wrote:
>> P.S. For those of you who haven't seen my other disclaimers in this
>> and other recent, related threads, I'm only asking these annoying,
>> persnickety, pedantic questions because I'm writing about this stuff
>> for new Lisp programmers. I'm trying to find the best way to describe
>> things that gives my readers both a good mental model of various Lisp
>> concepts *and* a vocabulary for talking about Lisp that other Lispers
>> understand.
>
Re the vocabulary. Rather, the *wrong* vocabulary.
Perl has created its own vocabulary, sometimes using the
same words that are used in either C or CL, but where
they mean different things.
For instance, perl's "local" is either similar or perhaps
identical to CL's "special" (dynamically bound), and for the
opposite concept, where other languages might use "local" (routine
r1, with locally-declared variable locA, calls either itself or
some other routine, r2, also with its own local locA -- those
two locA variables, while on the stack, are totally unrelated) --
well, perl's naming of "local" seems a bit unfortunate.
Why? Because the Perl-learner cannot go a standard computer-sci
or C or CL text and look up even the concept of "local" and
have that provide any understanding directly transferable to perl.
These days, they're designing a totally new (and incompatible)
"perl", and you'd think this would be the time to rename some
of their concepts such that they match terminology commonly
used throughout computer science.
So that someone could learn a concept from eg lisp or
haskell or whatever, and to the extent that the same
concept existed in the new perl, it would have the
same name. Right? Wrong!
Like what you'd call dynamic ("special" wasn't such a
great choice, was it, the word itself giving you
not a hint about its meaning, use, or operation),
last I heard, they are still going to call "local".
Arrrrgh!
David
How many variables here? How many bindings?
(let ((x 1))
(let ((x x))
(let ((x x))
x)))
>>* Peter Seibel wrote:
>>
>>>In the form:
>>> (let ((x 1))
>>> (let ((x 2))
>>> (let ((x 3))
>>> (print x))
>>> (print x))
>>> (print x))
>>
>>>would you say there are three variables or one variable? (Or something
>>>else?)
Jeff Caldwell <·····@yahoo.com> writes:
> How many variables here? How many bindings?
>
> (let ((x 1))
> (let ((x x))
> (let ((x x))
> x)))
I'd say three each (since they're the same thing, per the CLHS
glossary). If I were going to stray from the definitions in the
glossary, I'd be inclined to say that there are three variables and
(* 3 the-number-of-times-this-form-is-evaluated)
bindings. (This is also what I'd say about my original form too, so if
you'd say different things about the two versions, I'd be interested
to hear about it.)
-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
"3.1.1 Introduction to Environments
A binding is an association between a name and that which the name
denotes."
That text seems to me to say that there are three things: 1) a name, 2)
that which the name denotes, and 3) the binding which associates them.
It seems to me that in 198 below there are:
. three bindings from names x, y, and z
. to one variable, the foo instance
I don't see an argument that there is more than one variable since one
setf changed the evaluation of three names. Since a binding is an
association between a name and that which is denoted by the name, and
since there are three names, I think there are three bindings.
I have also, perhaps mistakenly (perhaps mistakenly in all of this),
considered non-dynamic bindings more of a compile-phase concept and less
of a run-phase concept. To the extent that is true, the lexical bindings
are not recreated each time the form is executed (but perhaps are
recreated every time the form is compiled or interpreted? -- not that it
matters).
In 198 below, my thinking is that the bindings are implemented by use of
a reference. Bindings are more of a design concept than an
implementation structure if that is a correct way of thinking. A binding
to a simple object might be realized entirely within registers, for example.
I welcome further insights or explanations and corrections.
Jeff
CL-USER 196 > (defstruct foo bar baz quux)
FOO
CL-USER 197 > (setq qaax (make-foo))
#S(FOO BAR NIL BAZ NIL QUUX NIL)
CL-USER 198 > (let ((x qaax))
(let ((y x))
(let ((z y))
(setf (foo-bar z) 'qiix)
(list x y z))))
(#S(FOO BAR QIIX BAZ NIL QUUX NIL)
#S(FOO BAR QIIX BAZ NIL QUUX NIL)
#S(FOO BAR QIIX BAZ NIL QUUX NIL))
Peter Seibel wrote:
> Jeff Caldwell <·····@yahoo.com> writes:
>
>
>>How many variables here? How many bindings?
>>
>>(let ((x 1))
>> (let ((x x))
>> (let ((x x))
>> x)))
>
>
> I'd say three each (since they're the same thing, per the CLHS
> glossary). If I were going to stray from the definitions in the
> glossary, I'd be inclined to say that there are three variables and
>
> (* 3 the-number-of-times-this-form-is-evaluated)
>
> bindings. (This is also what I'd say about my original form too, so if
> you'd say different things about the two versions, I'd be interested
> to hear about it.)
>
> -Peter
>
Jeff Caldwell <·····@yahoo.com> writes:
> "3.1.1 Introduction to Environments
> A binding is an association between a name and that which the name
> denotes."
>
>
> That text seems to me to say that there are three things: 1) a name,
> 2) that which the name denotes, and 3) the binding which associates
> them.
>
>
> It seems to me that in 198 below there are:
>
> . three bindings from names x, y, and z
> . to one variable, the foo instance
> I don't see an argument that there is more than one variable since
> one setf changed the evaluation of three names. Since a binding is
> an association between a name and that which is denoted by the name,
> and since there are three names, I think there are three bindings.
Well, that ignores the glossary entry for variable:
variable n. a binding in the ``variable'' namespace. See Section
3.1.2.1.1 (Symbols as Forms).
If a variable *is* a binding, I'm not sure how there can be more
bindings than variables (assuming none of the bindings in question are
some other type of binding altogether such as function bindings.)
I'd say there are three bindings, thus three variables, and one
*object*, the foo instance. That the variables/bindings happen to all
be refering to the same object doesn't say anything to me about how
many there are.
> I have also, perhaps mistakenly (perhaps mistakenly in all of this),
> considered non-dynamic bindings more of a compile-phase concept and
> less of a run-phase concept. To the extent that is true, the lexical
> bindings are not recreated each time the form is executed (but perhaps
> are recreated every time the form is compiled or interpreted? -- not
> that it matters).
Well, there's *something* that gets created at run time--the thing
that gets captured in a closure:
(defun make-counter ()
(let ((n 0))
#'(lambda () (incf n))))
I think the standard terminology would say that each time make-counter
is called, a new binding for n is created and captured in the returned
closure. But if I was sure about this I wouldn't have started this
thread.
>
> CL-USER 196 > (defstruct foo bar baz quux)
> FOO
>
> CL-USER 197 > (setq qaax (make-foo))
> #S(FOO BAR NIL BAZ NIL QUUX NIL)
>
> CL-USER 198 > (let ((x qaax))
> (let ((y x))
> (let ((z y))
> (setf (foo-bar z) 'qiix)
> (list x y z))))
> (#S(FOO BAR QIIX BAZ NIL QUUX NIL)
> #S(FOO BAR QIIX BAZ NIL QUUX NIL)
> #S(FOO BAR QIIX BAZ NIL QUUX NIL))
>
-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:
> Jeff Caldwell <·····@yahoo.com> writes:
>
> > How many variables here? How many bindings?
> >
> > (let ((x 1))
> > (let ((x x))
> > (let ((x x))
;;;-------------------------
> > x)))
>
> I'd say three each (since they're the same thing, per the CLHS
> glossary). If I were going to stray from the definitions in the
> glossary, I'd be inclined to say that there are three variables and
>
> (* 3 the-number-of-times-this-form-is-evaluated)
>
> bindings. (This is also what I'd say about my original form too, so if
> you'd say different things about the two versions, I'd be interested
> to hear about it.)
I would say that, at the line, there are three bindings, hence three
variables, connecting the name x to three different places. The
places denotes the same object (the FIXNUM 1, except in this special
case, where the object is a fixnum, it would possibly be stored
directly in the places as three different objects). Had it been
another object, like a cons, there would be only one object.
Additionally, there is only one symbol x, but that symbol is only used
by the reader to name the bindings, otherwise it is not involved.
Also, thanks for trying to clear up these things, I think it is useful.
--
Hilsen
Johan Ur Riise
Peter Seibel <·····@javamonkey.com> writes:
> In the form:
>
> (let ((x 1))
> (let ((x 2))
> (let ((x 3))
> (print x))
> (print x))
> (print x))
>
> would you say there are three variables or one variable? (Or something
> else?)
Three variables. Because they're all named X, they can't all be
visible at the same moment, but they're all different variables.
> How about in this case:
>
> (defvar *x*)
>
> (let ((*x* 1))
> (let ((*x* 2))
> (let ((*x* 3))
> (print *x*))
> (print *x*))
> (print *x*))
There are three bindings of the dynamic variable *X*. I make the
distinction because there's only one (necessary) location for *X*.
The lexical variables shadow eachother's visibility, but it's possible
to access all three locations at once by closing over them. The
dynamic bindings all share the same location.
FWIW, in another post, you talked about the lexical name disappearing
at runtime. This is true in compiled code. Lexical variables are
compile(-ish)[*] time objects -- all that's left after compile time
are lexical bindings.
[*] Not a technical term, but I had a precise meaning: compile time in
compiled code; or, that phase of evaluation that can be factored out
into compile-time, in evaluated code.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
···@apocalypse.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
> FWIW, in another post, you talked about the lexical name
> disappearing at runtime. This is true in compiled code. Lexical
> variables are compile(-ish)[*] time objects -- all that's left after
> compile time are lexical bindings.
So does it bother you at all that all that's left after the name
disappears is the "binding" when a binding is defined (in the CLHS
glossary) as
an association between a name and that which the name denotes
^^^^
I'm gathering the impression that knowledgable people *don't* seem to
be bothered by this seeming incongruity so pretty soon I'll stop being
bothered too. But I haven't quite gotten over it yet. ;-)
I'm also noticing that folks seem to use the same terms with slightly
different meanings, or at least connotations, when talking about
lexical vs. dynamic variables/bindings/etc. For example, your
distinction--which I believe I understand--between three lexical
variables for three bindings, vs one dynamic variable for three
bindings. (In fact I like that distinction and the way you explain it,
though I'm still not sure how to reconcile it with the glossary
definition of variable.)
Anyway, someday--soon I expect--I'll have wrapped my head around most,
if not all, of these nuances. In the meantime, thank you, and everyone
else, for your patience.
-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:
> ···@apocalypse.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
>
> > FWIW, in another post, you talked about the lexical name
> > disappearing at runtime. This is true in compiled code. Lexical
> > variables are compile(-ish)[*] time objects -- all that's left after
> > compile time are lexical bindings.
>
> So does it bother you at all that all that's left after the name
> disappears is the "binding" when a binding is defined (in the CLHS
> glossary) as
>
> an association between a name and that which the name denotes
> ^^^^
Well, (a) the glossary is not normative, and (b) that's exactly what a
binding is. That definition doesn't say when the name exists, is all.
> I'm gathering the impression that knowledgable people *don't* seem to
> be bothered by this seeming incongruity so pretty soon I'll stop being
> bothered too. But I haven't quite gotten over it yet. ;-)
I have 2.5 suggestions: one, try spending quality time with Python --
it has other benefits too (especially if you use CMUCL/SBCL);
one-and-one-half, try implementing a very, very simple Lisp compiler;
three, read Marx -- seriously, the definitions of "variable" and
"binding" aren't in conflict -- they complete each other
dialectically. Again, this one has other benefits.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
···@apocalypse.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
> Peter Seibel <·····@javamonkey.com> writes:
>
> > ···@apocalypse.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
> >
> > > FWIW, in another post, you talked about the lexical name
> > > disappearing at runtime. This is true in compiled code. Lexical
> > > variables are compile(-ish)[*] time objects -- all that's left after
> > > compile time are lexical bindings.
> >
> > So does it bother you at all that all that's left after the name
> > disappears is the "binding" when a binding is defined (in the CLHS
> > glossary) as
> >
> > an association between a name and that which the name denotes
> > ^^^^
>
> Well, (a) the glossary is not normative,
Sort of. That is, when a word doesn't appear in italic, the glossary
meaning might or might not apply; when a word does appear in italic,
the glossary meaning is supposed to apply, though I don't know that we
have done a full audit to assure no errors were made in this process.
Peter seems obsessed to the point of frustrating everyone here about
finding strange implications of what is there. That isn't the way the
community is supposed to work. It's one thing if you're stuck in
isolation and you read the spec and do a lot of investment in a
strange interpretation that you believed in good faith and that seemed
to make the world consistent for you and then were stunned to find out
it didn't work that way. (That happened, for example, with Robertson
Common Lisp (later Symbolics CLOE) when Paul Robertson implemented
variables in an odd way because he took the thing about DEFVAR
evaluating its argument only if it was used to mean 'if the variable
was used' so he set up little triggers for the variables to get
initialized on first use. He wasn't connected originally to the other
design community. It was embarrassing to us, and I think we fixed it
in the ANSI CL spec, though I didn't go and check just now.) But if
you are connected to the CL design community, and if you have a
confusion, while the spec does not require you to do so, the community
will be much happier with you if you just ASK what everyone does
(since everyone does the same thing) rather than trying to prove that
what is common knowledge and widely implemented is wrong. There is
simply NO confusion about these things you're asking about among all
of the extant implementations as far as I know, and so all you're
doing is irritating people by hammering on the fact that my editorial
text was not perfect--which it certainly is not. There are LOTS of
confusing wordings and if we have to have a conversation this long
about every time I wrote something muddy, I will have plopped you into
my killfile pretty quickly along the way. If there is a REAL problem
being generated here, please cite it. But I just don't see it.
We added the glossary in order to help you read the text, but not in
order to define the only possible way to read the text. It was an
ongoing effort to add more definitions and to italicize more and more
of the base document, but we did not succeed in noticing all the
different senses in which every word was used, nor did we find all
places that the existing meanings were used.
Part of the reason the wording in ANSI CL (and therefore in CLHS) is
awkward is also that there really are inconsistent meanings to binding.
Sometimes unbound means "there is no binding" and sometimes it means
"a binding exists but no value is mapped to". If you think of a binding
as a half-cons, i.e. a cell, into which a pointer can be dropped, then
for special variables it can have an unbound marker but for lexical
variables it can't. Variables initially might or might not have a special
variable cell; that is, no requirement is made that a symbol have an
allocated symbol-value cell as long as the behave as if one exists when
it's accessed. Probably (but again not necessarily) making something
unbound means dropping an unbound marker into the existing cell. A lot
of this is historical. It's best not explained this way. But it's how
it turns out. And making some of the language, like the morpheme
'unbound' in MAKUNBOUND, match up with the modern terminology for
bindings is a tightrope walk. Which is why it's done poorly. We simply
did not have the budget for me to spend days or weeks coming up with
terminology that was different and that was tested for correctness and
that would make everyone happy. There were more important things to do
since no one really had a disagreement with the way it all was. We relied
on common sense and community inertia, and you're trying to pretend you
don't need common sense and community inertia in order to read it. That
isn't going to do the best job for you.
> and (b) that's exactly what a
> binding is. That definition doesn't say when the name exists, is all.
Right.
> > I'm gathering the impression that knowledgable people *don't* seem to
> > be bothered by this seeming incongruity so pretty soon I'll stop being
> > bothered too. But I haven't quite gotten over it yet. ;-)
>
> I have 2.5 suggestions: one, try spending quality time with Python --
> it has other benefits too (especially if you use CMUCL/SBCL);
> one-and-one-half, try implementing a very, very simple Lisp compiler;
> three, read Marx -- seriously, the definitions of "variable" and
> "binding" aren't in conflict -- they complete each other
> dialectically. Again, this one has other benefits.
This is certainly a viable approach. Maybe even compare to other available
public implementations. Construct some test cases. If you come up with
unusual or unexpected results, raise those for question. But please, if
the implementations are not varying on these, don't try to make the case
that they should be. And if the implementations are not varying on these,
maybe it means you should take a cue from how everyone did things rather
than trying to find a new way.
Certainly the langauge as a legal document permits you to do what you are
doing. But the language as a legal document does not require people who
feel you're wasting their time to keep talking to you. Don't waste your
useful capital on things that don't matter to you, lest you not have it
later when you need it.
Required reading: The story of The Boy Who Cried Wolf.
Kent M Pitman <······@world.std.com> writes:
> ···@apocalypse.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
>
> > Peter Seibel <·····@javamonkey.com> writes:
> >
> > > ···@apocalypse.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
> > >
> > > > FWIW, in another post, you talked about the lexical name
> > > > disappearing at runtime. This is true in compiled code. Lexical
> > > > variables are compile(-ish)[*] time objects -- all that's left after
> > > > compile time are lexical bindings.
> > >
> > > So does it bother you at all that all that's left after the name
> > > disappears is the "binding" when a binding is defined (in the CLHS
> > > glossary) as
> > >
> > > an association between a name and that which the name denotes
> > > ^^^^
> >
> > Well, (a) the glossary is not normative,
>
> Sort of. That is, when a word doesn't appear in italic, the glossary
> meaning might or might not apply; when a word does appear in italic,
> the glossary meaning is supposed to apply, though I don't know that
> we have done a full audit to assure no errors were made in this
> process.
>
> Peter seems obsessed to the point of frustrating everyone here about
> finding strange implications of what is there.
If that's how I'm coming across let me both apologize and stop.
My intent is not to try to find "holes" in the spec. and certainly not
"to prove that what is common knowledge and widely implemented is
wrong". I fully recognize that the spec is a document produced by
human beings and intended to be read by other human beings who are
expected to exercise reasonable judgement in coming to their own
understanding of what's what.
I have tried to make clear (and cleary have failed to do so), that the
reason I'm asking these questions is to try to understand not only the
concepts but how people use the terminology in standard or from
elsewhere to talk about these concepts.
Ironically, what I really *want* is exactly the common sense, shared
understanding that, as you point out, *can't* be obtained just by
reading the spec.
I use the spec as a starting point for my questions because it's there
and is at least presumptively authoritative. And because, in many
cases, things that I initially found confusing, snapped into place
once I got a few pointers about how certain terms or ideas were
intended slightly differently than I originally understood them.
> all you're doing is irritating people by hammering on the fact that
> my editorial text was not perfect--which it certainly is not.
Again, if this is how it seems--I really apologize. I think the spec
is a stupendously good document and not deserving of any hammering.
And I don't certainly don't expect perfection. If you have any
patience left with me, maybe you can suggest how I can phrase a
question about the spec where the right answer might just be: "Yeah,
that's one of the places where the spec is a little confusing--every
body understands that to mean ...".
When I post something of the form "The spec says X, yet everyone else
seems to say Y, why is that?" I understand that the answer may be,
"because everybody understands that the intent, which may not have
been captured perfectly in the spec, was in fact Y". (And when people
fill in the historical details about why this thing that we all now
understand to mean Y, used to be expressed as X, that's awsome--I like
understanding how we got to where we are.) In fact, I'd often be
relieved to get an answer like that--I work pretty hard at trying to
understand things and when I still can't, it's sometimes nice to hear
that it's just because it *is* confusing, not because I'm a dolt.
> There are LOTS of confusing wordings and if we have to have a
> conversation this long about every time I wrote something muddy, I
> will have plopped you into my killfile pretty quickly along the way.
> If there is a REAL problem being generated here, please cite it. But
> I just don't see it.
I'm sorry this particular thread got dragged out so long--some of what
you explained in this post is exactly the kind of information I was
looking for; I didn't know until this post that anyone but me thought
the wording in the spec about bindings was awkward or confusing--I
sincerely hoped someone would either say, "No, no, here's how you need
to read that", *or* just what you said in this post: It's a bit
awkward, and here's why.
Again, if you have any suggestions how I could have worded any of my
questions along the way so that we could have got there without so
much frustration, I'm all ears. I'm certainly don't want to bother
everybody by asking questions that only frustrate people, so I'd like
to find a better way.
> We relied on common sense and community inertia, and you're trying
> to pretend you don't need common sense and community inertia in
> order to read it. That isn't going to do the best job for you.
I'm really not trying to pretend that, though I guess just saying so
probably doesn't help much. I'll certainly try to exhibit more common
sense in the future. In the meantime I'm trying to catch up to the
community inertia as fast as I can. I read CLtL2 cover to cover the
other weekend, cross checking a lot of things against the HyperSpec to
see how they had changed in the final standard; I read Steele's and
Gabriel's paper on the history of Lisp in HOPL2; the Lisp 1.5 manual;
several of Henry Baker's papers; and several of your papers. Pointers
to other things I can read are always welcome. I *get* it that there's
a lot of context beyond just the spec and I'm painfully aware that I'm
missing a lot of it, having not been around when the language was
standardized nor having had the opportunity to work as a professional
Lisp programmer, which would be the most natural way to absorb this
context.
> Certainly the langauge as a legal document permits you to do what
> you are doing. But the language as a legal document does not require
> people who feel you're wasting their time to keep talking to you.
> Don't waste your useful capital on things that don't matter to you,
> lest you not have it later when you need it.
I really don't think I'm doing what you think I'm doing but I
understand that I must be giving you some reason to think I am. For
that, I apologize.
-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:
> Anyway, someday--soon I expect--I'll have wrapped my head around most,
> if not all, of these nuances. In the meantime, thank you, and everyone
> else, for your patience.
I'm interested in why you are spending so much time trying to get the
terminology right and why you are asking questions about these little
details. I wouldn't suspect that you need to know this to be a
proficient programmer in Common Lisp. Just like I'm sure there are
good writers out there that don't know every detail about English
grammar and all the places that semi-colons can be used. Maybe you can
explain this to me?
Timmy Douglas <·····@cc.gatech.edu> writes:
> Peter Seibel <·····@javamonkey.com> writes:
>
> > Anyway, someday--soon I expect--I'll have wrapped my head around
> > most, if not all, of these nuances. In the meantime, thank you,
> > and everyone else, for your patience.
>
> I'm interested in why you are spending so much time trying to get
> the terminology right and why you are asking questions about these
> little details. I wouldn't suspect that you need to know this to be
> a proficient programmer in Common Lisp. Just like I'm sure there are
> good writers out there that don't know every detail about English
> grammar and all the places that semi-colons can be used. Maybe you
> can explain this to me?
Heh. I wondered how long before someone would ask me about that. I
guess I'll have to reveal my secret--I thought about mentioning it
before but I wanted to make some progress before I told the world: I'm
writing a book about Common Lisp. (I'll pause here to let those of you
who just fell out of their chairs, thinking--they let *that* guy write
a book. About Lisp?--get back up. There. Sorry about that.)
My target audience are the smart programmers out there who have heard
some good things about Lisp but have also absorbed too much anti-Lisp
propaganda to believe it could actually be used for anything real. Or
those who were traumatized by some college Scheme course. The people I
most want to reach are the folks who today are using Java, Python, or
Perl because they understand what a nightmare C++ can be. If I can
convince some C and C++ types too, that's gravy.
Anyway, what I lack in years of deep Lisp expertise, I hope I can make
up for in having a pretty good insight into what makes those folks
tick. Before I quit my job to devote myself to finally really learning
Common Lisp, I was an architect at a startup that was writing a
transactional message processing system in Java. Before that I was one
of the early engineers at Weblogic (now part of BEA). And before that
I was a Perl hacking web monkey.
Also, as a child, I owned shares in Symbolics, thanks to my Dad being
a big Lisp believer in the AI boom times. So I sort of grew up hearing
about the greatness of Lisp but other than a bit of hacking in college
I never had a chance to get deeply immersed until I quit my job.
So, that's why I have all these strangely detailed questions: I'm
trying to make sure that I not only understand the concepts but that I
can explain them in a way that is both clear and technically accurate.
Thanks to everyone who has helped me out.
-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:
> Timmy Douglas <·····@cc.gatech.edu> writes:
>
> > Peter Seibel <·····@javamonkey.com> writes:
> >
> > > Anyway, someday--soon I expect--I'll have wrapped my head around
> > > most, if not all, of these nuances. In the meantime, thank you,
> > > and everyone else, for your patience.
> >
> > I'm interested in why you are spending so much time trying to get
> > the terminology right and why you are asking questions about these
> > little details. I wouldn't suspect that you need to know this to be
> > a proficient programmer in Common Lisp. Just like I'm sure there are
> > good writers out there that don't know every detail about English
> > grammar and all the places that semi-colons can be used. Maybe you
> > can explain this to me?
>
> Heh. I wondered how long before someone would ask me about that. I
> guess I'll have to reveal my secret--I thought about mentioning it
> before but I wanted to make some progress before I told the world: I'm
> writing a book about Common Lisp. (I'll pause here to let those of you
> who just fell out of their chairs, thinking--they let *that* guy write
> a book. About Lisp?--get back up. There. Sorry about that.)
>
> My target audience are the smart programmers out there who have heard
> some good things about Lisp but have also absorbed too much anti-Lisp
> propaganda to believe it could actually be used for anything real. Or
> those who were traumatized by some college Scheme course. The people I
> most want to reach are the folks who today are using Java, Python, or
> Perl because they understand what a nightmare C++ can be. If I can
> convince some C and C++ types too,
Nothing wrong with that -- but Graham's _ANSI_CL_ works well for
people from a HLL (including Java, barely) background, without going
into semantic awefulness about binding. If you want an editor, I'm
sure you could find one (on a compeletely unrelated note, I'm a lit
major, and a consultant).
> that's gravy.
You gotta talk to E-40 and get some new words -- it's all gravity, now.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
> I'm writing a book about Common Lisp.
Some things you should include:
1.) In Lisp Programs and Data have the same form.
The only other language for which this holds is Machine Language &
Lisp is so much easier to use. This means that you can write systems
software easily in Lisp. It is rather easy to write compilers in Lisp--
as compaired to other HLLs.
2.) Lambda can explain a lot about the language. As I tried to explain
it can explain how variables are bound. It can also explain how
functions are called. And, with a Y-Combanator it can explain how
most of the rest of Lisp including CLOS is implemented. Google for
Lambda + Lisp + <other Lisp features>
3.) Lisp is a loosly typed language to support rapid prototyping--but you
can make type declarations to increase effecency when the program
is ready to be deployed--not too many people have written about this
features. (2 I think.)
4.) Most code for the Lisp Compiler is written in Lisp so that Lisp
programmers can make changes to the Lisp compiler if the
need should ever arise. I'm not saying that it should be done just
that it could be done.
5.) If you recompile a Lisp function you don't have to recompile the
whole program. You can also edit & debug programs on the
fly--if you find an error you can keep on generating and testing
functions until so fix the error.
6.) Lisp Macros produce Lisp code. You can embed compilers/interp.
for other languages rather easily in Lisp. Check out On Lisp on
Paul Ghrams web site, and Paradigms and Artificial Intelligence
Programming by Peter Novig. Both implement Prolog in Lisp.
Peter Novig's book his an exzcellent chapter about some common
Common Lisp errors bar none in my opinion.
I wish you luck with your book. I hope these points help you out.
If you'd like elaboration on any of them don't hesatate to ask.
BTW, Lisp has been called a HLL Machine Language because of how easy writing
systems software in it has been. (IMHO, this is a great selling point
because Lisp is alot easier for most people to learn than Machine Language,
can be run on many different hardware, and has an ANSI specificaion.
I forgot one thing.
Lisp can handle symbolic expressions.
Try implementing things like this in C++/Java.
(cons '(a b c) '(d e))
(mapcar #'(lambda (x) (second x)) '((a b) (c d) (e f) (g h)))
(defmacro ave-2 (&body body)
`(/ (reduce #'+ ,@body) ,(length body))
(defmacro ave-1 (&rest rest)
(reduce #'+ (length rest)))
in C++/Java most of these progs. would take more space
because Lisp treats symbolics in the same way as numbers.
It takes a lot of C++/Java code to = 1 line of Lisp code.
"Franz Kafka" <Symbolics _ XL1201 _ Sebek _ Budo _ Kafka @ hotmail . com> wrote in message news:<··················@news01.roc.ny.frontiernet.net>...
> > I'm writing a book about Common Lisp.
>
> Some things you should include:
>
> 1.) In Lisp Programs and Data have the same form.
> The only other language for which this holds is Machine Language &
> Lisp is so much easier to use. This means that you can write systems
> software easily in Lisp. It is rather easy to write compilers in Lisp--
> as compaired to other HLLs.
This requires a lot of explanation, because the obvious conclusion is
that Lisp is inefficient because an interpreter must be present which
walks the lists. (If programs are lists, the conclusion is that the
execution of programs requires the continuous processing and
re-processing of lists). This is wrong; in most Lisp implementations,
programs have at least three representations: printed text,
polymorphic lists and some additional compiled forms which are
typically not analyzeable or synthesizeable in any portable way.
It's better to say something along these lines:
Lisp has a layered approach to the representation of programs. A
printed notation codes for a data structure, and the data structure
serves as input to the compiler or interpreter and is the de facto
source code. The compiler and evaluator are available to the
programmer at run time, so that a Lisp application might execute not
only code that originated as text found in source files, but also code
formed by dynamically compiling or evaluating data structures
assembled at run time representing source code.
This has nothing to do with machine language. The representation of a
machine language program is a block of words to be loaded into memory.
This is the executable representation, not source code; the source
code to a machine language program is usually a text file containing
assembly language, or some syntax tree produced by a compiler for a
high level language. Meaningful manipulations of the program are
easier in these representations, particularly the second one, but
these representations are not available to the running machine
language program.
A block of memory is also an easy data structure to work with in
machine language. But this does not mean that a machine language
program can do meaningful things with those blocks which semantically
represent machine language programs! For a machine language program to
perform transformations on machine language programs, it has to parse
their encoding. Consider just the simple problem of ``extract the
fifth machine instruction from this block'' compared to the vaguely
analogus Lisp problem ``extract the fifth element from this list of
forms''. Unless the machine instructions all have the same length, you
have to parse each opcode from the beginning, so you know how many
immediate operands to skip. And then you have to parse the instruction
you want to know how long it is. That's not even to consider the
memory management issues: where are you going to place the transformed
program? How will you recycle unreachable ones?
Thus it is completely misleading to make any such comparison between
machine language and Lisp, and it's a great way to trigger lunatic
alarms to imply that any resemblance to machine language is some kind
of good thing.
> 2.) Lambda can explain a lot about the language. As I tried to explain
> it can explain how variables are bound. It can also explain how
> functions are called. And, with a Y-Combanator it can explain how
> most of the rest of Lisp including CLOS is implemented. Google for
> Lambda + Lisp + <other Lisp features>
I think that lambdas and Y combinators are probably a good way to put
the audience to sleep. It's a very bad idea to try to introduce
something complex by presenting some tiny set of mathematical axioms,
and then requiring the reader to understand how all else follows.
A Y combinator can't explain how real Lisps are implemented, because
they are not implemented that way.
> 3.) Lisp is a loosly typed language to support rapid prototyping--but you
> can make type declarations to increase effecency when the program
> is ready to be deployed--not too many people have written about this
> features. (2 I think.)
This type of statement implies that Lisp has weak type checking, that
it's inefficient, or that its dynamic approach is suitable for rapid
prototyping, but for production use, the declarations have to go in.
> 4.) Most code for the Lisp Compiler is written in Lisp so that Lisp
> programmers can make changes to the Lisp compiler if the
> need should ever arise. I'm not saying that it should be done just
> that it could be done.
There is no ``the Lisp compiler''. The sophisticated compilers
included in Lisp implementations are not necessarily ``user
serviceable parts''. Some Lisp implementations, most notably the
freeware ones, provide the source code to the compiler, but not all
do. Even if they do, there may be licensing issues with redistributing
modifications to such code. Your statement implies that all Lisp is
somehow open source, which is wrong.
"Franz Kafka" <Symbolics _ XL1201 _ Sebek _ Budo _ Kafka @ hotmail . com> writes:
> > I'm writing a book about Common Lisp.
>
> Some things you should include:
>
> 1.) In Lisp Programs and Data have the same form.
> The only other language for which this holds is Machine Language &
> Lisp is so much easier to use. This means that you can write systems
> software easily in Lisp. It is rather easy to write compilers in Lisp--
> as compaired to other HLLs.
> 2.) Lambda can explain a lot about the language. As I tried to explain
> it can explain how variables are bound. It can also explain how
> functions are called. And, with a Y-Combanator it can explain how
> most of the rest of Lisp including CLOS is implemented. Google for
> Lambda + Lisp + <other Lisp features>
> 3.) Lisp is a loosly typed language to support rapid prototyping--but you
> can make type declarations to increase effecency when the program
> is ready to be deployed--not too many people have written about this
> features. (2 I think.)
Common Lisp is not loosly typed language, it is a strongly typed language
where the type checking happens at runtime, for example :
CL: (+ 1 "2"); dies with an error
Perl: print 1 + "2" # prints 3, string gets magically turned into 2
perl is loosly typed and CL is not.
> 4.) Most code for the Lisp Compiler is written in Lisp so that Lisp
> programmers can make changes to the Lisp compiler if the
> need should ever arise. I'm not saying that it should be done just
> that it could be done.
If you have access to the source
> 5.) If you recompile a Lisp function you don't have to recompile the
> whole program. You can also edit & debug programs on the
> fly--if you find an error you can keep on generating and testing
> functions until so fix the error.
> 6.) Lisp Macros produce Lisp code. You can embed compilers/interp.
> for other languages rather easily in Lisp. Check out On Lisp on
> Paul Ghrams web site, and Paradigms and Artificial Intelligence
> Programming by Peter Novig. Both implement Prolog in Lisp.
> Peter Novig's book his an exzcellent chapter about some common
> Common Lisp errors bar none in my opinion.
>
> I wish you luck with your book. I hope these points help you out.
> If you'd like elaboration on any of them don't hesatate to ask.
>
> BTW, Lisp has been called a HLL Machine Language because of how easy writing
> systems software in it has been. (IMHO, this is a great selling point
> because Lisp is alot easier for most people to learn than Machine Language,
> can be run on many different hardware, and has an ANSI specificaion.
marc
From: Joe Marshall
Subject: Re: How would you describe this?
Date:
Message-ID: <r87ac1nw.fsf@ccs.neu.edu>
"Franz Kafka" <Symbolics _ XL1201 _ Sebek _ Budo _ Kafka @ hotmail . com> writes:
> 1.) In Lisp Programs and Data have the same form.
> The only other language for which this holds is Machine Language &
> Lisp is so much easier to use.
`M' (formerly known as Mumps)
TCL
REBOL
These are off the top of my head. You could make an argument for
Forth, too.
> 3.) Lisp is a loosly typed language to support rapid prototyping--but you
> can make type declarations to increase effecency when the program
> is ready to be deployed--not too many people have written about this
> features. (2 I think.)
Lisp is strongly typed (try taking the CDR of 27). Lisp has `latent'
types (also called dynamic types), i.e., the data is typed rather than
the variable.
Peter Seibel wrote:
> I
> guess I'll have to reveal my secret--I thought about mentioning it
> before but I wanted to make some progress before I told the world: I'm
> writing a book about Common Lisp. (I'll pause here to let those of you
> who just fell out of their chairs, thinking--they let *that* guy write
> a book. About Lisp?--get back up. There. Sorry about that.)
I think we knew this. I know I did. The bombshell would be if O'Reilly
was your publisher. Anyway, good for you.
> Anyway, what I lack in years of deep Lisp expertise, I hope I can make
> up for in having a pretty good insight into what makes those folks
> tick.
They care about fine distinctions between words like "binding" and
"variable"? I would think it would scare that crowd off, if they thought
they had to master such hairsplitting to use Lisp, and just confirm any
prejudice that Lisp is a freak language.
Like I said before, it's your book, but I have never been able to learn
tricky stuff from words, especially words that seem to have been
generated by an algorithm (such as AMOP), though I am definitely a
left-brainer. The light goes on for me when I see how examples /behave/.
Then I know how my code will behave if I use the same feature, and off I
go to get something done.
> So, that's why I have all these strangely detailed questions: I'm
> trying to make sure that I not only understand the concepts but that I
> can explain them in a way that is both clear and technically accurate.
> Thanks to everyone who has helped me out.
No good deed goes unpunished, so we will continue to harrass you for
your diligence. It's "The CLL Way." You might mention the working title,
that will keep us busy abusing you for weeks.
:)
--
kenny tilton
clinisys, inc
http://www.tilton-technology.com/
---------------------------------------------------------------
"Everything is a cell." -- Alan Kay
Kenny Tilton <·······@nyc.rr.com> writes:
> Peter Seibel wrote:
> > I guess I'll have to reveal my secret--I thought about mentioning
> > it before but I wanted to make some progress before I told the
> > world: I'm writing a book about Common Lisp. (I'll pause here to
> > let those of you who just fell out of their chairs,
> > thinking--they let *that* guy write a book. About Lisp?--get back
> > up. There. Sorry about that.)
>
> I think we knew this. I know I did. The bombshell would be if
> O'Reilly was your publisher. Anyway, good for you.
Thanks.
> > Anyway, what I lack in years of deep Lisp expertise, I hope I can
> > make up for in having a pretty good insight into what makes those
> > folks tick.
>
> They care about fine distinctions between words like "binding" and
> "variable"? I would think it would scare that crowd off, if they
> thought they had to master such hairsplitting to use Lisp, and just
> confirm any prejudice that Lisp is a freak language.
No, I'm sure they don't. I just want to make sure that to the extent
there is a fine distinction that's important to actual Lisp
programmers that I don't use those terms--if I use them at all--in an
incorrect or misleading way. *My* understanding needs to be precise
and detailed so that I can elide the *correct* details when explaining
things to others.
> Like I said before, it's your book, but I have never been able to
> learn tricky stuff from words, especially words that seem to have
> been generated by an algorithm (such as AMOP), though I am
> definitely a left-brainer. The light goes on for me when I see how
> examples /behave/. Then I know how my code will behave if I use the
> same feature, and off I go to get something done.
Isn't that right brained? Anyway, if all goes according to plan, the
book will be around half actual examples of non-trivial working Lisp
programs. So both sides of your brain should be happy.
> > So, that's why I have all these strangely detailed questions: I'm
> > trying to make sure that I not only understand the concepts but
> > that I can explain them in a way that is both clear and
> > technically accurate. Thanks to everyone who has helped me out.
>
> No good deed goes unpunished, so we will continue to harrass you for
> your diligence. It's "The CLL Way." You might mention the working
> title, that will keep us busy abusing you for weeks.
Heh. The working title is _Practical Lisp_. Abuse away. ;-)
-Peter
P.S. I just sent my first three chapters to the publisher--it's not
too late for you guys to find out who the publisher is and convince
them to pull the plug on the project; I have a contract with them but
I gather they reserve the right to bail if the first chapters are just
awful. I expect them to be satisfied but I realized last night that I
had jumped the gun a bit yesterday in outing myself--I should have
waited to get the final approval. But since Timmy had asked, I figured
I owed folks an explanation.
--
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 wrote:
> Kenny Tilton <·······@nyc.rr.com> writes:
>
>>Like I said before, it's your book, but I have never been able to
>>learn tricky stuff from words, especially words that seem to have
>>been generated by an algorithm (such as AMOP), though I am
>>definitely a left-brainer. The light goes on for me when I see how
>>examples /behave/. Then I know how my code will behave if I use the
>>same feature, and off I go to get something done.
>
>
> Isn't that right brained?
I don't think so, but my point was that (trust me) I am profoundly
left-brained and references /still/ do not work for me.
Digression: As for whether learning by example is left-brained or not, I
don't know, but it seems to me that looking at an example and deriving
therefrom a rule is analytical, hence left-brained.
> Anyway, if all goes according to plan, the
> book will be around half actual examples of non-trivial working Lisp
> programs. So both sides of your brain should be happy.
Excellent.
> Heh. The working title is _Practical Lisp_. Abuse away. ;-)
You call that a title?! Don't you want to sell any? <g>
Look, Norvig showed the way: PAIP II was Pythonized to create sales.
Your title should be "Lisp for Pythonistas", or "After Java, Lisp", or
"Lisp, the Better C++". I don't know, but you have to force the search
tools to bring your title up by mistake, and get the B&N folks to stack
it in the J, P, or C sections -- not L!
You said in the last message that your target was folks using Python,
Perl, whatever -- there's your title. grease the skids for them to pick
your book up off the shelf and pry it open for a look-see.
"Practical Lisp" sounds like a book for Lispniks, and only confirms to
non-Lispniks that Lisp is normally impractical, but can with the special
techniques found in your book be made (probably only somewhat)
practical. I know you mean "Lisp -- Guess what? It's Actually
Practical!". I just don't think "Practical Lisp" will be taken that way
by Lispophobes.
Even the structure of the book should reflect your stated target. Bounce
back and forth between, say, C++ and Lisp. First show straight
translation, as in "Lisp is just a good ol' HLL". Then show how Lisp has
an advantage. eg, simple iteration for (;;){..} vs dolist then dotimes
then DO then <gasp!> loop. #define vs defmacro (omigod). C++ classes vs
CLOS and esp. generic functions... edit-compile-link vs interactive
development... source-stepping after a crash vs writing new code to
analyze the failed data structures, then fixing a bug and restarting
from a selected stack frame... if this was a fight they'd stop it.
hey, how about a series of books? "Ultimate C++: Lisp", "Ultimate Java:
Lisp".. does it make more sense to start with C/C++ since FFIs tend to
mean "C FFI"? In case someone wants to adapt Lisp incrementally,
interfacing to existing code? Python gets a lot of its mojo from the
trivial ease of interfacing to C. Maybe a special section on the FFI?
One Lispnyck is a gentleman who happens at this very moment to be in
transition from C to CL. You two should be corresponding.... just to
eliminate the suspense, yeah, he digs Lisp bigtime.
:)
--
kenny tilton
clinisys, inc
http://www.tilton-technology.com/
---------------------------------------------------------------
"Everything is a cell." -- Alan Kay
From: Tim Bradshaw
Subject: Re: How would you describe this?
Date:
Message-ID: <ey37k90gprq.fsf@cley.com>
* Kenny Tilton wrote:
> They care about fine distinctions between words like "binding" and
> "variable"? I would think it would scare that crowd off, if they
> thought they had to master such hairsplitting to use Lisp, and just
> confirm any prejudice that Lisp is a freak language.
I'm sure they don't, but I think people are quite good at detecting
inconsistent use of terminology, even in areas they don't know about,
and so it's important for Peter to get the terminology consistent, and
as a second-order thing it's important that the terminology he uses is
consistent with what *other* Lisp people use.
Actually, from the cll point of view, the second issue is first-order
- imagine how painful it will be if we get tides of newbies turning up
saying `but you're all wrong because *I've* read Peter Seibel's book,
and *he* says this blah blah.'
--tim
Peter Seibel wrote:
> ···@apocalypse.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
>
>
>>FWIW, in another post, you talked about the lexical name
>>disappearing at runtime. This is true in compiled code. Lexical
>>variables are compile(-ish)[*] time objects -- all that's left after
>>compile time are lexical bindings.
>
>
> So does it bother you at all that all that's left after the name
> disappears is the "binding" when a binding is defined (in the CLHS
> glossary) as
>
> an association between a name and that which the name denotes
> ^^^^
Is this a category error? When is anything left over at run time? (OK,
Lisp is cool, it knows about symbols at run time god bless it, but the
exception proves the rule.) Hey, at real runtime the only thing left is
electricity.
Think of a binding as a contract between the compiler and the
programmer. aka, "an association between a name and...". So if the
programmer types a name into the source code, the associated value gets
used. The compiler's very job is to fulfill that contract during
compilation, when names get replaced by... however the compiler chooses
to fulfill that contract.
I lke clarity in terminology, but I think this whole thread is off the
mark for newbies.
--
kenny tilton
clinisys, inc
http://www.tilton-technology.com/
---------------------------------------------------------------
"Everything is a cell." -- Alan Kay
Peter Seibel <·····@javamonkey.com> writes:
> In the form:
>
> (let ((x 1))
> (let ((x 2))
> (let ((x 3))
> (print x))
> (print x))
> (print x))
>
> would you say there are three variables or one variable?
No. HTH.
-dan
--
http://www.cliki.net/ - Link farm for free CL-on-Unix resources
Daniel Barlow <···@telent.net> writes:
> Peter Seibel <·····@javamonkey.com> writes:
>
> > In the form:
> >
> > (let ((x 1))
> > (let ((x 2))
> > (let ((x 3))
> > (print x))
> > (print x))
> > (print x))
> >
> > would you say there are three variables or one variable?
>
> No. HTH.
Er, what *would* you say? Zero variables? Infinitely many? That you're
opposed to the concept of variables on a) technical b) moral c)
mystical grounds? (You did notice it wasn't a yes or no question,
didn't you?)
(Or were you just trying to tell me that this question annoyed you. If
so I'm sorry, and sorry that I've no doubt doubled the offense with
this post.)
-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
On Mon, 05 May 2003 19:49:19 GMT, Peter Seibel <·····@javamonkey.com>
wrote:
>In the form:
>
> (let ((x 1))
> (let ((x 2))
> (let ((x 3))
> (print x))
> (print x))
> (print x))
>
>would you say there are three variables or one variable? (Or something
>else?)
I'd say, trying to instruct a novice, that there are
three variables, and they have nothing to do with one another.
>
>How about in this case:
>
> (defvar *x*)
>
> (let ((*x* 1))
> (let ((*x* 2))
> (let ((*x* 3))
> (print *x*))
> (print *x*))
> (print *x*))
>
Here I would say that there are successive bindings of a single
global variable, or a stack of bindings, if you wish.
The difference between the two examples being that if you made a
random function call (FOO) inside the innermost let, say, it is
possible for the FOO function to access the current binding of *X*,
by referencing *X* by name, but not of X.
"Peter Seibel" <·····@javamonkey.com> wrote in message ···················@javamonkey.com...
> In the form:
>
> (let ((x 1))
> (let ((x 2))
> (let ((x 3))
> (print x))
> (print x))
> (print x))
>
> would you say there are three variables or one variable? (Or something
> else?)
Three Dead Trolls in a Baggie.
http://www.deadtroll.com/
http://www.deadtroll.com/video/livehelldesk.html
http://www.deadtroll.com/video/ossuckscable.html
Wade