I'm not sure how to ask this, so I want to preface this by saying I'm not try
start a language war. This is a question I had this weekend, and wanted to ask
as part of my "trying to understand the Lisp mentality."
Lately I've been trying to play with various (free) Lisp implementations just
to get the feel of the overall language. I've used clisp, scsh, MIT Scheme,
and I've even tinkered with Emacs Lisp and Dr. Scheme a little bit. In playing
with these different Lisps, I can see the similarities, and I can see the
differences. Now, I'm no where close to being anything but a hobbyist with it
so far, but I'm worndering: when one gets to the point that one can program
marvelous software with a specific implementation, does one kind of focus on
that specific implementation? I mean, do Lisp hackers generally focus on
learning one implementation, or is it better to kind of learn them at a
paralell pace?
I'm wondering -- and again, this isn't trying to say one is better than the
other -- should set MIT Scheme, Emacs Lisp, and such aside until I get better
at clisp? Or should I continue working with each one as I have been? What do
most Lisp hackers do? Any opinions are welcome. Thanks.
Andrew Burton -- tuglyraisin at aol dot com
Felecia Station on Harvestgain
Jipi: Don't Believe everything the Net tell you.
Chip: I agree with this. My inputs are not to be trusted.
CROW: Quick, save the Robot Ashley!
From: John M. Adams
Subject: Re: Implementation Favoritism, a question of Lisp mindsets
Date:
Message-ID: <xaoisth3rcm.fsf@anarky.stsci.edu>
···········@aol.commune (Andrew Burton) writes:
> I'm not sure how to ask this, so I want to preface this by saying I'm not try
> start a language war. This is a question I had this weekend, and wanted to ask
> as part of my "trying to understand the Lisp mentality."
>
> Lately I've been trying to play with various (free) Lisp implementations just
> to get the feel of the overall language. I've used clisp, scsh, MIT Scheme,
> and I've even tinkered with Emacs Lisp and Dr. Scheme a little bit. In playing
> with these different Lisps, I can see the similarities, and I can see the
> differences. Now, I'm no where close to being anything but a hobbyist with it
> so far, but I'm worndering: when one gets to the point that one can program
> marvelous software with a specific implementation, does one kind of focus on
> that specific implementation? I mean, do Lisp hackers generally focus on
> learning one implementation, or is it better to kind of learn them at a
> paralell pace?
>
> I'm wondering -- and again, this isn't trying to say one is better than the
> other -- should set MIT Scheme, Emacs Lisp, and such aside until I get better
> at clisp? Or should I continue working with each one as I have been? What do
> most Lisp hackers do? Any opinions are welcome. Thanks.
Well, people around here tend to believe that Common Lisp is the
better choice. Clisp is a Common Lisp and is probably the best thing
for you to play with. Unless you have a specific reason to prefer a
scheme implementation, for example you are going to take a sicp based
course, I'd recommend that you continue with clisp. There are other
Lisps you can try including cmucl, Open MCL, Franz Inc.'s, trial
version of Allegro Common Lisp (ACL). In my opinion, although I
prefer ACL professionally, clisp has the best combination of features
and user-friendliness of the free Lisps, especially for the new user.
However, I have never tried Open MCL.
--
John Michael Adams
In article <·····························@mb-fc.aol.com>,
Andrew Burton <···········@aol.commune> wrote:
>Lately I've been trying to play with various (free) Lisp implementations just
>to get the feel of the overall language. I've used clisp, scsh, MIT Scheme,
>and I've even tinkered with Emacs Lisp and Dr. Scheme a little bit. In playing
>with these different Lisps, I can see the similarities, and I can see the
>differences. Now, I'm no where close to being anything but a hobbyist with it
>so far, but I'm worndering: when one gets to the point that one can program
>marvelous software with a specific implementation, does one kind of focus on
>that specific implementation? I mean, do Lisp hackers generally focus on
>learning one implementation, or is it better to kind of learn them at a
>paralell pace?
Most of the general concepts that you learn about Lisp programming apply to
most dialects. There may be minor syntactic differences (e.g. Lisp's DEFUN
vs. Scheme's DEFINE), and occasionally some more significant differences
(e.g. Emacs Lisp is dynamically-scoped, the rest are statically-scoped),
but they all share enough qualities that it's not difficult to go from one
dialect to another (the dialect analogy seems quite proper for this -- it's
not too different from the American and British differences in the English
language).
Where implementation-specific stuff becomes important is if you need to go
outside the features provided by the standard language, e.g. foreign
function calling or fancy UI libraries.
--
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.
> Where implementation-specific stuff
> becomes important is if you need to go
> outside the features provided by the
> standard language, e.g. foreign function
> calling or fancy UI libraries.
Which is pretty much standard with every language/dialect, correct? So what
I'm doing now, playing with as many dialects (which, I agree is a god word), is
prebably a more comman, generally accepted means of learning Lisp?
Andrew Burton -- tuglyraisin at aol dot com
Felecia Station on Harvestgain
Jipi: Don't Believe everything the Net tell you.
Chip: I agree with this. My inputs are not to be trusted.
CROW: Quick, save the Robot Ashley!
In article <·····························@mb-ch.aol.com>,
···········@aol.commune (Andrew Burton) wrote:
> > Where implementation-specific stuff
> > becomes important is if you need to go
> > outside the features provided by the
> > standard language, e.g. foreign function
> > calling or fancy UI libraries.
>
> Which is pretty much standard with every language/dialect, correct? So what
> I'm doing now, playing with as many dialects (which, I agree is a god word),
> is
> prebably a more comman, generally accepted means of learning Lisp?
>
There is not one right way to learn Lisp. What I like about Lisp is that
it allows a wide variety of expressing programs. However, this also
means that it's mainly up to you in what order you want to learn the
details about Lisp. Your insistence seems to suggest that you _want_ to
learn Lisp by learning many dialects in parallel. If that's the thing
you want to do, then just go ahead and do it. If that's not what you
want to do, then first learn one of Common Lisp or Scheme. It really
doesn't matter with which to start, as long as you are going to look at
the other language as well at some stage.
Emacs Lisp is an old-fashioned dialect and especially lacks lexical
scoping. Use it only when you want to tweak Emacs.
Pascal
--
"If I could explain it, I wouldn't be able to do it."
A.M.McKenzie
Andrew Burton wrote:
> So what
> I'm doing now, playing with as many dialects (which, I agree is a god word), is
> prebably a more comman, generally accepted means of learning Lisp?
If you want to learn how to program Lisp, I would recommend against this
strategy. Choose _one_ platform and learn this one properly. Then look
around and broaden your view (this will be easy once you understand the
fundamentals).
For a first Lisp-experience I would go for the Scheme-dialect of Lisp
(you mentioned Dr.Scheme which is a good platform for learning). There
is good literature on the web (Abelson & Sussman: "Structure and
Interpretation of Computer Programs", Felleisen et al. "How to design
programs") and this dialect is smaller than, e.g., Common Lisp.
Matthias
On Tue, Apr 15, 2003 at 09:59:05AM +0200, M H wrote:
> Andrew Burton wrote:
>
> > So what
> > I'm doing now, playing with as many dialects (which, I agree is a god word), is
> > prebably a more comman, generally accepted means of learning Lisp?
>
> If you want to learn how to program Lisp, I would recommend against this
> strategy. Choose _one_ platform and learn this one properly. Then look
> around and broaden your view (this will be easy once you understand the
> fundamentals).
This I agree with.
> For a first Lisp-experience I would go for the Scheme-dialect of Lisp
> (you mentioned Dr.Scheme which is a good platform for learning). There
> is good literature on the web (Abelson & Sussman: "Structure and
> Interpretation of Computer Programs", Felleisen et al. "How to design
> programs") and this dialect is smaller than, e.g., Common Lisp.
Why? I've found every Scheme environment I've tried--including
DrScheme--to be lacking in comparison to the CL environments. If you
want to learn Lisp, you should start with CL. Xanalys LispWorks offers
an excellent IDE for personal use, or Emacs in combination with any of
the other CLs works well.
Scheme's "simplicity" does not in any way aid the learning process, and
it only discourages potential future Lispers. The several good books
that use Scheme can easily be paralleled with CL.
Better to learn Scheme when you already know what Lisp can do.
--
; Matthew Danish <·······@andrew.cmu.edu>
; OpenPGP public key: C24B6010 on keyring.debian.org
; Signed or encrypted mail welcome.
; "There is no dark side of the moon really; matter of fact, it's all dark."
"Matthew Danish" <·······@andrew.cmu.edu> wrote in message
··························@lain.cheme.cmu.edu...
> On Tue, Apr 15, 2003 at 09:59:05AM +0200, M H wrote:
> > For a first Lisp-experience I would go for the Scheme-dialect of Lisp
> > (you mentioned Dr.Scheme which is a good platform for learning). There
> > is good literature on the web (Abelson & Sussman: "Structure and
> > Interpretation of Computer Programs", Felleisen et al. "How to design
> > programs") and this dialect is smaller than, e.g., Common Lisp.
>
> Why? I've found every Scheme environment I've tried--including
> DrScheme--to be lacking in comparison to the CL environments. If you
> want to learn Lisp, you should start with CL. Xanalys LispWorks offers
> an excellent IDE for personal use, or Emacs in combination with any of
> the other CLs works well.
>
> Scheme's "simplicity" does not in any way aid the learning process, and
> it only discourages potential future Lispers. The several good books
> that use Scheme can easily be paralleled with CL.
Right. Common Lisp is quite big in terms of features, but isn't harder to
learn than Scheme when you start with a subset of the language, then
gradually learn the rest. For example, start with symbols and other types,
evaluation rules, list manipulations, function definition, basic i/o, and
you can already write nice little programs. Then you can learn about macros,
advanced data structures, condition system, CLOS, etc. And the whole
learning process should be pretty smooth.
--
Matthieu Villeneuve
Matthieu Villeneuve wrote:
> "Matthew Danish" <·······@andrew.cmu.edu> wrote in message
> ··························@lain.cheme.cmu.edu...
>
>>On Tue, Apr 15, 2003 at 09:59:05AM +0200, M H wrote:
>>
>>>For a first Lisp-experience I would go for the Scheme-dialect of Lisp
>>>(you mentioned Dr.Scheme which is a good platform for learning). There
>>>is good literature on the web (Abelson & Sussman: "Structure and
>>>Interpretation of Computer Programs", Felleisen et al. "How to design
>>>programs") and this dialect is smaller than, e.g., Common Lisp.
>>
>>Why? I've found every Scheme environment I've tried--including
>>DrScheme--to be lacking in comparison to the CL environments. If you
>>want to learn Lisp, you should start with CL. Xanalys LispWorks offers
>>an excellent IDE for personal use, or Emacs in combination with any of
>>the other CLs works well.
>>
>>Scheme's "simplicity" does not in any way aid the learning process, and
>>it only discourages potential future Lispers. The several good books
>>that use Scheme can easily be paralleled with CL.
>
>
> Right. Common Lisp is quite big in terms of features, but isn't harder to
> learn than Scheme when you start with a subset of the language, then
> gradually learn the rest. For example, start with symbols and other types,
> evaluation rules, list manipulations, function definition, basic i/o, and
> you can already write nice little programs. Then you can learn about macros,
> advanced data structures, condition system, CLOS, etc. And the whole
> learning process should be pretty smooth.
>
>
> --
> Matthieu Villeneuve
>
Hi --
A bit late for this, but I agree. Scheme makes you do "workarounds"
for some problems that CL has already defined a language token.
Here's a "subset" as suggested by Robert Wilensky's book. It doesn't
go into OOP, but my guess is the OP shoudn't go into CLOS before
grasping such a subset.
Cheers.
Henry Lenzi
Evaluation and control functions
QUOTE
EVAL
APPLY
FUNCALL
MACROEXPAND
MULTIPLE-VALUE-BIND
VALUES
Variable creation functions
LET
LET*
Input/Output functions
READ
LOAD
PRINT
PRINC
PPRINT
TERPRI
FORMAT
CLOSE
OPEN
Debugging functions
APROPOS
DESCRIBE
BREAK
STEP
TRACE
UNTRACE
Function definition functions
DEFUN
DEFMACRO
DEFSETF
DEFSTRUCT
(LAMBDA...)
FUNCTION
Symbol functions
GET
SYMBOL-PLIST
SYMBOL-FUNCTION
SYMBOL-NAME
SYMBOL-PACKAGE
GENSYM
Package functions
INTERN
UNINTERN
EXPORT
IMPORT
PROVIDE
REQUIRE
IN-PACKAGE
USE-PACKAGE
Arithmetic functions
+
-
*
/
MOD (uses FLOOR)
REM (uses TRUNCATE)
1+
1-
Array functions
MAKE-ARRAY
VECTOR
AREF
Compiler functions
COMPILE
COMPILE-FILE
DEFVAR
EVAL-WHEN
Declaration function
DECLARE
PROCLAIM
THE
Type functions
TYPE-OF
DEFTYPE
List functions
CAR
CDR
CADR,...,CDDDDR
FIRST, SECOND,...,TENTH
LAST
NTH
NTHCDR
CONS
APPEND
LIST
NCONC
ASSOC (uses EQL)
SUBST
Sequence functions
EQL
LENGTH
ELT
FIND
POSITION
CONCATENATE
REDUCE
REMOVE
REVERSE
EVERY
SOME
Data storage functions
SETF
SETQ
SET
General testing functions
AND
OR
NOT
NULL
NUMBERP
SYMBOLP
LISTP
ENDP
CONSP
TYPEP
EQ
EQL
EQUAL
MEMBER
>
>=
=
<=
<
ZEROP
MINUSP
PLUSP
EVENP
ODDP
Flow of control functions
COND
IF
WHEN
UNLESS
CASE (T ans OTHERWISE match anything)
DO
DOLIST
DOTIMES
LOOP
PROG
TAGBODY
GO
BLOCK
RETURN
RETURN-FROM
PROG1
PROG2
PROGN
MAPC
MAPCAN
MAPCAR
MAP
CATCH
THROW
UNWIND-PROTECT
ERROR
From: Barry Wilkes
Subject: Re: Implementation Favoritism, a question of Lisp mindsets
Date:
Message-ID: <87lly4fggh.fsf@wilde.bew.org.uk>
synthespian <···········@uol.com.br> writes:
>
> Here's a "subset" as suggested by Robert Wilensky's book. It doesn't go into
> OOP, but my guess is the OP shoudn't go into CLOS before grasping such a
> subset.
>
>
I cannot *begin* to express how much I disagree with an awful lot of the
entries below. Are you *really* suggesting that a newbie learns :
> CADR,...,CDDDDR
...
> DEFMACRO
> DEFSETF
...
> Declaration function
> DECLARE
> PROCLAIM
> THE
...
> SETQ
> SET
...
> PROG
> TAGBODY
> GO
> BLOCK
> RETURN
> RETURN-FROM
> PROG1
> PROG2
*before* they learn CLOS? Why? What on earth is so complex about defclass
when compared to defstruct when used in a similar way? Why should someone
need to know about 'set' before they use 'defmethod'? I don't think I have
*ever* used 'set' in any of my code. And, please, WHY should someone know
about 'cddddr' and 'tagbody..go' before using 'defgeneric'? In my view,
unless you are writing some pretty hairy macros (we are talking a newbie here)
you should *not* be using 'tagbody..go' in code written today. They are from
another time, another place.
I could continue, but I think I have made my point. It is more important that
someone coming to the language learns it as it is (mostly) used and written
today, and that includes CLOS. It doesn't, on the whole, include prog1,
unless (again) you are writing macros.
As for the stuff on declarations, *that* is something that a newbie *should*
leave until later. Premature optimisation, and all that...
Barry.
--
If in the last few years you haven't discarded a major opinion or
acquired a new one, check your pulse. You may be dead.
-- Gelett Burgess (1866-1951)
Barry Wilkes wrote:
> synthespian <···········@uol.com.br> writes:
>
>
>> Here's a "subset" as suggested by Robert Wilensky's book. It doesn't go into
>>OOP, but my guess is the OP shoudn't go into CLOS before grasping such a
>>subset.
>>
>>
>
> I cannot *begin* to express how much I disagree with an awful lot of the
> entries below. Are you *really* suggesting that a newbie learns :
>
>
>> CADR,...,CDDDDR
>
> ...
>
>> DEFMACRO
>> DEFSETF
>
> ...
>
>>Declaration function
>> DECLARE
>> PROCLAIM
>> THE
>
> ...
>
>> SETQ
>> SET
>
> ...
>
>> PROG
>> TAGBODY
>> GO
>> BLOCK
>> RETURN
>> RETURN-FROM
>> PROG1
>> PROG2
>
>
> *before* they learn CLOS? Why? What on earth is so complex about defclass
> when compared to defstruct when used in a similar way? Why should someone
> need to know about 'set' before they use 'defmethod'? I don't think I have
> *ever* used 'set' in any of my code. And, please, WHY should someone know
> about 'cddddr' and 'tagbody..go' before using 'defgeneric'? In my view,
> unless you are writing some pretty hairy macros (we are talking a newbie here)
> you should *not* be using 'tagbody..go' in code written today. They are from
> another time, another place.
OK, valid point. The list was copied from Wilenky's book and, being I
newbie myself, I just assumed it was valid. It is true that defclass is
not so complex when compared to defstruct...
My intention was about posting an "authoritative" subset of the
language. The issue of a "learning subset" has come up before and, to my
knowledge, it hasn't been resolved or agreed upon.
>
> I could continue, but I think I have made my point. It is more important that
> someone coming to the language learns it as it is (mostly) used and written
> today, and that includes CLOS. It doesn't, on the whole, include prog1,
> unless (again) you are writing macros.
>
Perhaps you would care to suggest a modification or a subset (or just
would care to comment the list I posted above?)
If I understand you correctly, you suggest CLOS from early on and
macros as the last thing? This is a bit different from the usual order
as presented in most books. You definitely have a point, though.
> As for the stuff on declarations, *that* is something that a newbie *should*
> leave until later. Premature optimisation, and all that...
>
> Barry.
>
Thank you.
Henry Lenzi
From: Barry Wilkes
Subject: Re: Implementation Favoritism, a question of Lisp mindsets
Date:
Message-ID: <87u1crbokh.fsf@wilde.bew.org.uk>
synthespian <···········@uol.com.br> writes:
<Snip>
> If I understand you correctly, you suggest CLOS from early on and macros as
> the last thing? This is a bit different from the usual order as presented in
> most books. You definitely have a point, though.
>
That's exactly what I am saying. If we are talking about someone who has
already had some exposure to programming and wants to get quickly up to speed
on CL, I would recommend Graham's 'ANSI Common Lisp' together with Keene's
'Object-Oriented Programming in Common Lisp.' As for macros, I think that
someone learning lisp should get a feel for how they are used in CL itself
before worrying about writing them. Graham's book gives a good introduction.
I don't really think that a 'you must know this' list is paticularly
helpful -- it's more about coding style. For example, while I initially
learnt CL from Graham, I have not taken on his 'anti-loop' stance. I *like*
loop. But, that is about style, and is something that the person learning
lisp must develop -- a personal style. Reading Graham initially put me off
loop, but seeing it used by others (on this newsgroup and elsewhere) made me
think that it is a powerful, useful tool. I would not claim that this was
right or wrong -- that's my choice. There are people who have far more
experience than me who dislike loop intensly. All *any* book can give you is
a starting point. I would say that the combination of Graham and Keene
will give someone a good starting point. It's then down to them. To learn to
write good code, one must both read good code and write a lot of code for
oneself. There is no other way.
Barry.
--
If in the last few years you haven't discarded a major opinion or
acquired a new one, check your pulse. You may be dead.
-- Gelett Burgess (1866-1951)
Oops! Barry Wilkes <·······@acm.org> was seen spray-painting on a wall:
> synthespian <···········@uol.com.br> writes:
> <Snip>
>> If I understand you correctly, you suggest CLOS from early on and
>> macros as the last thing? This is a bit different from the usual
>> order as presented in most books. You definitely have a point,
>> though.
> That's exactly what I am saying. If we are talking about someone
> who has already had some exposure to programming and wants to get
> quickly up to speed on CL, I would recommend Graham's 'ANSI Common
> Lisp' together with Keene's 'Object-Oriented Programming in Common
> Lisp.' As for macros, I think that someone learning lisp should get
> a feel for how they are used in CL itself before worrying about
> writing them. Graham's book gives a good introduction.
Hear, hear.
I don't see there being a lot of value in spending much time on
DEFSTRUCT, for instance. It isn't much harder to figure out basic use
of DEFCLASS, and you can certainly "scale up" DEFCLASS to do _much_
more sophisticated things. (I find DEFCLASS 'syntax' more compact and
attractive, too, personally...)
> I don't really think that a 'you must know this' list is paticularly
> helpful -- it's more about coding style. For example, while I
> initially learnt CL from Graham, I have not taken on his 'anti-loop'
> stance. I *like* loop. But, that is about style, and is something
> that the person learning lisp must develop -- a personal style.
> Reading Graham initially put me off loop, but seeing it used by
> others (on this newsgroup and elsewhere) made me think that it is a
> powerful, useful tool. I would not claim that this was right or
> wrong -- that's my choice. There are people who have far more
> experience than me who dislike loop intensly. All *any* book can
> give you is a starting point. I would say that the combination of
> Graham and Keene will give someone a good starting point. It's then
> down to them. To learn to write good code, one must both read good
> code and write a lot of code for oneself. There is no other way.
I don't much like that LOOP syntax is complex, but it can get used to
compactly describe very complex control structures.
When LOOP code is hard to read, is this because:
a) LOOP is "bad and evil and should not be used?", or
b) The code was very complex, and hence not easy to read...
--
(reverse (concatenate 'string ··········@" "enworbbc"))
http://www.ntlug.org/~cbbrowne/finances.html
Twice five syllables
Plus seven can't say much but
That's haiku for you.
From: Nikodemus Siivola
Subject: Re: Implementation Favoritism, a question of Lisp mindsets
Date:
Message-ID: <b833sg$4t2d4$1@midnight.cs.hut.fi>
Christopher Browne <········@acm.org> wrote:
> I don't see there being a lot of value in spending much time on
> DEFSTRUCT, for instance. It isn't much harder to figure out basic use
> of DEFCLASS, and you can certainly "scale up" DEFCLASS to do _much_
> more sophisticated things. (I find DEFCLASS 'syntax' more compact and
More sophisticated, yes. Also an order of magnitude slower. Sometimes
things like that matter. ,)
Cheers,
-- Nikodemus
From: Barry Wilkes
Subject: Re: Implementation Favoritism, a question of Lisp mindsets
Date:
Message-ID: <878yu2fhch.fsf@wilde.bew.org.uk>
Nikodemus Siivola <········@kekkonen.cs.hut.fi> writes:
> Christopher Browne <········@acm.org> wrote:
>
> > I don't see there being a lot of value in spending much time on
> > DEFSTRUCT, for instance. It isn't much harder to figure out basic use
> > of DEFCLASS, and you can certainly "scale up" DEFCLASS to do _much_
> > more sophisticated things. (I find DEFCLASS 'syntax' more compact and
>
> More sophisticated, yes. Also an order of magnitude slower. Sometimes
> things like that matter. ,)
>
If CLOS is slower by an order of magnitude for typical things you would use
structures for -- well, I suggest you speak to your vendor. That certainly
isn't the case for the implementation I use.
Barry.
--
If in the last few years you haven't discarded a major opinion or
acquired a new one, check your pulse. You may be dead.
-- Gelett Burgess (1866-1951)
From: Nikodemus Siivola
Subject: Re: Implementation Favoritism, a question of Lisp mindsets
Date:
Message-ID: <b84kc9$4tc8a$1@midnight.cs.hut.fi>
Barry Wilkes <·······@acm.org> wrote:
> If CLOS is slower by an order of magnitude for typical things you would use
> structures for -- well, I suggest you speak to your vendor. That certainly
> isn't the case for the implementation I use.
I use CMUCL, so there's no vendor as such... But I suppose this depends on
what you consider typical: if speed matters I'm probably cruncing floats.
Also, I'm not referring to slot-access speed, but method-call overhead.
If you use functions in speed critical sections anyways, then what does
DEFCLASS buy you?
Cheers,
-- Nikodemus
Nikodemus Siivola <········@kekkonen.cs.hut.fi> writes:
> Barry Wilkes <·······@acm.org> wrote:
>
> > If CLOS is slower by an order of magnitude for typical things you would use
> > structures for -- well, I suggest you speak to your vendor. That certainly
> > isn't the case for the implementation I use.
>
> I use CMUCL, so there's no vendor as such... But I suppose this depends on
> what you consider typical: if speed matters I'm probably cruncing floats.
> Also, I'm not referring to slot-access speed, but method-call overhead.
>
> If you use functions in speed critical sections anyways, then what does
> DEFCLASS buy you?
So you're not talking about defstruct/defclass, but defun/defmethod.
That's a very different divide. What defclass buys you over
defstruct, regardless of whether you use normal functions or generic
functions, is redefinability, and multiple inheritance.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
From: Edi Weitz
Subject: Re: Implementation Favoritism, a question of Lisp mindsets
Date:
Message-ID: <874r4qjdok.fsf@bird.agharta.de>
Nikodemus Siivola <········@kekkonen.cs.hut.fi> writes:
> I use CMUCL, so there's no vendor as such... But I suppose this
> depends on what you consider typical: if speed matters I'm probably
> cruncing floats. Also, I'm not referring to slot-access speed, but
> method-call overhead.
Have you tried Gerd Moellmann's improvements to CMUCL's PCL? They'll
most likely be integrated into the next release and are currently
available here:
<http://cvs2.cons.org/ftp-area/cmucl/experimental/pcl/>
Edi.
From: Nikodemus Siivola
Subject: Re: Implementation Favoritism, a question of Lisp mindsets
Date:
Message-ID: <b84lpk$4tc8a$2@midnight.cs.hut.fi>
Edi Weitz <···@agharta.de> wrote:
> Have you tried Gerd Moellmann's improvements to CMUCL's PCL? They'll
Nope, but thanks for the link. Though I doubt I get the time to look at
them for a fair while. Are you inferring that they make method calls as
fast as function calls?
Why do I think even a small method call overhead is significant in my
case?
I used to break the (unsinged-int 32) call-counter in CMUCL's
profile-package with an overflow whenever I profiled. Took a while before
I figured out what was happening, and adjusted for a lighter workload...
Cheers,
-- Nikodemus
From: Edi Weitz
Subject: Re: Implementation Favoritism, a question of Lisp mindsets
Date:
Message-ID: <87k7dkothg.fsf@bird.agharta.de>
Nikodemus Siivola <········@kekkonen.cs.hut.fi> writes:
> Edi Weitz <···@agharta.de> wrote:
>
> > Have you tried Gerd Moellmann's improvements to CMUCL's PCL?
>
> Nope, but thanks for the link. Though I doubt I get the time to look
> at them for a fair while. Are you inferring that they make method
> calls as fast as function calls?
No, I'm not, I haven't tested it extensively. However, I seem to
recall that Gerd's new PCL implementation was meant to significantly
improve the speed of method calls.
I'd suggest that you either try yourself or ask on cmucl-imp where
people with more knowledge about this subject can respond (including
Gerd himself).
Cheers,
Edi.
A long time ago, in a galaxy far, far away, Nikodemus Siivola <········@kekkonen.cs.hut.fi> wrote:
> Christopher Browne <········@acm.org> wrote:
>
>> I don't see there being a lot of value in spending much time on
>> DEFSTRUCT, for instance. It isn't much harder to figure out basic use
>> of DEFCLASS, and you can certainly "scale up" DEFCLASS to do _much_
>> more sophisticated things. (I find DEFCLASS 'syntax' more compact and
>
> More sophisticated, yes. Also an order of magnitude slower. Sometimes
> things like that matter. ,)
It has been known to be an order of magnitude slower, with bad CLOS
implementations, in years past.
What seems likely to be the right resolution to that?
- To hold internal arguments over whether 'tis nobler to use DEFCLASS
for a particular application, or not?
- Or to get a better implementation?
--
(concatenate 'string "cbbrowne" ·@ntlug.org")
http://cbbrowne.com/info/wp.html
"Access to a COFF symbol table via ldtbread is even less abstract,
really sucks in general, and should be banned from earth."
-- SCSH 0.5.1 unix.c
From: Christopher C. Stacy
Subject: Re: Implementation Favoritism, a question of Lisp mindsets
Date:
Message-ID: <uist4o7wt.fsf@dtpq.com>
>>>>> On 22 Apr 2003 21:53:10 GMT, Christopher Browne ("Christopher") writes:
Christopher> A long time ago, in a galaxy far, far away, Nikodemus Siivola <········@kekkonen.cs.hut.fi> wrote:
>> Christopher Browne <········@acm.org> wrote:
>>
>>> I don't see there being a lot of value in spending much time on
>>> DEFSTRUCT, for instance. It isn't much harder to figure out basic use
>>> of DEFCLASS, and you can certainly "scale up" DEFCLASS to do _much_
>>> more sophisticated things. (I find DEFCLASS 'syntax' more compact and
>>
>> More sophisticated, yes. Also an order of magnitude slower. Sometimes
>> things like that matter. ,)
Christopher> It has been known to be an order of magnitude slower, with bad CLOS
Christopher> implementations, in years past.
Christopher> What seems likely to be the right resolution to that?
The same solution as with any compiler/runtime that makes
your code run too slow: pay your vendor to fix it.
Matthew Danish wrote:
> On Tue, Apr 15, 2003 at 09:59:05AM +0200, M H wrote:
>>For a first Lisp-experience I would go for the Scheme-dialect of Lisp
>>(you mentioned Dr.Scheme which is a good platform for learning). There
>>is good literature on the web (Abelson & Sussman: "Structure and
>>Interpretation of Computer Programs", Felleisen et al. "How to design
>>programs") and this dialect is smaller than, e.g., Common Lisp.
>
>
> Why? I've found every Scheme environment I've tried--including
> DrScheme--to be lacking in comparison to the CL environments. If you
> want to learn Lisp, you should start with CL. Xanalys LispWorks offers
> an excellent IDE for personal use, or Emacs in combination with any of
> the other CLs works well.
>
> Scheme's "simplicity" does not in any way aid the learning process, and
> it only discourages potential future Lispers. The several good books
> that use Scheme can easily be paralleled with CL.
Name one CL book, targeted towards beginners, which resembles SICP in
how it teaches "how to think functionally". I know Graham's and
Norvig's books and I think they are outstanding. But they do not
explain how to work with functions returning functions and taking
functions as arguments. To beginners, these things are difficult to
grasp (not to speak about students who have already touched C or Java).
Background: At my university we just switched from Java to Scheme to
teach computer science fundamentals to about 350 first-year students. My
experience was: (1) Students need good literature targeted towards
beginners. (2) A programming envionment which especially supports
beginners is a plus (in DrScheme you have different language levels, in
some you can execute your code step-by-step stepping forwards and
backwards; also the error messages are helpful to beginners). (3) Some
things are more consistent in Scheme than they are in CL (names of
functions, e.g.).
> Better to learn Scheme when you already know what Lisp can do.
To cite Paul Graham (http://www.paulgraham.com/faq.html)
>Common Lisp is powerful but ugly. Scheme is small and clean, but the
>standard only defines the inner core of the language. If I had to
>deliver an application I'd probably use Common Lisp; if I were teaching
>a course I might use Scheme (but with Common Lisp macros).
Matthias
On Tue, Apr 15, 2003 at 08:53:38PM +0200, M H wrote:
> Name one CL book, targeted towards beginners, which resembles SICP in
> how it teaches "how to think functionally". I know Graham's and
> Norvig's books and I think they are outstanding. But they do not
> explain how to work with functions returning functions and taking
> functions as arguments. To beginners, these things are difficult to
> grasp (not to speak about students who have already touched C or
> Java).
I don't have Graham's book on hand, but I do know that Norvig's book is
not entirely devoid of functional programming techniques (and even
implements call/cc). However, you are making a mistake. You are
assuming that ``thinking functionally'' is overwhelmingly important. A
great thing about PAIP is that it covers many different ways of
thinking. With *Lisp*, functional programming is not so important that
it should trump all other paradigms. This is a Lisp group, and the OP
asked about Lisp programming, so I think it's fair to say that FP is not
held as the One True Way here.
On a side note, I never finished SICP myself, got tired of it.
> Background: At my university we just switched from Java to Scheme to
> teach computer science fundamentals to about 350 first-year students.
> My experience was: (1) Students need good literature targeted towards
> beginners. (2) A programming envionment which especially supports
> beginners is a plus (in DrScheme you have different language levels,
> in some you can execute your code step-by-step stepping forwards and
> backwards; also the error messages are helpful to beginners). (3) Some
> things are more consistent in Scheme than they are in CL (names of
> functions, e.g.).
So basically, we're going to have another 350 students who think that
Scheme is Lisp and that you can only use recursion and lists. And Lisp
is interpreted only.
> To cite Paul Graham (http://www.paulgraham.com/faq.html)
> >Common Lisp is powerful but ugly. Scheme is small and clean, but the
> >standard only defines the inner core of the language. If I had to
> >deliver an application I'd probably use Common Lisp; if I were
> >teaching a course I might use Scheme (but with Common Lisp macros).
I really don't see any reason why you wouldn't want to use your delivery
language for learning purposes. Especially when said delivery language
is as advanced. Truth be told, I'm having a lot of trouble figuring out
what niche Scheme fits into. CL fits the ``industrial strength dynamic
programming language'' bill, and Haskell/ML fits the ``functional
programming academic language'' mold.
--
; Matthew Danish <·······@andrew.cmu.edu>
; OpenPGP public key: C24B6010 on keyring.debian.org
; Signed or encrypted mail welcome.
; "There is no dark side of the moon really; matter of fact, it's all dark."
In article <·····················@lain.cheme.cmu.edu>, Matthew Danish
<·······@andrew.cmu.edu> wrote:
> I don't have Graham's book on hand, but I do know that Norvig's book is
> not entirely devoid of functional programming techniques (and even
> implements call/cc).
I am a novice at this Lisp stuff, so I could well be wrong on some
points below.
Least anyone mis-interprets the following part of your post, namely:
> .....programming techniques (and even implements call/cc).
I would like to clarify a few points, for any newbie lurkers.
For example, this "full strength" version of call/cc in Scheme runs
okay:
(from page 771 of Norvig's book)
=> (+ 1 (call/cc (lambda (cc)
(set! old-cc cc)
(+ 20 (cc 300)))))
301
=> (old-cc 500
501
Norvig explains what is going on above in the Scheme code:
"Here, we first computed 301, just as before, but along the way saved
cc in the global variable old-cc. Afterward, calling (old-cc 500)
returns (for the second time) to the point in the computation where 1
is added, this time returning 501. The equivalent Common Lisp code
leads to an error"
Then Norvig shows the "equivalent" CL code below:
> (+ 1 (catch 'tag (+ 20 (throw 'tag 300))))
301
> (throw 'tag 500)
Error: there was no pending CATCH for the tag TAG
Norvig explains:
"In other words, call/cc's continuations have indefinite extent, while
throw/catch tags only have dynamic extent."
This points up the fact that any trivial attempt to duplicate what
Scheme continuations do by using CL's catch, throw, tag, block, go,
tagbody, return-from, and other built-in CL constructs will just not
work in many cases.
To get the full power of call/cc in Common Lisp, a full-blown
Scheme-like interpreter would have to be created within Common Lisp,
which Norvig describes how to do in pages 773-776 of his book.
I am not all that certain that Norvig covered all bases with this
imbedded interpreter, so I plan to check it out on some tough cases,
like "unwind" and "wind" techniques, and rather hairy coroutines
running the "Samefringe" problem, and other nasty applications of
coroutines.
I really hope that Norvig's imbedded interpreter passes my tests,
because I would like to have the option of using "real" continuations
within CL.
Mark-
From: Tim Bradshaw
Subject: Re: Implementation Favoritism, a question of Lisp mindsets
Date:
Message-ID: <ey3el42n2sd.fsf@cley.com>
* Mark Conrad wrote:
> I really hope that Norvig's imbedded interpreter passes my tests,
> because I would like to have the option of using "real" continuations
> within CL.
Why not just *use scheme* if what you want is call/cc?
--tim
Tim Bradshaw <···@cley.com> writes:
> * Mark Conrad wrote:
>
> > I really hope that Norvig's imbedded interpreter passes my tests,
> > because I would like to have the option of using "real" continuations
> > within CL.
>
> Why not just *use scheme* if what you want is call/cc?
I'd suggest using Paul Graham's continuations-in-CL system instead. I
suspect that anyone using it, if they thought twice any time they used
continuations, would pretty quickly figure out that (almost?) all its
uses can be better handled in CL another way. Switching to scheme is
just going to reinforce the erronious notion that continuations are
actually useful, as opposed to a cool toy.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
From: Edi Weitz
Subject: Re: Implementation Favoritism, a question of Lisp mindsets
Date:
Message-ID: <878yua4p14.fsf@bird.agharta.de>
Mark Conrad <······@iam.invalid> writes:
> I really hope that Norvig's imbedded interpreter passes my tests,
> because I would like to have the option of using "real"
> continuations within CL.
This whole call/cc thing seems like a straw man to me. If you're
really interested in learning Common Lisp try to forget about
continuations for some time, try to write larger programs and look at
larger programs others have written. Then, after a couple of months,
you might want to raise the issue again and ask yourself whether you
ever really _needed_ the whole call/cc machinery for a _real_ problem
you came across.
Common Lisp has been designed by some _very_ smart people and you can
bet they knew about continuations - there are reasons why they weren't
included. This subject has been beaten to death here often enough but
you might want to search Google Groups for c.l.l postings about
"continuations" or "call/cc", specifically those by Kent M
Pitman. Here are some starting points:
<http://www.nhplace.com/kent/PFAQ/unwind-protect-vs-continuations.html>
<http://groups.google.com/groups?selm=slrnapmp2a.2bbm.Gareth.McCaughan%40g.local>
<http://groups.google.com/groups?selm=sfwwv2rubgp.fsf%40world.std.com>
Of course, if you decide before the fact that you can't live without
call/cc just use Scheme as Tim Bradshaw has already proposed...
Edi.
In article <··············@bird.agharta.de>, Edi Weitz <···@agharta.de>
wrote:
> > I really hope that Norvig's imbedded interpreter passes my tests,
> > because I would like to have the option of using "real"
> > continuations within CL.
>
> This whole call/cc thing seems like a straw man to me.
Of course, that is your prerogative, a personal opinion. I also have
my own personal opinions, believing OOP is a "straw man".<g>
As to whether continuations, OOP, or anything else is useful, now that
depends on what we are trying to do with our programs, doesn't it?
Lisp is touted as a language which is very good for creating the
initial-concept of some problem one is trying to solve.
This is how I intend to use Lisp, in order to take advantage of Lisp's
unique strengths.
With the Initial Concept, one does not usually have all the information
that one desires to have, in order to solve the problem by way of a
computer program.
Often in such a 'non-deterministic' sort of program, where crucial data
is lacking, a lot of brute-force searching has to take place in order
to 'bracket' missing data, to at least get a small range of data that
might contain what one is looking for.
Once the missing data is found 'within bounds', it becomes a lot easier
to get answers with enough precision to perhaps solve the overall
problem.
So one real application of using full-blown continuations is to speed
up these brute-force searches to the point where it is feasible to do
searching in the first place, by exotic backtracking techniques using
full-strength continuations
These continuations can avoid searching paths that show little or no
promise, thereby saving time and making the search worthwhile.
Now we could use CL's crippled continuations, implemented by these
built-in CL constructs:
throw
catch
block
go
tag
unwind-protect
prog
tagbody
return
return-from
...but continuations built using these built-in constructs can't do
things that real industrial-strength continuations can do.
We could use Paul Graham's six macros that implement continuations in
CL. They are a little better but still no cigar. The code of these
six macros is very non-intuitive compared to real call/cc
continuations, leading to the chance that mistakes will be made in
coding, and creating a code-maintenance nightmare.
We could temporarily load a Scheme application into RAM memory long
enough to 'do a continuation' - then reload CL back into RAM memory,
but the nature of some backtracking searches is such that this would
have to be done thousands of times for intermediate calculations,
making the search take an intolerable time.
We could build Norvig's imbedded call/cc interpreter, which preserves
the full power of Scheme's call/cc continuations, (including creating
continuations with indefinite extent) - and that is the approach that I
am going to take.
Mark-
In article <··············@bird.agharta.de>, Edi Weitz <···@agharta.de>
wrote:
> Common Lisp has been designed by some _very_ smart people and you can
> bet they knew about continuations - there are reasons why they weren't
> included.
No doubt.
> This subject has been beaten to death here often enough but
> you might want to search Google Groups for...<snipped>...
I will look up your references as to why the designers decided not to
implement continuations, it should be interesting.
They CL designers made a compromise, allowing CL users to create
'crippled' continuations using catch, throw, etc., which can do some of
the things that can be done with more robust continuations.
The fact that many CL users yearn for continuations shows that the
designers of CL might have goofed a little bit when they assumed that
users would not miss industrial strength continuations.
CL is so flexible that industrial strength continuations _should_ be
able to be added to CL, using Norvig's imbedded call/cc interpreter,
assuming Norvig covered all bases in his design of the imbedded
interpreter.
On page 774 Norvig even claims that his interpreter will even support
continuations that have "indefinite extent", as in Scheme.
Norvig's imbedded interpreter will run slower, due to the fact that the
heap is used for storage instead of stacks, but that should not create
all that much of a problem, because CL's garbage collector is
efficient.
It should be interesting when I compare the speed of the imbedded
interpreter against Scheme's continuations.
A note to other Lisp newbies like me:
There is no reason to fear continuations. They are merely a way to
jump out of a function before the function would normally finish.
The function is just "paused" at the point where the continuation was
activated in the middle of the function.
The function can then be "resumed" later if desired, at the exact point
in the code where it was paused or interrupted.
As you can imagine, jumping out of a function before it is normally due
to finish can cause all sorts of problems.
Jumping back into the middle of a 'suspended' function can also cause
all sorts of problems.
Despite all this, continuations allow for all sorts of flexibility if
they are used when no other means is available to solve a particular
programming problem.
Mark-
On Wed, Apr 16, 2003 at 10:24:45PM +0000, Mark Conrad wrote:
> They CL designers made a compromise, allowing CL users to create
> 'crippled' continuations using catch, throw, etc., which can do some of
> the things that can be done with more robust continuations.
>
> The fact that many CL users yearn for continuations shows that the
> designers of CL might have goofed a little bit when they assumed that
> users would not miss industrial strength continuations.
You are taking a rather strange view of things. If given a choice
between having call/cc only, or having a condition system, catch/throw,
block/return-from, tagbody/go, etc... I will choose the latter. While
call/cc may be used to implement these non-local control transfer
constructs, it is a gigantic pain in the ass. I do not want to use
call/cc to do these mundane tasks. The condition system is infinitely
more useful than call/cc, and Scheme's lack of it is one reason I will
not use Scheme.
I wouldn't call Scheme's continuations industrial-strength anyway. They
are almost useless in industry. Academic-strength, perhaps.
> CL is so flexible that industrial strength continuations _should_ be
> able to be added to CL, using Norvig's imbedded call/cc interpreter,
> assuming Norvig covered all bases in his design of the imbedded
> interpreter.
>
> On page 774 Norvig even claims that his interpreter will even support
> continuations that have "indefinite extent", as in Scheme.
It is not magic, you know.
> Norvig's imbedded interpreter will run slower, due to the fact that the
> heap is used for storage instead of stacks, but that should not create
> all that much of a problem, because CL's garbage collector is
> efficient.
>
> It should be interesting when I compare the speed of the imbedded
> interpreter against Scheme's continuations.
You are failing to understand the implementation of call/cc. I highly
recommend that you sit down and implement a very simple eval function
which can handle call/cc. The easiest way to write this is to do it in
continuation-passing style, and you do not need call/cc to do this.
Norvig covers this, so I presume you are following it.
What you will learn is that support for call/cc must be built into the
implementation of every operator of the language. This also increases
the difficulty of generating efficient code. Hopefully you will also
pick up the difference between writing an interpreter and having call/cc
in CL. Using an embedded interpreter is NOT what I mean by embedding a
language into CL. Compiling into CL is closer; but that is what macros
do.
Personally, I think you can do everything you need to do simply by
writing in continuation-passing style.
--
; Matthew Danish <·······@andrew.cmu.edu>
; OpenPGP public key: C24B6010 on keyring.debian.org
; Signed or encrypted mail welcome.
; "There is no dark side of the moon really; matter of fact, it's all dark."
In article <·····················@lain.cheme.cmu.edu>, Matthew Danish
<·······@andrew.cmu.edu> wrote:
> What you will learn is that support for call/cc must be built into the
> implementation of every operator of the language.
I suspected that. Norvig does not say one way or the other whether
his interpreter faithfully supports call/cc in most all respects.
Anyhow, I will have fun finding out what his interpreter will do.
Mark-
From: Kenny Tilton
Subject: Re: Implementation Favoritism, a question of Lisp mindsets
Date:
Message-ID: <3E9DE5C4.2030207@nyc.rr.com>
Mark Conrad wrote:
> A note to other Lisp newbies like me:
>
> There is no reason to fear continuations. They are merely a way to
> jump out of a function before the function would normally finish.
>
> The function is just "paused" at the point where the continuation was
> activated in the middle of the function.
>
> The function can then be "resumed" later if desired, at the exact point
> in the code where it was paused or interrupted.
What is a good example demonstrating the utility of such a thing,
something that is made much easier/clearer/whatever by continuations?
--
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:
>What is a good example demonstrating the utility of such a thing,
>something that is made much easier/clearer/whatever by continuations?
The ability to teach undergraduates about...continuations!
In article <················@nyc.rr.com>, Kenny Tilton
<·······@nyc.rr.com> wrote:
> > There is no reason to fear continuations. They are merely a way to
> > jump out of a function before the function would normally finish.
> >
> > The function is just "paused" at the point where the continuation was
> > activated in the middle of the function.
> >
> > The function can then be "resumed" later if desired, at the exact point
> > in the code where it was paused or interrupted.
>
> What is a good example demonstrating the utility of such a thing,
> something that is made much easier/clearer/whatever by continuations?
Heck, I dunno, I am just a clueless newbie.
> ...easier/clearer/whatever by continuations?
Easier/clearer? - definitely not, continuations are tough to use, at
least for me, and they are far from being clear.
Hmm, that leaves "whatever"<g>
Lemme answer this indirectly, to see if it makes any sense to you.
(or to me, for that matter!)
If a new program I created is being executed, and I have periodic
"tests" within the code to determine whether or not the program is
making progress in solving the overall problem, and the tests start
returning indications like:
1) The built-in test code indicates that all is not well. Not only is
the program not making progress, but it is going backwards as regards
to solving the overall problem. Progress _could_ be made if it could
somehow get out of this dead-end part of the program, and jump into a
different part of the program before too much time is wasted.
2) The program needs additional information from a function that has
already completed running in an earlier part of the program. The
program needs to suspend what it is presently doing, get the needed
additional information from the earlier function, then jump back into
the suspended code section and resume running with the additional
information.
3) The program has several interdependent functions running
"at-the-same-time". The built-in tests indicate when it is time to
suspend operation of the one "active" function, and resume operation of
one of the "dormant" functions. Ordinary multitasking OS's can't
handle resuming a function at a specific point inside the function's
code.
All the above off the top of my head. If I was not a clueless newbie,
I could likely think of many more uses for continuations.
Continuations are basically "jumps", something like the "goto"
statements in the old fashioned Basic language.
When used with care, continuations have benefits.
For example, the ultimate "flexible" language is machine-code, which is
loaded with jumps of all sorts.
I think having the option of gaining added flexibility in CL is a good
thing, _provided_ continuations are used with extreme care.
Mark-
> 1) The built-in test code indicates that all is not well. Not only
> is the program not making progress, but it is going backwards as
> regards to solving the overall problem. Progress _could_ be made if
> it could somehow get out of this dead-end part of the program, and
> jump into a different part of the program before too much time is
> wasted.
This sounds like backtracking. Continuations CAN be used to implement
backtracking, but there are other ways to do it.
> 2) The program needs additional information from a function that has
> already completed running in an earlier part of the program. The
> program needs to suspend what it is presently doing, get the needed
> additional information from the earlier function, then jump back
> into the suspended code section and resume running with the
> additional information.
>
> 3) The program has several interdependent functions running
> "at-the-same-time". The built-in tests indicate when it is time to
> suspend operation of the one "active" function, and resume operation
> of one of the "dormant" functions. Ordinary multitasking OS's can't
> handle resuming a function at a specific point inside the function's
> code.
These two both sound like something that would be accomplished using
various multiprocessing constructs. Continuations can be used to
implement multiprocessing but there are other ways to do it.
I am particularly confused by your comment that "Ordinary multitasking
OS's can't handle resuming a function at a specific point inside the
function's code." I wonder what exactly you think ordinary
multitasking OSs do. (Or perhaps by "ordinary" you mean "cooperative"
or "products of Microsoft" or something, in which case I could
understand your comment a little better....)
One of the points of Scheme is to implement extremely powerful,
general constructs that can be used to implement programming
constructs that people are used to. Pedagogically speaking this seems
to be a good idea. However, for getting things done it is a bit like
asking a carpenter to carry the entire carpentry shop to the job site
in order to pound some nails. At the same time, as Eric Naggum once
said, using Scheme is like going to buy a beer mug and getting a pile
of sand and an electric furnace. You wind up with a lot of baggage,
but you still have to do much of the work yourself.
For example, one of the drawbacks of Scheme continuations is that they
require everything to be heap-allocated, since if a function allocates
things on the stack it can't be resumed once it has returned. This
can lead to inefficiency.
Another drawback is that it complicates the implementation of
unwind-protect. If you save a continuation inside an unwind-protect,
should you execute the exit clauses of the unwind-protect every time
you resume the continuation? This could result in, for example,
closing already closed files. Unwind-protect is such a valuable
feature that this alone would be considered a killer for call/cc by
some.
Here's a quotation from Kent Pitman about this:
I, for one, am glad not to see continuations in CL. If someone
proposed adding them, I would argue strongly against the move. I
feel about them the same way as others feel about GO. They
encourage unstructured programming and I think they're a semantic
mess. (No, I don't mean they can't be defined in a formal
semantics. I mean there is no proof that being modelable in a
formal semantics implies being a good way for a human being to
think about or describe something.) Critically absent from
continuations (i.e., procedurally embedded in them, and therefore
not always "apparent"--halting problems and all, you know) is the
answer to the question "is this the last time this continuation
will return?", which makes a mess of any attempt to attach a
rational semantics to unwind-protect. Scheme doesn't offer
unwind-protect, of course; it leaves it as an exercise to the
(human) reader. But you can see hints of how ugly the situation
would be in 6.6.1 Ports in the Revised^5 Report on Scheme by
realizing that unwind-protect or its equivalent is subprimitive
to call-with-input-file, and realizing the war between
unwind-protect and continuations is what leads to the mega-yuck
wording there.
> All the above off the top of my head. If I was not a clueless
> newbie, I could likely think of many more uses for continuations.
>
> Continuations are basically "jumps", something like the "goto"
> statements in the old fashioned Basic language.
>
> When used with care, continuations have benefits.
>
> For example, the ultimate "flexible" language is machine-code, which
> is loaded with jumps of all sorts.
>
> I think having the option of gaining added flexibility in CL is a
> good thing, _provided_ continuations are used with extreme care.
Nope, continuations aren't jumps. They are more powerful than that
because they snapshot the state of the computation.
The problem with continuations is not their *use* so much as their
implementation. Implementing continuations has an effect on the
entire system, but they only solve a small number of problems (in
fact, you yourself are somewhat hard-pressed to name problems they
solve). Thus Common Lisp designers, who are less concerned about
pedagogy and more concerned for obtaining production code, turn to
less general but also less expensive mechanisms for solving the
problems that continuations would otherwise solve.
This is a clue. Note that if you "have" it, you will no longer be a
clueless newbie. Are you willing to make the jump?
--
Fred Gilham ······@csl.sri.com
The amazing thing is, back when I was a C++ programmer, I thought that
[Design Patterns] was SUCH a great book. And I guess it was, in a
way: it made it possible to use C++ and get something done. In the
long run, of course, that may have been a disservice... - Alain Picard
Kenny Tilton <·······@nyc.rr.com> writes:
> What is a good example demonstrating the utility of such a thing,
> something that is made much easier/clearer/whatever by
> continuations?
This deserves the label "interesting":
http://www.beta4.com/seaside2/
From: Kenny Tilton
Subject: Re: Implementation Favoritism, a question of Lisp mindsets
Date:
Message-ID: <3E9ECA7E.2020005@nyc.rr.com>
Nils Kassube wrote:
> Kenny Tilton <·······@nyc.rr.com> writes:
>
>
>>What is a good example demonstrating the utility of such a thing,
>>something that is made much easier/clearer/whatever by
>>continuations?
>
>
> This deserves the label "interesting":
>
> http://www.beta4.com/seaside2/
This particular example of being able to code a web page session as one
continuous top-to-bottom /code/ session sounds yummy, but we don't
program like that anymore anyway, because we need a modeless
architecture to give the user the flexible experience GUI apps were
designed to provide.
That means having enough state to pick up wherever they are and do
whatever they want us to do. And since I cannot anticipate "whatever",
hell, I /want/ to come in the top of my app, not start from a
continuation that will "start" me in the middle of a routine somewhere.
--
kenny tilton
clinisys, inc
http://www.tilton-technology.com/
---------------------------------------------------------------
"Everything is a cell." -- Alan Kay
From: Tim Bradshaw
Subject: Re: Implementation Favoritism, a question of Lisp mindsets
Date:
Message-ID: <ey3adeqdpec.fsf@cley.com>
* Mark Conrad wrote:
> The fact that many CL users yearn for continuations [...]
Many? How many? And of those `many' how many understand the cost of
continuations-in-the-language? And how does this set compare with
those who insist on mandatory TCO?
> shows that the
> designers of CL might have goofed a little bit when they assumed that
> users would not miss industrial strength continuations.
Or that they made an informed decision based on the implementation
costs versus the benefits. But no, of course, they were fools, we
know that.
Please, the language you want is called *scheme* and it's over that
way.
--tim
From: Edi Weitz
Subject: Re: Implementation Favoritism, a question of Lisp mindsets
Date:
Message-ID: <87istenjhl.fsf@bird.agharta.de>
Mark Conrad <······@iam.invalid> writes:
> The fact that many CL users yearn for continuations shows that the
> designers of CL might have goofed a little bit when they assumed
> that users would not miss industrial strength continuations.
I have yet to see a Common Lisp user who "yearns" for
continuations. (Obviously, my definition of a "user" is someone who
has actually used the language for serious stuff.)
Edi.
In article <·························@iam.invalid>,
Mark Conrad <······@iam.invalid> wrote:
> In article <··············@bird.agharta.de>, Edi Weitz <···@agharta.de>
> wrote:
>
> > Common Lisp has been designed by some _very_ smart people and you can
> > bet they knew about continuations - there are reasons why they weren't
> > included.
>
> No doubt.
>
> > This subject has been beaten to death here often enough but
> > you might want to search Google Groups for...<snipped>...
>
> I will look up your references as to why the designers decided not to
> implement continuations, it should be interesting.
Please read those references first, _before_ you speculate and make
strong claims about Common Lisp, its designers and the "strength" of
continuations. It's easy to find what appear to be conceptual
shortcomings in Common Lisp on a superficial level, when in fact most of
the decisions in the specification are well-balanced. You need more than
a newbie's first look to find the real weak spots.
BTW, even continuations are not as general as you might think at the
moment. Monads are a generalization of continuations that have found
their way into the Haskell programming language (and they seem to me to
be much easier to be implemented in Common Lisp than continuations). And
they have already found another generalization of monads called arrows.
And there surely will be even further generalization of these things in
the future. "Only the sky is the limit."
At a certain stage you have to stop generalizing things and think about
which of the concepts are actually useful in practice, and then do some
real hacking.
So, as has been stated before, if you are really interested in getting
as abstract as possible, then Common Lisp is probably not the right
language for you. There's nothing wrong in trying to get as abstract as
possible, but there's also nothing wrong in not doing that, and Common
Lispers have a tendency towards the latter.
Pascal
--
"If I could explain it, I wouldn't be able to do it."
A.M.McKenzie
In article <······························@news.netcologne.de>, Pascal
Costanza <········@web.de> wrote:
> Monads are a generalization of continuations that have found
> their way into the Haskell programming language (and they seem to me to
> be much easier to be implemented in Common Lisp than continuations).
Thanks for that info'.
> Please read those references first, _before_ you speculate and make
> strong claims about Common Lisp, its designers and the "strength" of
> continuations.
You are gonna take away all my fun, aren't you ;-)
Mark-
From: Jochen Schmidt
Subject: Re: Implementation Favoritism, a question of Lisp mindsets
Date:
Message-ID: <b7l725$9av$01$1@news.t-online.com>
Mark Conrad wrote:
> I will look up your references as to why the designers decided not to
> implement continuations, it should be interesting.
>
> They CL designers made a compromise, allowing CL users to create
> 'crippled' continuations using catch, throw, etc., which can do some of
> the things that can be done with more robust continuations.
>
> The fact that many CL users yearn for continuations shows that the
> designers of CL might have goofed a little bit when they assumed that
> users would not miss industrial strength continuations.
>
> CL is so flexible that industrial strength continuations _should_ be
> able to be added to CL, using Norvig's imbedded call/cc interpreter,
> assuming Norvig covered all bases in his design of the imbedded
> interpreter.
Continuations are a too highlevel tool for a lowlevel need.
Yes it is possible to implement multithreading, a condition system and
backtracking search algorithms using continuations. The question is if it
is really a good idea to do so.
Continuations are like a swiss army knife - they offer from all a bit but
nothing works out. If you want to cut fish for sushi it will be a bad idea
to choose your swiss army knife. The same counts for using it instead of a
real saw or a real screw driver.
Common Lisp is an industrial language. A tool for professional software
developers. Continuations are not an industrial strength tool but a half
arsed emulation utility for real world tools.
ciao,
Jochen
Jochen Schmidt <···@dataheaven.de> writes:
> Continuations are like a swiss army knife - they offer from all a bit but
> nothing works out. If you want to cut fish for sushi it will be a bad idea
> to choose your swiss army knife. The same counts for using it instead of a
> real saw or a real screw driver.
You have just insulted my Swiss Army knife and Leatherman, I have
graduated to a Leatherman. The reason I think that your comparison is
unfair is that the root reason for the "tool box in a pocket" is so
that when you need a tool unexpectedly you have a good shot at having
it and that is a good thing. Scheme does not have that reason for
call/cc, from what little I know about it. I believe the reason is
the same as the refusal to have a looping construct, I know they
recently added "do" for looping. Remember recursion was pure and
looping was bad. call/cc was pure and all the useful bits of call/cc
aka the continuation system was bad.
marc
Marc Spitzer wrote:
> ....Scheme does not have that reason for
> call/cc, from what little I know about it. I believe the reason is
> the same as the refusal to have a looping construct, I know they
> recently added "do" for looping.
True. Even more recently, in the early 1980s, Common Lisp followed
Scheme's lead on this by adopting a version of DO whose syntax is
similar to that of Scheme, albeit with a subtly different semantics.
Will
In article <···············@news.t-online.com>, Jochen Schmidt
<···@dataheaven.de> wrote:
> Continuations are not an industrial strength tool but a half
> arsed emulation utility for real world tools.
Well, I am still trying to make up my mind as to whether continuations
in CL are worth the trouble, as far as I personally am concerned.
My present attitude towards them are to only use them if no other way
is available to do the same thing.
For example, interdependent co-routines, where one of the functions is
run for awhile, then the other function, etc.
Multithreading OS's won't let me pick the exact place in the suspended
function where I want to resume operation. Continuations will.
Another thing, if I have a CL function that takes a long while to run,
say an hour for example, I can use a continuation to halt the function
half way through, shut off my computer, then resume operation later at
the exact point that I interrupted the function.
With conventional CL using catch/throw etc., I would have to restart
the function at the beginning.
Mark-
On Thu, Apr 17, 2003 at 02:38:42PM +0000, Mark Conrad wrote:
> My present attitude towards them are to only use them if no other way
> is available to do the same thing.
You will find that there is almost always another way.
> For example, interdependent co-routines, where one of the functions is
> run for awhile, then the other function, etc.
A very cooperative way of multi-tasking.
> Multithreading OS's won't let me pick the exact place in the suspended
> function where I want to resume operation. Continuations will.
That's not what Multithreaded OSes are for, though. Where is the
pre-emption, as well?
> Another thing, if I have a CL function that takes a long while to run,
> say an hour for example, I can use a continuation to halt the function
> half way through, shut off my computer, then resume operation later at
> the exact point that I interrupted the function.
You have very strange ideas. First, you've forgotten the need to
program your function in such a way that this is possible. Next, you've
forgotten the need to have some way of triggering this "halt", ie. you
must check I/O constantly. Lastly, you forgot to save your image!
> With conventional CL using catch/throw etc., I would have to restart
> the function at the beginning.
* (defun f () (loop))
F
* (F)
;; running ........
;; now I hit Ctrl-C
Interrupted at #x108D3F94.
Restarts:
0: [CONTINUE] Return from BREAK.
1: [ABORT ] Return to Top-Level.
Debug (type H for help)
(UNIX::SIGINT-HANDLER #<unused-arg> #<unused-arg> #.(SYSTEM:INT-SAP #x3FFFE878))
Source:
; File: target:code/signal.lisp
; File has been modified since compilation:
; target:code/signal.lisp
; Using form offset instead of character position.
(DEFINE-SIGNAL-HANDLER SIGINT-HANDLER "Interrupted" BREAK)
0] 0
;; running ....
I will say this once again, since you haven't picked up on it. If you
want Continuation-Passing style, then write your code in CPS!
Catch/throw, conditions, etc, all have more specific purposes and they
do their jobs just fine.
Investigate the CPS interpreter in Norvig's book. It is not difficult.
And it's call/cc is not inferior to Scheme. Call/cc is for hooking into
the implementation's continuations. There is no magic involved.
--
; Matthew Danish <·······@andrew.cmu.edu>
; OpenPGP public key: C24B6010 on keyring.debian.org
; Signed or encrypted mail welcome.
; "There is no dark side of the moon really; matter of fact, it's all dark."
In article <·····················@lain.cheme.cmu.edu>, Matthew Danish
<·······@andrew.cmu.edu> wrote:
> > Another thing, if I have a CL function that takes a long while to run,
> > say an hour for example, I can use a continuation to halt the function
> > half way through, shut off my computer, then resume operation later at
> > the exact point that I interrupted the function.
> > With conventional CL using catch/throw etc., I would have to restart
> > the function at the beginning.
>
> * (defun f () (loop))
>
> F
> * (F)
>
> ;; running ........
> ;; now I hit Ctrl-C
>
> Interrupted at #x108D3F94.
>
> Restarts:
> 0: [CONTINUE] Return from BREAK.
> 1: [ABORT ] Return to Top-Level.
>
> Debug (type H for help)
Your example code will work if I leave the power on to my computer, but
not if I shut the computer off, then power up later.
Is there some CL feature that will allow me to do that, so I can get
away from "continuations" for this particular chore?
Mark-
In article <··············@mycroft.actrix.gen.nz>, Paul Foley
<···@below.invalid> wrote:
> On Fri, 18 Apr 2003 12:30:31 GMT, Mark Conrad wrote:
>
> > Your example code will work if I leave the power on to my computer, but
> > not if I shut the computer off, then power up later.
>
> > Is there some CL feature that will allow me to do that, so I can get
> > away from "continuations" for this particular chore?
>
> What makes you think Scheme would keep working after you turn the
> power off???
Let me clarify what I meant. If CL had continuations, or something
closely approaching continuations, code could be written in such a
manner that I could manually interrupt a long-running function from the
keyboard, then turn the computer power off; I could then turn the
power on later, and resume running the long-running function from the
exact point it was interrupted.
Near as I can determine be looking at Matthew Danish's post below, it
does not appear that his solution will do what I want to do along these
lines, because it appears that he relied on the computer staying
powered up.
> In article <·····················@lain.cheme.cmu.edu>, Matthew Danish
> <·······@andrew.cmu.edu> wrote:
>
> > > Another thing, if I have a CL function that takes a long while to run,
> > > say an hour for example, I can use a continuation to halt the function
> > > half way through, shut off my computer, then resume operation later at
> > > the exact point that I interrupted the function.
> > > With conventional CL using catch/throw etc., I would have to restart
> > > the function at the beginning.
> >
> > * (defun f () (loop))
> >
> > F
> > * (F)
> >
> > ;; running ........
> > ;; now I hit Ctrl-C
> >
> > Interrupted at #x108D3F94.
> >
> > Restarts:
> > 0: [CONTINUE] Return from BREAK.
> > 1: [ABORT ] Return to Top-Level.
> >
> > Debug (type H for help)
>
>
> Your example code will work if I leave the power on to my computer, but
> not if I shut the computer off, then power up later.
>
> Is there some CL feature that will allow me to do that, so I can get
> away from "continuations" for this particular chore?
>
> Mark-
From: Christopher C. Stacy
Subject: Re: Implementation Favoritism, a question of Lisp mindsets
Date:
Message-ID: <u8yu5fcg3.fsf@dtpq.com>
>>>>> On Sun, 20 Apr 2003 13:03:45 GMT, Mark Conrad ("Mark") writes:
Mark> In article <··············@mycroft.actrix.gen.nz>, Paul Foley
Mark> <···@below.invalid> wrote:
>> On Fri, 18 Apr 2003 12:30:31 GMT, Mark Conrad wrote:
>>
>> > Your example code will work if I leave the power on to my computer, but
>> > not if I shut the computer off, then power up later.
>>
>> > Is there some CL feature that will allow me to do that, so I can get
>> > away from "continuations" for this particular chore?
>>
>> What makes you think Scheme would keep working after you turn the
>> power off???
Mark> Let me clarify what I meant. If CL had continuations, or something
Mark> closely approaching continuations, code could be written in such a
Mark> manner that I could manually interrupt a long-running function from the
Mark> keyboard, then turn the computer power off; I could then turn the
Mark> power on later, and resume running the long-running function from the
Mark> exact point it was interrupted.
That's not what "continuations" in Scheme are.
From: Kenny Tilton
Subject: Re: Implementation Favoritism, a question of Lisp mindsets
Date:
Message-ID: <3EA2B975.7010805@nyc.rr.com>
Mark Conrad wrote:
> In article <··············@mycroft.actrix.gen.nz>, Paul Foley
> <···@below.invalid> wrote:
>
>
>>On Fri, 18 Apr 2003 12:30:31 GMT, Mark Conrad wrote:
>>
>>
>>>Your example code will work if I leave the power on to my computer, but
>>>not if I shut the computer off, then power up later.
>>
>>>Is there some CL feature that will allow me to do that, so I can get
>>>away from "continuations" for this particular chore?
>>
>>What makes you think Scheme would keep working after you turn the
>>power off???
>
>
>
> Let me clarify what I meant. If CL had continuations, or something
> closely approaching continuations, code could be written in such a
> manner that I could manually interrupt a long-running function from the
> keyboard, then turn the computer power off; I could then turn the
> power on later, and resume running the long-running function from the
> exact point it was interrupted.
this is getting funny: von Neuman separated code from data, Lisp
accepted code as data, and now here we have a runtime snapshot not just
as data but as persistent data. somehow it is so hard to express the
ongoing state of some computation in a conventional data structure that
one needs to store the computation itself in some cryogenic deep freeze
along with Ted Williams, to be reawakened at some point -- when one gets
to work the next day? me, i would just leave the computer running, which
I do anyway.
just wondering, has the argument in favor of call/cc been backed into a
corner where the only justification is how to yo-yo the system in
mid-run? in a setting that does not have the luxury of a backup
shadowing system to carry on the computation? for an application whose
running computational state cannot be expressed in some conventional,
persistent data structure?
One thing that is consistent throughout this thread is that all the
"application" requirements offered in support of the argument for
call/cc boil down to this: "Suppose I want to use call/cc to solve some
problem. Now..."
kt
clinisys
In article <················@nyc.rr.com>, Kenny Tilton
<·······@nyc.rr.com> wrote:
> just wondering, has the argument in favor of call/cc been backed into a
> corner where the only justification is how to yo-yo the system in
> mid-run?
Not at all. :)
Paul Graham, in his CL book "On Lisp" (1994) - makes many strong points
in favor of using continuations in CL, not even remotely connected with
my posts about "persistant continuations".
His best points are summed up in two pages, 284-285, which should be
required reading for those who ridicule the concept of using CL
continuations. (...and CL macros)
(in his book section "21.3". That section of his "On Lisp" book is
titled "The Less-than-Rapid Prototype")
I want to thank all the fine gentlemen here in this NG for assisting me
in my quest to pursue my own brand of programming in CL.
Unfortunately, I did not save the posts, so I will have to go back in
Google and dig up all the "juicy" posts for my archives.
Mark-
From: Peter Seibel
Subject: Re: Implementation Favoritism, a question of Lisp mindsets
Date:
Message-ID: <m3of307otq.fsf@javamonkey.com>
Mark Conrad <······@iam.invalid> writes:
> In article <················@nyc.rr.com>, Kenny Tilton
> <·······@nyc.rr.com> wrote:
>
> > just wondering, has the argument in favor of call/cc been backed into a
> > corner where the only justification is how to yo-yo the system in
> > mid-run?
>
> Not at all. :)
>
> Paul Graham, in his CL book "On Lisp" (1994) - makes many strong
> points in favor of using continuations in CL, not even remotely
> connected with my posts about "persistant continuations".
>
> His best points are summed up in two pages, 284-285, which should be
> required reading for those who ridicule the concept of using CL
> continuations. (...and CL macros)
Well, his point, on those pages is that contiuations may fall in the
class of constructs that allow you to try out various ideas in the
"get it right" phase before you switch to different constructs in the
"make it fast" phase.
The problem, with this argument, it seems to me, is that the kind of
code you write with continuations is totally different than the kind
of code you write without them. This isn't like using lists and then
later realizing that a vector would be more efficient.
Now continuations might be interesting if you are interested in, as he
says, "experimenting with other aspects of multiple processes, like
scheduling alogirthms". However, these days if you're writing
production software there's probably no point in experimenting with
scheduling algorithms for what will eventually be a multi-threaded
program because you don't get to change the scheduler--it's either in
the OS (native threads) or in your virtual threads implementation.
So, if you're writing a Lisp implementation and are planning on adding
a multiprocessing API--particularly one not built upon OS-level
threads--you might benenift from experimenting with different schemes
implemented on top of continuations.
But if I'm writing programs on top of Lisp, it's not clear--at least
not to me--how prototyping my program with continuations (if they
existed in CL) wouldn't leave me painted in a corner when I realized I
needed to get rid of them in order to make my program efficient. Maybe
you can give us an actual example.
-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:
> The problem, with this argument, it seems to me, is that the kind of
> code you write with continuations is totally different than the kind
> of code you write without them. This isn't like using lists and then
> later realizing that a vector would be more efficient.
Actually, it's just like that. Vectors aren't only efficient lists,
and closures aren't only use-once continuations. If you prototype
your code using lists, you might just find that you've used them in
ways (eg, inserting in the middle) that don't map well to vectors.
You can do the same thing with continuations. But, if you only use
your continuations once, they should map well to closures.
That said, I've played with continuations, but I wouldn't want to
prototype with them, exactly because CL has such a rich set of
alternatives -- I'd be afraid I'd accidentally do something that'd
require major rewriting.
EG, you can write coroutine code in an unnecessarily
continuation-dependant manner. But, you can also use mutual
recursion, and have code that's easier to make efficient (with a good
compiler).
> So, if you're writing a Lisp implementation and are planning on adding
> a multiprocessing API--particularly one not built upon OS-level
> threads--you might benenift from experimenting with different schemes
> implemented on top of continuations.
As someone who's done exactly this, I disagree. I don't think they're
even good for that :-)
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
From: Peter Seibel
Subject: Re: Implementation Favoritism, a question of Lisp mindsets
Date:
Message-ID: <m3k7dn7t31.fsf@javamonkey.com>
···@apocalypse.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
> Peter Seibel <·····@javamonkey.com> writes:
> > So, if you're writing a Lisp implementation and are planning on
> > adding a multiprocessing API--particularly one not built upon
> > OS-level threads--you might benenift from experimenting with
> > different schemes implemented on top of continuations.
>
> As someone who's done exactly this, I disagree. I don't think
> they're even good for that :-)
Okay--I'll take your word for it. Haven't tried myself. ;-)
--
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:
> But if I'm writing programs on top of Lisp, it's not clear--at least
> not to me--how prototyping my program with continuations (if they
> existed in CL) wouldn't leave me painted in a corner when I realized I
> needed to get rid of them in order to make my program efficient. Maybe
> you can give us an actual example.
I am the last person in the world to give such an example, because I am
just starting with learning how to handle continuations.
However, I can suggest an approach, which seems to work for me.
Quickly finding the entry/exit points in the macros I create is fairly
easy, as I demonstrated in my recent post to you.
(the "countdown" macro)
Most users know how to expand macros into ordinary code.
Armed with the above two things, it should not be too difficult to look
at the expanded code, with its known entry and exit points, and rewrite
the code, splitting up the code so that the new entry/exit points
coincide with the beginnings and endings of ordinary rewritten
functions.
Again, let me stress that the overwhelming time consumer, at least for
me, is not converting the code, but rather sketching it out, trying to
get it to run, re-sketching a better version, trying to get that to
run, etc., etc.
I will use any tool at my disposal, including continuations, to make
the initial versions of a program.
Mark-
From: Peter Seibel
Subject: Re: Implementation Favoritism, a question of Lisp mindsets
Date:
Message-ID: <m3bryy4hxu.fsf@javamonkey.com>
Mark Conrad <······@iam.invalid> writes:
> Someone in this thread said that Paul Graham's "On Lisp" book could be
> downloaded via the Internet?
>
> (I forgot to save that post)
Let's see, type "+on lisp graham" into Google and click on the I'm
Feeling Lucky button.
-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:
> > Someone in this thread said that Paul Graham's "On Lisp" book could be
> > downloaded via the Internet?
> >
> > (I forgot to save that post)
>
> Let's see, type "+on lisp graham" into Google and click on the I'm
> Feeling Lucky button.
Okay, I did a Google search and most of the results refered to the
following web site for the book download:
www.paulgraham.com/onlisptext.html
I selected to download it as a pdf file because that is more convenient
for me instead of messing around with a Postscript file.
Initial problems with the download, message in IE
"IE does not know how to handle the download"
I hit the "Application" button on that error screen, then navigated to
my "Acrobat" application, opening it as a helper application for the
download.
The entire 413 page book is a 1-meg download, takes a few minutes on my
slow dialup connection.
Only things missing are 9 "diagrams", which Graham said are missing
from both the pdf and Postscript downloads for some unknown reason.
I don't know how it will reproduce in this post, but here is a rough
idea of one of the nine missing diagrams, the one on page 263
Missing figure 20.2 on page 263 of On Lisp book
- - - - - - - - - - - Two Trees - - - - - - - - - -
a 1
/ \ |
b c 2
/ / | \ / | \
d e f g 3 4 5
| | / |
h i 6 7
Tree One (T1) contains 9 nodes (leaves) "a thru i"
Tree Two (T2) contains 7 nodes (leaves) "1 thru 7"
Lotsa good stuff in the book about how to use macros, much more
comprehensive IMO than Norvig's book.
There are errors in the book pertaining to examples given to explain
continuations in CL, and how to use the six macros that implement
continuations in Common Lisp.
Here are the six macros, with slight changes to help in various ways:
;****************************************************
; Slightly altered version of Paul Graham's macros page 267
(setq %cont% #'identity)
(defmacro =lambda (parms &body body)
`#'(lambda (%cont% ,@parms) ,@body))
(defmacro =defun (name parms &body body)
(let ((f (gensym)))
`(progn
(defmacro ,name ,parms
`(,',f %cont% ,,@parms))
(defun ,f (%cont% ,@parms) ,@body) )))
(defmacro =bind (parms expr &body body)
`(let ((%cont% #'(lambda ,parms ,@body))) ,expr))
(defmacro =values (&rest retvals)
`(funcall %cont% ,@retvals))
(defmacro =funcall (fn &rest args)
`(funcall ,fn %cont% ,@args))
(defmacro =apply (fn &rest args)
`(apply ,fn %cont% ,@args))
;****************************************************
- Notes -
I used a gensym version of the =defun macro to sidestep
variable-capture problems.
I used %cont% throughout instead of Paul Graham's *cont* to alert users
to the fact that %cont% is _not_ a special variable. (dynamic
variable)
Rather it is a top-level lexical variable, visible to all code by
virtue of the fact that all code is within the lexical scope of %cont%
It is an important distinction, because the continuations would not
work if %cont% was turned into a special variable by defvar.
Mark-
From: Lars Brinkhoff
Subject: Re: Implementation Favoritism, a question of Lisp mindsets
Date:
Message-ID: <85wuhlithz.fsf@junk.nocrew.org>
Mark Conrad <······@iam.invalid> writes:
> There are errors in [On Lisp] pertaining to examples given to
> explain continuations in CL, and how to use the six macros that
> implement continuations in Common Lisp.
What errors? The book may be republished, so if there are any errors,
it would be nice to correct them in the new version.
In article <··············@junk.nocrew.org>, Lars Brinkhoff
<·········@nocrew.org> wrote:
> Mark Conrad <······@iam.invalid> writes:
> > There are errors in [On Lisp] pertaining to examples given to
> > explain continuations in CL, and how to use the six macros that
> > implement continuations in Common Lisp.
>
> What errors? The book may be republished, so if there are any errors,
> it would be nice to correct them in the new version.
Nothing critical, in the six macros themselves that allow continuations
to be implemented in CL.
I got no response when I tried to contact Paul.
A lot of his support functions and macros have errors, there is an
example of this on page 270 in the macro "foo" which purports to
explain a feature of the critical "=bind" macro.
Several errors in the book code, in the macro "foo", and the support
functions and macros used with foo.
(=defun baz ()
(=bind (m n) (message)
(=values (list m n) )))
(=defun bar (x)
(=values (list 'a (add1 x) )))
(=defun message ()
(=values 'hello 'there))
(=defun foo (x)
(=bind (y) (bar x)
(format t "Ho ")
(=bind (z) (baz x)
(format t "Hum. ")
(=values x y z) )))
Some obvious errors are -
1) baz should not have an argument (in foo)
2) Paul should have mentioned that add1 was a user defined function
3) "message" should be a function, not a macro, "=values" in "message"
needs to be replaced by ordinary "values".
4) Paul neglected to mention in general what foo should do, and why foo
needs a number as an argument.
Unless foo gets a number argument, an error occurs.
If "message" is a macro, a very serious error occurs:
"Too many arguments while executing 'identity' "
That particular error typically indicates a major flaw in the code,
in this case using a macro where none was required.
There are several other confusing results that occur when foo is run.
I did not mess around with trying to ferret out all the errors.
In general, Paul does a rather poor job of explaining how his critical
six macros work. A novice like me has to figure it out by himself.
It is possible to figure it all out, with lots of experimentation.
I am slowly sorting it all out, and should be fairly proficient at
creating my own continuations in CL as time goes by.
I wish there was someone out there who has used Paul's macros a lot,
so I could ask them questions.<g>
Mark-
From: Lars Brinkhoff
Subject: Re: Implementation Favoritism, a question of Lisp mindsets
Date:
Message-ID: <85ist5iag8.fsf@junk.nocrew.org>
Mark Conrad <······@iam.invalid> writes:
> Lars Brinkhoff wrote:
> > Mark Conrad <······@iam.invalid> writes:
> > > There are errors in [On Lisp] pertaining to examples given to
> > > explain continuations in CL, and how to use the six macros that
> > > implement continuations in Common Lisp.
> > What errors? The book may be republished, so if there are any errors,
> > it would be nice to correct them in the new version.
> Nothing critical [...]
Well, if you like, you could talk to Doris Wong <doris (at) apress.com>,
and she should be able to pass along your corrections to an editor.
From: Nils Goesche
Subject: Re: Implementation Favoritism, a question of Lisp mindsets
Date:
Message-ID: <lyfzo9fgnv.fsf@cartan.de>
Mark Conrad <······@iam.invalid> writes:
> In article <··············@junk.nocrew.org>, Lars Brinkhoff
> <·········@nocrew.org> wrote:
>
> > Mark Conrad <······@iam.invalid> writes:
> > > There are errors in [On Lisp] pertaining to examples given to
> > > explain continuations in CL, and how to use the six macros that
> > > implement continuations in Common Lisp.
> >
> > What errors? The book may be republished, so if there are any
> > errors, it would be nice to correct them in the new version.
>
> Nothing critical, in the six macros themselves that allow
> continuations to be implemented in CL.
>
> I got no response when I tried to contact Paul.
Have a bit more respect and you might get an answer next time.
> A lot of his support functions and macros have errors, there is an
> example of this on page 270 in the macro "foo" which purports to
> explain a feature of the critical "=bind" macro.
Look, Paul Graham might be an eccentric, but he is not an idiot. When
some code in his book doesn't work for you, you should rather think
about how it was /meant/ to be used. It was very generous of him to
put this book online for free download, so today's newbies who cannot
purchase the book anymore because it is out of print, still have a
chance to learn a lot about Lisp by reading it. Thanking your teacher
by publicly posting baseless accusations is rather antisocial
behavior, though, because it is giving him a good reason to reconsider
his decision.
> Several errors in the book code, in the macro "foo", and the support
> functions and macros used with foo.
>
> (=defun baz ()
> (=bind (m n) (message)
> (=values (list m n) )))
>
> (=defun bar (x)
> (=values (list 'a (add1 x) )))
>
> (=defun message ()
> (=values 'hello 'there))
>
> (=defun foo (x)
> (=bind (y) (bar x)
> (format t "Ho ")
> (=bind (z) (baz x)
> (format t "Hum. ")
> (=values x y z) )))
>
> Some obvious errors are -
>
> 1) baz should not have an argument (in foo)
You should really not assume that when a function is called FOO, BAR
or BAZ in one place of a book, that every occurrence of FOO, BAR or
BAZ is referring to the same function. The code for FOO you quoted
occurs, seperated from the other code, in Figure 20.5 to illustrate
something that is independent of how BAR or BAZ are particularly
defined. As the first example function BAZ you quoted does not take
any parameters, the function FOO is invoking is obviously not meant to
be the same.
> 2) Paul should have mentioned that add1 was a user defined function
Why? He is giving its definition several times in that chapter.
Assuming that his readers do not have the attention span of a moth is
not an error on his side.
> 3) "message" should be a function, not a macro, "=values" in "message"
> needs to be replaced by ordinary "values".
Absolutely not. You are obviously still having trouble to understand
the whole construction. That's fine, of course, but in that case you
should refrain from posting public accusations of Graham's example
code. In Graham's book, the definition of MESSAGE occurs /before/ the
definition of BAZ. /You/ broke the code by changing that order.
> 4) Paul neglected to mention in general what foo should do, and why foo
> needs a number as an argument.
Whenever that happens, you are probably supposed to figure that out
yourself. What FOO does is /absolutely irrelevant/ as its definition
only illustrates some restrictions on the usage of =BIND.
> Unless foo gets a number argument, an error occurs.
As FOO's argument is passed on to some imaginary functions BAR and
BAZ, what FOO accepts obviously depends on /their/ definition. See
above.
> If "message" is a macro, a very serious error occurs:
>
> "Too many arguments while executing 'identity' "
/You/ caused that error by changing the order of those functions.
> That particular error typically indicates a major flaw in the code,
> in this case using a macro where none was required.
The major flaw seems to be in your head. Next time something doesn't
work, try to figure out what /you/, a beginner, are doing wrong,
instead of automatically assuming that some Lisp master like Paul
Graham must be in error.
> There are several other confusing results that occur when foo is
> run.
>
> I did not mess around with trying to ferret out all the errors.
Maybe you should have.
> In general, Paul does a rather poor job of explaining how his
> critical six macros work. A novice like me has to figure it out by
> himself.
I think he is doing an excellent job. It is simply not exactly
trivial, so you are supposed to do some thinking.
> I am slowly sorting it all out, and should be fairly proficient at
> creating my own continuations in CL as time goes by.
If you are having problems with these small macros, it will take some
time until you will be able to do enough code-walking for achieving
that goal. Which is an irrational goal, BTW, as lots of people have
told you before. You do not /need/ continuations in Common Lisp.
Learn to program in Common Lisp and to use /its/ constructs, and this
should become apparent in no time. By obsessing about continuations
like that you are only blinding yourself for other ways and will
probably not make much progress.
You are looking a lot like Don Quixote. I hope my still answering to
you doesn't make /me/ look like Sancho Pansa...
Regards,
--
Nils G�sche
"Don't ask for whom the <CTRL-G> tolls."
PGP key ID 0x0655CFA0
From: Nils Goesche
Subject: Re: Implementation Favoritism, a question of Lisp mindsets
Date:
Message-ID: <lyk7dlfin0.fsf@cartan.de>
Mark Conrad <······@iam.invalid> writes:
> Here are the six macros, with slight changes to help in various
> ways:
>
> ;****************************************************
> ; Slightly altered version of Paul Graham's macros page 267
>
> (setq %cont% #'identity)
>
> (defmacro =lambda (parms &body body)
> `#'(lambda (%cont% ,@parms) ,@body))
>
> (defmacro =defun (name parms &body body)
> (let ((f (gensym)))
> `(progn
> (defmacro ,name ,parms
> `(,',f %cont% ,,@parms))
> (defun ,f (%cont% ,@parms) ,@body) )))
>
> (defmacro =bind (parms expr &body body)
> `(let ((%cont% #'(lambda ,parms ,@body))) ,expr))
>
> (defmacro =values (&rest retvals)
> `(funcall %cont% ,@retvals))
>
> (defmacro =funcall (fn &rest args)
> `(funcall ,fn %cont% ,@args))
>
> (defmacro =apply (fn &rest args)
> `(apply ,fn %cont% ,@args))
>
> ;****************************************************
>
> - Notes -
>
> I used a gensym version of the =defun macro to sidestep
> variable-capture problems.
Don't worry about that too much. As Graham writes in a footnote
(p.266), he didn't use gensyms so he can trace the generated
functions.
> I used %cont% throughout instead of Paul Graham's *cont* to alert
> users to the fact that %cont% is _not_ a special variable. (dynamic
> variable)
>
> Rather it is a top-level lexical variable, visible to all code by
> virtue of the fact that all code is within the lexical scope of
> %cont%
What you apparently don't know is that there is no such thing in
Common Lisp. By (setq *cont* #'identity) you are simply invoking
undefined behavior.
> It is an important distinction, because the continuations would not
> work if %cont% was turned into a special variable by defvar.
Which is why they don't work in general, anyway. It is a hack that
/sometimes/ works on /some/ implementations, as is clear if you know
how these implementations work.
The whole purpose of these macros is to teach people how to write
macros. He simplified things for didactic purposes. Graham mentions
in 20.3 that to do it right you need a code-walker, which is not
trivial at all.
Regards,
--
Nils G�sche
"Don't ask for whom the <CTRL-G> tolls."
PGP key ID 0x0655CFA0
Nils Goesche wrote:
> Mark Conrad <······@iam.invalid> writes:
>>Rather it is a top-level lexical variable, visible to all code by
>>virtue of the fact that all code is within the lexical scope of
>>%cont%
>
> What you apparently don't know is that there is no such thing in
> Common Lisp. By (setq *cont* #'identity) you are simply invoking
> undefined behavior.
As an addendum, ANSI Common Lisp provides define-symbol-macro, and one
of its intended purposes is to emulate top-level lexical variables. See
the HyperSpec for more details.
Pascal
--
Pascal Costanza University of Bonn
···············@web.de Institute of Computer Science III
http://www.pascalcostanza.de R�merstr. 164, D-53117 Bonn (Germany)
In article <··············@cartan.de>, Nils Goesche <······@cartan.de>
wrote:
> > I used %cont% throughout instead of Paul Graham's *cont* to alert
> > users to the fact that %cont% is _not_ a special variable. (dynamic
> > variable)
> >
> > Rather it is a top-level lexical variable, visible to all code by
> > virtue of the fact that all code is within the lexical scope of
> > %cont%
>
> What you apparently don't know is that there is no such thing in
> Common Lisp. By (setq *cont* #'identity) you are simply invoking
> undefined behavior.
You are absolutely correct, there is no such thing in CL.
Thanks for catching my error.
What I should have written is this:
"I used %cont% throughout instead of Paul Graham's *cont* to alert
users to the fact that %cont% is _not_ a special variable. (also
called a dynamic variable)
Rather %cont% is a 'non-special'variable for lack of a better
term. When defvar enters the picture, then %cont% acts entirely
differently in the program."
What is certain is that if defvar is used on %cont% , it will screw up
the operation of a lot of the uses for CL continuations.
For example, if one defvar line is added to Paul's macro definitions:
(defvar %cont%) <== added line to make %cont% a special variable
(setq %cont% #'identity) <== legitimate first line of Paul's macros
...it will radically mess up the operation of a lot of programs that
use continuations, such as my version of Paul's tree-backtracking demo'
program on page 271 of his "On Lisp" book.
(setq %flag% t)
(setq %saved% nil)
(defun dft (tree)
(cond ((null tree) nil)
((atom tree) (princ tree))
(t (dft (car tree))
(dft (cdr tree)) )))
(=defun restart ()
(if %saved%
(funcall (pop %saved%))
(=values 'done)))
(=defun dft-node (tree)
(cond ((null tree) (restart))
((atom tree) (=values tree))
(t (push #'(lambda () (dft-node (cdr tree)))
%saved%)
(dft-node (car tree)) )))
(=defun dft2 (tree)
(setq %saved% nil)
(=bind (node) (dft-node tree)
(cond ((eq node 'done) (=values nil))
(t (princ node)
(restart)) )))
(setq t1 '(a (b (d h)) (c e (f i) g))
t2 '(1 (2 (3 6 7) 4 5)))
(defun fizz ()
(=bind (node1) (dft-node t1)
(=bind (node2) (dft-node t2)
(if (eq node1 'done)
(throw 'hop (progn
(terpri)
(terpri)
'finished__needs-to-be-reset))
(list node1 node2) ))) )
(defun number-of-runs (n) %cont%
(if %flag%
(progn (setq %flag% nil)
(print (fizz))
(setq n (1- n)) ))
(catch 'hop
(if (not (dotimes (x n)
(print (restart) )))
(progn
(terpri)
(terpri)
'more-left-to-run) )))
(defun reset ()
(setq %flag% t)
'ready-to-run)
;;**************************************************************
;; End of code
The continuations will do a cross-product depth-first traversal on the
trees below.
As the text in the book brings out, here we will just print the nodes.
In an actual program data would be attached to each node of each tree.
Here it would just complicate the example.
Tree tI Tree t2
-A- -1-
/ \ |
/ \ |
/ \ 2
B C /|\
/ /|\ / | \
/ / | \ / | \
D E F G 3 4 5
| | /|
| | / |
H I 6 7
A few sample runs would be:
? (number-of-runs 8)
(A 1)
(A 2)
(A 3)
(A 6)
(A 7)
(A 4)
(A 5)
(B 1)
MORE-LEFT-TO-RUN
?
? (number-of-runs 2)
(B 2)
(B 3)
MORE-LEFT-TO-RUN
?
On these trees, if a total of 64 or more runs are made, a message is
displayed:
FINISHED__NEEDS-TO-BE-RESET
...then you have to type (reset) to start again from the beginning.
Thanks again for catching my error about the mythical
top-level-lexical-variable.
Mark-
From: Nils Goesche
Subject: Re: Implementation Favoritism, a question of Lisp mindsets
Date:
Message-ID: <ly8ytzevuj.fsf@cartan.de>
Mark Conrad <······@iam.invalid> writes:
> In article <··············@cartan.de>, Nils Goesche <······@cartan.de>
> wrote:
>
> > > I used %cont% throughout instead of Paul Graham's *cont* to
> > > alert users to the fact that %cont% is _not_ a special
> > > variable. (dynamic variable)
> > >
> > > Rather it is a top-level lexical variable, visible to all code
> > > by virtue of the fact that all code is within the lexical scope
> > > of %cont%
> >
> > What you apparently don't know is that there is no such thing in
> > Common Lisp. By (setq *cont* #'identity) you are simply invoking
> > undefined behavior.
>
> You are absolutely correct, there is no such thing in CL.
>
> Thanks for catching my error.
>
> What I should have written is this:
>
> "I used %cont% throughout instead of Paul Graham's *cont* to alert
> users to the fact that %cont% is _not_ a special variable. (also
> called a dynamic variable)
> Rather %cont% is a 'non-special'variable for lack of a better
> term. When defvar enters the picture, then %cont% acts entirely
> differently in the program."
But it is /still/ undefined behavior :-)
> What is certain is that if defvar is used on %cont% , it will screw
> up the operation of a lot of the uses for CL continuations.
Right -- with DEFVAR it won't work at all. Why it wouldn't work with
a special variable should become apparent by closely studying page
269.
> For example, if one defvar line is added to Paul's macro definitions:
>
> (defvar %cont%) <== added line to make %cont% a special variable
>
> (setq %cont% #'identity) <== legitimate first line of Paul's macros
>
> ...it will radically mess up the operation of a lot of programs that
> use continuations, such as my version of Paul's tree-backtracking
> demo' program on page 271 of his "On Lisp" book.
Yes, that won't work. But Pascal Costanza has already indicated how
it can be fixed:
(define-symbol-macro %cont% #'identity)
works just fine. And I agree that it shouldn't be called *cont* then,
either because it is /not/ a special variable.
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:
> > What is certain is that if defvar is used on %cont% , it will screw
> > up the operation of a lot of the uses for CL continuations.
>
> Right -- with DEFVAR it won't work at all. Why it wouldn't work with
> a special variable should become apparent by closely studying page
> 269.
I studied that page profusely, but no luck.
Unless I can comprehend *why* defvar affects the scope/extent of some
of the code, I have no hope of understanding what is going on.
The frustrating thing is that it only affects programs that are written
like the tree example code that I posted; some other programs that use
continuations run okay when defvar is used.
There is definately a difference between how these two act in a program:
(setq cont 'initial-value-of-cont)
(defvar cont2 'initial-value-of-cont2)
In order to get some clues, I decided to try to use proclaim, which can
be looked on as an aggravated form of defvar.
(proclaim '(special cont))
(setq cont 'initial-value-of-cont)
(setq cont2 'initial-value-of-cont2)
(defun start ()
(catch 'my-tag (foo) ))
(defun foo ()
(setq cont #'(lambda (x) (list x x)))
(setq cont2 #'(lambda (y) (list y y y)))
(print (funcall cont 'boom))
(print (funcall cont2 'bam))
(throw 'my-tag '(foo has completely finished)))
;; ? (start)
;; (BOOM BOOM)
;; (BAM BAM BAM)
;; (FOO HAS COMPLETELY FINISHED)
;; ?
;; ? (funcall cont 'fooey)
;; (FOOEY FOOEY)
;; ? (funcall cont2 'fooey) <== cont2 initial value messed up
;; (FOOEY FOOEY FOOEY)
;; ?
Now I am even more confused, the variable cont2 should not have been
affected by proclaim at all.
Mark-
In article <··············@cartan.de>, Nils Goesche <······@cartan.de>
wrote:
Regarding the scope and extent differences between:
(setq *cont* 'foo) versus (defvar *cont* 'foo)
...at toplevel, and assuming the (setq *cont* 'foo) was tried *before*
the (defvar *cont* 'foo) was tried.
> To understand why this
> doesn't work, you'll have to understand special variables. This
> example illustrates the problem...<snipped>...
Thanks very much for your example code, I will retreat into my cave and
digest the implications of your code.
> That's right: That's why people keep telling you to stop worrying
> about continuations and learn Lisp first.
It is not all that easy, at least for me. None of my books addressed
this issue, and I have a large assortment of good Lisp books - - - I
managed to learn CPS, Y-op, etc. but not this particular gnarly
subject.
I will give you an idea of what I endured years ago, when I pestered
people in this NG about this subject.
Start of l-o-o-o-n-g response from a gentleman, years ago -
Don't read unless you want a headache.
**********************************************
�---- Sacr 14400, 8/26/96, 11:13:32 PM, CompuServe Mail System ----�
�FB�ME
Message ID: 329-45978
Date: 8/26/96 4:04 PM
From: Robert Munyer ···············@mcs.com
Subject: Re: Toplevel var' - - lexical???
Sender: ······@mcs.com
Received: from freenet3.freenet.ufl.edu (freenet3.afn.org
[128.227.163.9]) by hil-img-5.compuserve.com (8.6.10/5.950515)
id TAA12174; Mon, 26 Aug 1996 19:03:53 -0400
Received: from [128.227.163.142] by freenet3.freenet.ufl.edu
(8.7.3/4.11)
id TAA90942; Mon, 26 Aug 1996 19:03:33 -0400
Message-Id: <·····················@freenet3.freenet.ufl.edu>
X-Sender: ······@popmail.mcs.net (Unverified)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Mon, 26 Aug 1996 19:06:47 -0500
To: Gerald Smith <··········@CompuServe.COM>
From: ······@mcs.com (Robert Munyer)
Subject: Re: Toplevel var' - - lexical???
On 8/21/96, you wrote:
> Very confusing, lots of luck resolving this issue. If you don't
> get back to me I will figure the Lisp body-snatchers got to you
> and thoroughly brain-washed you until you were so confused that
> you just ran off muttering to yourself. ;-)
Geez, I know what you mean!
My brain is still my own, it hasn't been washed, but it's certainly
feeling a bit scuffed and dented after all this.
I'm still holding off for a while on posting the article in
comp.lang.lisp.mcl, but I decided to send you an "advance copy" by
e-mail so you can take a look at it first.
I was originally going to write some explanatory material, and then go
over your code examples one by one. But then I realized it would be a
better test of the clarity of my explanation if I let you go over your
own examples. I am hoping that after reading the explanation you will
be able to understand all of your examples and see that they are not
really contradictory.
If there's anything that still doesn't make sense to you, please write
back; your feedback will help me improve the article before I post it.
Let me know if there are any places where you think I ought to add some
example code to prove a point.
--------------------------------
This is a reply for Gerald Smith, who noticed some striking differences
between DEFVAR and SETQ when used to initialize global variables. He
was wondering if perhaps the variables initialized by SETQ are actually
lexical, because they seem to behave differently from the ones
initialized by DEFVAR.
I have some thoughts about how to make the issues involved in this
question a bit easier to understand, and I'm posting an explanation
here. Suggestions for improvements are welcome. This article is a bit
abstract and philosophical at the beginning, but it gets more practical
about a third of the way through.
Suppose we start up Common Lisp and initialize a variable X by
evaluating (SETQ X 5). We have created an association between the
symbol X and the number 5. But is this association dynamic or lexical?
Of course we could look up the answer in a book. But let's try to make
this more challenging (and more educational): let's try to come up with
our own answer by looking only at what the language actually does, not
at what the manual says.
Probably the best way to decide whether something is dynamic or lexical
is to look at the outer boundary of its accessibility. If it's only
available inside of some kind of time-oriented container (like a lambda
invocation) then it's dynamic. If it's only available inside a
place-oriented container (like a lambda body) then it's lexical. But
our top-level association between X and 5 is global; it has no limits
of time or place. Because of this, if we want to be philosophical
purists we can say that it is neither dynamic nor lexical.
[ Or we could go to the other philosophical extreme, and say that it is
both dynamic AND lexical. We could claim that it has a time boundary
because it goes away when you terminate Common Lisp. We could claim
that it has a place boundary because it can't be accessed by code in
some other process that happens to be running at the same time as
Common Lisp. But this kind of thinking is not very useful unless
you're extending Common Lisp to support multiprocessing and/or object
persistence, so we'll skip it for now. ]
We've explored the outer boundary of our association between X and 5,
and at this point we have a tie. So far there is no compelling reason
to call this association either dynamic or lexical. When outer
boundaries don't help, the next best place to look for a tie-breaker
would probably be the inner boundaries. For example, if we find that
this association can be overridden (or shadowed) by a dynamic
construct, but not by a lexical one, then we would be justified in
calling our top-level association dynamic. But, when we explore this
possibility, we find that we once again have a tie. Our top-level
association can be overridden either dynamically or lexically. Here is
some example code to demonstrate:
? (setq x 5) ; global x=5
5
? (flet ((foo () x)) ; dynamic x=6 shadows global x=5
(let ((x 6))
(declare (special x))
(foo)))
6
? (let ((foo (let ((x 6)) ; lexical x=6 shadows global x=5
#'(lambda () x))))
(funcall foo))
6
Thus we see that neither outer nor inner boundaries can help us justify
choosing either "dynamic" or "lexical" as our preferred term for
describing the global association between X and 5. One thing this
should tell us is that when two people disagree about this issue, we
shouldn't automatically assume that one of them is not thinking
straight.
I can think of a third place to look for a tie-breaker, but it is not as
philosophically pure as the outer and inner boundaries we looked at
above. It is more closely tied to implementation considerations. So
the third attempt will have to wait until after I have described some
details about how the language actually works.
OK, now we are getting out of the philosophical part of this article and
into the part that is more practical. The first part explained why the
issue is inherently difficult; this second part will explain how the
language actually works and should enable you to predict how any given
code will work.
If you want to understand scoping in Common Lisp, you have to understand
"special." And to understand that, the most important thing I can tell
you is that you need to be VERY careful about what you mean when you
say
"variable." In Common Lisp there are three separate entities that we
commonly lump together under the single concept "variable," but to
understand "special" you have to be able to keep these three entities
separate. They are: variable NAMES, variable REFERENCES, and variable
BINDINGS. A variable NAME is just a symbol. In the form (LET ((X 'X))
(LIST X X)), what looks like four X's is really just one single variable
name or symbol, which appears in four places (even though one of the
four is probably not going to be used as a variable at all!). A
variable REFERENCE is the existence of a variable name at a particular
spot in the code. The last two X's in the form above are two
individual variable references, even though they are represented by the
exact same Lisp object (the variable name, or symbol, X). A variable
BINDING is an association between a variable name and a value. The
single name X can have multiple bindings as well as multiple
references.
Now we need to look at how "special" affects each of these three
entities: bindings, names, and references. A variable binding is
either dynamic (time bounded) or lexical (place bounded) or global
(unbounded). We say that dynamic bindings are "special" and lexical
bindings are "not special." As for the global ones, we'll get back to
that later.
Now we get to the central issue that seems to cause trouble for many
people. The variable name itself can also be called "special" or "not
special." This use of "special" for variable names is related to the
one above for variable bindings, but it is NOT the same thing. When we
say a symbol (i. e. variable name) is "special," we are using that as a
convenient shorthand for saying that the name has been "proclaimed
special." If a name has been proclaimed special, then ALL bindings and
references involving that name will be dynamic. But if the name has not
been proclaimed special, then it can still have lexical bindings and
references AS WELL AS dynamic ones. Since a non-special variable name
can be used in both ways, there is no such thing as a lexical symbol or
variable name. It is better to call symbols special and non-special,
rather than dynamic and lexical. Incidentally, this difference between
special symbols and non-special ones is the cause of all the curious
effects that Mr. Smith noticed when he used SETQ to initialize a global
variable. Unlike DEFVAR, SETQ does not proclaim the symbol to be
special. But as I said above, this does not mean that all the symbol's
bindings are lexical; it simply means the symbol can have both types of
bindings.
We've covered the use of "special" with variable bindings and variable
names; now let's try it with variable references. We are about to
arrive (finally) at the tie-breaker which will allow us to justify the
use of "dynamic" or "lexical" on global bindings. It turns out that in
Common Lisp there are only two kinds of variable references. One of
them is the non-special reference: this retrieves the value of the
variable name's innermost lexical binding. The other kind, the special
variable reference, obeys the following rule: it retrieves the value of
the variable name's innermost dynamic binding if there are any dynamic
bindings; if there are none, it retrieves the variable name's global
binding. Since the non-special reference works with lexical bindings,
we call it a "lexical" reference. Since the special reference works
with dynamic bindings (as well as global ones) we call it a "dynamic"
reference. Notice that there is no way to access a variable name's
global binding except by using the kind of variable reference that
checks for dynamic bindings first. There is no such thing as a "global
reference;" if you want the global binding you will have to get it
through a dynamic reference, and just hope there aren't any dynamic
bindings in the way. While a global binding is being shadowed by a
dynamic one, there is no way to access the global one (except
through debugger facilities which are not actually part of the
language).
Now we have our tie-breaker. We know that global bindings can only be
accessed by dynamic references, and not by lexical references, so
obviously it makes sense to say that if we must choose either "dynamic"
or "lexical" for global bindings, then we should choose "dynamic." Of
course we could have just looked this up in the manual. But I think it
was more educational this way.
At this point I think there is only one subject left for me to cover. I
need to explain, for each kind of variable related entity (name,
binding, and reference) how to tell whether it is special or
non-special. Common Lisp is a big language so I may accidentally omit
one or more important clues below; if so, I hope someone will add them
in a follow-up.
We will start with variable names, since they are the simplest. A
variable name (symbol) is either "proclaimed special" or it is not. In
effect this is a true/false attribute of every symbol. Often DESCRIBE
or INSPECT will tell you whether a symbol has been proclaimed special.
Or there might be a function like VARIABLE-INFORMATION or
PROCLAIMED-SPECIAL-P which you can use in a program. A symbol can be
"proclaimed special" by PROCLAIM, DECLAIM, DEFVAR, DEFPARAMETER, or
DEFCONSTANT; or by belonging to the keyword package; or by being
predefined as constant or special (e. g. PI or *QUERY-IO*).
Next we will cover variable bindings. A binding is either special or
it is not. (Special bindings are dynamic, a category in which we are
now including global bindings). A binding will be special if: (a) it
is
global; or (b) it has been declared to be special; or (c) its variable
name has been proclaimed to be special.
Finally, variable references. A reference is either special or it is
not. (Special references are the ones which retrieve the innermost
dynamic binding, if there is one, or else the global binding.) A
reference will be special if: (a) it has been declared to be special;
or (b) its variable name has been proclaimed to be special; or (c) it
has no enclosing lexical binding. Mr. Smith, pay close attention to
that last one because it can explain the behavior of many of the code
snippets you posted. For example, in your example (DEFUN BAR () XX),
the XX is a SPECIAL variable reference, even though neither the
reference nor its name was ever declared or proclaimed to be special.
Hope this helps.
-- Robert
P. S. Part (c) in the last full paragraph above can also help answer
your side question: "If the null lexical environment is the same as the
dynamic environment, then why is the word 'lexical' in its name?" To
explain this, suppose I give you the following hypothetical situation:
you have a variable reference X, and this reference has not been
declared to be special, nor has its name X been proclaimed to be
special. Then I ask you: is this reference lexical or dynamic?
Keeping the preceding paragraph in mind, you can see that in this
hypothetical situation I have ruled out (a) and (b) but not (c). I
have not given you enough information to answer my question. Before
you can answer you will have to ask me: "Is there any enclosing lexical
binding for X?"
Now, consider the implication of the question you just had to ask me.
The implication of rule (c), and the question that it forced you to ask
me, is this: In any variable reference that is not affected by a
special
declaration or proclamation, the whole lexical environment effectively
overrides (or shadows) the whole dynamic environment. When the compiler
needs to know which kind of variable reference to generate in this
situation, it first searches through the lexical environment, and then
it generates a dynamic reference only if it couldn't find an enclosing
lexical binding. Now, if the lexical environment is completely empty
(i. e., null) then the effect will be the same as if the compiler never
searched the lexical environment at all, and just generated a dynamic
reference directly. That is why compiling in the "null lexical
environment" means the same thing as compiling in the dynamic
environment.
Distribution:
To: [70363,2333]
�----- Reply ------� (from Gerald Smith)
Robert,
Thanks for a very detailed reply to my question concerning whether
global variables are lexical or dynamic.
I saw a little of the discourse in comp.lang.lisp.mcl and it looked to
be rather vicious at times, good thing you had your asbestos shorts on.
<g>
A lot of confusion surrounds the common terms used to describe this
general subject, if two people have a slightly different understanding
of the terms they use, confusion reigns rampant and tempers become short
because of the frustration involved in getting accross one's point.
The only part of your fine article that I had a little trouble with was
the part pertaining to "special", specifically the part:
"It is better to call symbols special and non-special,
rather than dynamic and lexical."
(about half-way through your article)
My understanding of the word special was that it was used to describe
"something out of the ordinary" - - the ordinary in Common Lisp
supposedly being the default lexical nature of the language, in so far
as the handling of "variables" is concerned.
All this contrasted to "old" Lisp, which was dynamic in nature.
I realize, however, that this default lexical nature of modern Lisp
does not necessarily hold true for global variables created at top
level by (SETQ X 5) for example.
Possibly your article might benefit from a little elaboration about
exactly what is special about "special", explained in general English
as much as possible. Just a suggestion.
I think you did an excellent job.
Hopefully others will appreciate the large outlay of time and effort
that you put into this project, I know I do.
**********************************************
Mark-
In article <··············@cartan.de>, Nils Goesche <······@cartan.de>
wrote:
> > Unless I can comprehend *why* defvar affects the scope/extent of
> > some of the code, I have no hope of understanding what is going on.
>
> That's right: That's why people keep telling you to stop worrying
> about continuations and learn Lisp first. To understand why this
> doesn't work, you'll have to understand special variables. This
> example illustrates the problem...<snipped>...
Very good example, I had to hit a few books to understand it.
I made my own 'newbie' version of your example.<g>
(setq x "the global setq value of x")
(defun test (&optional p)
(let ((x x))
(let ((x #'(lambda ()
(terpri)
(princ " Value of x is ")
(unless p (princ x))
(when p (princ p))
(terpri) )))
(funcall x)
(terpri)
(values) )))
;Compiler warnings :
; Undeclared free variable X, in TEST.
TEST
?
?(test)
Value of x is the global setq value of x
?
?(test x)
Value of x is the global setq value of x
?
?(defvar x)
X
?
?(defun test (&optional p)
(let ((x x))
(let ((x #'(lambda ()
(terpri)
(princ " Value of x is ")
(unless p (princ x))
(when p (princ p))
(terpri) )))
(funcall x)
(terpri)
(values) )))
TEST
?
?(test)
Value of x is #<COMPILED-LEXICAL-CLOSURE #x1EAF413E>
?
?(test x)
Value of x is the global setq value of x
?
Lots of fun, I now understand the difference in behavior of these two
toplevel forms:
(setq x 'foo) compared-to (defvar x 'foo)
The breakthrough for me was Paul Graham's explanations on pages 16-17
of his "On Lisp" book. He explained aspects of "scope" in a way that
I could understand.
Thanks for your help on this problem, now I have a chance of
understanding continuations in CL.
Mark-
From: Peter Seibel
Subject: Re: Implementation Favoritism, a question of Lisp mindsets
Date:
Message-ID: <m3of2ttk2p.fsf@javamonkey.com>
Mark Conrad <······@iam.invalid> writes:
> Lots of fun, I now understand the difference in behavior of these
> two toplevel forms:
>
> (setq x 'foo) compared-to (defvar x 'foo)
You don't understand it as well as you think if you still think:
(setq x 'foo)
has some meaning as a top-level form when it's not preceded by a:
(defvar x 'foo)
Better men than me have tried but I'll reiterate the point:
In Common Lisp, the behavior of code that calls SETQ on a non-existent
variable (i.e. not yet created via a variable creating form such as
DEFVAR, LET, SYMBOL-MACROLET, or DEFINE-SYMBOL-MACRO) is *undefined*.
There is NO POINT trying to understand what its behavior is because it
is--one more time--*undefined*. Just because one implementation (or
all of them for that matter) happen to do some particular thing in the
face of code with undefined behavior does not make it defined and you
should not rely on that behavior, especially when you're trying to
learn the fundamental concepts of the language.
-Peter
P.S. This concept is not unique to Lisp. Switch over to comp.lang.c
and somethnig like 90% of the threads there are about how various
constructs that may be accepted by various C compilers have, in fact,
no meaning in standard C.
--
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:
> Just because one implementation (or
> all of them for that matter) happen to do some particular thing in the
> face of code with undefined behavior does not make it defined and you
> should not rely on that behavior, especially when you're trying to
> learn the fundamental concepts of the language.
All of what you posted has finally sunk in.
I will change my code to include "define-symbol-macro" which should
make my code portable in all implementations of CL that adhere to the
present hyperspec standard for the language.
Thanks very much for continuing to beat on my head until this sunk in.
I erroneously thought that "undefined behavior" was a trivial thing.
I can now see that "undefined behavior" is very important, as regards
whether or not my code will work.
I am curious as to why I could not see that obvious fact long ago, it
took Pascal Costanza's recent post to drive it home to me.
Mark-
From: Tim Bradshaw
Subject: Re: Implementation Favoritism, a question of Lisp mindsets
Date:
Message-ID: <ey3n0idxmp5.fsf@cley.com>
* Mark Conrad wrote:
> Lots of fun, I now understand the difference in behavior of these two
> toplevel forms:
> (setq x 'foo) compared-to (defvar x 'foo)
You don't, because, as people keep telling you, toplevel (setq x 'foo)
*does not have* a defined behaviour unless it has been preceded by
DEFVAR.
--tim
In article <···············@cley.com>, Tim Bradshaw <···@cley.com>
wrote:
> * Mark Conrad wrote:
>
> > Lots of fun, I now understand the difference in behavior of these two
> > toplevel forms:
>
> > (setq x 'foo) compared-to (defvar x 'foo)
>
>
> You don't, because, as people keep telling you, toplevel (setq x 'foo)
> *does not have* a defined behaviour unless it has been preceded by
> DEFVAR.
>
> --tim
Thanks for alerting me to the error of my false-confidence.
I will change my code to include "define-symbol-macro" which should
make my code portable in all implementations of CL that adhere to the
present hyperspec standard for the language.
Mark-
In article <·························@iam.invalid>, Mark Conrad
<······@iam.invalid> wrote:
> ...bunch of erroneous newbie stuff, hopefully I gained some smarts.
Functions and macros that will allow us to rename macros
(reference pages 389 and pages 214-215 of "On Lisp")
;**********************************************
(defun group (source n)
(if (endp source)
nil
(let ((rest (nthcdr n source)))
(cons (if (consp rest)
(subseq source 0 n) source)
(group rest n)) )))
(defmacro abbrev (short long)
`(defmacro ,short (&rest args)
`(,',long ,@args)))
(defmacro abbrevs (&rest names)
`(progn
,@(mapcar #'(lambda (pair)
`(abbrev ,@pair))
(group names 2) )))
(abbrevs =setq define-symbol-macro)
;**********************************************
Thanks to help from the knowledgeable people in the
comp.lang.lisp newsgroup, the following code should
work on *any* CL implementation which adheres to
the CL standard.
Enter the forms below in sequence, to see the effect
of a properly defined toplevel variable y which is
forced to be a lexical variable by the user-defined
macro "=setq" (renamed from "define-symbol-macro")
(=setq y 'toplevel-lexical-value-of-y)
(defun closure#1 (x)
(list x y))
(closure#1 "Boo")
(=setq y 'new-toplevel-lexical-value-of-y)
(defun closure#1 (x)
(list x y))
(closure#1 "Boo")
(=setq y 2)
(defun closure#1 (x)
(list x y))
(closure#1 'u)
Mark-
In article <·························@iam.invalid>, Mark Conrad
<······@iam.invalid> wrote:
> (=setq y 'toplevel-lexical-value-of-y)
Whoops! - Lines like that should have been written instead:
(=setq y 'value-of-toplevel-lexical-variable-y)
The entire previous post responds the same whether variable y is
lexical or dynamic. The code in this post is the most simple example
that I could come up with, where variable y responds diferently,
depending on whether y is lexical or dynamic.
It is assumed we have all the preliminary functions already loaded, so
that our macro "=set" will work.
Okay, here is the "lexical" example to manipulate toplevel variable y
;; In this example, the variable y is
;; forced to be a "lexical" variable.
;;
;; Keep in mind that "=setq" is just an
;; abbreviation for "define-symbol-macro",
;; and it is only used to force y to be a
;; lexical variable.
;;
;; Notice the screen values displayed
;; by any line containing "funcall"
(=setq y 12345)
(defvar test)
(setq test #'(lambda (x) y (list x y)))
(funcall test 7)
(let ((y 9)) y (funcall test 7))
(=setq y 54321)
(setq test #'(lambda (x) y (list x y)))
(funcall test 7)
(let ((y 9)) y (funcall test 7))
;************************************
Below is the "dynamic" example to manipulate toplevel variable y
"=setq" is not needed here, because the only purpose of =setq is to
force y to be lexical, and obviously that is not needed here.
;; In this example, the variable y is
;; a "dynamic" variable.
;;
;; Notice the screen values displayed
;; by any line containing "funcall"
(defvar y)
(defvar test)
(setq y 12345)
(setq test #'(lambda (x) y (list x y)))
(funcall test 7)
(let ((y 9)) y (funcall test 7))
(setq y 54321)
(setq test #'(lambda (x) y (list x y)))
(funcall test 7)
(let ((y 9)) y (funcall test 7))
If we *completely* understand each and every line of my examples above,
and why the displayed screen results are different between the lexical
and dynamic cases, we are then ready to tangle with using CL
"continuations" for fun and profit. (mainly fun)
Mark-
From: Kenny Tilton
Subject: Re: Implementation Favoritism, a question of Lisp mindsets
Date:
Message-ID: <3EA346DC.9040709@nyc.rr.com>
Mark Conrad wrote:
>
> His best points are summed up in two pages, 284-285, which should be
> required reading for those who ridicule the concept of using CL
> continuations...
You mean where he says, "for god's sake, don't do this in production"? I
guess that means that, after using call/cc for prototyping, you just do
the same thing without call/cc. So... whatever you can do with call/cc
can be done without call/cc. So... there is no need for call/cc?
let the google show: turns out we agree!
--
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:
> So... whatever you can do with call/cc
> can be done without call/cc. So... there is no need for call/cc?
Granted that whatever I do with CL continuations, I can also do using
conventional Lisp code *without* continuations, no argument there.
In fact, Paul Graham implements his CL continuations by using ordinary
"strings-of-closures", possibly aided by (in my case) :
catch/throw/unwind-protect/go/prog/tag/block/return/return-from
...and a few others that I forgot to mention.
The whole point is, I prefer to use a few of my own "created"
continuation-handling macros, in preference to the alternative of
having to write all the bulky closures, catch/throws/unwind-protects
etc. that the macro replaces.
One can easily get lost in one's own code, which is why the
"visual-clarity" of my continuation-handling macros is *sometimes*
prefered to ordinary Lisp code.
Keep in mind that I only plan to use continuations in those places that
cry out for them, such as code where unexpected and unpredictable jumps
take place within functions, for whatever noble reason.
Another excellent use of continuations would be to abandon one
previously determined path in a program when it "suddenly" becomes
apparent that particular path leads nowhere, and a previously abandoned
path should be resumed instead.
Now when I say the word "continuation", just substitute in your own
mind the phrase "a bunch of closures, catch/throws etc.".
...which is after all what CL continuations really are, as implemented
by Paul Graham's strings of closures.
CL continuations are weaker than Scheme continuations.
With Scheme, I can execute *only* this snippet of code:
(+ 1 (frozen 'safely))
...and it will return to toplevel ==> (THE CALL/CC RETURNED SAFELY)
...without an error occuring due to the pending addition.
With CL "continuations" as implemented by Graham, there is no way to do
the same thing, on that same snippet of code.
No doubt there are other things that CL continuations can't do,
compared to their Scheme counterparts.
Another bad feature of Graham's "continuations" is that a lot of ifs,
ands, and buts have to be memorized as to how to use them. They have
a bunch of restrictions that have to be observed, compared to the
easier-to-use Scheme continuations.
Mark-
From: Marco Antoniotti
Subject: Re: Implementation Favoritism, a question of Lisp mindsets
Date:
Message-ID: <%%cpa.16$L4.1749@typhoon.nyu.edu>
Mark Conrad wrote:
> In article <················@nyc.rr.com>, Kenny Tilton
> wrote:
>
>
> >So... whatever you can do with call/cc
> >can be done without call/cc. So... there is no need for call/cc?
>
>
> Granted that whatever I do with CL continuations, I can also do using
> conventional Lisp code *without* continuations, no argument there.
>
> In fact, Paul Graham implements his CL continuations by using ordinary
> "strings-of-closures", possibly aided by (in my case) :
> catch/throw/unwind-protect/go/prog/tag/block/return/return-from
>
> ...and a few others that I forgot to mention.
>
> The whole point is, I prefer to use a few of my own "created"
> continuation-handling macros, in preference to the alternative of
> having to write all the bulky closures, catch/throws/unwind-protects
> etc. that the macro replaces.
>
> One can easily get lost in one's own code, which is why the
> "visual-clarity" of my continuation-handling macros is *sometimes*
> prefered to ordinary Lisp code.
>
> Keep in mind that I only plan to use continuations in those places that
> cry out for them, such as code where unexpected and unpredictable jumps
> take place within functions, for whatever noble reason.
>
> Another excellent use of continuations would be to abandon one
> previously determined path in a program when it "suddenly" becomes
> apparent that particular path leads nowhere, and a previously abandoned
> path should be resumed instead.
>
> Now when I say the word "continuation", just substitute in your own
> mind the phrase "a bunch of closures, catch/throws etc.".
>
> ...which is after all what CL continuations really are, as implemented
> by Paul Graham's strings of closures.
>
> CL continuations are weaker than Scheme continuations.
>
> With Scheme, I can execute *only* this snippet of code:
>
> (+ 1 (frozen 'safely))
>
> ...and it will return to toplevel ==> (THE CALL/CC RETURNED SAFELY)
>
> ...without an error occuring due to the pending addition.
Yes, but in Scheme you cannot execute
(aref #2A((1 #C(0 1)) (0 1)) 0 1)
out of the box.
Cheers
--
Marco Antoniotti
On Tue, 22 Apr 2003 14:07:52 GMT, Mark Conrad <······@iam.invalid> wrote:
> Now when I say the word "continuation", just substitute in your own
> mind the phrase "a bunch of closures, catch/throws etc.".
Just a reminder that Common Lisp has a powerful condition system.
Paolo
--
Paolo Amoroso <·······@mclink.it>
From: Tim Bradshaw
Subject: Re: Implementation Favoritism, a question of Lisp mindsets
Date:
Message-ID: <ey3ist9nsfc.fsf@cley.com>
* Mark Conrad wrote:
> Let me clarify what I meant. If CL had continuations, or something
> closely approaching continuations, code could be written in such a
> manner that I could manually interrupt a long-running function from the
> keyboard, then turn the computer power off; I could then turn the
> power on later, and resume running the long-running function from the
> exact point it was interrupted.
Well, now you can see why we don't want them! Obviously continuations
have to store the entire OS state to nonvolatile storage, if you have
anything like open network connections, they probably have to fork a
copy of the entire universe, and dump *that* to disk. Ouch.
The rest of us just use OSs which have a suspend-to disk facility.
--tim
Mark Conrad <······@iam.invalid> writes Re: Implementation Favoritism, a question of Lisp mindsets
> If CL had continuations, or something closely approaching continuations,
> code could be written in such a
> manner that I could manually interrupt a long-running function from the
> keyboard, then turn the computer power off; I could then turn the
> power on later, and resume running the long-running function from the
> exact point it was interrupted.
You want not just continuations, but persistent continuations.
In many CL systems you can just dump the system image.
For instance, see function ext:saveinitmem in clisp,
or extensions:save-lisp in cmucl or sb-ext:save-lisp in sbcl, etc.
If you really want to make continuation persistent independently
from the rest of the system, you'll find that even scheme doesn't allow that.
However, you'll find that with some metaprogramming, you can do that
on top of either Scheme or CL: see David Alan Hall's Tube for a
Scheme-based system that does precisely what you want.
As for implementing the Tube on top of CL,
I'm sure you could do that, too, by hacking Screamer.
[ Fran�ois-Ren� �VB Rideau | Reflection&Cybernethics | http://fare.tunes.org ]
[ TUNES project for a Free Reflective Computing System | http://tunes.org ]
That man who dares to waste one hour of time, has not discovered
the value of life. -- Charles Darwin
In article <·················@Samaris.tunes.org>, Francois-Rene Rideau
<····@tunes.org> wrote:
> Mark Conrad <······@iam.invalid> writes Re: Implementation Favoritism, a
> question of Lisp mindsets
> > If CL had continuations, or something closely approaching continuations,
> > code could be written in such a manner that I could manually interrupt
> > a long-running function from the keyboard, then turn the computer
> > power off; I could then turn the power on later, and resume running the
> > long-running function from the exact point it was interrupted.
>
> You want not just continuations, but persistent continuations.
Not only that, but I want "Network Persistant Continuations", (in CL) -
which would save the states of the entire network of computers at the
instant of the interruption. Such a system would require the
cooperation of all computers on the network, of course.
Such a system would allow all computer users in the network to come and
go as they please, power-on/power-off, yet still retain the option of
resuming/rerunning some past discussion of interest, with the assurance
that the state of all the computers online at that past time would be
faithfully preserved and recorded.
Mark-
In article <·························@iam.invalid>,
Mark Conrad <······@iam.invalid> wrote:
> In article <·················@Samaris.tunes.org>, Francois-Rene Rideau
> <····@tunes.org> wrote:
>
> > Mark Conrad <······@iam.invalid> writes Re: Implementation Favoritism, a
> > question of Lisp mindsets
> > > If CL had continuations, or something closely approaching continuations,
> > > code could be written in such a manner that I could manually interrupt
> > > a long-running function from the keyboard, then turn the computer
> > > power off; I could then turn the power on later, and resume running the
> > > long-running function from the exact point it was interrupted.
> >
> > You want not just continuations, but persistent continuations.
>
> Not only that, but I want "Network Persistant Continuations", (in CL) -
> which would save the states of the entire network of computers at the
> instant of the interruption. Such a system would require the
> cooperation of all computers on the network, of course.
>
> Such a system would allow all computer users in the network to come and
> go as they please, power-on/power-off, yet still retain the option of
> resuming/rerunning some past discussion of interest, with the assurance
> that the state of all the computers online at that past time would be
> faithfully preserved and recorded.
By "computers" one assumes that you're using the historical definition,
namely "person who performs computations" in a Turing-test-complete
sense? Otherwise the continuations wouldn't be nearly as useful.
paul
"Mark Conrad" <······@iam.invalid> wrote in message
······························@iam.invalid...
> In article <·················@Samaris.tunes.org>, Francois-Rene Rideau
> <····@tunes.org> wrote:
> > You want not just continuations, but persistent continuations.
>
> Not only that, but I want "Network Persistant Continuations", (in CL) -
> which would save the states of the entire network of computers at the
> instant of the interruption. Such a system would require the
> cooperation of all computers on the network, of course.
This is a different problem entirely. What you are looking for here is
essentially a continuation that can be persisted, and not only be persisted
but be persisted in such a way as to be reloaded into a completely different
(albeit it must be "compatible") image.
While Scheme makes continuations a first class object, not very many that I
am aware of allow you to actually persist the continuations individually.
Also, most implementations that I know of treat continuations as an opaque
object, which implies that there isn't any exported mechanisms to modiy or
rebuild a continuation.
There are just a gazillion issues with persisting a continuation, and even
more in loading them back in, much less into a different image. As a simple
exercise for the reader, what happens to a continuation that is saved out at
a point within a function, and then that function is actually changed to
physically move that point or even remove it? How does the continutation
reload properly? How does it know that it's been shot in the back?
The most trivial contrived analogy would be a C program dumping out a
jmp_buf populated by a setjmp() call to a file, and then having another
program read it in and expect it to work.
A continuation I would think would have to minimally dump it's entire call
tree as well as all of the other data captured in its environment. I won't
even go into the versioning issues this brings up.
There's also the issues of captured external resources (for example, what if
you have captured a handle to a file or a socket when you persist the
continuation?).
Then there are the "work areas" that routines like to use (buffers, and what
not). Ideally these are volatile, but maybe not. Minimally, they need to
aware of when they're saving and loading. And THAT of course brings up the
entire "serialization of objects" issue....
If you're not going to persist the actual continuation, then that means
you're persisting a symbolic version of the continuation. Which means that
you'll need something that "reads" the continuation "source", and then
rebuilds it. THAT takes a compiler/interpreter of its own, and no doubt
taking some short cuts (like not saving Stuff You Don't Want).
But when you're not saving Stuff You Don't Want, then you're not really a
continuation any more. You're something else. A sort of like maybe almost a
continuation. Something that persists enough of the state you feel is
necessary for you to start back up where you left off. Either way, you're
not a native continuation (and as I mentioned before, I'm not aware of any
Scheme's that let you piece together your own continuation bit by bit).
So, after all of the hubabaloo about a continuations, you inevitably have
this Thing that is anything but. It's just a blob of portable state that
works within your framework.
It's a blob that you need to persist, reify, interpret, compile, and Jump
To.
Well, hell, you can pretty much do that kind of thing is ANY modern high
level language. Some languages might even be easier to do that in than
others, in different ways. But if you want to make it easy to use, you'll
need to scribble up some syntax and thereby not only create the whole State
Thing system, but the Glue State Together In State Thing system.
Sounds like its getting pretty complicated. Taking something as simple as
continuations and making a mountain out of a mole hill. You might as well
write your own language to do this. Or grab a Scheme and start beating on
it -- really hard. That way you get continuations "for free".
Otherwise, perhaps you might want to think of something on a little bit
higher level. Something that lets you write your code the way you want (or
at least a good compromise) without the low level pain of what a
continuation really is.
Oh, and if you want to do something like thought, odds are pretty good the
CL will let you do what you want.
Regards,
Will Hartung
(·····@msoft.com)
In article <······················@newssvr14.news.prodigy.com>, Will
Hartung <·····@msoft.com> wrote:
> There are just a gazillion issues with persisting a continuation, and even
> more in loading them back in...<snipped>...
Yipes! - I was protected by my newbie ignorance, which believes
everything is possible.
FWIW, I saved your post, because it brings up a lot of things I was not
aware of.
Needless to say, you have amply demonstrated why it is not feasible to
try to save the state of an entire network of computers.
Mark-
Mark Conrad <······@iam.invalid> writes:
> I want "Network Persistant Continuations", (in CL) -
David Halls' Tube gives you that in Scheme.
You can port it to CL (using Screamer), or switch to Scheme.
> which would save the states of the entire network of computers at the
> instant of the interruption.
Well, you could do that based on the Tube and some consensus library.
Beware that synchronizing a lot of computers can cost quite a lot, too.
Maybe you can have a peek at Askemos and similar projects.
On top of CL, maybe ABCL/R2 can do things like that? Hum.
If you find or hack something, please put it on
http://www.cliki.net/Distributed
Would you like to save the state of the human world
and freeze the wall clock, too?
[ Fran�ois-Ren� �VB Rideau | Reflection&Cybernethics | http://fare.tunes.org ]
[ TUNES project for a Free Reflective Computing System | http://tunes.org ]
The last good thing written in C was Franz Schubert's Symphony number 9.
-- Erwin Dieterich <·····@cvt12.verfahrenstechnik.uni-stuttgart.de>
In article <··············@Samaris.tunes.org>, Francois-Rene Rideau
<····@tunes.org> wrote:
> Would you like to save the state of the human world
> and freeze the wall clock, too?
I *was* thinking of saving the state of the entire known universe
since the big bang.
Mark-
Mark Conrad <······@iam.invalid> writes:
> In article <··············@Samaris.tunes.org>, Francois-Rene Rideau
> <····@tunes.org> wrote:
>
> > Would you like to save the state of the human world
> > and freeze the wall clock, too?
>
> I *was* thinking of saving the state of the entire known universe
> since the big bang.
Saving the state is easy. Restoring it is hard. I think I got it
right, though. I assume no one remembers the awful problems we had in
January 2027....
Mark Conrad <······@iam.invalid> writes:
> Let me clarify what I meant. If CL had continuations, or something
> closely approaching continuations, code could be written in such a
> manner that I could manually interrupt a long-running function from the
> keyboard, then turn the computer power off; I could then turn the
> power on later, and resume running the long-running function from the
> exact point it was interrupted.
My computer does that already, for all applications whether written in
scheme or not. You don't want continuations, you want APM (or ACPI)
suspend-to-disk.
-dan
--
http://www.cliki.net/ - Link farm for free CL-on-Unix resources
From: Nils Goesche
Subject: Re: Implementation Favoritism, a question of Lisp mindsets
Date:
Message-ID: <lyistdp3hs.fsf@cartan.de>
Mark Conrad <······@iam.invalid> writes:
> In article <···············@news.t-online.com>, Jochen Schmidt
> <···@dataheaven.de> wrote:
>
> > Continuations are not an industrial strength tool but a half arsed
> > emulation utility for real world tools.
>
> Well, I am still trying to make up my mind as to whether
> continuations in CL are worth the trouble, as far as I personally am
> concerned.
How could you possibly make that decision before actually learning CL?
> My present attitude towards them are to only use them if no other
> way is available to do the same thing.
There is /always/ another way...
> For example, interdependent co-routines, where one of the functions
> is run for awhile, then the other function, etc.
>
> Multithreading OS's won't let me pick the exact place in the
> suspended function where I want to resume operation. Continuations
> will.
So chances are you will design your program differently when writing
in Lisp. You sound like a C++ programmer who thinks he cannot write
programs in Lisp because he hasn't got call-by-reference available
then.
> Another thing, if I have a CL function that takes a long while to
> run, say an hour for example, I can use a continuation to halt the
> function half way through, shut off my computer, then resume
> operation later at the exact point that I interrupted the function.
> With conventional CL using catch/throw etc., I would have to restart
> the function at the beginning.
So you don't use CATCH and THROW but BREAK and CONTINUE or anything
like that. Why do you mention THROW and CATCH all the time? Lisp
programmers hardly ever use these because the condition system is much
more powerful. Defer all that worrying for now and learn to write and
/think/ in Lisp. Chances are you will not even remember ever wanting
continuations then.
Regards,
--
Nils G�sche
"Don't ask for whom the <CTRL-G> tolls."
PGP key ID 0x0655CFA0
From: Tim Bradshaw
Subject: Re: Implementation Favoritism, a question of Lisp mindsets
Date:
Message-ID: <ey3wuhtjdu7.fsf@cley.com>
* Mark Conrad wrote:
> Multithreading OS's won't let me pick the exact place in the suspended
> function where I want to resume operation. Continuations will.
Sure they will. Just use some one of the many standard semaphore /
lock mechanisms. I do this all the time.
> Another thing, if I have a CL function that takes a long while to run,
> say an hour for example, I can use a continuation to halt the function
> half way through, shut off my computer, then resume operation later at
> the exact point that I interrupted the function.
Similarly, just use some kind of lock or semaphore. This is hardly
rocket science.
And (native) threads will let you make good use of the multiple
processors that everything but the lowest-end machines now have.
Doing that with call/cc would be ... challenging.
--tim
In article <··············@mycroft.actrix.gen.nz>, Paul Foley
<···@below.invalid> wrote:
> > The fact that many CL users yearn for continuations shows that the
> > designers of CL might have goofed a little bit when they assumed that
> > users would not miss industrial strength continuations.
>
> Really? "The fact"? So where are these "many CL users", and why are
> none of them posting here?
Just going by what a previous poster said, about the subject of
continuations being "beaten to death" previously.
If that much energy was devoted to the subject, must have been a lot of
CL users doing the beating.
As to why they are not posting here, they know better because they will
get beaten up by the biased hardheads in this NG.
> > Despite all this, continuations allow for all sorts of flexibility if
> > they are used when no other means is available to solve a particular
> > programming problem.
>
> Like what? Multiprocessing? Most implementations already have that
> (and if yours doesn't, and you think you need it, get one that does).
> Error handling? We have a nice condition system.
Multiprocessing is not fine-grained enough, it can't resume operation
at the exact spot in the function where operation was previously
suspended.
Your "nice condition system" in CL can't handle the types of errors
that rely on CL having "infinite extent". Why? Because catch/throw
etc. only have "dynamic extent".
For example:
=> (+ 1 (catch 'tag (+ 20 (throw 'tag 300))))
301
=> (throw 'tag 500)
Error: there was no pending CATCH for the tag TAG
CL coughs up an imaginary error message here, when there is no error.
With continuations, no false error message is printed.
Mark-
Mark Conrad <······@iam.invalid> writes:
> If that much energy was devoted to the subject, must have been a lot of
> CL users doing the beating.
>
> As to why they are not posting here, they know better because they will
> get beaten up by the biased hardheads in this NG.
And the fact that god doesn't show himself is proof of his existence,
right?
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
From: Duane Rettig
Subject: Re: Implementation Favoritism, a question of Lisp mindsets
Date:
Message-ID: <4vfxdrrn8.fsf@beta.franz.com>
Mark Conrad <······@iam.invalid> writes:
> In article <··············@mycroft.actrix.gen.nz>, Paul Foley
> <···@below.invalid> wrote:
>
> > > The fact that many CL users yearn for continuations shows that the
> > > designers of CL might have goofed a little bit when they assumed that
> > > users would not miss industrial strength continuations.
> >
> > Really? "The fact"? So where are these "many CL users", and why are
> > none of them posting here?
>
> Just going by what a previous poster said, about the subject of
> continuations being "beaten to death" previously.
>
> If that much energy was devoted to the subject, must have been a lot of
> CL users doing the beating.
Most of the energy I'm spending on this subject is being spent reading
this thread which you refuse to just let die.
> As to why they are not posting here, they know better because they will
> get beaten up by the biased hardheads in this NG.
You refuse to consider another possibility - that you're simply wrong,
and that there are not many CL users who yearn for continuations.
As an implementor, I have the right and the capability to add extensions
to the implementation I support. I add many such extensions, as time
allows, when my customers ask me for them.
I just went to our spr (softwware-problem-report) database, which has
every customer interaction from 1989 to present, and which includes
problems _and_ requests by customers for enhacement to our product.
I only found two sprs which even had continuations in the subject line,
and of those, one was really about debugging. The other was sent to
us in August of 1993 by a customer who was converting a Scheme program
to our lisp, and wanted Scheme-like continuations. We interacted with
him for a while, trying to be helpful by suggesting that he use Screamer,
but on his own he came back with the announcement that our multiprocessing
system would satisfy his needs.
No, CL users simply don't yearn for contiuations.
--
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
On Thu, Apr 17, 2003 at 03:14:09PM +0000, Mark Conrad wrote:
> In article <··············@mycroft.actrix.gen.nz>, Paul Foley
> <···@below.invalid> wrote:
>
> > Really? "The fact"? So where are these "many CL users", and why are
> > none of them posting here?
>
> Just going by what a previous poster said, about the subject of
> continuations being "beaten to death" previously.
>
> If that much energy was devoted to the subject, must have been a lot of
> CL users doing the beating.
No, Schemers being annoying.
> Your "nice condition system" in CL can't handle the types of errors
> that rely on CL having "infinite extent". Why? Because catch/throw
> etc. only have "dynamic extent".
PLEASE GO AND LEARN CL ALREADY. CATCH AND THROW ARE NOT THE CONDITION
SYSTEM!
--
; Matthew Danish <·······@andrew.cmu.edu>
; OpenPGP public key: C24B6010 on keyring.debian.org
; Signed or encrypted mail welcome.
; "There is no dark side of the moon really; matter of fact, it's all dark."
In article <·····················@lain.cheme.cmu.edu>, Matthew Danish
<·······@andrew.cmu.edu> wrote:
> > Your "nice condition system" in CL can't handle the types of errors
> > that rely on CL having "infinite extent". Why? Because catch/throw
> > etc. only have "dynamic extent".
>
> PLEASE GO AND LEARN CL ALREADY. CATCH AND THROW ARE NOT THE CONDITION
> SYSTEM!
PRETTY HARD TO DO WHEN "CONDITION SYSTEM" IS NOWHERE IN THE INDEX OF
RECOGNIZED CL BOOKS LIKE NORVIG'S "ARTIFICIAL INTELLIGENCE
PROGRAMMING".
SUBTITLE "CASE STUDIES IN COMMON LISP"
...or any other CL book I have, for that matter.
Speak Amelican, for crying out loud !
Mark-
From: Paul F. Dietz
Subject: Re: Implementation Favoritism, a question of Lisp mindsets
Date:
Message-ID: <lzGdnavLGafGbwKjXTWcog@dls.net>
Mark Conrad wrote:
> PRETTY HARD TO DO WHEN "CONDITION SYSTEM" IS NOWHERE IN THE INDEX OF
> RECOGNIZED CL BOOKS LIKE NORVIG'S "ARTIFICIAL INTELLIGENCE
> PROGRAMMING".
Mr. Conrad, blaming others for your own mistakes is a sign of a
seriously defective character. You really shouldn't advertise this
on usenet.
Paul
From: Lars Brinkhoff
Subject: Re: Implementation Favoritism, a question of Lisp mindsets
Date:
Message-ID: <85fzogm07e.fsf@junk.nocrew.org>
Mark Conrad writes:
> Pretty hard to do when "condition system" is nowhere in the index of
> recognized CL books like Norvig's "Artificial Intelligence Programming".
> ...or any other CL book I have, for that matter.
CLtL2 is a quite widely recognized CL book. Check out chapter 29.
From: Nikodemus Siivola
Subject: Re: Implementation Favoritism, a question of Lisp mindsets
Date:
Message-ID: <b7pced$4qr31$1@midnight.cs.hut.fi>
Mark Conrad <······@iam.invalid> wrote:
> PRETTY HARD TO DO WHEN "CONDITION SYSTEM" IS NOWHERE IN THE INDEX OF
> RECOGNIZED CL BOOKS LIKE NORVIG'S "ARTIFICIAL INTELLIGENCE
Try HyperSpec:
http//www.lispworks.com/reference/HyperSpec/Body/09_.htm
Or Google, even:
http://www.google.com/search?hl=en&ie=UTF-8&oe=UTF-8&q=Common+Lisp+Condition+System
Cheers,
-- Nikodemus
--
I refuse to have a battle of wits with an unarmed person.
From: Kenny Tilton
Subject: Re: Implementation Favoritism, a question of Lisp mindsets
Date:
Message-ID: <3E9EDBF9.20607@nyc.rr.com>
Mark Conrad wrote:
> As to why they are not posting here, they know better because they will
> get beaten up by the biased hardheads in this NG.
We'll know if cll is biased and hard-headed after you stop being both.
The bias is in thinking everything is a nail to the call/cc hammer. Your
problem solutions require call/cc only because the tool is a favorite of
yours and you tend to look for call/cc-centric solutions.
The hard-headedness is in reacting with name-calling to a lot of
sincere, well-meant advice. You won't be getting much more.
There were two ways to react the anti-call/cc chorus. One was to ask,
do these folks know something I do not? The other was to presume you
have run into bias.
The latter has the advantage of not requiring you to learn anything new.
--
kenny tilton
clinisys, inc
http://www.tilton-technology.com/
---------------------------------------------------------------
"Everything is a cell." -- Alan Kay
From: Nils Goesche
Subject: Re: Implementation Favoritism, a question of Lisp mindsets
Date:
Message-ID: <lyel41p1vh.fsf@cartan.de>
Mark Conrad <······@iam.invalid> writes:
> In article <··············@mycroft.actrix.gen.nz>, Paul Foley
> <···@below.invalid> wrote:
>
> > > The fact that many CL users yearn for continuations shows that
> > > the designers of CL might have goofed a little bit when they
> > > assumed that users would not miss industrial strength
> > > continuations.
> >
> > Really? "The fact"? So where are these "many CL users", and why
> > are none of them posting here?
>
> Just going by what a previous poster said, about the subject of
> continuations being "beaten to death" previously.
It was beaten to death just like now: Not because of Lispers wanting
continuations but because of newbies who do not even know Lisp but
think they have to teach everybody else what's wrong with this
language they don't know.
> As to why they are not posting here, they know better because they
> will get beaten up by the biased hardheads in this NG.
That's right: Call everybody who disagrees with your statements about
a language you don't even know and have no experience with a ``biased
hardhead��.
> > > Despite all this, continuations allow for all sorts of
> > > flexibility if they are used when no other means is available to
> > > solve a particular programming problem.
You wouldn't believe how much some people would miss the immense
flexibility of FORTRAN's computed GOTO; let alone an Assembly JMP
instruction.
> > Like what? Multiprocessing? Most implementations already have
> > that (and if yours doesn't, and you think you need it, get one
> > that does). Error handling? We have a nice condition system.
>
> Multiprocessing is not fine-grained enough, it can't resume
> operation at the exact spot in the function where operation was
> previously suspended.
Where exactly do you believe operation is resumed after scheduling??
> Your "nice condition system" in CL can't handle the types of errors
> that rely on CL having "infinite extent".
You are being incoherent.
> Why? Because catch/throw etc. only have "dynamic extent".
>
> For example:
>
> => (+ 1 (catch 'tag (+ 20 (throw 'tag 300))))
> 301
>
>
> => (throw 'tag 500)
> Error: there was no pending CATCH for the tag TAG
>
> CL coughs up an imaginary error message here, when there is no
> error.
Of course there is: You misused exceptions. And it is not clear at
all which ``particular programming problem��, for which there is ``no
other means available��, calling (throw 'tag 500) a second time is
supposed to solve.
Regards,
--
Nils G�sche
"Don't ask for whom the <CTRL-G> tolls."
PGP key ID 0x0655CFA0
Nils Goesche <······@cartan.de> writes:
> Mark Conrad <······@iam.invalid> writes:
>
> > In article <··············@mycroft.actrix.gen.nz>, Paul Foley
> > <···@below.invalid> wrote:
> > > > Despite all this, continuations allow for all sorts of
> > > > flexibility if they are used when no other means is available to
> > > > solve a particular programming problem.
>
> You wouldn't believe how much some people would miss the immense
> flexibility of FORTRAN's computed GOTO; let alone an Assembly JMP
> instruction.
Nils, I thought we sent you the latest memo. This year it's computed
COME FROM that's hot. We're going for the inverse of "computed GOSUB"
next year, but we don't have a name yet. "SUB FROM" or "COME SUB" have
both been suggested.
//Ingvar
--
My posts are fair game for anybody who wants to distribute the countless
pearls of wisdom sprinkled in them, as long as I'm attributed.
-- Martin Wisse, in a.f.p
In article <··············@cartan.de>, Nils Goesche <······@cartan.de>
wrote:
> > Why? Because catch/throw etc. only have "dynamic extent".
> >
> > For example:
> >
> > => (+ 1 (catch 'tag (+ 20 (throw 'tag 300))))
> > 301
> >
> >
> > => (throw 'tag 500)
> > Error: there was no pending CATCH for the tag TAG
> >
> > CL coughs up an imaginary error message here, when there is no
> > error.
>
> Of course there is: You misused exceptions.
Okay, I will acknowledge that the error message was genuine.
So hang me, I made a mistake in my wording, I *know* that it was a real
error.
The point is, if I had used a "CL continuation", i.e. extended CL so it
would recognize continuations (continuations with infinite extent) - -
- then no error message would have occured.
Example:
[Assume this is done in an 'extended' CL that recognizes call/cc ,
I am guessing somewhat at the code below, but the important point is
that we are assuming that CL was extended to recognize call/cc and that
call/cc has infinite extent, allowing the continuation to be used
repeatedly to return to the same point in the code - - - immediately
after the (+ 1... ]
(defvar *prior-cc* "an unimportant initial value")
==> (+ 1 (call/cc #'(lambda (cc)
(setf *prior-cc* cc)
(+ 20 (cc 300))) ))
301
==> (funcall *prior-cc* 500)
501
==> (funcall *prior-cc* 300)
301
==> (funcall *prior-cc* 0)
1
The above continuation is "used" a total of four times, to return me to
the same spot in the lambda function, right after the (+ 1
(assuming I can force code somewhat like the above example to work)
The (+ 20... is ignored in all cases, that is how continuations work,
they depend heavily on the 'order of evaluation' rules of a language,
and in this case the (cc 300) in the lambda function is evaluated
*before* the (+ 20
I would give my eye teeth if I could do everything that continuations
do by some other means in CL.
Right now I am concentrating on the above trivial code.
Someone said that they did not believe that Norvig's Scheme interpreter
on pages 756-777 would do the job of getting CL "extended" to recognize
continuations.
Belatedly, I am inclined to agree. :-(
Mark-
On Fri, 18 Apr 2003 12:28:18 GMT, Mark Conrad wrote:
> I would give my eye teeth if I could do everything that continuations
> do by some other means in CL.
Well, how about telling us what you actually want to do, rather than
just posting a bunch of nonsense code? Then perhaps someone could
tell you how to do it without continuations. If you don't say what
you want to do, noone can even try to help you.
> Right now I am concentrating on the above trivial code.
Fine, just replace
(1+ (call/cc ...))
with the much simpler
(funcall (setq *prior-cc* #'1+) 300)
--
There is no reason for any individual to have a computer in their home.
-- Ken Olson, President of DEC
(setq reply-to
(concatenate 'string "Paul Foley " "<mycroft" '(··@) "actrix.gen.nz>"))
From: Tim Bradshaw
Subject: Re: Implementation Favoritism, a question of Lisp mindsets
Date:
Message-ID: <ey3smshjcpe.fsf@cley.com>
* Mark Conrad wrote:
> Multiprocessing is not fine-grained enough, it can't resume operation
> at the exact spot in the function where operation was previously
> suspended.
Look, this is not hard.
(let ((x (make-lock :name "wait" :state :unlocked)))
(values (make-thread
"foo"
#'(lambda ()
...
(wait x)
...))
x))
--tim
From: Tim Bradshaw
Subject: Re: Implementation Favoritism, a question of Lisp mindsets
Date:
Message-ID: <ey3of35jcil.fsf@cley.com>
* Mark Conrad wrote:
> Just going by what a previous poster said, about the subject of
> continuations being "beaten to death" previously.
One person is quite enough to cause a huge frenzy in newsgroups.
Search for Ilias on cll in google groups, say.
--tim
From: Eduardo Muñoz
Subject: Re: Implementation Favoritism, a question of Lisp mindsets
Date:
Message-ID: <uu1cx8316.fsf@terra.es>
Mark Conrad <······@iam.invalid> writes:
> In article <··············@mycroft.actrix.gen.nz>, Paul Foley
> <···@below.invalid> wrote:
>
> > > The fact that many CL users yearn for continuations shows that the
> > > designers of CL might have goofed a little bit when they assumed that
> > > users would not miss industrial strength continuations.
> >
> > Really? "The fact"? So where are these "many CL users", and why are
> > none of them posting here?
>
> Just going by what a previous poster said, about the subject of
> continuations being "beaten to death" previously.
>
> If that much energy was devoted to the subject, must have been a lot of
> CL users doing the beating.
The beating was done by Mr Naggum with exquiste style. The
beating subject being the schemer wannabe though.
BTW, does anybody has news about Erik?
He has dissapeared from usenet and his website
(www.naggum.no) has been down for some time now. I remember
that he mentioned some kind of illness.
I really miss his icepick-like humor.
--
Eduardo Mu�oz | (prog () 10 (print "Hello world!")
http://213.97.131.125/ | 20 (go 10)) ;)
"Eduardo Mu�oz" <······@terra.es> writes:
> BTW, does anybody has news about Erik? He has dissapeared from
> usenet and his website (www.naggum.no) has been down for some time
> now. I remember that he mentioned some kind of illness.
>
> I really miss his icepick-like humor.
(I do, too.) I correspond with him now and then by email, and find
his wit to be as keen as ever. He has a different ISP, which I'm sure
he is capable of advertising if he wants people to know about it, so I
won't do that for him. For reasons personal to him, he seems to just
be choosing to do other things, at least for now.
In article <···············@shell01.TheWorld.com>, Kent M Pitman
<······@world.std.com> wrote:
> "Eduardo Mu�oz" <······@terra.es> writes:
>
> > BTW, does anybody has news about Erik? He has dissapeared from
> > usenet and his website (www.naggum.no) has been down for some time
> > now. I remember that he mentioned some kind of illness.
> >
> > I really miss his icepick-like humor.
>
> (I do, too.) I correspond with him now and then by email, and find
> his wit to be as keen as ever. He has a different ISP, which I'm sure
> he is capable of advertising if he wants people to know about it, so I
> won't do that for him. For reasons personal to him, he seems to just
> be choosing to do other things, at least for now.
One of the things that Erik did frequently was excoriate people for
talking about him instead of Lisp. So following his example:
Will all you pathetic whiners who are pining for the return of Lord
Naggumort please move your sniveling to this thread so that those of us
who don't miss his psychotic ranting can carry on talking about Lisp
without this distraction?
Thank you.
E.
P.S. I have a nice sharp ice pick here for anyone who really feels the need.
···@jpl.nasa.gov (Erann Gat) writes:
> In article <···············@shell01.TheWorld.com>, Kent M Pitman
> <······@world.std.com> wrote:
>
> > "Eduardo Mu�oz" <······@terra.es> writes:
> >
> > > BTW, does anybody has news about Erik? He has dissapeared from
> > > usenet and his website (www.naggum.no) has been down for some time
> > > now. I remember that he mentioned some kind of illness.
> > >
> > > I really miss his icepick-like humor.
> >
> > (I do, too.) I correspond with him now and then by email, and find
> > his wit to be as keen as ever. He has a different ISP, which I'm sure
> > he is capable of advertising if he wants people to know about it, so I
> > won't do that for him. For reasons personal to him, he seems to just
> > be choosing to do other things, at least for now.
>
> One of the things that Erik did frequently was excoriate people for
> talking about him instead of Lisp. So following his example:
>
> Will all you pathetic whiners who are pining for the return of Lord
> Naggumort please move your sniveling to this thread so that those of us
> who don't miss his psychotic ranting can carry on talking about Lisp
> without this distraction?
>
> Thank you.
>
> E.
>
> P.S. I have a nice sharp ice pick here for anyone who really feels the need.
Sure, I'll move my "I'm done for this month" post to this list. To be
clear, this message of mine here would not have happened had this new
thread not been created.
First, I don't happen to count what we were doing as whining. We were
exchanging a human courtesy of being concerned about one absent who
had been listed as ill, and assuring others that the person was still
alive. It was two messages, and it did not require a thread. A question
asked and answered, easily found by someone who cared using Google, easily
ignored by someone who didn't care.
Next, I hope that you, Erann, or anyone, if they are ever gone for a
community are remembered for the best they contributed, not the worst.
Not all of us come free of baggage. Some people seem to slug through my
posts because they find some value in them, but I'm forever amazed by the
ability of others to say the same thing as I often set out to say in
ever so much simpler a fashion. I'd like to think I'll not just be
remembered for being long-winded, even if that's clearly an aspect of
who I am.
I have said before and I'll say it again, I do not approve of people
writing detracting posts about other people. That's not to say I make
the rules. There are, effectively, no rules, since there is no material
mode of enforcement. This is a free speech forum.
http://www.nhplace.com/kent/PFAQ/usenet-freedom.html
I claim it's better to ignore what you don't like, since everyone
doesn't like something and there is no power to make things you don't
like go away. In this case, the thing you don't like is even gone,
and you still find the need to say something bad about it.
Furthermore, I have also said that I find it a faux pas of a higher
order to start a new thread to excoriate someone because then even
people who were just visiting the newsgroup and surveying the topics
discussed will find your post. Putting something in a subject line is
like putting a private conversation up a billboard. I think the
people who are deep down in an thread are few to start with, and
that's the _best_ time for something to get unnecessarily personal, if
it's going to be at all (which I wish it wouldn't be), because it's
largely buried by its nature. Putting something in a thread subject
adds fuel to what may be only a potential fire, veritably assuring it
will ignite. (Incidentally, I think it had burned itself out as of my
post. It was just two isolated messages, and you have now fanned the
dimming embers back to life.)
And finally, I have also noted that for the same reason as I don't think
people should whine at other people, I am being hypocritical myself if
I don't follow my own whining, into which you have drawn me, with some
sort of punitive action that acknowledges I'm doing exactly the thing
I'm saying shouldn't be done. I impose no sanction on you; I have no
power to do that, nor per se right to judge. But for myself, I do have
both the power and, arguably, the responsibility. So as penalty for my
contributing to the fanned embers of negativism, I withdraw from
newsgroup posts for the remainder of this month. Shame on me. See you
all when hopefully I've calmed down, and this thread, too, sometime
after the start of May.
--Kent
In article <···············@shell01.TheWorld.com>, Kent M Pitman
<······@world.std.com> wrote:
> ···@jpl.nasa.gov (Erann Gat) writes:
> > One of the things that Erik did frequently was excoriate people for
> > talking about him instead of Lisp. So following his example:
> >
> > Will all you pathetic whiners who are pining for the return of Lord
> > Naggumort please move your sniveling to this thread so that those of us
> > who don't miss his psychotic ranting can carry on talking about Lisp
> > without this distraction?
> First, I don't happen to count what we were doing as whining.
I was not addressing you specifically. I was addressing pathetic
whiners. If you are not a pathetic whiner then I was obviously not
talking to you.
> It was two messages,
Treacly nostalgia for he-who-must-not-be-named has been stealthily
appearing in many contexts since he went to ground. These two messages
just pushed me past my limit of tolerance.
> Next, I hope that you, Erann, or anyone, if they are ever gone for a
> community are remembered for the best they contributed, not the worst.
Well, I appreciate that. Do you hope that Saddam Hussein will be
remembered for the good he did for Iraq? Do you think we should remember
Hitler for lifting Germany out of its horrible economic conditions?
(Godwin was right.)
> Not all of us come free of baggage. Some people seem to slug through my
> posts because they find some value in them, but I'm forever amazed by the
> ability of others to say the same thing as I often set out to say in
> ever so much simpler a fashion. I'd like to think I'll not just be
> remembered for being long-winded, even if that's clearly an aspect of
> who I am.
There's nothing wrong with being long-winded. There's a lot wrong with
being uncivil, even on usenet (maybe especially on usenet). (And yes, I
admit I was somewhat uncivil before. I was emulating Erik's style for the
benefit of those who claimed to miss him. Sue me.)
> I have said before and I'll say it again, I do not approve of people
> writing detracting posts about other people. That's not to say I make
> the rules. There are, effectively, no rules, since there is no material
> mode of enforcement. This is a free speech forum.
I agree with this. I am on the record as defending Erik's (and by
implication everyone else's) right to post whatever they want on c.l.l.
http://groups.google.com/groups?selm=gat-1201021625040001%40192.168.1.50
Nonetheless I believe that he did far more harm than good, and that his
departure is a net win for Lisp.
In my assessment, c.l.l. has seen a renaissance since he left. A dozen
local Lisp interest groups have sprung up overnight. New people have come
and not been chased away. We even managed to talk about the war without
it degenerating into a flamefest! (Someone even commented on how
impressed he was that we could do that, though I can't find the reference
just now.)
> I claim it's better to ignore what you don't like,
Of course it's better. The problem is that it only works if everyone does
it, and the fact is that almost no one does it, not even you (and
certainly not Erik). If you did we would not be having this discussion.
> since everyone
> doesn't like something and there is no power to make things you don't
> like go away. In this case, the thing you don't like is even gone,
> and you still find the need to say something bad about it.
No, the thing I don't like is not gone, it is right here in my face. The
thing I don't like is the hypocricy of being told that I should ignore
what I don't like by someone who is obviously not ignoring what they don't
like. The gall! The minute you start to follow your own advice this
conversation will be over.
> Furthermore, I have also said that I find it a faux pas of a higher
> order to start a new thread to excoriate someone because then even
> people who were just visiting the newsgroup and surveying the topics
> discussed will find your post. Putting something in a subject line is
> like putting a private conversation up a billboard. I think the
> people who are deep down in an thread are few to start with, and
> that's the _best_ time for something to get unnecessarily personal, if
> it's going to be at all (which I wish it wouldn't be), because it's
> largely buried by its nature. Putting something in a thread subject
> adds fuel to what may be only a potential fire, veritably assuring it
> will ignite. (Incidentally, I think it had burned itself out as of my
> post. It was just two isolated messages, and you have now fanned the
> dimming embers back to life.)
You are making the false assumption that my intent was to stop people from
posting nostalgic remembrances of Erik. It was not. As I said, I too
believe in free speech. You Erik-worshippers have the right to advertise
your nostalgia for him. I likewise have the right to dissent, which is
what I am doing here. I think that as a common courtesy all such
off-topic posts should be clearly marked as such, which is the reason I
started this new thread. I don't want to silence this discussion, I
*want* to fan the flames (hopefully we can all get this out of our systems
once and for all), but I want the flames isolated and clearly marked.
That's how we managed to talk about the war without things getting out of
hand, and that's how I hope we'll get past this without things getting out
of hand. So all you folks who miss Erik, post here and get it out of your
system. All you who wish him consigned to the depths do likewise, but do
it here in this off-topic thread so the rest of us can get on with the
business at hand in the rest of the newsgroup.
> And finally, I have also noted that for the same reason as I don't think
> people should whine at other people, I am being hypocritical myself if
> I don't follow my own whining, into which you have drawn me,
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
I have done no such thing. I am not holding a gun to your head. You are
posting these things of your own free will. Don't try to blame your
shameful hypocricy on me.
> with some
> sort of punitive action that acknowledges I'm doing exactly the thing
> I'm saying shouldn't be done. I impose no sanction on you; I have no
> power to do that, nor per se right to judge. But for myself, I do have
> both the power and, arguably, the responsibility. So as penalty for my
> contributing to the fanned embers of negativism, I withdraw from
> newsgroup posts for the remainder of this month. Shame on me. See you
> all when hopefully I've calmed down, and this thread, too, sometime
> after the start of May.
Oh, Kent, grow up will you? You're really getting too old for this
I'm-going-to-take-my-ball-and-bat-and-go-home game.
E.
···@jpl.nasa.gov (Erann Gat) writes:
> hypocricy
Please, guys: It's /hypocrisy/, not hypocricy.
Just say NO to this thread.
Regards,
--
Nils G�sche
Ask not for whom the <CONTROL-G> tolls.
PGP key ID #xD26EF2A0
···@jpl.nasa.gov (Erann Gat) wrote in message news:<····················@k-137-79-50-101.jpl.nasa.gov>...
> In article <···············@shell01.TheWorld.com>, Kent M Pitman
> <······@world.std.com> wrote:
>
> > ···@jpl.nasa.gov (Erann Gat) writes:
>
> > > One of the things that Erik did frequently was excoriate people for
> > > talking about him instead of Lisp. So following his example:
> > >
> > > Will all you pathetic whiners who are pining for the return of Lord
> > > Naggumort please move your sniveling to this thread so that those of us
> > > who don't miss his psychotic ranting can carry on talking about Lisp
> > > without this distraction?
>
> > First, I don't happen to count what we were doing as whining.
>
> I was not addressing you specifically. I was addressing pathetic
> whiners. If you are not a pathetic whiner then I was obviously not
> talking to you.
>
Given the above statement of yours; had I written what KMP had
written, you'd have given the same response. Since that "whining"
remark was directed specifically towards Erik (and some others), I
wonder what your response would have been if Erik'd said: "First, I
don't happen to count what we were doing as whining."
>
> Nonetheless I believe that he did far more harm than good, and that his
> departure is a net win for Lisp.
>
My memory of Erik is this: he was a lisp expert, and never hesitated
to bring anyone flying back to the ground. And I agree that in all
these `fights' started because of a reply from him to someone, he
always said that he added "hooks" in his posts to see if anyone would
fall for them; it turned out that most people did (especially, for
some reason, you and your colleagues). Then you would all get into
great verbal debates etc etc., which, as far as I always noticed,
ended up with Erik winning hands down. (I talk only about those posts
where the two parties argue about non-lisp matters etc.)
>
> > I claim it's better to ignore what you don't like,
>
> Of course it's better. The problem is that it only works if everyone does
> it, and the fact is that almost no one does it, not even you (and
> certainly not Erik). If you did we would not be having this discussion.
>
It would work if you had your own set of standards, and did not depend
on another person's behaviour to act on your own. If a man steals
from you, that does not justify your stealing from him. If you do
both of you are theives, with none nobler than the other. If you'd
chosen to ignore Erik, you were free to at all times. It takes two
hands to clap (or two to tango) and your continued arguing with him
puts you in no position to judge him. The only reason you continually
argued with him was ego. Refusing to respond meant losing, and that
was something you were never willing to accept. But at all times you
would talk about how degenerate the discussions were etc., but with no
end of them in sight. Again, saying "I shouldn't respond to your
trash." wouldn't work because Erik would always say, "And that
wouldn't have worked without this message would it?" or some such, and
you'd all be hooked in again.
> > And finally, I have also noted that for the same reason as I don't think
> > people should whine at other people, I am being hypocritical myself if
> > I don't follow my own whining, into which you have drawn me,
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> I have done no such thing. I am not holding a gun to your head. You are
> posting these things of your own free will. Don't try to blame your
> shameful hypocricy on me.
In that case, Erik never picked a fight with you; he wasn't holding a
gun at /your/ head either. You chose to draw yourself into a fight
(and always ended up making a fool of yourself). Don't try to blame
your shameful hypocricy on Erik.
P.S. Your next post will counter every statement I've made. So, FWIW,
you win.
Thanks,
Vijay L
···@jpl.nasa.gov (Erann Gat) writes:
> In article <···············@shell01.TheWorld.com>, Kent M Pitman
> <······@world.std.com> wrote:
>
> > ···@jpl.nasa.gov (Erann Gat) writes:
>
> > > One of the things that Erik did frequently was excoriate people for
> > > talking about him instead of Lisp. So following his example:
> > >
> > > Will all you pathetic whiners who are pining for the return of Lord
> > > Naggumort please move your sniveling to this thread so that those of us
> > > who don't miss his psychotic ranting can carry on talking about Lisp
> > > without this distraction?
>
> > First, I don't happen to count what we were doing as whining.
>
> I was not addressing you specifically. I was addressing pathetic
> whiners. If you are not a pathetic whiner then I was obviously not
> talking to you.
Well Kent thought you were addressing him, to some extent anyway. I
guess you should have been clearer, perhaps a list would help.
>
> > It was two messages,
>
> Treacly nostalgia for he-who-must-not-be-named has been stealthily
> appearing in many contexts since he went to ground. These two messages
> just pushed me past my limit of tolerance.
So your complaint is that people like Erik and respect him, that is
why we wish he was here after all. And Erik is obscenely useful, iff
you can do four of things:
1: pay attention
2: think
3: honestly try to work towards a solution
4: keep personal and professional separate, aka behave like an adult
>
> > Next, I hope that you, Erann, or anyone, if they are ever gone for a
> > community are remembered for the best they contributed, not the worst.
>
> Well, I appreciate that. Do you hope that Saddam Hussein will be
> remembered for the good he did for Iraq? Do you think we should remember
> Hitler for lifting Germany out of its horrible economic conditions?
> (Godwin was right.)
Well that response was rude, abusive and uncalled for. Even if you do
not like Erik, what has Kent done to deserve this? Are you looking
for new enemies now that old ones are absent?
>
> > Not all of us come free of baggage. Some people seem to slug through my
> > posts because they find some value in them, but I'm forever amazed by the
> > ability of others to say the same thing as I often set out to say in
> > ever so much simpler a fashion. I'd like to think I'll not just be
> > remembered for being long-winded, even if that's clearly an aspect of
> > who I am.
>
> There's nothing wrong with being long-winded. There's a lot wrong with
> being uncivil, even on usenet (maybe especially on usenet). (And yes, I
> admit I was somewhat uncivil before. I was emulating Erik's style for the
> benefit of those who claimed to miss him. Sue me.)
Erik wan never uncivil first, from what I have observed. And that
included the time he zaped me when I first came here.
>
> > I have said before and I'll say it again, I do not approve of people
> > writing detracting posts about other people. That's not to say I make
> > the rules. There are, effectively, no rules, since there is no material
> > mode of enforcement. This is a free speech forum.
>
> I agree with this. I am on the record as defending Erik's (and by
> implication everyone else's) right to post whatever they want on c.l.l.
>
> http://groups.google.com/groups?selm=gat-1201021625040001%40192.168.1.50
>
> Nonetheless I believe that he did far more harm than good, and that his
> departure is a net win for Lisp.
And you are wrong.
>
> In my assessment, c.l.l. has seen a renaissance since he left. A dozen
> local Lisp interest groups have sprung up overnight. New people have come
> and not been chased away. We even managed to talk about the war without
> it degenerating into a flamefest! (Someone even commented on how
> impressed he was that we could do that, though I can't find the reference
> just now.)
And you claim that Erik's absence is the root cause for this? You
have to be joking or a fool blinded by his own opinion. Now let me
address each of your wrong statements in order:
First the users groups, lispnyc was the first publicly announced group
in the current crop. This group came into being because of my big
mouth, "Lets form a users group in nyc guys" posted here and the
generosity of David Bakhash, who let us use his office for the first
few meetings(thanks again Dave). Then there were the monthly meeting
announcements that showed it was working, people showed up. This lead
other people to start asking if there were lispers in their
neighborhood and the beer did not hurt. And it happened over the
course of 4-6 months.
Next Erik, to the best of my knowledge, has never chased away someone
who was serious about learning CL, ie. paid attention to the help they
were given and thought about it. He did not suffer fools though.
And now third, your deliberately and remarkably off topic post on Gulf
II. You were flamed idiot go reread the thread from google. I know
I flamed you.
>
> > I claim it's better to ignore what you don't like,
>
> Of course it's better. The problem is that it only works if everyone does
> it, and the fact is that almost no one does it, not even you (and
> certainly not Erik). If you did we would not be having this discussion.
No it works for you when you do it and it is that simple. Since you
choose not to shut up even when you post that you know you should it
is wholly your fault that you post. And your moronic logic is truly
silly when Kent is one of the people who is consistent in this
regard. The worst thing he does is say he is taking a break from the
group when he feels that there is too much screaming going on. And it
works because we want Kent to come back and stay.
> > since everyone
> > doesn't like something and there is no power to make things you don't
> > like go away. In this case, the thing you don't like is even gone,
> > and you still find the need to say something bad about it.
>
> No, the thing I don't like is not gone, it is right here in my face. The
> thing I don't like is the hypocricy of being told that I should ignore
> what I don't like by someone who is obviously not ignoring what they don't
> like. The gall! The minute you start to follow your own advice this
> conversation will be over.
Now you are trying to engage Kent as if he responded like Erik to your
flawed logic. How long have you been here? Idiot Kent does not do
that.
>
> > Furthermore, I have also said that I find it a faux pas of a higher
> > order to start a new thread to excoriate someone because then even
> > people who were just visiting the newsgroup and surveying the topics
> > discussed will find your post. Putting something in a subject line is
> > like putting a private conversation up a billboard. I think the
> > people who are deep down in an thread are few to start with, and
> > that's the _best_ time for something to get unnecessarily personal, if
> > it's going to be at all (which I wish it wouldn't be), because it's
> > largely buried by its nature. Putting something in a thread subject
> > adds fuel to what may be only a potential fire, veritably assuring it
> > will ignite. (Incidentally, I think it had burned itself out as of my
> > post. It was just two isolated messages, and you have now fanned the
> > dimming embers back to life.)
>
> You are making the false assumption that my intent was to stop people from
> posting nostalgic remembrances of Erik. It was not. As I said, I too
> believe in free speech. You Erik-worshippers have the right to advertise
> your nostalgia for him. I likewise have the right to dissent, which is
Now you are dehumanizing the people who want Erik around, fuck you.
And you have a right to shit in your hat, that does not mean it is a
good idea(even for you).
> what I am doing here. I think that as a common courtesy all such
> off-topic posts should be clearly marked as such, which is the reason I
> started this new thread. I don't want to silence this discussion, I
> *want* to fan the flames (hopefully we can all get this out of our systems
> once and for all), but I want the flames isolated and clearly marked.
> That's how we managed to talk about the war without things getting out of
> hand, and that's how I hope we'll get past this without things getting out
> of hand. So all you folks who miss Erik, post here and get it out of your
> system. All you who wish him consigned to the depths do likewise, but do
> it here in this off-topic thread so the rest of us can get on with the
> business at hand in the rest of the newsgroup.
>
> > And finally, I have also noted that for the same reason as I don't think
> > people should whine at other people, I am being hypocritical myself if
> > I don't follow my own whining, into which you have drawn me,
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> I have done no such thing. I am not holding a gun to your head. You are
> posting these things of your own free will. Don't try to blame your
> shameful hypocricy on me.
And no one is holding a gun to your head either, so why do you keep
posting? We /made/ you do it, right?
>
> > with some
> > sort of punitive action that acknowledges I'm doing exactly the thing
> > I'm saying shouldn't be done. I impose no sanction on you; I have no
> > power to do that, nor per se right to judge. But for myself, I do have
> > both the power and, arguably, the responsibility. So as penalty for my
> > contributing to the fanned embers of negativism, I withdraw from
> > newsgroup posts for the remainder of this month. Shame on me. See you
> > all when hopefully I've calmed down, and this thread, too, sometime
> > after the start of May.
>
> Oh, Kent, grow up will you? You're really getting too old for this
> I'm-going-to-take-my-ball-and-bat-and-go-home game.
You are one to talk??? Kent is simply stating that if he does not
like what is going on in the room he will leave. And he is not
blaming anyone else for the behavior, is that what you do not
understand?
marc
Marc Spitzer <········@optonline.net> wrote in message news:<··············@bogomips.optonline.net>...
> So your complaint is that people like Erik and respect him, that is
> why we wish he was here after all. And Erik is obscenely useful, iff
> you can do four of things:
> 1: pay attention
> 2: think
> 3: honestly try to work towards a solution
> 4: keep personal and professional separate, aka behave like an adult
Yeah, I guess point number 4 has always been his (and his minions's)
most noticeable virtue.
Were you serious? I hope not.
········@techie.com (Boethius) writes:
> Marc Spitzer <········@optonline.net> wrote in message news:<··············@bogomips.optonline.net>...
>
> > So your complaint is that people like Erik and respect him, that is
> > why we wish he was here after all. And Erik is obscenely useful, iff
> > you can do four of things:
> > 1: pay attention
> > 2: think
> > 3: honestly try to work towards a solution
> > 4: keep personal and professional separate, aka behave like an adult
>
> Yeah, I guess point number 4 has always been his (and his minions's)
> most noticeable virtue.
What is it with this minion shit? As far as I know I have never had any
direct interaction with you so why do you choose to attack me personally?
>
> Were you serious? I hope not.
Yes and since I disagree with you I *must* be evil. What a /small/ mind
you appear to have.
marc
From: Tim Daly, Jr.
Subject: Re: The Erik Naggum Fan Club (OFF TOPIC)
Date:
Message-ID: <87u1cw39cj.fsf@tenkan.org>
Kent M Pitman <······@world.std.com> writes:
> ···@jpl.nasa.gov (Erann Gat) writes:
>
...
> > One of the things that Erik did frequently was excoriate people for
> > talking about him instead of Lisp. So following his example:
> >
> > Will all you pathetic whiners who are pining for the return of Lord
> > Naggumort please move your sniveling to this thread so that those of us
> > who don't miss his psychotic ranting can carry on talking about Lisp
> > without this distraction?
> >
> > Thank you.
> >
> > E.
> >
> > P.S. I have a nice sharp ice pick here for anyone who really feels the need.
>
> Sure, I'll move my "I'm done for this month" post to this list. To be
> clear, this message of mine here would not have happened had this new
> thread not been created.
...
Sir Gat, at the risk of an ice pick through the toe, wasn't your post
meant to be amusing?
This is usenet, my good man! Psychotic ranting is the nature of the
beast.
I've also wondered what happened to Erik. It's not c.l.l without him.
-Tim
--
In article <··············@tenkan.org>, ···@tenkan.org (Tim Daly, Jr.)
wrote:
> I've also wondered what happened to Erik. It's not c.l.l without him.
Of course, this is c.l.l - check the settings of your news reader.
I am glad that EN has left this group, and I hope that he will never
return again. But I agree that this thread is not very useful.
Pascal
P.S.: I hope that kmp stays here, because usually I find his posts to be
extremely helpful and enlightening, even when I don't agree with some of
his conclusions.
--
"If I could explain it, I wouldn't be able to do it."
A.M.McKenzie
Pascal Costanza <········@web.de> writes:
> In article <··············@tenkan.org>, ···@tenkan.org (Tim
> Daly, Jr.) wrote:
>
> > I've also wondered what happened to Erik. It's not c.l.l
> > without him.
>
> Of course, this is c.l.l - check the settings of your news
> reader.
Nothing can beat German humor.
> I am glad that EN has left this group, and I hope that he will
> never return again.
What the fuck is wrong with you people? To make it clear even to
the ethically most challenged: Kicking at people who cannot
defend themselves because they haven't been around for several
months is not only immoral, it is also low, disgusting and a sign
of bad character.
> But I agree that this thread is not very useful.
Useful enough to add fuel to it, it seems.
Regards,
--
Nils G�sche
Ask not for whom the <CONTROL-G> tolls.
PGP key ID #xD26EF2A0
Nils Goesche wrote:
> What the fuck is wrong with you people?
Precisely. We have only had two bullshit threads lately, and Erann has
started them both. Pascal had chalked up a lot of points in my book,
then tossed them all with one mean-spirited sentence. And to think they
both pose as Protectors of c.l.l. chya!
The problem we all have is not wanting to perpetuate a bullshit thread,
but at the same time not wanting the bullshit to go unanswered. kwmp
dashed himself on the rocks of this conflict, lies now in drydock.
What we need is a non-continuing continuation, and your casting of the
problem ("what the fuck is wrong with [Erann and Pascal]") solves that
neatly; we can now dissect /their/ characters over the next couple of
dozen articles. Erann especially likes it when we dissect him when he
asks us to dissect others.
Scalpel!
ps. My honest take on this is that Erann was trying with his seemingly
harsh post to provoke the ENth Coming. And Pascal seems like an OK guy,
maybe he was doing his best to help. In this benign light, cll is forgiven.
--
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:
> We have only had two bullshit threads lately, and Erann has
> started them both.
Frankly, compared to how much bullshit was being slung around here in the
EN days I think two bullshit threads in a month is doing pretty well.
Still, I am fairly chagrined to realize that Kenny is right. I apologize,
and hereby depart this thread.
E.
In article <·················@darkstar.cartan>,
Nils Goesche <···@cartan.de> wrote:
> > I am glad that EN has left this group, and I hope that he will
> > never return again.
>
> What the fuck is wrong with you people? To make it clear even to
> the ethically most challenged: Kicking at people who cannot
> defend themselves because they haven't been around for several
> months is not only immoral, it is also low, disgusting and a sign
> of bad character.
I wonder in which way my statement can be interpreted as "kicking at
people". I have just stated a personal, subjective opinion. How could
anybody be able to defend themselves against expressions of antipathy in
any case?
The reason for my statement is as follows: Several other people have
stated that they miss EN. It has just started to look as if this was a
generally accepted notion. I just wanted to clarify that it is not.
> > But I agree that this thread is not very useful.
>
> Useful enough to add fuel to it, it seems.
see above
Pascal
--
"If I could explain it, I wouldn't be able to do it."
A.M.McKenzie
"Nils Goesche" <···@cartan.de> wrote in message
······················@darkstar.cartan...
> Pascal Costanza <········@web.de> writes:
> > But I agree that this thread is not very useful.
>
> Useful enough to add fuel to it, it seems.
The interesting thing is that, not knowing him personally, I have this
feeling that a lot of the ill will (in all directions) that surrounds EN
seems to stem not only from the personalities involved, but also the medium
of conversation.
If the conversations that explode off on to their own thread branches had
started in person, I bet they all would have died fairly quickly and
quietly, and ideally peacably, compared to the anger and such on USENET.
Inevitably the debate drifted off the topic and to various forms of debating
techique and understanding of the principles of formal argument and then
inevitably into the personal insults.
As has been made clear I think over and over, email, USENET, BBSs, etc are
great ways to exchange and transfer information, particularly technical and
factual information. But they are terrible ways facilitate "communication"
between people. It is such a low bandwidth medium compared to what we are
used to when working face to face.
The other example is how two people who meet each other on a street in their
cars end up screaming at each other (in their cars), whereas were they to
meet in person (say at a door), nothing would happen -- one would go first,
the other second and neither think twice about it.
So, consider this next time things get completely out of hand, that it might
not just be the messenger, but also the medium.
Regards,
Will Hartung
(·····@msoft.com)
From: Tim Bradshaw
Subject: Re: The Erik Naggum Fan Club (OFF TOPIC)
Date:
Message-ID: <ey3he8wzo7k.fsf@cley.com>
* Erann Gat wrote:
> P.S. I have a nice sharp ice pick here for anyone who really feels the need.
Just use it on your own head, why don't you, and do us all a favour?
--tim
Tim Bradshaw <···@cley.com> wrote in message news:<···············@cley.com>...
> * Erann Gat wrote:
>
> > P.S. I have a nice sharp ice pick here for anyone who really feels the need.
>
> Just use it on your own head, why don't you, and do us all a favour?
>
> --tim
(progn
(concatenate 'string "It can also be used to " "show American pride.")
(concatenate 'string "Use it on Ossama's Face " "along with a rusty razor.")
(concatenate 'string "Also use it " "on Saddam's face.")
(concatenate 'string "And on any " "Terrorists caught on American soil.")
(concatenate 'string "Then shove it" "up their @r$3.")
)
;; Writing vile sarcastic messages in Lisp code is sure fun.
;; Lisp can provide a solution to the problem of Terrorism.
;; And, the solutions to many other problems, too: Iraq, Ossama, etc.
;; Remember to dispose of the ice pick/ razor.
From: Eduardo Muñoz
Subject: Re: The Erik Naggum Fan Club (OFF TOPIC)
Date:
Message-ID: <u1y00q72y.fsf@terra.es>
···@jpl.nasa.gov (Erann Gat) writes:
> Will all you pathetic whiners who are pining for the return of Lord
> Naggumort please move your sniveling to this thread so that those of us
> who don't miss his psychotic ranting can carry on talking about Lisp
> without this distraction?
Talking about the war is so much better, isnt it?
Get a brain, a personality and some manners and you will be
missed when you go away too.
> Thank you.
Fuck you
> P.S. I have a nice sharp ice pick here for anyone who really feels the need.
Put it up your ass.
--
Eduardo Mu�oz | (prog () 10 (print "Hello world!")
http://213.97.131.125/ | 20 (go 10))
On Wed, 16 Apr 2003 22:24:45 GMT, Mark Conrad <······@iam.invalid> wrote:
> They CL designers made a compromise, allowing CL users to create
> 'crippled' continuations using catch, throw, etc., which can do some of
> the things that can be done with more robust continuations.
It might be instructive to compare the experience and skills of the Common
Lisp users who yearn for "industrial strength continuations", and the
Common Lisp designers themselves.
Paolo
--
Paolo Amoroso <·······@mclink.it>
I can understand the standard simple examples that are typically quoted, and
I can easily think in terms of machine language to figure out how call/cc
would work. However, any serious scheme code with call/cc seems so bloody
obfuscated to me, I always give up trying to understand it.
If programs are a method of communicating with other programmers, then
call/cc has failed miserably, rather like my poem below.
Little Jack Horner
sat in a corner
Coding and Scheming against LISP.
He called Forth
obfuscation galore
but on continuation felt something amiss.
Seriously, I have never found the patience to really grok this wonderful
thing. I can always achive the set goals in a very readable manner in other
ways.
K.
>
> A note to other Lisp newbies like me:
>
> There is no reason to fear continuations. They are merely a way to
> jump out of a function before the function would normally finish.
>
> The function is just "paused" at the point where the continuation was
> activated in the middle of the function.
>
> The function can then be "resumed" later if desired, at the exact point
> in the code where it was paused or interrupted.
>
> As you can imagine, jumping out of a function before it is normally due
> to finish can cause all sorts of problems.
>
> Jumping back into the middle of a 'suspended' function can also cause
> all sorts of problems.
>
> Despite all this, continuations allow for all sorts of flexibility if
> they are used when no other means is available to solve a particular
> programming problem.
>
> Mark-
From: Tim Daly, Jr.
Subject: Re: Implementation Favoritism, a question of Lisp mindsets
Date:
Message-ID: <871xzr5rmu.fsf@tenkan.org>
Mark Conrad <······@iam.invalid> writes:
...
> A note to other Lisp newbies like me:
...
A note to other Lisp newbies like Mark: Mark is a newbie.
It's been my experience in languages both natural and artificial, that
ease and power of expression vary with skill. There are people in
this newsgroup that have attained mastery of both Scheme and Lisp,
(the most blatant example being, probably, Kent Pitman). If they say
that continuations would be superfluous, even troublesome, in CL,
well, that means something. But if Mark Conrad has trouble expressing
himself without continuations, well, I'll wager that's because he just
hasn't learned how, yet.
On a side note, I have some sympathy with Mark. I obviously didn't
learn every programming language before deciding that I like Lisp, and
I don't figure anybody else did, either. Some instinct led us here,
some sense of what's right, and what's pretty. Probably that very
same instinct is causing Mark some frustration, as he learns that
there's a shiny thing called a continuation, and it isn't to be found
in CL.
There are other things that, although they are general, and powerful,
CL doesn't include. I mean, heck, why don't we treat all the world as
an array?
-Tim
--
On this day of my life at 2230 PDST local time Thursday 2003 AD, or
0630 GMT Friday, Tim Daly Jr. offered up the following observation:
In article <··············@tenkan.org>, Tim Daly, Jr. <···@tenkan.org>
wrote:
> But if Mark Conrad has trouble expressing
> himself without continuations, well, I'll wager that's because he just
> hasn't learned how, yet.
You got that right.
To me, Common Lisp is a nail, and I have this handy dandy continuation
hammer.
I am into Lisp for the short haul, as a recreational pursuit.
All this CL stuff is a big mystery to me. Until recently, I thought a
cons-cell was a place where they kept criminals.
My present hobby-horse is a snippet of code that I posted recently to
Mr. Nils Goesche.
I hope he ignores my post, because the code I posted to him did not
seem to be affected at all by the presence *or* absence of the
"proclaim" line. (or an equivilent "defvar" line for that matter)
I had fervently hoped that "proclaim" would be a back-door to help me
understand "defvar", but sadly it was not to be.
Yet, Paul Graham's backtracking tree-search code on page 271 of his
"On-Lisp" book is adversely affected by an illigitimate defvar line.
Boils down to some programs are affected, some are not.
Graham states that his line (setq *cont* #'identity) on his page 267 is
absolutely necessary for correct running of his CL "continuations"
...and can't be (defvar *cont* #'identity) for example.
I don't have the smarts to figure out the effect of defvar on the scope
and extent considerations in his code.
I can't think of a *simple* code example to illustrate the difference
between these two different toplevel lines at the beginning of a
program:
(defvar *cont* 'foo)
- - or - -
(setq *cont* 'foo)
Mark-
On Fri, Apr 25, 2003 at 06:30:45AM +0000, Mark Conrad wrote:
> I can't think of a *simple* code example to illustrate the difference
> between these two different toplevel lines at the beginning of a
> program:
>
> (defvar *cont* 'foo)
> - - or - -
> (setq *cont* 'foo)
Kinda tough when one of them causes undefined behavior.
--
; Matthew Danish <·······@andrew.cmu.edu>
; OpenPGP public key: C24B6010 on keyring.debian.org
; Signed or encrypted mail welcome.
; "There is no dark side of the moon really; matter of fact, it's all dark."
In article <·····················@lain.cheme.cmu.edu>, Matthew Danish
<·······@andrew.cmu.edu> wrote:
> On Fri, Apr 25, 2003 at 06:30:45AM +0000, Mark Conrad wrote:
> > I can't think of a *simple* code example to illustrate the difference
> > between these two different toplevel lines at the beginning of a
> > program:
> >
> > (defvar *cont* 'foo)
> > - - or - -
> > (setq *cont* 'foo)
>
> Kinda tough when one of them causes undefined behavior.
Yes indeed, especially when an acknowledged CL expert like Paul Graham
uses this undefined CL behavior in his published code.
Mark-
From: Nils Goesche
Subject: Re: Implementation Favoritism, a question of Lisp mindsets
Date:
Message-ID: <87ptn8oxd5.fsf@darkstar.cartan>
Mark Conrad <······@iam.invalid> writes:
> In article <·····················@lain.cheme.cmu.edu>, Matthew Danish
> <·······@andrew.cmu.edu> wrote:
>
> > On Fri, Apr 25, 2003 at 06:30:45AM +0000, Mark Conrad wrote:
> > > I can't think of a *simple* code example to illustrate the
> > > difference between these two different toplevel lines at
> > > the beginning of a program:
> > >
> > > (defvar *cont* 'foo)
> > > - - or - -
> > > (setq *cont* 'foo)
> >
> > Kinda tough when one of them causes undefined behavior.
>
> Yes indeed, especially when an acknowledged CL expert like Paul
> Graham uses this undefined CL behavior in his published code.
My copy of ``On Lisp�� says Copyright 1994. Chances are he wrote
the book before the ANSI standard was published, and IIRC
DEFINE-SYMBOL-MACRO was a rather recent addition. Maybe Graham
simply didn't know about it yet.
Regards,
--
Nils G�sche
Ask not for whom the <CONTROL-G> tolls.
PGP key ID #xD26EF2A0
In article <··············@darkstar.cartan>, Nils Goesche
<···@cartan.de> wrote:
> Mark Conrad <······@iam.invalid> writes:
>
> > In article <·····················@lain.cheme.cmu.edu>, Matthew Danish
> > <·······@andrew.cmu.edu> wrote:
> >
> > > On Fri, Apr 25, 2003 at 06:30:45AM +0000, Mark Conrad wrote:
> > > > I can't think of a *simple* code example to illustrate the
> > > > difference between these two different toplevel lines at
> > > > the beginning of a program:
> > > >
> > > > (defvar *cont* 'foo)
> > > > - - or - -
> > > > (setq *cont* 'foo)
> > >
> > > Kinda tough when one of them causes undefined behavior.
> >
> > Yes indeed, especially when an acknowledged CL expert like Paul
> > Graham uses this undefined CL behavior in his published code.
>
> My copy of ``On Lisp�� says Copyright 1994. Chances are he wrote
> the book before the ANSI standard was published, and IIRC
> DEFINE-SYMBOL-MACRO was a rather recent addition. Maybe Graham
> simply didn't know about it yet.
>
> Regards,
When I wrote my part of the above exchange, I caught hell from members
of this NG. They thought I was being critical of Paul Graham.
That was the last thing in my mind, I was merely agreeing with a
previous respondent when he observed that it was "Kinda tough" to use
"undefined behavior" code in a working program.
(tends to make a program non-portable across CL implementations)
There are a *lot* of things listed in the recent hyperspec standard as
being "undefined behavior".
At times people use these things even though they are undefined,
because they know they can get by with it because *all* the existing CL
applications may be handling the "undefined" stuff in a uniformly
consistant manner, creating a defacto standard, in effect.
> My copy of ``On Lisp�� says Copyright 1994. Chances are he wrote
> the book before the ANSI standard was published, and IIRC
> DEFINE-SYMBOL-MACRO was a rather recent addition. Maybe Graham
> simply didn't know about it yet.
Absolutely correct, that was pointed out to me after I wrote my post.
I was totally unaware of the existance of DEFINE-SYMBOL-MACRO.
Now I use that macro in my code all the time, to ensure that some of my
toplevel variables are forced to have lexical scope.
I used some of Graham's macros to allow me to abbreviate
DEFINE-SYMBOL-MACRO to the shorter =SETQ, which I use whenever the need
for a toplevel lexically-scoped variable arises:
(=setq %cont%
"This string is the initial value of the toplevel
lexically-scoped variable named %cont%")
As Paul Graham points out, that initial value is almost never used,
except for demonstration purposes.
The variable %cont% is re-assigned in the program to "hold" the CL
continuation.
When re-assignment is done, =setq has to be used instead of setq, to
ensure that %cont% remains a lexically-scoped variable.
I used %cont% instead of *cont* to impress on everyone that %cont%
is lexically-scoped; *cont* is commonly used in CL to signify a
dynamically-scoped variable, so *cont* is not desired here because it
misleads people into thinking that *cont* is dynamically-scoped.
If several different continuation-holding variables are used in the
same program, they could be named %cont-one%, %cont-two%, etc.
A common-lisp continuation is a high-level GOTO, which allows a
programmer to jump to a pre-determined place in his code, a place that
would be difficult or impossible to jump to by using standard Lisp
constructs like catch/throw or unwind-protect.
CL continuations preseve "state", which merely means that the
continuation can be used to return to the place in the code where the
"jump" originated from, and continue normal program execution from that
point, with the assurance that all the variables at that point in the
program will be exactly the same as if the temporary "jump" had never
occured in the first place.
Mark-
In article <·························@iam.invalid>, Mark Conrad
<······@iam.invalid> wrote:
> I used %cont% instead of *cont* to impress on everyone that %cont%
> is lexically-scoped; *cont* is commonly used in CL to signify a
> dynamically-scoped variable, so *cont* is not desired here because it
> misleads people into thinking that *cont* is dynamically-scoped.
Yipes! - the usenet newsreader apparently removed the asterisks from
around cont in my post, all references to cont in the passage
above should have asterisks around the word cont
Wonder if there is any way to guarantee that the asterisks appear in my
future posts.
Mark-
Mark Conrad wrote:
> In article <·························@iam.invalid>, Mark Conrad
> <······@iam.invalid> wrote:
>
>
>>I used %cont% instead of *cont* to impress on everyone that %cont%
>>is lexically-scoped; *cont* is commonly used in CL to signify a
>>dynamically-scoped variable, so *cont* is not desired here because it
>>misleads people into thinking that *cont* is dynamically-scoped.
>
>
> Yipes! - the usenet newsreader apparently removed the asterisks from
> around cont in my post, all references to cont in the passage
> above should have asterisks around the word cont
I could see them in my (for today) news reader (Mozilla).
--
Jens Axel S�gaard
In article <·························@dread11.news.tele.dk>, Jens Axel
S�gaard <······@jasoegaard.dk> wrote:
> Mark Conrad wrote:
> > In article <·························@iam.invalid>, Mark Conrad
> > <······@iam.invalid> wrote:
> >
> >
> >>I used %cont% instead of *cont* to impress on everyone that %cont%
> >>is lexically-scoped; *cont* is commonly used in CL to signify a
> >>dynamically-scoped variable, so *cont* is not desired here because it
> >>misleads people into thinking that *cont* is dynamically-scoped.
> >
> >
> > Yipes! - the usenet newsreader apparently removed the asterisks from
> > around cont in my post, all references to cont in the passage
> > above should have asterisks around the word cont
>
> I could see them in my (for today) news reader (Mozilla).
Good! - I will have to remember to surround stuff like that with
quotes, as in "*cont*" so it will display properly in newsreaders
which use asterisks to make a word appear bold.
I certainly am having fun playing with Paul Graham's macros that
implement continuations in CL.
It remains to be seen if continuations have any practical uses.
Mark-
Mark Conrad <······@iam.invalid> writes:
> In article <·························@iam.invalid>, Mark Conrad
> <······@iam.invalid> wrote:
>
> > I used %cont% instead of *cont* to impress on everyone that %cont%
> > is lexically-scoped; *cont* is commonly used in CL to signify a
> > dynamically-scoped variable, so *cont* is not desired here because it
> > misleads people into thinking that *cont* is dynamically-scoped.
>
> Yipes! - the usenet newsreader apparently removed the asterisks from
> around cont in my post, all references to cont in the passage
> above should have asterisks around the word cont
>
> Wonder if there is any way to guarantee that the asterisks appear in my
> future posts.
>
> Mark-
when you use an asterisk ( aka shift 8) in a message many news readers
render it is bold text like so: *bold*. You may have something that
turns bold text into normal appearing text in your news reader, so you
see no difference
marc
In article <··············@bogomips.optonline.net>, Marc Spitzer
<········@optonline.net> wrote:
> when you use an asterisk ( aka shift 8) in a message many news readers
> render it is bold text like so: *bold*. You may have something that
> turns bold text into normal appearing text in your news reader, so you
> see no difference
Yes, I keep forgetting that my Thoth newsreader does that.
I will have to quote the symbol, as in "*cont*" whenever I use
asterisks.
Gadd, I hate to use global names of any kind, they cause a lot of extra
work in my programs, keeping track of them so they don't interfere with
each other.
Still, when one considers the alternative below, I guess global names
are worth the trouble they cause ;-)
(funcall ;; Start of "lambda-ized" Y operator, replaces "defun"
(funcall
#'(lambda (m)
((lambda (u)
(funcall m #'(lambda (&rest arg)
(apply (funcall u u) arg) )))
#'(lambda (u)
(funcall m #'(lambda (&rest arg)
(apply (funcall u u) arg))) )))
#'(lambda (foo) ;; Replaces function "append-lists"
#'(lambda (list1 list2)
(cond
((null list1) nil)
(t (cons (car list1)
(cons (car list2)
(funcall foo (cdr list1)
(cdr list2))) ))) )))
'(a c e) '(b d f) ) ;; Arguments for the function "append-lists"
Returns (A B C D E F)
Well, back to my present project. I am not all that convinced yet
that I can't replace CL's "catch" and "throw" with continuations.
Anyhow, I am going to try, should be lots of fun.
Mark-
"Mark Conrad" <······@iam.invalid> wrote in message
······························@iam.invalid...
> That was the last thing in my mind, I was merely agreeing with a
> previous respondent when he observed that it was "Kinda tough" to use
> "undefined behavior" code in a working program.
>
> (tends to make a program non-portable across CL implementations)
Not quite, using code that causes "undefined behaviour" makes a program
*unreliable* across *all* implementations. This is a much worse
characteristic of a body of code than merely being non-portable which may
not be any concern at all. Reread what Duane posted about undefined
behaviour.
> There are a *lot* of things listed in the recent hyperspec standard as
> being "undefined behavior".
>
> At times people use these things even though they are undefined,
> because they know they can get by with it because *all* the existing CL
> applications may be handling the "undefined" stuff in a uniformly
> consistant manner, creating a defacto standard, in effect.
Perhaps you are confusing "undefined" with "not covered"? But other wise I
don't think what you say is correct.
--
Coby Beck
(remove #\Space "coby 101 @ bigpond . com")
From: Joe Marshall
Subject: Re: Implementation Favoritism, a question of Lisp mindsets
Date:
Message-ID: <u1cmel15.fsf@ccs.neu.edu>
Mark Conrad <······@iam.invalid> writes:
> I had fervently hoped that "proclaim" would be a back-door to help me
> understand "defvar", but sadly it was not to be.
Here are some things that may help:
1. Special proclamations and DEFVARs are permanent. You cannot
`undo' them. This makes it tricky to compare lexical
vs. dynamic scoping.
2. Consider this expression:
(setq foo 22)
The variable FOO is `free' (neither lexically bound NOR
declared special). Technically speaking, this is *not*
conforming Common Lisp code!
Most Common Lisp systems, however, will assume that you meant
to declare FOO to be special and perform the appropriate side
effect upon value cell of the symbol 'FOO.
Some Common Lisp systems will go further and PROCLAIM FOO to
be special.
> Yet, Paul Graham's backtracking tree-search code on page 271 of his
> "On-Lisp" book is adversely affected by an illigitimate defvar line.
>
> Boils down to some programs are affected, some are not.
Of course! If a declaration had no effect on a program, why would you
use it?
> Graham states that his line (setq *cont* #'identity) on his page 267 is
> absolutely necessary for correct running of his CL "continuations"
>
> ...and can't be (defvar *cont* #'identity) for example.
>
> I don't have the smarts to figure out the effect of defvar on the scope
> and extent considerations in his code.
The effect of *cont* being special is that all bindings of the
variable *cont* are shared. This is clearly not what is desired.
> I can't think of a *simple* code example to illustrate the difference
> between these two different toplevel lines at the beginning of a
> program:
>
> (defvar *cont* 'foo)
> - - or - -
> (setq *cont* 'foo)
There may or may not be a difference depending upon the
implementation. What you should try is this:
(eval-when (:load-toplevel :execute)
(setf (symbol-value '*cont*) 'foo))
And do it in a fresh image where *cont* is NOT proclaimed special and
*cont* has not been SETQ'd at top level.
In article <············@ccs.neu.edu>, Joe Marshall <···@ccs.neu.edu>
wrote:
> Here are some things that may help...<snipped>...
Thanks, I really appreciate your suggestions, hopefully I can put this
subject to rest in a reasonable period of time.
Mark-
In article <············@ccs.neu.edu>, Joe Marshall <···@ccs.neu.edu>
wrote:
> Most Common Lisp systems, however, will assume that you meant
> to declare FOO to be special and perform the appropriate side
> effect upon value cell of the symbol 'FOO.
Does this mean that a CL application that adheres to the CLtL2 standard
might assume that a toplevel (setq foo 5) might consider foo to be a
special variable?
That seems odd, because there then would be no reason to use defvar, if
all toplevel setq's were automatically considered to be special.
> If a declaration had no effect on a program, why would you use it?
Precisely! As I mentioned above.
Another phrase I see mentioned occassionally in some books is
"toplevel-lexical-environment". That really confuses me.
I wonder if the authors mean that the toplevel symbols bound by a setq
are lexical in nature by default, being that CL is a lexical language -
- - or if the phrase has an entirely different meaning.
Mark-
From: Tim Bradshaw
Subject: Re: Implementation Favoritism, a question of Lisp mindsets
Date:
Message-ID: <ey3r87pxz0y.fsf@cley.com>
* Mark Conrad wrote:
> Does this mean that a CL application that adheres to the CLtL2 standard
> might assume that a toplevel (setq foo 5) might consider foo to be a
> special variable?
A CL application might assume that a toplevel SETQ of an undeclared
variable launches nuclear weapons at France.
How many times do people have to say `undefined behaviour'?
--tim
In article <···············@cley.com>, Tim Bradshaw <···@cley.com>
wrote:
> A CL application might assume that a toplevel SETQ of an undeclared
> variable launches nuclear weapons at France.
>
> How many times do people have to say `undefined behaviour'?
It takes a while for the ramifications of "undefined behavior" to sink
in.<g>
Finally, I think I see the danger. If code with "undefined behavior"
is written, there is a definite likelyhood that the code might not work
in *all* CL applications, even if all those applications strictly
adhere to the "standard".
Even I can now see that that would be a Bad Thing.
Mark-
From: Duane Rettig
Subject: Re: Implementation Favoritism, a question of Lisp mindsets
Date:
Message-ID: <4znmdc5df.fsf@beta.franz.com>
Mark Conrad <······@iam.invalid> writes:
> In article <···············@cley.com>, Tim Bradshaw <···@cley.com>
> wrote:
>
> > A CL application might assume that a toplevel SETQ of an undeclared
> > variable launches nuclear weapons at France.
> >
> > How many times do people have to say `undefined behaviour'?
>
> It takes a while for the ramifications of "undefined behavior" to sink
> in.<g>
>
> Finally, I think I see the danger. If code with "undefined behavior"
> is written, there is a definite likelyhood that the code might not work
> in *all* CL applications, even if all those applications strictly
> adhere to the "standard".
I assume that by "applications", you mean "implementations".
And this is mostly correct, but the danger is even more subtle than
that:
Your statement alludes to your application being written on
CL-implementation-A, working there, and then being ported to
CL-implementation-B and possibly not working, because the
behavior is undefined.
That is correct. However, what about a new version of
CL-implementation-A? For undefined behavior, you can't even expect
it to work on this new version, even if it worked on the older
version.
And what about a new invocation of the earlier version of
CL-implementation-A? Again, for undefined behavior, you can't
count on it even working on a new invocation.
How about a second try on the same invocation of the same version
of the same implementation? Can you guess what the answer is?
Now, I'm not talking about extensions, which the vendor has defined
in spite of it not being defined by CL. Usually these are documented,
and they are not as likely to change, or at least to change compatibly,
or to change with a compatibility package (so as not to alienate their
users). But such extensions are not really undefined behavior; they're
extensions. Undefined behavior, as said many times before, _cannot_ be
counted on.
> Even I can now see that that would be a Bad Thing.
--
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
From: Joe Marshall
Subject: Re: Implementation Favoritism, a question of Lisp mindsets
Date:
Message-ID: <65oyadmc.fsf@ccs.neu.edu>
Mark Conrad <······@iam.invalid> writes:
> In article <···············@cley.com>, Tim Bradshaw <···@cley.com>
> wrote:
>
> > A CL application might assume that a toplevel SETQ of an undeclared
> > variable launches nuclear weapons at France.
> >
> > How many times do people have to say `undefined behaviour'?
>
> It takes a while for the ramifications of "undefined behavior" to sink
> in.<g>
>
> Finally, I think I see the danger. If code with "undefined behavior"
> is written, there is a definite likelyhood that the code might not work
> in *all* CL applications, even if all those applications strictly
> adhere to the "standard".
It's worse than that. Not only might it not work, it might do
something *completely* irrelevant, arbitrary, and possibly dangerous.
`Undefined behavior' includes such things as `silently corrupting
memory', `terminating the process without warning', and the ever
popular `making monkeys fly out of your favorite orifice'.
In article <·························@iam.invalid>,
Mark Conrad <······@iam.invalid> wrote:
> In article <············@ccs.neu.edu>, Joe Marshall <···@ccs.neu.edu>
> wrote:
>
> > Most Common Lisp systems, however, will assume that you meant
> > to declare FOO to be special and perform the appropriate side
> > effect upon value cell of the symbol 'FOO.
>
> Does this mean that a CL application that adheres to the CLtL2 standard
> might assume that a toplevel (setq foo 5) might consider foo to be a
> special variable?
>
> That seems odd, because there then would be no reason to use defvar, if
> all toplevel setq's were automatically considered to be special.
Here are some comments and answers - please read them carefully:
- CLtL2 is not a standard. It was a book that described the state of the
standardization process in 1989. The actual ANSI standard was finalized
in 1995. There have been some changes in between. The easiest way to
refer to the ANSI standard is to use the HyperSpec at http://www.lispworks.com/reference/HyperSpec/
- The ANSI standard doesn't say anything about the behavior of a
toplevel (setq foo 5) when foo is a free variable. So yes, an
implementation might choose to isssue an error or assume foo to be
lexically scoped or assume it to be special and/or to issue a warning in
the last two cases. You can't rely on any assumptions in this regard.
- Paul Graham's book was published in 1993. This was at a time when
there was no official way in Common Lisp to declare a lexically scoped
toplevel variable.
- The ANSI standard has included define-symbol-macro as the "official"
way to simulate lexically scoped toplevel variables. Note again: This
was two years after Paul Graham's book was published.
- This means that a new edition of Paul Graham's book should switch to
the use of define-symbol-macro instead of just setq in his
continuation-passing macros.
I hope this helps to clarify your confusion.
Pascal
--
"If I could explain it, I wouldn't be able to do it."
A.M.McKenzie
In article <······························@news.netcologne.de>, Pascal
Costanza <········@web.de> wrote:
> Here are some comments and answers - please read them carefully:
> .....<snipped>.....I hope this helps to clarify your confusion.
Thanks very much, your post does indeed clear up my confusion.
I will download the entire hyperspec (assuming that is possible) in
order to get up to date on the present "official" specification for the
language.
Mark-
From: Joe Marshall
Subject: Re: Implementation Favoritism, a question of Lisp mindsets
Date:
Message-ID: <bryqadzs.fsf@ccs.neu.edu>
Mark Conrad <······@iam.invalid> writes:
> Another phrase I see mentioned occassionally in some books is
> "toplevel-lexical-environment". That really confuses me.
It confuses me, too. There is NO top level lexical environment in
Common Lisp.
A variable in a Common Lisp program is either lexically bound,
dynamically bound, or free. If the variable is free, it's value is
the current dynamic value (fetched from the value cell of the
symbol).
In article <············@ccs.neu.edu>, Joe Marshall <···@ccs.neu.edu>
wrote:
> Mark Conrad <······@iam.invalid> writes:
>
> > Another phrase I see mentioned occassionally in some books is
> > "toplevel-lexical-environment". That really confuses me.
>
> It confuses me, too. There is NO top level lexical environment in
> Common Lisp.
>
> A variable in a Common Lisp program is either lexically bound,
> dynamically bound, or free. If the variable is free, it's value is
> the current dynamic value (fetched from the value cell of the
> symbol).
Here is my problem with that, perhaps you can enlighten me as to the
correct terminology?
If I create a closure function this way:
(define-symbol-macro x 2)
? x
2
(defun test () x))
We know that running the closure function (test) will return 2
? (test)
2
Now x is "toplevel", I assume
? x
2
x is obviously a lexically scoped variable, because if we change its
value then there is no effect on our closure function "test"
- a dynamically scoped variable _would_ have an effect on (test) -
(define-symbol-macro x 'foo)
? x
FOO
? (test)
2
Now the closure-function "test" was created in a lexical environment,
where x was part of that lexical environment, or so it seems to me.
Could you please straighten this out for me?
I am more confused than ever.
Mark-
From: Peter Seibel
Subject: Re: Implementation Favoritism, a question of Lisp mindsets
Date:
Message-ID: <m3r87loheb.fsf@javamonkey.com>
Mark Conrad <······@iam.invalid> writes:
> In article <············@ccs.neu.edu>, Joe Marshall <···@ccs.neu.edu>
> wrote:
>
> > Mark Conrad <······@iam.invalid> writes:
> >
> > > Another phrase I see mentioned occassionally in some books is
> > > "toplevel-lexical-environment". That really confuses me.
> >
> > It confuses me, too. There is NO top level lexical environment in
> > Common Lisp.
> >
> > A variable in a Common Lisp program is either lexically bound,
> > dynamically bound, or free. If the variable is free, it's value is
> > the current dynamic value (fetched from the value cell of the
> > symbol).
>
> Here is my problem with that, perhaps you can enlighten me as to the
> correct terminology?
>
> If I create a closure function this way:
>
> (define-symbol-macro x 2)
>
> ? x
> 2
>
> (defun test () x))
>
> We know that running the closure function (test) will return 2
This isn't a closure since X is not a variable. It's a macro. When you
evaluated the DEFUN form X was replaced with the literal 2, just as if
you had written:
(defun test () 2)
> ? (test)
> 2
>
>
> Now x is "toplevel", I assume
It is a top-level *macro*.
> ? x
> 2
>
> x is obviously a lexically scoped variable, because if we change its
> > value then there is no effect on our closure function "test" - a
> dynamically scoped variable _would_ have an effect on (test) -
Not quite. This theory falls apart because X isn't a variable at all.
> (define-symbol-macro x 'foo)
>
> ? x
> FOO
>
> ? (test)
> 2
This is because theh macro was expanded when TEST was defined. Not
because it closed over the "value" of X.
> Now the closure-function "test" was created in a lexical
> environment, where x was part of that lexical environment, or so it
> seems to me.
>
> Could you please straighten this out for me?
>
> I am more confused than ever.
HTH.
-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:...a whole bunch of good points.
Thanks, it is going to take a while for all this to sink in.
BTW, thanks for your second follow-up post clarifying some points you
brought up in your first post, all that helps considerably in getting
me to understand the various subtle aspects of this issue.
Mark-
In article <··············@javamonkey.com>, Peter Seibel
<·····@javamonkey.com> wrote:
> > (defun test () x))
> >
> > We know that running the closure function (test) will return 2
>
> This isn't a closure since X is not a variable. It's a macro. When you
> evaluated the DEFUN form X was replaced with the literal 2, just as if
> you had written:
>
> (defun test () 2)
I still think test is a closure. It does not matter much exactly
*when* the literal 2 was slapped in there, as regards whether "test" is
a closure.
The important thing about whether something is a closure or not is
whether it preserves the prior state (value) of a variable when a
lexical binding form like a "let" is trying to change that value.
Consider code below, where this time it is called test2 instead of test.
Forgive the sloppy code, I don't know how to use "format" yet.
(define-symbol-macro x 2)
(defun test2 ()
(terpri)
(princ "\"test2\" is a closure because it preserves value of global
x\,")
(terpri)
(princ "value of global x in this case is ") (princ x)
(terpri))
(let ((y 3))
(defun test3 ()
(terpri)
(princ "\"test3\" is also a closure\, made in the conventional
way\,")
(terpri)
(princ "it preserves the value of ") (princ y)
(terpri)))
(defun test4 (p)
(terpri)
(princ "\"test4\" is not a closure\, it preserves no prior value\,")
(terpri)
(princ "this time test4 prints ") (princ p)
(terpri))
(let ((x 'boom) (y 'bam) (z 'fizzle))
x y
(terpri)
(test2)
(terpri)
(test3)
(terpri)
(test4 z)
(terpri)
(terpri)
(terpri)
(values))
Below is the screen printout from running the "let" form:
"test2" is a closure because it preserves value of global x,
value of global x in this case is 2
"test3" is also a closure, made in the conventional way,
it preserves the value of 3
"test4" is not a closure, it preserves no value,
this time test4 prints FIZZLE
Mark-
From: Joe Marshall
Subject: Re: Implementation Favoritism, a question of Lisp mindsets
Date:
Message-ID: <wuhaehv7.fsf@ccs.neu.edu>
Mark Conrad <······@iam.invalid> writes:
> In article <··············@javamonkey.com>, Peter Seibel
> <·····@javamonkey.com> wrote:
>
> > > (defun test () x))
> > >
> > > We know that running the closure function (test) will return 2
> >
> > This isn't a closure since X is not a variable. It's a macro. When you
> > evaluated the DEFUN form X was replaced with the literal 2, just as if
> > you had written:
> >
> > (defun test () 2)
>
> I still think test is a closure.
Then you must think that there is a binding over which TEST is closed.
But the function TEST does not refer to any bound variables.
Therefore it is not a closure.
> It does not matter much exactly *when* the literal 2 was slapped in
> there, as regards whether "test" is a closure.
Actually it does. Suppose I write this code:
(defun foo (x)
(+ x 3))
Is this closed over anything? What if I told you that I was mentally
thinking of a variable name, but I knew it would never change from 3,
so I omitted it and just used the literal. Under your definition, FOO
is closed over a variable, but you'd have to read my mind to find out
which variable.
> The important thing about whether something is a closure or not is
> whether it preserves the prior state (value) of a variable when a
> lexical binding form like a "let" is trying to change that value.
No, because this would apply to copies as well. Consider:
(defun foo (x)
(values
(lambda () (incf x))
(eval `(LAMBDA () ,x))))
This returns two values, only one of which (the first) is a closure.
The closure can refer to the binding of X and can modify that
binding. The second value returned is a function that `preserves the
prior state (value)' of X, yet it is not a closure because it does not
refer to the binding of x.
In article <············@ccs.neu.edu>, Joe Marshall <···@ccs.neu.edu>
wrote:
> Then you must think that there is a binding over which TEST is closed.
> But the function TEST does not refer to any bound variables.
> Therefore it is not a closure.
True, so far as your reasoning goes.
However, I maintain that a closure can "close-over" and preserve the
value of "stuff" other than the bindings created by 'let' and its
cousins.
Let's look at the temporary binding of x to the value 7 below:
(defun baz (x)
"The parameter-variable x is 'bound' temporarily to
whatever value is supplied to baz when baz is executed"
(cons x '(is bound to x within the function baz)))
Now when baz is used below, the value 7 is temporarily "bound-to" the
lexically-scoped variable x which resides in the definition of the
function baz.
? (baz 7)
(7 IS BOUND TO X WITHIN THE FUNCTION BAZ)
baz does not qualify as a closure bacause the binding of x is not
preserved; that binding of x to value 7 is lost as soon as baz
terminates.
Okay, with that out of the way, let's create two things, a real closure
which we will name "closure", and a function that might be a closure,
which we will name "closure???"
The aim of this exercise is to determine if both functions act the same
under all circumstances of usage.
(define-symbol-macro k 'whoopie)
(defun closure??? () k)
(let ((h 'fe-fi-fo-fum))
(defun closure () h))
Now if "closure???" looks like a duck, sounds like a duck, and waddles
like a duck, as far as I am concerned it is a duck.
? (let ((k 'newer-value-of-k) (h 'newer-value-of-h))
(print k)
(print h)
(closure))
NEWER-VALUE-OF-K
NEWER-VALUE-OF-H
FE-FI-FO-FUM
? (let ((k 'newer-value-of-k) (h 'newer-value-of-h))
(print k)
(print h)
(closure???))
NEWER-VALUE-OF-K
NEWER-VALUE-OF-H
WHOOPIE
So far, both "closure" and "closure???" both act alike, in the sense
that they both preserve the values of whatever they were bound to at
the time of their creation.
Yes, I accept the fact that k is not a variable, but rather a macro.
Despite that, to all intents and purposes k acts like a variable, does
it not?
I imagine that if I pushed it too far, k would break my code just when
I started relying on k to act like a variable.
Mark-
From: Tim Bradshaw
Subject: Re: Implementation Favoritism, a question of Lisp mindsets
Date:
Message-ID: <ey3fzny9jzu.fsf@cley.com>
* Mark Conrad wrote:
> Now if "closure???" looks like a duck, sounds like a duck, and waddles
> like a duck, as far as I am concerned it is a duck.
But it doesn't, does it? Try this:
(let ((x 1))
(defun x () x)
(defun set-x (new)
(setf x new)))
(x)
(set-x 3)
(x)
Hey, look, mutable state!
As to your claim that `there are things that can only be learned by
asking specific questions in NG's like this one': if you type `lisp
closure' at google the *first* hit you get is David Lamkins' excellent
`successful lisp' book. Was it too hard to do that?
--tim
From: Tim Bradshaw
Subject: Re: Implementation Favoritism, a question of Lisp mindsets
Date:
Message-ID: <ey3vfwuepjf.fsf@cley.com>
* Mark Conrad wrote:
> I still think test is a closure. It does not matter much exactly
> *when* the literal 2 was slapped in there, as regards whether "test" is
> a closure.
> The important thing about whether something is a closure or not is
> whether it preserves the prior state (value) of a variable when a
> lexical binding form like a "let" is trying to change that value.
No, that is not the important thing at all. The important thing is
that a closure captures a *binding* of a variable to a value, which
binding is mutable state. If the binding modified (so its value is
changed) then all the closures which share that binding see the
modified binding.
You *really* need to go away and do some serious reading, because you
are making yourself look (no: you have made yourself look) a fool.
--tim
Tim Bradshaw <···@cley.com> writes:
> * Mark Conrad wrote:
>
> > I still think test is a closure. It does not matter much exactly
> > *when* the literal 2 was slapped in there, as regards whether "test" is
> > a closure.
>
> > The important thing about whether something is a closure or not is
> > whether it preserves the prior state (value) of a variable when a
> > lexical binding form like a "let" is trying to change that value.
>
> No, that is not the important thing at all. The important thing is
> that a closure captures a *binding* of a variable to a value, which
> binding is mutable state. If the binding modified (so its value is
> changed) then all the closures which share that binding see the
> modified binding.
The Elite ttlotbafir Greenspunian Guard recently invented lexical
scoping with visibility but not mutation of variables from outer
scopes. They call the obscenities resulting from passing these around
"closures", and (so far, at least) they Won't Be Told.
> You *really* need to go away and do some serious reading, because you
> are making yourself look (no: you have made yourself look) a fool.
Is there a rilly rilly big (and ideally authoritative, but mostly big)
reference book I can beat them about the head with?
Des
will then work on multiple name-spaces, macros and s-exp syntax.
--
Des Small / Scientific Programmer/ School of Mathematics /
University of Bristol / UK / Word falling / Image falling
In article <···············@cley.com>, Tim Bradshaw <···@cley.com>
wrote:
> You *really* need to go away and do some serious reading, because you
> are making yourself look (no: you have made yourself look) a fool.
Reading does not resolve the issues being discussed here, and I have
many darn good Lisp books.
I care less about appearing a fool, that does not bother me at all.
If I make foolish, wrong, convoluted, nonsense statements in this NG,
the fine people here do not let those statements stand.
They correct me, and I learn.
...then I make another rash statement, based on my enlightened newer
knowledge. If the newer statement is still incorrect, again I get
corrected forthwith.
As I get closer and closer to the truth of the matter, eventually my
statements make sense.
Mark-
Mark Conrad <······@iam.invalid> writes:
> In article <···············@cley.com>, Tim Bradshaw <···@cley.com>
> wrote:
>
> > You *really* need to go away and do some serious reading, because you
> > are making yourself look (no: you have made yourself look) a fool.
>
> Reading does not resolve the issues being discussed here, and I have
> many darn good Lisp books.
>
> I care less about appearing a fool, that does not bother me at all.
>
> If I make foolish, wrong, convoluted, nonsense statements in this NG,
> the fine people here do not let those statements stand.
>
> They correct me, and I learn.
The observed problem is that it takes multiple corrections of the same
mistake on your part to pound the message home. Most people do not
want to have to deal with this for free. The real issue is that you
have not just appeared a fool but that you have made a good case for
actually being a fool. You did this by repeatedly disregarding the
corrections presented to you about the need for continuations in
Common Lisp, you did not get the point until people, who generally do
not insult people here, started insulting you because of your repeated
refusal to engage your brain in the discussion.
>
> ...then I make another rash statement, based on my enlightened newer
> knowledge. If the newer statement is still incorrect, again I get
> corrected forthwith.
At least you know the difference between rash and ignorant
>
> As I get closer and closer to the truth of the matter, eventually my
> statements make sense.
>
> Mark-
Well just consider this another correction.
marc
In article <··············@bogomips.optonline.net>, Marc Spitzer
<········@optonline.net> wrote:
> > They correct me, and I learn.
>
> Well just consider this another correction.
I do, thanks for taking the time and effort.
I can see be the general tone of the responses lately that I have worn
out my welcome here.
Thanks to all here for helping me learn, I appreciated it immensely.
I would have liked to continue, but that does not seem possible because
my preferred method of learning tends to infuriate people here.
I noted that there was one side thread where the poster wrote that he
gained valuable insite from the posts in _this_ thread, so I feel
somewhat vindicated by my "fool's-approach" to acquiring knowledge.
Cool down fellas, and remember:
Old CL newbie fools never die, they just f-a-a-a-d-e away.
Mark-
Mark Conrad <······@iam.invalid> writes:
> In article <··············@bogomips.optonline.net>, Marc Spitzer
> <········@optonline.net> wrote:
>
> > > They correct me, and I learn.
> >
> > Well just consider this another correction.
>
>
> I do, thanks for taking the time and effort.
>
> I can see be the general tone of the responses lately that I have worn
> out my welcome here.
>
> Thanks to all here for helping me learn, I appreciated it immensely.
>
> I would have liked to continue, but that does not seem possible because
> my preferred method of learning tends to infuriate people here.
In all honesty you would have no problem staying here iff you changed
one thing in your preferred method of learning, stop assuming you are
right when you do not know what you are talking about. If you are
truly trying to learn something then you only need to be corrected once
on any given point, look at your continuations thread for a counter
example.
>
> I noted that there was one side thread where the poster wrote that he
> gained valuable insite from the posts in _this_ thread, so I feel
> somewhat vindicated by my "fool's-approach" to acquiring knowledge.
That is besides the point, your preferred method is designed to piss
people off and this is counter productive from you POV as someone who
want to learn something. You may get a better response from
c.l.python or c.l.perl because you have more people to piss off until
you can not get any more help, but it is still daft to do this.
marc
In article <··············@bogomips.optonline.net>, Marc Spitzer
<········@optonline.net> wrote:
> ...<snipped>...is designed to piss people off...<snipped>...
A dangling point remains to be addressed before I leave this NG.
Thanks to the unknown poster who contributed code below:
*********************************************
* Mark Conrad wrote:
> Now if "closure???" looks like a duck, sounds like a duck, and waddles
> like a duck, as far as I am concerned it is a duck.
But it doesn't, does it? Try this:
(let ((x 1))
(defun x () x)
(defun set-x (new)
(setf x new)))
*********************************************
Running his code in MCL ver' 4.3
? (x)
1
? (set-x 3)
3
? (x)
3
?
At the very least, this is unexpected behavior. It is yet another
exception to the general behavior of CL that has to be memorized and
allowed for so it won't bite me later.
Lisp gurus somehow learn the exceptions to general rules, (as those
rules are laid down in the books), but the only way I had to learn
about the nasty behavior above was to make a rash statement about how I
thought the cookie crumbled, then sit back and wait for agreement or
disagreement to my rash statement.
At the worst, something is broken somewhere in the CL implementation or
in the CL hyperspec, and should be changed.
Contrast that posters example with my variation below which runs as it
should run.
(defvar a)
(defvar b)
(let ((x 'value-of-lexical-x) (y 'value-of-lexical-y))
(setq a x)
(setq b y)
(setq x 'screwed-up-value-of-lexical-x)
(setq y 'screwed-up-value-of-lexical-y)
(values))
? a
VALUE-OF-LEXICAL-X
? b
VALUE-OF-LEXICAL-Y
Now let's make small changes in my above code to demonstrate the
unexpected nasty behavior, nasty behavior that is *not* explained in
any of the books that have been recommended to me in this NG.
(defvar a)
(defvar b)
(let ((x 'value-of-lexical-x) (y 'value-of-lexical-y))
(setq a #'(lambda () x))
(setq b #'(lambda () y))
(setq x 'screwed-up-value-of-lexical-x)
(setq y 'screwed-up-value-of-lexical-y)
(values))
? (funcall a)
SCREWED-UP-VALUE-OF-LEXICAL-X
? (funcall b)
SCREWED-UP-VALUE-OF-LEXICAL-Y
I don't want to "piss people off" so this will likely be my last post
in this NG.
I can see now why there are so few new newbies adopting CL as their
preferred language, when it is apparent how cantankerous and downright
ornery people are in this NG.
Mark-
Mark Conrad writes:
> At the worst, something is broken somewhere in the CL implementation
> or in the CL hyperspec, and should be changed.
Oh my. Seldom does one find oneself so completely confirmed in one's
expectation.... :-)
Backing up a little, Mark wrote:
> > (let ((x 1))
> > (defun x () x)
> > (defun set-x (new)
> > (setf x new)))
> *********************************************
>
>
> Running his code in MCL ver' 4.3
> ? (x)
> 1
> ? (set-x 3)
> 3
> ? (x)
> 3
> ?
>
> At the very least, this is unexpected behavior. It is yet another
> exception to the general behavior of CL that has to be memorized and
> allowed for so it won't bite me later.
>
> Lisp gurus somehow learn the exceptions to general rules, (as those
> rules are laid down in the books), but the only way I had to learn
> about the nasty behavior above was to make a rash statement about
> how I thought the cookie crumbled, then sit back and wait for
> agreement or disagreement to my rash statement.
Your comment that this is unexpected is fine. It is discoveries like
this that were the bait that caught me when I first started with
Lisp.
But it isn't an exception to the general behavior. It is a new idea.
It goes along with Lisp. This is how closures work. It's not nasty
behavior. It's wonderful. It's part of the underlying stratum of
object-oriented programming.
If you like continuations how can you not like this?
> I don't want to "piss people off" so this will likely be my last
> post in this NG.
>
> I can see now why there are so few new newbies adopting CL as their
> preferred language, when it is apparent how cantankerous and
> downright ornery people are in this NG.
Well, you could just try to roll with the punches and figure out what
is pissing people off, and do a little less of it.
Most people in this newsgroup have at least a bit of the language
evangelist in them, and if you stay good humored you can probably do
fine. There is kind of an expectation that eventually you'll graduate
beyond newbie-hood, but I'm sure you haven't worn out your welcome
yet. Honestly, even if you post things people think are nonsense you
will always find those ready to rise up in anger to smite you, and you
could even glean information from that.
--
Fred Gilham ······@csl.sri.com
Jordan Hubbard: We have a crash bug. It needs to be fixed. We DO NOT
need to know how to print 3000 spaces in 11 different languages! :-)
Daniel Sobral: I concur. But if anyone wants to do it with loader,
: 3kbl 3000 0 do bl emit loop ; 3kbl will do the trick.
In article <··············@snapdragon.csl.sri.com>, Fred Gilham
<······@snapdragon.csl.sri.com> wrote:
> Backing up a little, Mark wrote:
...lotsa stuff, some of it wrong...
Now why can't everyone in this NG be as non-judgemental as you are.
Very fine post you crafted, gentle nudges and suggestions, makes me
actually enjoy learning this CL stuff.
Up until Gareth's post, I used to think both these terms meant the same
thing.
"The binding of x is 5"
"The value of x is 5"
I completely missed the distinctions between the terms while reading
about closures in my books, and the connection between the words
"binding" and "environment", which proved to be my downfall and led to
me making foolish statements about how the cookie crumbled.
Gareth came to my rescue, explaining that "binding" and "value" are two
seperate and completely different things.
Once I was alerted to that, everything else fell into place.
Before today I could not spell "expert".
Now I are an expert on closures ;-)
Anyhow, at least now I know a little bit more about them.
About the difference between 'binding' and 'value' -
In retrospect, I can't believe I was blind-sided by such an obvious
ommission from my store of knowledge.
Wonder what else I have screwy ideas about.
Hmm, time for me to make more rash statements about how I believe the
cookie crumbles.
Wait fellas, wait - I was just kidding.
Mark-
From: Matthew Danish
Subject: Re: Implementation Favoritism, a question of Lisp mindsets
Date:
Message-ID: <20030502211803.C25716@mapcar.org>
On Fri, May 02, 2003 at 09:29:04PM +0000, Mark Conrad wrote:
> But it doesn't, does it? Try this:
>
> (let ((x 1))
> (defun x () x)
> (defun set-x (new)
> (setf x new)))
> *********************************************
>
>
> Running his code in MCL ver' 4.3
> ? (x)
> 1
> ? (set-x 3)
> 3
> ? (x)
> 3
> ?
>
> At the very least, this is unexpected behavior. It is yet another
> exception to the general behavior of CL that has to be memorized and
> allowed for so it won't bite me later.
>
> Lisp gurus somehow learn the exceptions to general rules, (as those rules are
> laid down in the books), but the only way I had to learn about the nasty
> behavior above was to make a rash statement about how I thought the cookie
> crumbled, then sit back and wait for agreement or disagreement to my rash
> statement.
Okay. Since it seems to require at least 5 people yelling at you to get any
point through, here is my contribution:
********************************
What you demonstrate IS the general and expected behavior. You do not
understand anything about how closures work in Common Lisp. Stop telling us
that we are wrong and learn how they actually do work.
How is it that everyone else seems to understand these concepts? Have you even
begun to think that maybe... just maybe... you are doing something wrong? And
this has nothing to do with learning methods, this has to do with LISTENING and
UNDERSTANDING what people say. Your learning level is on par with a 3-year
old, right now.
********************************
Let me illustrate this for you better:
The functions X and SET-X share a single BINDING.
Let us repeat that:
The functions X and SET-X share a single BINDING.
Do you notice the word BINDING?
BINDING BINDING BINDING BINDING BINDING (5 times, hopefully enough)
That BINDING is named by the variable X.
X is BOUND to 1, initially.
X -----> 1
Calling (X) returns the value of evaluating that variable binding, giving you
1.
Calling (SET-X 2) modifies the binding of X so that it now is BOUND to 2.
X -----> 2
Now, calling (X) returns the value of evaluating the variable binding named X.
Can you guess what happens?
I better spell it out: it returns 2.
Stop futzing with continuations, and get your easy semantics down pat first.
You are trying to do calculus without being able to add, much less anything
else.
--
; Matthew Danish <·······@andrew.cmu.edu>
; OpenPGP public key: C24B6010 on keyring.debian.org
; Signed or encrypted mail welcome.
; "There is no dark side of the moon really; matter of fact, it's all dark."
From: Nikodemus Siivola
Subject: Re: Implementation Favoritism, a question of Lisp mindsets
Date:
Message-ID: <b8uqgg$56oeq$1@midnight.cs.hut.fi>
Mark Conrad <······@iam.invalid> wrote:
> At the very least, this is unexpected behavior. It is yet another
> exception to the general behavior of CL that has to be memorized and
> allowed for so it won't bite me later.
No! This means that you do not understand what bindings, closures or
object identity mean. You know the words and have some mental constructs
about them, but *they are wrong*. Do yourself a favor and read SICP. From
the beginning. You may even learn something.
Cheers,
-- Nikodemus
From: Greg Menke
Subject: Re: Implementation Favoritism, a question of Lisp mindsets
Date:
Message-ID: <m3llxo3g6t.fsf@europa.pienet>
Mark Conrad <······@iam.invalid> writes:
> I don't want to "piss people off" so this will likely be my last post
> in this NG.
>
> I can see now why there are so few new newbies adopting CL as their
> preferred language, when it is apparent how cantankerous and downright
> ornery people are in this NG.
>
> Mark-
People in this newsgroup only get cantankerous when a newbie comes
into the group and throws his/her weight around on the strength of
(possibly) wide experience in other languages. It is necessary for
newbies to be quiet and pay close attention to the language until they
being to understand it from the standpoint of actual, non-trivial use.
Its great to ask questions about the language, but you mustn't presume
to know how the language <should> be. Common Lisp isn't perfect, but
once you learn it (and by doing so, unlearning and properly relearning
techniques and language characteristics you've long thought cast in
stone), then you'll begin to appreciate how nice it really is.
I think if you spend 6 months really trying to learn Common Lisp, by
writing programs, then you'll find yourself starting to write Lisp in
other languages too. I didn't really start to perceive some of the
subtlties of C/C++ (such as they are) until I began a serious approach
to Common Lisp.
Gregm
From: Tim Bradshaw
Subject: Re: Implementation Favoritism, a question of Lisp mindsets
Date:
Message-ID: <ey33cjx57np.fsf@cley.com>
* Mark Conrad wrote:
> At the very least, this is unexpected behavior. It is yet another
> exception to the general behavior of CL that has to be memorized and
> allowed for so it won't bite me later.
Of course it isn't. This *is* the general behaviour. As people have
repeatedly said, closures capture *bindings*, not values Lexical
bindings in Common Lisp have lexical scope and indefinite extent, and
are mutable. I don't think you understand what a closure is at all.
I must admit to being rather confused now though. At some point
earlier in the thread you were enthusing about wanting to do
everything with continuations and complaining that it was a deficiency
that CL didn't have call/cc.
Well, one fairly common view of continuations (and, I expect, how they
would appear in a CL which did have them), is that they are simply the
generalisation of closures to include block names and possibly other
control points, which currently have lexical scope and dynamic extent,
to have lexical scope and indefinite extent.
How can you want call/cc and *not* understand what a lexical closure
is? Do you actually have any *idea* what a continuation is, or are
you just repeating some magic phrase that you read?
Incidentally I liked this:
> At the worst, something is broken somewhere in the CL implementation
> or in the CL hyperspec, and should be changed.
You don't trade under the name `ilias' do you?
--tim
Mark Conrad wrote:
[someone else:]
> (let ((x 1))
> (defun x () x)
> (defun set-x (new)
> (setf x new)))
> *********************************************
>
>
> Running his code in MCL ver' 4.3
> ? (x)
> 1
> ? (set-x 3)
> 3
> ? (x)
> 3
> ?
>
> At the very least, this is unexpected behavior. It is yet another
> exception to the general behavior of CL that has to be memorized and
> allowed for so it won't bite me later.
How so? It's *exactly* the expected behaviour.
This is precisely what closures are about. What
general behaviour do you think it's an exception to?
What is it about this behaviour that makes you
call it "nasty" later on?
> Now let's make small changes in my above code to demonstrate the
> unexpected nasty behavior, nasty behavior that is *not* explained in
> any of the books that have been recommended to me in this NG.
>
> (defvar a)
> (defvar b)
>
> (let ((x 'value-of-lexical-x) (y 'value-of-lexical-y))
> (setq a #'(lambda () x))
> (setq b #'(lambda () y))
> (setq x 'screwed-up-value-of-lexical-x)
> (setq y 'screwed-up-value-of-lexical-y)
> (values))
>
> ? (funcall a)
> SCREWED-UP-VALUE-OF-LEXICAL-X
>
> ? (funcall b)
> SCREWED-UP-VALUE-OF-LEXICAL-Y
Why's it nasty? I'd ask "why's it unexplained?", but
that's not really the right question. The right question
is: What is it you think you know that makes it
*require* explanation?
I'm not asking just out of curiosity, by the way.
I'd like to explain, but I don't see how to explain
until I know what it is that needs explaining. Maybe
this potted summary will help in the interim:
It's common to say that (1) a closure is a function
plus its environment, and (2) an environment is a
mapping from names to values. In fact, I've said
both those things several times myself. But #2 may
be misleading, because an environment is a *changeable*
mapping from names to values. It might be better to
call it a mapping from names to *value-holders*, or,
more simply, to variables. So, when you say
(let ((x 'value-of-lexical-x) (y 'value-of-lexical-y))
...)
you have created new variables X and Y. They're visible
only within the scope of the LET (unless X or Y has been
declared special, of course). But they're real variables,
and they continue to exist after the LET form has finished
being processed.
Now, the things you've put into A and B inside the LET
form are closures: each is a function plus (a reference
to) its environment. That environment consists of the
bindings of X and Y. Note: the *bindings*, not the
*values*. If you change what X and Y are bound to,
that change is visible to the closures in A and B.
Which is exactly what happens when you do the third
and fourth SETQs. The closures in A and B still refer
to the same variables X and Y, but now the values of
those variables have changed.
You obviously find this nasty, but I don't know why.
Here's an example of somewhere where it might be
useful. The MAPHASH function calls a user-supplied
function for each (key, value) pair in a hash table.
So you can do things like this:
(let ((boring-keys nil))
(maphash (lambda (k v)
(when (null v)
(push k boring-keys)))
*my-hash-table*)
(format t "~&Boring keys:~{ ~A~^,~}." boring-keys)
(do-something-else-with boring-keys))
Notice that what you're passing into MAPHASH is a closure
that needs to be able to alter BORING-KEYS.
As it happens, you can do that without closures with
either LOOP or WITH-HASH-TABLE-ITERATOR. So here's another
example. Suppose you're doing some kind of mathematical
computing; numerical integration, perhaps. You have a
bunch of algorithms you've been developing for adaptive
quadrature (i.e., calculating integrals to a prescribed
level of accuracy, working out what function evaluations
they need to do to achieve that accuracy) and you want
to see how they compare. Then:
- You can count the number of times one of the algorithms
evaluates the function, like this:
(defun count-evaluations (integrator integrand)
(let ((n 0))
(funcall integrator (lambda (x) (incf n) (funcall integrand x))
*lower-bound* *upper-bound*)
n))
- You can get a list of the arguments at which it evaluates
the function, like this:
(defun evaluation-points (integrator integrand)
(let ((result '()))
(funcall integrator (lambda (x)
(push x result)
(funcall integrand x))
*lower-bound* *upper-bound*)
result))
- You can count the number of times it does two successive
evaluations very close together, like this:
(defun count-near-repetitions (integrator integrand)
(let ((n 0)
(last nil))
(funcall integrator (lambda (x)
(when (and last (<= (abs (- x last)) *delta*))
(incf n))
(setq last x)
(f x))
*lower-bound* *upper-bound*)
n))
All this without having to make any change to the code
of the integrators or the integrand functions. And this
*requires* the ability to alter variables you've closed
over. You call that "nasty", but it isn't nasty; it's
at least half of the point.
> I don't want to "piss people off" so this will likely be my last post
> in this NG.
If you want to answer my questions above by e-mail,
feel free. But I doubt answering them in c.l.l will
piss anyone off very much.
> I can see now why there are so few new newbies adopting CL as their
> preferred language, when it is apparent how cantankerous and downright
> ornery people are in this NG.
I think you'd find much less cantankerousness if you
didn't assume that whenever CL doesn't behave the way
you expect it to that indicates something broken with
either CL or the books you're reading. You'd learn
faster, too :-).
--
Gareth McCaughan ················@pobox.com
.sig under construc
In article <······························@g.local>, Gareth McCaughan
<················@pobox.com> wrote:
> ...<snipped>...environment consists of the bindings of X and Y.
> Note: the bindings, not the values.
Thank you, thank you, you are the first person who raised my awareness
that there was a _difference_ between bindings and values.
Oh, I read the prattle in the books about bindings, then more prattle
about values, but _nothing_ in those books about a binding being
different than a value.
Up until now, I thought that saying "the value of x is 5" was exactly
the same as saying "the binding of x is 5".
Thanks to your post, I now realize that "binding" and "value" are two
seperate and distinct things.
After reading your post, I did some experimenting:
? (let (x) (setq x 5) x)
5
The (x) in the let-form above creates a "binding" for x.
(whatever the heck a "binding" is)
The (setq x 5) creates a "value" for x.
To elaborate a bit, let's make a slightly more complicated 'let'
? (let (x (y 7)) (setq x 5) (list x y))
(5 7)
The (let (x... in the let-form above creates a "binding" for x.
(whatever the heck a "binding" is)
The (setq x 5) creates a "value" for x, a separate operation from
creating the "binding" for x.
The (y 7) creates a binding *and* a value for y.
Now, thanks to you, and no thanks to the %*#&*! books, I *finally*
have a clear idea of what a "closure" is.
Back to the book, I gotta find find out what earthly reason there is
for seperating "binding" from "value", other than to confuse newbies.
Needless to say, your post gets saved to my Extremely-Valuable-Posts
file.
Mark-
From: Thien-Thi Nguyen
Subject: Re: Implementation Favoritism, a question of Lisp mindsets
Date:
Message-ID: <7gwuh87ert.fsf@gnufans.net>
Mark Conrad <······@iam.invalid> writes:
> Thanks to your post, I now realize that "binding" and "value" are two
> seperate and distinct things.
but you don't yet understand their relationship:
> After reading your post, I did some experimenting:
>
> ? (let (x) (setq x 5) x)
> 5
>
> The (x) in the let-form above creates a "binding" for x.
> (whatever the heck a "binding" is)
>
> The (setq x 5) creates a "value" for x.
binding is sight, and like sight, is constrained by who is looking and
where/when/how/why they look. value is what is perceived given this
complicated process of looking.
here, `let' creates a small telescope (we are one end, `x' the other),
`setq' moves the telescope. the 5 has always been there (how could it
not be?); moving the telescope in its direction does not create it.
what is created is our awareness of it, through the `x'.
that is why "the truth is out there" is not a bad approach to
mass-market functional conspiracy programming... (end lame joke).
thi
Wow... the Zen of let.
Thien-Thi Nguyen wrote:
...
> `let' creates (a way to see)*
> ... the 5 has always been there
> (how could it not be)?
> moving ... does not create it.
> what is created is our awareness
* - changed from 'a telescope' for ... well, for poetic purposes
In article <··············@gnufans.net>, Thien-Thi Nguyen
<···@glug.org> wrote:
Mark Conrad wrote:
> > After reading your post, I did some experimenting:
> >
> > ? (let (x) (setq x 5) x)
> > 5
> >
> > The (x) in the let-form above creates a "binding" for x.
> > (whatever the heck a "binding" is)
> >
> > The (setq x 5) creates a "value" for x.
The example code above was a very bad example, I did not realize that
the 'let' form assigned a default value of NIL to x.
Mark Conrad wrote this to Gareth McCaughan:
> > Thanks to your post, I now realize that "binding" and "value" are two
> > seperate and distinct things.
>
Thien-Thi Nguyen observed:
> but you don't yet understand their relationship
You are correct. As of right now I am leaning towards "binding" and
"value" as meaning essentially the same thing, as in:
"The lexical binding of x is 5"
"The value of x is 5"
..."binding" could get across a little more information, like whether
the variable x is lexically-scoped or dynamically-scoped.
I have a bunch of good Lisp books, but they don't go into detail about
whether or not there are any more differences between "binding" and
"value".
Mark-
From: Nikodemus Siivola
Subject: Re: Implementation Favoritism, a question of Lisp mindsets
Date:
Message-ID: <b90lis$556cg$1@midnight.cs.hut.fi>
Mark Conrad <······@iam.invalid> wrote:
> You are correct. As of right now I am leaning towards "binding" and
> "value" as meaning essentially the same thing, as in:
Don't theorize. Don't guess. You'll just get it wrong.
Binding is a box. Value is something inside the box. (But don't read
too much into that statement. Just use it as a visual tool, ok?)
> I have a bunch of good Lisp books, but they don't go into detail about
> whether or not there are any more differences between "binding" and
> "value".
Maybe because it's not a Lisp consept, but a common elementary computer
science consept? It's something that should be explained right after
the point when the prospective programmer has been thought how to open
a text editor!
Learn how to walk before you start running. You are obiously wondering
in a maze of confusion, born out of faulty assumptions. These
assumptions may model the world sufficently for the needs of "Hello
World", but not much else.
Common Lisp is a fine language to learn to program in, but since it
seems to confuse you I'd recommend you look into Scheme, Smalltalk, or
even Ruby as you first language.
Also, don't try to learn by reading a *language* manual. Learn by
reading a *programming* treatise.
Have you looked into SICP yet?
Cheers,
-- Nikodemus
In article <··············@midnight.cs.hut.fi>, Nikodemus Siivola
<········@kekkonen.cs.hut.fi> wrote:
> Learn how to walk before you start running.
Naw, that is no fun.
Once I learn how to run, learning walking will be easy ;-)
> Binding is a box. Value is something inside the box. (But don't read
> too much into that statement. Just use it as a visual tool, ok?)
Too late, I already put too much faith in the "Binding is a box" thing.
> Value is something inside the box.
Does that mean if I don't explicitly place a value in the box, that I
do not have a real "binding"?
Can a variable-binding "exist" independent of any value?
Offhand, it seems that a binding might be able to exist, if a binding
is indeed a location in memory (a "box" in memory) - even though the
box is empty (has no value placed in it)
Mark-
"Mark Conrad" <······@iam.invalid> wrote in message
······························@iam.invalid...
> > Value is something inside the box.
>
> Does that mean if I don't explicitly place a value in the box, that I
> do not have a real "binding"?
>
> Can a variable-binding "exist" independent of any value?
CL-USER 53 > (defvar no-value)
NO-VALUE
CL-USER 54 > no-value
Error: The variable NO-VALUE is unbound.
1 (continue) Try evaluating NO-VALUE again.
2 Return the value of :NO-VALUE instead.
3 Specify a value to use this time instead of evaluating NO-VALUE.
4 Specify a value to set NO-VALUE to.
5 (abort) Return to level 0.
6 Return to top loop level 0.
Type :b for backtrace, :c <option number> to proceed, or :? for other
options
CL-USER 55 : 1 >
Clear as mud for you now, eh? :) (Note continuation number 4, this is
where you could create a binding.)
--
Coby Beck
(remove #\Space "coby 101 @ bigpond . com")
In article <··············@gnufans.net>, Thien-Thi Nguyen
<···@glug.org> wrote:
> but you don't yet understand their relationship
This is the code that worries me, someone posted it a few days ago.
(let ((x 1))
(defun x () x)
(defun set-x (new)
(setf x new)))
? (x)
1
? (set-x 3)
? (x)
3
I don't have any idea what is going on with that example.
I feel that if I could understand the subtle differences between the
meanings of "binding" and "value", that might have something to do with
figuring out why the above example code above works as it does.
Mark-
> This is the code that worries me, someone posted it a few days ago.
>
> (let ((x 1))
> (defun x () x)
> (defun set-x (new)
> (setf x new)))
>
> ? (x)
> 1
>
>
> ? (set-x 3)
>
>
> ? (x)
> 3
Ok, here is some terminology:
Value: an object that we're concerned about.
Variable: an association between a name and a value.
Binding: a place, associated with a name, where the value is kept.
Scope: the area of a program where a name is valid as a variable.
Extent: the part of the program at run-time where a variable binding
is valid.
I think what's screwing you up is the idea of "extent". Variables
have both "scope", that is, the area of the program where they are
visibile, and "extent", which means how long they persist in having
valid values.
Here's an example in C how scope and extent work:
int
foo ( int a)
{
if (a == 0) return 1;
else {
int b = 2;
return b + a;
}
}
Note that the variable b is a local variable and has only local scope,
and only local extent. You can see that if you had
int
foo ( int a)
{
if (a == 0) return 1;
else {
int b += a;
}
return b;
}
you'd bomb, because b is out of scope. But if you had
int *
foo ( int a)
{
int b = 0;
if (a == 0) return 1;
else {
b += a;
}
return *b;
}
you'd also bomb, because while b has a value within the body of foo,
the location for that value, typically the C stack, becomes invalid
once foo returns. The extent of b, the time b has a valid binding, is
just the time the program is in foo.
The trick is to realize that in Lisp, variables can have "infinite"
extent. The lisp example above shows how the variable X stays alive
even after its scope has disappeared, in a way C locals do not. It
would. be more as if you had done
int *
foo ( int a)
{
static int b = 0;
if (a == 0) return 1;
else {
b += a;
}
return *b;
}
except you can't easily create closures in C, so you can't get the
information hiding that closures afford.
We say that lexical closures "capture" the bindings of the variables
they close over. That means that they retain knowledge regarding the
association between the variable and the value. They don't just
substitute in the value. So in the example above, nothing outside the
scope of the let can ever affect the binding of X after that let
exits. But because a closure is created, the functions defined within
the closure still have access to the binding.
The name X is no longer valid as a variable outside the let, because
it is out of scope.
* (let ((x 1))
(defun x () x)
(defun set-x (new)
(setf x new)))
; Converted X.
; Converted SET-X.
SET-X
* x
Error in KERNEL::UNBOUND-SYMBOL-ERROR-HANDLER: the variable X is unbound.
Restarts:
0: [ABORT] Return to Top-Level.
Debug (type H for help)
(EVAL X)
Source:
; File has been modified since compilation:
; target:code/eval.lisp
; Using form offset instead of character position.
(SYMBOL-VALUE EXP)
0]
But, as you saw, the binding for X can still be accessed by the
functions in the closure that captured them, because the binding has
infinite extent.
Note that my terminology may be a little off here, but the idea is
basically as I described it.
--
Fred Gilham ······@csl.sri.com
REPRODUCTIVE RIGHTS: the right not to reproduce, no matter what else
you do. PLANNED PARENTHOOD: an organization that helps you plan to
avoid becoming a parent.
In article <··············@snapdragon.csl.sri.com>, Fred Gilham
<······@snapdragon.csl.sri.com> wrote:
> But, as you saw, the binding for X can still be accessed by the
> functions in the closure that captured them, because the binding has
> infinite extent.
Yes, I am going to have to be satisfied with that, and stop looking for
other dark hidden meanings for the word "binding".
Namely, can a binding still exist when no value is assigned to the
binding.
My knee-jerk reaction is that any binding, in order to *be* a
binding, has to have a value assigned to the binding.
Mark-
From: Ed L Cashin
Subject: Re: Implementation Favoritism, a question of Lisp mindsets
Date:
Message-ID: <87y91nvcv7.fsf@cs.uga.edu>
Mark Conrad <······@iam.invalid> writes:
> In article <··············@snapdragon.csl.sri.com>, Fred Gilham
> <······@snapdragon.csl.sri.com> wrote:
>
>> But, as you saw, the binding for X can still be accessed by the
>> functions in the closure that captured them, because the binding has
>> infinite extent.
>
> Yes, I am going to have to be satisfied with that, and stop looking for
> other dark hidden meanings for the word "binding".
>
> Namely, can a binding still exist when no value is assigned to the
> binding.
>
> My knee-jerk reaction is that any binding, in order to *be* a
> binding, has to have a value assigned to the binding.
Bindings aren't just lisp things.
For each person "p" in the empty room, comb the hair of p.
In that case, the name p is bound inside the directive, "comb the hair
of p." What that means is just that p refers to something specific in
that context -- p is a name that is bound to each person in the room.
Since the room is empty, p never "takes on a value". The binding is
the relationship between the name p and the concept "one of the people
in the room". There don't have to be any people in the room for it to
make sense.
--
--Ed L Cashin PGP public key: http://noserose.net/e/pgp/
In article <··············@cs.uga.edu>, Ed L Cashin <·······@uga.edu>
wrote:
> Bindings aren't just lisp things.
>
> For each person "p" in the empty room, comb the hair of p.
>
> In that case, the name p is bound inside the directive, "comb the hair
> of p." What that means is just that p refers to something specific in
> that context -- p is a name that is bound to each person in the room.
>
> Since the room is empty, p never "takes on a value". The binding is
> the relationship between the name p and the concept "one of the people
> in the room". There don't have to be any people in the room for it to
> make sense.
I like that analogy :)
Now the whole idea of a binding comes close to being a "concept",
besides perhaps being a "place" and/or a "value".
"The ties that bind" <g>
Mark-
Mark Conrad <······@iam.invalid> writes:
> In article <··············@snapdragon.csl.sri.com>, Fred Gilham
> <······@snapdragon.csl.sri.com> wrote:
>
> > But, as you saw, the binding for X can still be accessed by the
> > functions in the closure that captured them, because the binding has
> > infinite extent.
>
> Yes, I am going to have to be satisfied with that, and stop looking for
> other dark hidden meanings for the word "binding".
>
> Namely, can a binding still exist when no value is assigned to the
> binding.
>
> My knee-jerk reaction is that any binding, in order to *be* a
> binding, has to have a value assigned to the binding.
How about this. In Lisp, one possible value to put in a binding is
|
---
a.k.a. "bottom". Bottom is the invalid value.
So a variable is "unbound" when Lisp looks at the binding (note, for
the sake of argument I didn't say "looks in the binding") and finds
bottom.
I think that's mostly the way it's implemented.
That also makes it possible to think of a binding as a place that can
have values stuffed in it. Regardless of what people say, this is the
way to think about it that makes the most sense operationally. Or,
"Thinking about it like this won't steer you wrong."
By the way, why do my followups to your messages always wind up with
Cc: nobody
in the header?
--
Fred Gilham ······@csl.sri.com
The amazing thing is, back when I was a C++ programmer, I thought that
[Design Patterns] was SUCH a great book. And I guess it was, in a
way: it made it possible to use C++ and get something done. In the
long run, of course, that may have been a disservice... - Alain Picard
From: Tim Bradshaw
Subject: Re: Implementation Favoritism, a question of Lisp mindsets
Date:
Message-ID: <ey3k7d6xza8.fsf@cley.com>
* Fred Gilham wrote:
> So a variable is "unbound" when Lisp looks at the binding (note, for
> the sake of argument I didn't say "looks in the binding") and finds
> bottom.
Well, specifically, a lexical variable binding can never have no value
associated with it, while a dynamic binding can (witness PROGV). The
spec is explicit about this somewhere. I presume the (or a) reason is
efficiency - a lexical binding is likely to be compiled away to a much
greater extent than a dynamic one. There's no way of finding out if a
lexical binding exists, either (other than the obvious: is it
lexically visible...)
--tim
In article <··············@snapdragon.csl.sri.com>, Fred Gilham
<······@snapdragon.csl.sri.com> wrote:
> That also makes it possible to think of a binding as a place that can
> have values stuffed in it. Regardless of what people say, this is the
> way to think about it that makes the most sense operationally. Or,
> "Thinking about it like this won't steer you wrong."
Yeah, I finally wound up thinking of a binding the same way also.
> By the way, why do my followups to your messages always wind up with
>
> Cc: nobody
>
> in the header?
Oh, it is the way this Thoth newsreader handles things.
I have not really learned how to set up the newsreader yet, so anything
that looked like it might throw spam into my email, I set to
"antisocial" settings.<g> "nobody" was the recommended setting for one
part of the newsreader, so I entered it.
(I don't know what Cc refers to in the newsreader)
I certainly am happy that folks here straightened out my thinking about
bindings. I believe knowing about bindings is necessary, absolutely
necessary.
Now that I have bindings more-or-less under my belt, I can concentrate
on the flow-of-control terms, catch, throw, unwind-protect, etc.
Once I can use *all* the abnormal-flow-of-control terms to my
satisfaction, I will then create some "practice-programs" really loaded
with every flow-of-control term I can think of - - - tagbody, block,
return-from, go, return, prog, and all the rest of them including
catch/throw etc.
Then I will try to replace *all* those terms with continuations, just
as an exercise to learn how to use continuations.
Paul Graham's continuations are not easy to use in regular CL code,
because to get them to work one has to write CL code in a rather
hard-to-understand fashion. That makes any subsequent debugging hard
to do.
Fortunately, there are very few times that continuations are called for
in everyday CL programming.
Mark-
From: Tim Bradshaw
Subject: Re: Implementation Favoritism, a question of Lisp mindsets
Date:
Message-ID: <ey3llxl7mbd.fsf@cley.com>
* Mark Conrad wrote:
> Paul Graham's continuations are not easy to use in regular CL code,
> because to get them to work one has to write CL code in a rather
> hard-to-understand fashion. That makes any subsequent debugging hard
> to do.
Well, CL people would probably say that Scheme continuations are not
easy to use in regular Scheme code, because to get them to work one
has to write Scheme code in a rather hard-to-understand fashion. That
makes any subsequent debugging hard to do.
But the language is smaller and purer, which is all that really
counts, of course. I myself am working on reducing my English
vocabulary to 400 words.
--tim
Tim Bradshaw <···@cley.com> writes:
> But the language is smaller and purer, which is all that really
> counts, of course. I myself am working on reducing my English
> vocabulary to 400 words.
Doubleplusgood!
-dan
--
http://www.cliki.net/ - Link farm for free CL-on-Unix resources
From: Tim Bradshaw
Subject: Re: Implementation Favoritism, a question of Lisp mindsets
Date:
Message-ID: <ey3r87d7fcm.fsf@cley.com>
* Daniel Barlow wrote:
> Doubleplusgood!
We do not need the weasely `double' - plusplusgood is enough for us.
Indeed, why bother with `plus', when we can just use `+'. ++good,
what could be better? And those multiple-letter words, who needs
them, ++g should be enough.
--tim
From: Aleksandr Skobelev
Subject: Re: Implementation Favoritism, a question of Lisp mindsets
Date:
Message-ID: <87y91lno5r.fsf@list.ru>
Tim Bradshaw <···@cley.com> writes:
>
> But the language is smaller and purer, which is all that really
> counts, of course. I myself am working on reducing my English
> vocabulary to 400 words.
>
> --tim
Well, there was a person in "Twenty Armchairs" by I. Ilf and
E. Petrov. She was able to use 30 words only...
In article <··············@snapdragon.csl.sri.com>, Fred Gilham
<······@snapdragon.csl.sri.com> wrote:
> I think what's screwing you up is the idea of "extent".
Yes, and I know better, I use interdependent closures all the time
here, where one closure modifies the shared values of another closure,
at any time during the running of the Lisp program. (indefinite extent)
I think the Lisp code that puzzled me just caught me at a bad time,
when my brain was not working. I like to do my Lisp stuff late at
night in the wee morning hours, and sometimes I stay up longer than I
should.
It is obvious to me now that both function x and function set-x share
the *variable* x in the 'let', and the value "1" that is associated
with variable x.
Naturally, the function set-x can change the value associated with
shared variable x.
(let ((x 1))
(defun x () x)
(defun set-x (new)
(setf x new)))
Gadd, I am doing it again, stayed up all night, it is now 5:45 AM in
the morning. Time for me to hit the hay.
Mark-
In article <·························@iam.invalid>, Mark Conrad
<······@iam.invalid> wrote:
> In article <··············@gnufans.net>, Thien-Thi Nguyen
> <···@glug.org> wrote:
>
> > but you don't yet understand their relationship
>
>
> This is the code that worries me, someone posted it a few days ago.
>
> (let ((x 1))
> (defun x () x)
> (defun set-x (new)
> (setf x new)))
>
> ? (x)
> 1
>
>
> ? (set-x 3)
>
>
> ? (x)
> 3
>
>
> I don't have any idea what is going on with that example.
>
> I feel that if I could understand the subtle differences between the
> meanings of "binding" and "value", that might have something to do with
> figuring out why the above example code above works as it does.
Try this:
A binding is a memory location.
A value is what is stored in that memory location.
So what is going on in the example above is:
(let ((x 1)) ; Establish a binding (i.e. a memory location) for X.
(defun x () x) ; Return the value in the binding (i.e. the memory location)
; established above
(defun set-x (new) ; Change the value in the binding (the memory location)
(setf x new)) ; of X to NEW
)
Did that help?
E.
In article <····················@192.168.1.51>, Erann Gat
<···@jpl.nasa.gov> wrote:
> > I feel that if I could understand the subtle differences between the
> > meanings of "binding" and "value", that might have something to do with
> > figuring out why the above example code above works as it does.
>
> Try this:
>
> A binding is a memory location.
>
> A value is what is stored in that memory location.
>
> So what is going on in the example above is:
>
> (let ((x 1)) ; Establish a binding (i.e. a memory location) for X.
>
> (defun x () x) ; Return the value in the binding (i.e. the memory
> location)
> ; established above
>
> (defun set-x (new) ; Change the value in the binding (the memory location)
> (setf x new)) ; of X to NEW
> )
>
> Did that help?
Definitely helped, thanks.
> You might also want to take a look at:
>
> http://groups.google.com/groups?selm=gat-0911021704350001%40192.168.1.51
I did, that helped considerably also. I was surprised at how many
different kinds of symbols that CL has.
I would recommend that Google link of yours to any CL newbie who wants
to learn more about symbols, variables, bindings, values, closures,
etc.
Mark-
Erann Gat <···@jpl.nasa.gov> wrote:
+---------------
| Mark Conrad <······@iam.invalid> wrote:
| > I feel that if I could understand the subtle differences between the
| > meanings of "binding" and "value", that might have something to do with
| > figuring out why the above example code above works as it does.
|
| Try this:
| A binding is a memory location.
| A value is what is stored in that memory location.
+---------------
Actually, here's one area where IMHO the Scheme folk seem to have the
terminology about right. From R5RS 3.1 "Variables, syntactic keywords,
and regions":
An identifier may name a type of syntax, or it may name a
location where a value can be stored. ... An identifier that
names a location is called a variable and is said to be bound to
that location. The set of all visible bindings in effect at some
point in a program is known as the environment in effect at that
point. The value stored in the location to which a variable is
bound is called the variable's value.
Note that they also warn:
By abuse of terminology, the variable is sometimes said to name
the value or to be bound to the value. This is not quite accurate,
but confusion rarely results from this practice.
Except in discussions like this thread... ;-} ;-}
+---------------
| So what is going on in the example above is:
| (let ((x 1)) ; Establish a binding (i.e. a memory location) for X.
+---------------
Actually, *three* things logically happen here [assuming a lexical binding]:
1. A new location is allocated;
2. The variable "x" is bound to (caused to name) that location; and
3. The location is initialized with the value "1".
In CL terms, one may treat "location" as equivalent to "place", so that
one may use a bound variable as the destination of a SETQ or SETF.
+---------------
| (defun x () x) ; Return the value in the binding (i.e. the memory
| ; location) established above
| (defun set-x (new) ; Change the value in the binding (the memory location)
| (setf x new)) ; of X to NEW
| )
+---------------
Close enough, I guess, but if I was being picky I'd say "return/change
the contents of the location the variable 'x' is bound to".
-Rob
-----
Rob Warnock, PP-ASEL-IA <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
In article <·························@iam.invalid>, Mark Conrad
<······@iam.invalid> wrote:
> I feel that if I could understand the subtle differences between the
> meanings of "binding" and "value", that might have something to do with
> figuring out why the above example code above works as it does.
You might also want to take a look at:
http://groups.google.com/groups?selm=gat-0911021704350001%40192.168.1.51
E.
In article <·························@iam.invalid>,
Mark Conrad <······@iam.invalid> wrote:
> > ...<snipped>...environment consists of the bindings of X and Y.
> > Note: the bindings, not the values.
>
> Thank you, thank you, you are the first person who raised my awareness
> that there was a _difference_ between bindings and values.
>
> Oh, I read the prattle in the books about bindings, then more prattle
> about values, but _nothing_ in those books about a binding being
> different than a value.
See for example the entry for binding in the glossary section of the
HyperSpec:
binding n. an association between a name and that which the name
denotes. ``A lexical binding is a lexical association between a name and
its value.'' When the term binding is qualified by the name of a
namespace , such as ``variable'' or ``function,'' it restricts the
binding to the indicated namespace, as in: `` let establishes variable
bindings.'' or `` let establishes bindings of variables.''
There are goods books for beginners out there, some for free, that
explain theses things. For example, take a look at http://psg.com/~dlamkins/sl/cover.html
Pascal
In article <······························@news.netcologne.de>, Pascal
Costanza <········@web.de> wrote:
> See for example the entry for binding in the glossary section of the
> HyperSpec:
>
> binding n. an association between a name and that which the name
> denotes. ``A lexical binding is a lexical association between a name and
> its value.'' When the term binding is qualified by the name of a
> namespace , such as ``variable'' or ``function,'' it restricts the
> binding to the indicated namespace, as in: `` let establishes variable
> bindings.'' or `` let establishes bindings of variables.''
Specifically:
> '' When the term binding is qualified by the name of a
> namespace , such as ``variable'' or ``function,'' it restricts the
> binding to the indicated namespace, as in: `` let establishes variable
> bindings.'' or `` let establishes bindings of variables.''
Is that all in the heck "binding" means. Cheez!
And I thought there was much more that "binding" meant, that influenced
exactly how the variable would act in a program.
Now I see why the great majority of my Lisp books don't even mention
"binding" in the index.
Okay, if I FINALLY understand binding correctly, the 'let' form below
does *not* establish a binding between x and anything else!
? (let (x) x 'lexical-variable-x-is-not-bound-to-anything)
LEXICAL-VARIABLE-X-IS-NOT-BOUND-TO-ANYTHING
Likewise:
(defvar k)
The special variable k is not bound to anything either.
All the lousy defvar does is make a promise to the compiler, a
'declaration' to the compiler, (and to anyone who reads my code), that
eventually a 'special' binding to k _will_ be created, if and when I
get around to using setq to create the binding.
Likewise:
When one uses the word "binding" when describing closures -
...as in "In the closure k below, lexical variable x is bound to the
value BIG, and lexical variable y is bound to the value DADDY"
I am right back where I started a week ago, when I said there was no
difference between saying:
" X is 'bound' to the value BIG "
- - or - -
" The value of X is BIG "
Okay, here is the closure k that I have been talking about:
(defvar k)
(let ((x 'big) (y 'daddy))
(setq k #'(lambda () (list x y) )))
? (funcall k)
(BIG DADDY)
Now, where is that guy who made a statement a few days ago to the
effect that a closure preserves the bindings, not the values.
To me they seem to be essentially the same thing.
Wonder what he meant?
Oh well, twenty years from now I will figure it all out.
FWIW, all SICP had about bindings was a general statement on page 184
that bindings associated values with variables.
Mark-
From: Paul F. Dietz
Subject: Re: Implementation Favoritism, a question of Lisp mindsets
Date:
Message-ID: <l5mdnd6LqsfXRC6jXTWcpQ@dls.net>
Mark Conrad wrote:
> Okay, if I FINALLY understand binding correctly, the 'let' form below
> does *not* establish a binding between x and anything else!
>
> ? (let (x) x 'lexical-variable-x-is-not-bound-to-anything)
> LEXICAL-VARIABLE-X-IS-NOT-BOUND-TO-ANYTHING
No, (let (x) ...) is equivalent to (let ((x nil)) ...).
Paul
In article <······················@dls.net>, Paul F. Dietz
<·····@dls.net> wrote:
> No, (let (x) ...) is equivalent to (let ((x nil)) ...).
Yeah, I found that out after I had already posted. :-(
Mark-
From: Paul F. Dietz
Subject: Re: Implementation Favoritism, a question of Lisp mindsets
Date:
Message-ID: <qVWdnUaQVOPVpimjXTWcog@dls.net>
Mark Conrad wrote:
> Yeah, I found that out after I had already posted. :-(
However, there *is* a way to make valueless dynamic bindings
(see PROGV).
Paul
From: Nikodemus Siivola
Subject: Re: Implementation Favoritism, a question of Lisp mindsets
Date:
Message-ID: <b90lu1$556cg$2@midnight.cs.hut.fi>
Mark Conrad <······@iam.invalid> wrote:
> FWIW, all SICP had about bindings was a general statement on page 184
> that bindings associated values with variables.
Which is excatly what they do. And all they do.
But you didn't actually read you way through there, did you? No, you
jumped ahead.
Read from the beginning. Do the excercises. It's a course book, ment to
be read and studied sequentially. That means don't move on before you
understand what was just said, and have verified that you actually got
it right by doing the excercises.
And when you don't understand something ask about it in
comp.lang.scheme.
Cheers,
-- Nikodemus
In article <··············@midnight.cs.hut.fi>, Nikodemus Siivola
<········@kekkonen.cs.hut.fi> wrote:
> > FWIW, all SICP had about bindings was a general statement on page 184
> > that bindings associated values with variables.
>
> Which is excatly what they do. And all they do.
Well, perhaps we can all agree on that.
The tricky part is what the exact nature of the association is.
This whole subject of what "bindings" means is complex, and not subject
to explanation in say 100 words or less.
I will read all the relevant chapters in SICP and do all the exercises,
to see if I can resolve this issue to my satisfaction.
Mark-
P.S. - FWIW, I was already fully aware of the "scope" and "extent"
rules for variables within closures before I even started discussing
the subject in this NG.
...and closures *do* behave as the scope and extent rules say they
should behave.
What puzzles me is the true/untrue notion that once a closure is
"defined" (evaluated) in a body of code, certain aspects of that
closure should be "set-in-stone", preserved against being changed.
(namely, the "environment" AT THE TIME OF THE CREATION OF THE CLOSURE)
...unless the closure definition itself is re-defined (re-evaluated)
Some of the code presented in this NG seems to violate the
"set-in-stone" premise, which is where my misunderstanding kicks in.
From: Matthew Danish
Subject: Re: Implementation Favoritism, a question of Lisp mindsets
Date:
Message-ID: <20030503174740.A2801@mapcar.org>
On Sat, May 03, 2003 at 09:04:36PM +0000, Mark Conrad wrote:
> What puzzles me is the true/untrue notion that once a closure is
> "defined" (evaluated) in a body of code, certain aspects of that
> closure should be "set-in-stone", preserved against being changed.
> (namely, the "environment" AT THE TIME OF THE CREATION OF THE CLOSURE)
>
> ...unless the closure definition itself is re-defined (re-evaluated)
>
> Some of the code presented in this NG seems to violate the
> "set-in-stone" premise, which is where my misunderstanding kicks in.
Time to ditch your premise then. Fact comes before hypothesis. Lisp lets you
modify the value of variable bindings captured in a closure. Why? Why not?
It's just a mapping. In Python, there is an arbitrary restriction against the
same. Why? Who knows?
--
; Matthew Danish <·······@andrew.cmu.edu>
; OpenPGP public key: C24B6010 on keyring.debian.org
; Signed or encrypted mail welcome.
; "There is no dark side of the moon really; matter of fact, it's all dark."
Mark Conrad wrote:
> FWIW, all SICP had about bindings was a general statement on page 184
> that bindings associated values with variables.
Well, how much did you read of the first two chapters?
In this section the withdraw is a closure.
[note: (define (withdraw amount) ...) is sugar for
(define withdraw (lambda (amount) ...)) ]
<http://mitpress.mit.edu/sicp/full-text/book/book-Z-H-20.html>
The pedagogy of the book is to show you how things work first,
and then later in great detail explain the evaluation model.
--
Jens Axel S�gaard
In article <·························@iam.invalid>,
Mark Conrad <······@iam.invalid> wrote:
> Okay, here is the closure k that I have been talking about:
>
> (defvar k)
>
> (let ((x 'big) (y 'daddy))
> (setq k #'(lambda () (list x y) )))
>
> ? (funcall k)
> (BIG DADDY)
>
>
> Now, where is that guy who made a statement a few days ago to the
> effect that a closure preserves the bindings, not the values.
>
> To me they seem to be essentially the same thing.
>
> Wonder what he meant?
Try the following:
(defvar k)
(defvar setx)
(defvar sety)
(let ((x 'big) (y 'daddy))
(setq k #'(lambda () (list x y)))
(setq setx #'(lambda (value) (setq x value)))
(setq sety #'(lambda (value) (setq y value))))
? (funcall k)
(big daddy)
? (funcall sety 'mummy)
mummy
Try to guess what (funcall k) will print now.
And PLEASE: It's not very constructive that you don't follow the links
people provide to you. See http://www.psg.com/~dlamkins/sl/contents.html, especially lessons 5 and 6.
Do it! Do it now! Take some time to read and understand these things.
There are over 30 chapters in that book. You don't want to post that
much as you do on every single topic, right?
Pascal
In article <······························@news.netcologne.de>, Pascal
Costanza <········@web.de> wrote:
> And PLEASE: It's not very constructive that you don't follow the links
> people provide to you. See http://www.psg.com/~dlamkins/sl/contents.html,
> especially lessons 5 and 6.
>
> Do it! Do it now! Take some time to read and understand these things.
> There are over 30 chapters in that book. You don't want to post that
> much as you do on every single topic, right?
That online book was very helpful, I read all the chapters you
suggested plus chapter 15 on closures.
The book was not all that helpful in resolving the issue of whether a
"binding" is a location in memory or not, and whether that "binding" is
*still* a "binding" if no value is placed in the
binding-memory-location.
Confusion reigns surpreme on this particular aspect of "binding",
because even the Hyperspec says that a binding is an association
between a variable and its value.
In other words, is a binding still a binding when there is no value
placed in the "binding-location" in memory?
We then have "no association" between the variable's binding with the
variable's value, which the Hyperspec seems to demand.
Mark-
From: Peter Seibel
Subject: Re: Implementation Favoritism, a question of Lisp mindsets
Date:
Message-ID: <m3fznvh1ml.fsf@javamonkey.com>
Mark Conrad <······@iam.invalid> writes:
> In article <······························@news.netcologne.de>, Pascal
> Costanza <········@web.de> wrote:
>
> > And PLEASE: It's not very constructive that you don't follow the links
> > people provide to you. See http://www.psg.com/~dlamkins/sl/contents.html,
> > especially lessons 5 and 6.
> >
> > Do it! Do it now! Take some time to read and understand these things.
> > There are over 30 chapters in that book. You don't want to post that
> > much as you do on every single topic, right?
>
> That online book was very helpful, I read all the chapters you
> suggested plus chapter 15 on closures.
>
> The book was not all that helpful in resolving the issue of whether a
> "binding" is a location in memory or not, and whether that "binding" is
> *still* a "binding" if no value is placed in the
> binding-memory-location.
>
> Confusion reigns surpreme on this particular aspect of "binding",
> because even the Hyperspec says that a binding is an association
> between a variable and its value.
I'm not sure the HyperSpec says that. Here's another way to read it,
which may clarify things. Or not--I certainly agree that folks tend to
use different words to mean the same thing and the same words to mean
slightly different things when discussing this topic, which can be
confusing. And here I am just adding another interpretation. But here
goes. (BTW, if folks think this explanation is flawed or good, I'd be
interested to hear about it--I'm trying to write something about this
for some materials I'm working on.)
The glossary entry for "binding" says:
binding n. an association between a name and that which the name
denotes.
It goes on to use as an *example* of the use of the word:
``A lexical binding is a lexical association between a name and its
value.''
But, as I understand it, those sentences in quotation marks are not
necessarily normative statements about the language, they're just
examples of the term in use. Presumably they are mostly true but I
don't think they are required to be.
So going just on the definitional part, a binding associates a "name"
and "that which the name denotes". So we're all, I think, pretty clear
on what the "name" of a binding in the variable namespace is--it's the
symbol read by the Lisp reader. But there's a couple ways you can
think of "that which the name denotes".
One point of view is that it is the "value" of the variable. Some
people (such as that example sentence in the glossary) talk about
things that way.
Other folks, point out--as someone in this thread has--that there are
really *three* things involved in a variable binding: the name, the
value, *and* the memory where the value will be stored. Since the
value can change anytime, perhaps it's reasonable to say that "that
which the name denotes" is the memory location where the value will be
stored.
Unfortunately the "memory location" is not mentioned explicitly in the
standard (that I'm aware of) because it's not a first class entity--it
is totally dependent on the implementation what a "memory location" is
and they won't be the same for all bindings. For instance, if the
compiler compiles some code that creates a binding:
(let ((x 10)) ...)
and that binding is not captured by a closure, the "memory location"
where the value is stored, may be on the stack or in a register. If it
*is* captured then it may still be initally allocated on the stack or
in a register but will be relocated to somewhere on the heap at the
end of the LET body. Or the compiler might just put it on the heap
from the beginning, knowing it's going to be closed over. Dynamic
bindings will presumable have their "memory locations" handled
differently. The point is, it's all internal to the implementation.
> In other words, is a binding still a binding when there is no value
> placed in the "binding-location" in memory?
By my interpretation, yes.
> We then have "no association" between the variable's binding with
> the variable's value, which the Hyperspec seems to demand.
So that's evidence to me that "that which the thing denotes" is not
the value but the place where the value is stored.
--
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: Peter Seibel
Subject: Re: Implementation Favoritism, a question of Lisp mindsets
Date:
Message-ID: <m38ytngvl4.fsf@javamonkey.com>
Peter Seibel <·····@javamonkey.com> writes:
> Mark Conrad <······@iam.invalid> writes:
>
> > In article <······························@news.netcologne.de>, Pascal
> > Costanza <········@web.de> wrote:
> >
> > > And PLEASE: It's not very constructive that you don't follow the links
> > > people provide to you. See http://www.psg.com/~dlamkins/sl/contents.html,
> > > especially lessons 5 and 6.
> > >
> > > Do it! Do it now! Take some time to read and understand these things.
> > > There are over 30 chapters in that book. You don't want to post that
> > > much as you do on every single topic, right?
> >
> > That online book was very helpful, I read all the chapters you
> > suggested plus chapter 15 on closures.
> >
> > The book was not all that helpful in resolving the issue of whether a
> > "binding" is a location in memory or not, and whether that "binding" is
> > *still* a "binding" if no value is placed in the
> > binding-memory-location.
> >
> > Confusion reigns surpreme on this particular aspect of "binding",
> > because even the Hyperspec says that a binding is an association
> > between a variable and its value.
>
> I'm not sure the HyperSpec says that. Here's another way to read it,
> which may clarify things. Or not--I certainly agree that folks tend to
> use different words to mean the same thing and the same words to mean
> slightly different things when discussing this topic, which can be
> confusing. And here I am just adding another interpretation. But here
> goes. (BTW, if folks think this explanation is flawed or good, I'd be
> interested to hear about it--I'm trying to write something about this
> for some materials I'm working on.)
Blech. I think I need to recant, or at least rethink, this
explanation. Because the way I wanted to understand "binding", "bind",
"bound", and "unbound" doesn't fit with the definiton of BOUNDP and
MAKUNBOUND and the observed behavior of two implementations. (I.e. I
assume the implementors, since they agree, got it right and I'm the
one who's confused.) Anyway suppose you do define a special variable
with DEFVAR:
(defvar *s* 10)
Now evaluate:
(let ()
(format t "*S*: ~a (boundp: ~a)~%" *s* (boundp '*s*))
(let ((*s* 20))
(format t "*S*: ~a (boundp: ~a)~%" *s* (boundp '*s*))
(makunbound '*s*)
(if (boundp '*s*)
(format t "*S*: ~a (boundp: ~a)~%" *s* (boundp '*s*))
(format t "*s* not bound~%"))
(setq *s* 30)
(if (boundp '*s*)
(format t "*S*: ~a (boundp: ~a)~%" *s* (boundp '*s*))
(format t "*s* not bound~%")))
(format t "*S*: ~a (boundp: ~a)~%" *s* (boundp '*s*)))
In both the implementations I tried this, it prints:
*S*: 10 (boundp: T)
*S*: 20 (boundp: T)
*s* not bound
*S*: 30 (boundp: T)
*S*: 10 (boundp: T)
At this point I have to join Mark Conrad in his confusion about what
the relation between "bindings", being "bound", and having a "value"
is. Here are some relevant bits of the standard:
binding glossary entry
"n. an association between a name and that which the name
denotes."
bound glossary entry:
"1. adj. having an associated denotation in a binding."
unbound glossary entry:
"adj. not having an associated denotation in a binding. See bound."
BOUNDP dictionary entry:
"Returns true if symbol is bound; otherwise, returns false."
MAKUNBOUND
"Makes the symbol be unbound, regardless of whether it was
previously bound."
LET dictionary entry:
"let and let* create new variable bindings"
PROGV dictionary entry:
"If too few values are supplied, the remaining symbols are bound
and then made to have no value."
variable glossary entry:
"n. a binding in the ``variable'' namespace."
So it seems that the only way to interpret the definiton of "binding"
that is consistent with the definitions of "bound", "unbound", BOUNDP,
and MAKUNBOUND, is that the *value* is "that which the name denotes",
as it's the *value* that MAKUNBOUND removes.
However, the code I showed above seems to demonstrate--in the two
implementations I tried it in, anyway--that there is *something* that
is created by the inner LET that persists after the MAKUNBOUND. That
is, there's either a "location" that the SETQ stores the value 30 that
is different than the "location" that the global value of *S* is
stored, or there's something that causes the old value of *S* to be
restored at the end of the inner LET. I'm tempted to call that
"something" the "binding" but that isn't correct since the "binding"
is "an association between a name and that which the name denotes" and
the name *S* in "unbound" and thus doesn't have "an associated
denotation". And it can't be the "variable" because a "variable" is
just "a binding", per the glossary.
So what the heck is the name for that something?
-Peter
P.S. I'm fairly sure I understand the *behavior* of DEFVAR, LET,
PROGV, BOUNDP, MAKUNBOUND, etc. I'm just confused about how to
correctly use the terminology of the spec to describe that behavior.
--
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:
> I think I need to recant, or at least rethink, this
> explanation. Because the way I wanted to understand "binding", "bind",
> "bound", and "unbound" doesn't fit with the definiton of BOUNDP and
> MAKUNBOUND and the observed behavior of two implementations.
- - - and - - -
> I'm fairly sure I understand the *behavior* of DEFVAR, LET,
> PROGV, BOUNDP, MAKUNBOUND, etc. I'm just confused about how to
> correctly use the terminology of the spec to describe that behavior.
Same here, I also am fairly certain that I understand the actual
*behavior* of those CL terms. I can look at a code segment containg
those terms and anticipate how it will act once it is executed.
It is just that I have been away from CL for many years now, so I don't
yet feel 'comfortable' with the terminology that I am re-learning.
So, to be better Lisp users, we all try to understand the terms used to
describe how things work in Lisp.
Take the term "binding" for example. The CL HyperSpec glossary
describes that word as a noun. (a person, a place, or a thing)
Well we can pretty well rule out 'binding' as being a person<g>
It is tempting to think of a binding as a thing. (a value, for example)
These "values" can change during the course of running the Lisp
program.
A binding could also be thought of as a place, a particular place in a
RAM memory chip, or if virtual memory is being used perhaps a
particular place on a hard disk platter. These "places" where the
binding "is at" can change during the course of running the Lisp
program.
As to whether a binding is a place or a value stored in that place or
the combination of a place-and-a-value - - - all that does not seem to
be nailed down in the description of "binding". (in the HyperSpec)
Does that hurt us? Maybe. We might come to differing conclusions
about how a segment of code will work, depending on what we expected a
"binding" in that code to do.
Can we avoid that predictament? Mostly we can, by experimenting with
"bindings" and becoming aware of how they act in many differing
situations.
We can each ask ourselves, how certain are we that our particular idea
about "binding" is correct.
We can discuss this until we are blue in the face, but I don't think we
will wind up agreeing about what a binding is, exactly.
I am content to let the subject drop, but will listen intently to
others as they discuss this subject amonst themselves.
Thanks to all, you have cleared the air quite a bit regarding
"bindings", and no doubt many lurkers have benefited also.
Mark-
In article <······························@news.netcologne.de>, Pascal
Costanza <········@web.de> wrote:
> > Now, where is that guy who made a statement a few days ago to the
> > effect that a closure preserves the bindings, not the values.
> >
> > To me they seem to be essentially the same thing.
> >
> > Wonder what he meant?
>
> Try the following:
>
> (defvar k)
> (defvar setx)
> (defvar sety)
>
> (let ((x 'big) (y 'daddy))
> (setq k #'(lambda () (list x y)))
> (setq setx #'(lambda (value) (setq x value)))
> (setq sety #'(lambda (value) (setq y value))))
>
> ? (funcall k)
> (big daddy)
>
> ? (funcall sety 'mummy)
> mummy
>
> Try to guess what (funcall k) will print now.
Thanks for the help.
I can see now that the binding remains "preserved", i.e. variable k
still persists, even though the value associated with variable k has
been changed to a different value.
Mark-
From: Ed L Cashin
Subject: Re: Implementation Favoritism, a question of Lisp mindsets
Date:
Message-ID: <878ytnyjvh.fsf@cs.uga.edu>
Pascal Costanza <········@web.de> writes:
> See for example the entry for binding in the glossary section of the
> HyperSpec:
>
> binding n. an association between a name and that which the name
> denotes. ``A lexical binding is a lexical association between a name and
> its value.''
Thank you! I was growing worried after two people suggested that a
binding is a bucket where a value can be kept. Then the word itself
wouldn't relate to its meaning. Nothing is being bound in the concept
of "a location where a value may be kept".
--
--Ed L Cashin PGP public key: http://noserose.net/e/pgp/
In article <··············@cs.uga.edu>, Ed L Cashin <·······@uga.edu>
wrote:
> Pascal Costanza <········@web.de> writes:
>
> > See for example the entry for binding in the glossary section of the
> > HyperSpec:
> >
> > binding n. an association between a name and that which the name
> > denotes. ``A lexical binding is a lexical association between a name and
> > its value.''
>
> Thank you! I was growing worried after two people suggested that a
> binding is a bucket where a value can be kept. Then the word itself
> wouldn't relate to its meaning. Nothing is being bound in the concept
> of "a location where a value may be kept".
FWIW, those same suggestions that a binding is a location puzzled and
confused me also, so you are not alone.
I see that idea of a binding being a location in a few of my Lisp books
also.
Mark-
From: Ed L Cashin
Subject: Re: Implementation Favoritism, a question of Lisp mindsets
Date:
Message-ID: <873cjvwtxi.fsf@cs.uga.edu>
Mark Conrad <······@iam.invalid> writes:
> In article <··············@cs.uga.edu>, Ed L Cashin <·······@uga.edu>
> wrote:
>
>> Pascal Costanza <········@web.de> writes:
>>
>> > See for example the entry for binding in the glossary section of the
>> > HyperSpec:
>> >
>> > binding n. an association between a name and that which the name
>> > denotes. ``A lexical binding is a lexical association between a name and
>> > its value.''
>>
>> Thank you! I was growing worried after two people suggested that a
>> binding is a bucket where a value can be kept. Then the word itself
>> wouldn't relate to its meaning. Nothing is being bound in the concept
>> of "a location where a value may be kept".
>
> FWIW, those same suggestions that a binding is a location puzzled and
> confused me also, so you are not alone.
I don't think I was confused, just distressed. To equate "binding" to
"location" is confusion. So when Erann Gat says,
(let ((x 1)) ; Establish a binding (i.e. a memory location) for X.
... it's misleading. There are distinct things happenning: there's a
memory location allocated, and there's a name, "x", associated with
that memory location. The binding is the relationship between the
name and the memory location that allows you to access the memory
location by using the name.
There's no advantage to collapsing the concepts of location and
binding. Calling a memory location an "object" or just a memory
location is more accurate and more discriptive.
> I see that idea of a binding being a location in a few of my Lisp
> books also.
Yeah, I think that's an unhelpful collapse of ideas, where the useful
distinction between memory objects, names, and bindings is being lost.
In a forum like this, I expect a higher standard of precision. After
all, after newbies read confusing books, this is where they'll come.
--
--Ed L Cashin PGP public key: http://noserose.net/e/pgp/
In article <··············@cs.uga.edu>, Ed L Cashin <·······@uga.edu>
wrote:
> After all, after newbies read confusing books,
> this is where they'll come.
You got that right!
I know all the help in this NG will make it easier for me when it comes
to understanding the books.
Usually, I try the books first, then if a subject is not covered in any
of my books, I try a Google search. If that doesn't pay off, then I
hit the newsgroups.
It is amazing how much knowledge resides in this NG.
Mark-
In article <······························@news.netcologne.de>, Pascal
Costanza <········@web.de> wrote:
> See for example the entry for binding in the glossary section of the
> HyperSpec
Thanks very much for digging up that reference in the HyperSpec.
Thanks also for the online book reference.
I am still furiously trying to resolve the issue of whether or not a
binding is still a binding when no value is specifically assined to the
binding by the user.
In other words, does a binding cease to be a binding if the user does
not explicitly assign a value to the memory location associated with
the binding.
(assuming a memory-location *is* assigned to the binding)
Mark-
From: Kenny Tilton
Subject: Re: Implementation Favoritism, a question of Lisp mindsets
Date:
Message-ID: <3EB32B0C.8050309@nyc.rr.com>
Mark Conrad wrote:
> I can see now why there are so few new newbies adopting CL as their
> preferred language, when it is apparent how cantankerous and downright
> ornery people are in this NG.
The word you are looking for is "savages".
--
kenny tilton
clinisys, inc
http://www.tilton-technology.com/
---------------------------------------------------------------
"Everything is a cell." -- Alan Kay
Kenny Tilton <·······@nyc.rr.com> writes:
> Mark Conrad wrote:
> > I can see now why there are so few new newbies adopting CL as their
> > preferred language, when it is apparent how cantankerous and downright
> > ornery people are in this NG.
>
> The word you are looking for is "savages".
So he is the missionary? To the rest of the savages "Soups on"
marc
From: Joe Marshall
Subject: Re: Implementation Favoritism, a question of Lisp mindsets
Date:
Message-ID: <n0i1ch4k.fsf@ccs.neu.edu>
Mark Conrad <······@iam.invalid> writes:
<code demonstrating lexical binding snipped>
> Running his code in MCL ver' 4.3
> ? (x)
> 1
> ? (set-x 3)
> 3
> ? (x)
> 3
> ?
>
> At the very least, this is unexpected behavior.
It is certainly the behavior I expect.
> It is yet another exception to the general behavior of CL that has
> to be memorized and allowed for so it won't bite me later.
No, it is the defined behavior of Common Lisp. Not only that, it is
defined behavior of any language that supports lexical scope and
mutable bindings.
> Lisp gurus somehow learn the exceptions to general rules, (as those
> rules are laid down in the books), but the only way I had to learn
> about the nasty behavior above was to make a rash statement about how I
> thought the cookie crumbled, then sit back and wait for agreement or
> disagreement to my rash statement.
You could read the computer science literature.
> At the worst, something is broken somewhere in the CL implementation or
> in the CL hyperspec, and should be changed.
You might want to look back at the messages posted by one `ilias'.
You seem to have overlooked the possibility that it is your
*understanding* of CL that is broken and should be changed.
> Now let's make small changes in my above code to demonstrate the
> unexpected nasty behavior, nasty behavior that is *not* explained in
> any of the books that have been recommended to me in this NG.
This is the *essence* of lexical bindings. The bindings are of
indefinite extent --- they remain in effect as long as necessary.
This is *very* elementary stuff, and you need to go back to the books
and re-learn them.
> I don't want to "piss people off" so this will likely be my last post
> in this NG.
Right......
> I can see now why there are so few new newbies adopting CL as their
> preferred language, when it is apparent how cantankerous and downright
> ornery people are in this NG.
Yes. We are hostile and unfriendly.
Mark Conrad wrote:
> If I make foolish, wrong, convoluted, nonsense statements in this NG,
> the fine people here do not let those statements stand.
>
> They correct me, and I learn.
>
> ...then I make another rash statement, based on my enlightened newer
> knowledge. If the newer statement is still incorrect, again I get
> corrected forthwith.
>
> As I get closer and closer to the truth of the matter, eventually my
> statements make sense.
The danger is that, before your statements start to make
sense, the fine people here decide that you're wasting
their time. Because the approach you're taking is, shall
we say, not calculated to minimize the number of foolish
questions you need to ask. Some people may reasonably feel
that they aren't obliged to offer you the extra support
that's required as a result of your inefficient choice
of learning method.
(I'm not as convinced as some people here that it's
a very bad way to learn. There's something to be said
for jumping in at the deep end, and there's a lot to
be said for learning by doing something that motivates
you. But you have to be aware that you're running the
risk of annoying the people you depend on for help
so much that they give up...)
--
Gareth McCaughan ················@pobox.com
.sig under construc
Gareth McCaughan <················@pobox.com> writes:
> (I'm not as convinced as some people here that it's
> a very bad way to learn. There's something to be said
> for jumping in at the deep end, and there's a lot to
> be said for learning by doing something that motivates
> you. But you have to be aware that you're running the
> risk of annoying the people you depend on for help
> so much that they give up...)
It's not a bad way to learn, provided you have a tutor who is willing
to go along with it. I once tutored someone in math, who, despite
getting straight C's in high school math, had semi-grandiose theories
about how math worked, which he would explain to me. This approach
paid off, and he ended out getting a good score on his Math SAT.
However, this *only* works if you have a tutor who's willing to go
along with it (the OP seems to need repetition). Otherwise, it's
simply antisocial behavior.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
From: Nikodemus Siivola
Subject: Re: Implementation Favoritism, a question of Lisp mindsets
Date:
Message-ID: <b8sj91$54qef$1@midnight.cs.hut.fi>
Mark Conrad <······@iam.invalid> wrote:
> Reading does not resolve the issues being discussed here, and I have
> many darn good Lisp books.
Then you are reading the wrong books, or the right books in the wrong
manner.
Several of your comments have demonstrated a general lack of rigor
required to grasp the underlying issues. You have also on numerous
occasions referred to "On Lisp", which could be considered an advanced
text. Hence, I would recommend two books to you:
1) Structure and Interpretation of Computer Programs. The full text is
available online, just google for it. Don't just read it, but do the
excercises as well. And don't expect to finish it in "a week or
two". Depending on the time you invest two months to a year is a more
realistic goal.
After you have finished the SICP:
2) ANSI Common Lisp by Paul Graham. This one you have to buy, but it's
worth it. If you have SICP under your belt at this point it will be fast
and easy reading.
Then you can have a go at "On Lisp" and continuations. Sorry, but that's
the way it is.
Cheers,
-- Nikodemus
From: Tim Bradshaw
Subject: Re: Implementation Favoritism, a question of Lisp mindsets
Date:
Message-ID: <ey3k7da9kg9.fsf@cley.com>
* Mark Conrad wrote:
> They correct me, and I learn.
No, they correct you, you ignore the correction, and reiterate the
same confusion. Eventually they give up.
Mark Conrad wrote:
[Joe Marshall:]
> > It confuses me, too. There is NO top level lexical environment in
> > Common Lisp.
> >
> > A variable in a Common Lisp program is either lexically bound,
> > dynamically bound, or free. If the variable is free, it's value is
> > the current dynamic value (fetched from the value cell of the
> > symbol).
[Mark:]
> Here is my problem with that, perhaps you can enlighten me as to the
> correct terminology?
>
> If I create a closure function this way:
>
> (define-symbol-macro x 2)
>
> ? x
> 2
>
> (defun test () x))
This is not the way to use DEFINE-SYMBOL-MACRO to make
things-that-look-like-global-lexical-variables.
Consider:
(define-symbol-macro x (list 1 2 3))
(eql x x) ==> NIL
This is not good.
What you need is something more along the following lines:
(defmacro def-global-lexical (name &optional value-form)
(let ((real-name (gensym)))
`(progn
(defvar ,real-name ,value-form)
(define-symbol-macro ,name ,real-name))))
> We know that running the closure function (test) will return 2
>
> ? (test)
> 2
>
> Now x is "toplevel", I assume
>
> ? x
> 2
>
> x is obviously a lexically scoped variable, because if we change its
> value then there is no effect on our closure function "test"
No, X is not a lexically scoped variable. X is a special kind
of macro. I don't think it's unreasonable, though, to say
that the definition of this macro is part of a "top-level
lexical environment". But there is no top-level lexical
environment *for variables*.
A better way to say all this: lexicality is not a property
of environments but of bindings. A binding is lexical if
its scope is the body of some form. There is a top-level
environment. Variable bindings in that environment are
made by DEFVAR and its friends, and if a variable has
such a binding then it cannot be given a lexical binding.
Function bindings in the top-level environment are made
by DEFUN and its friends, and things so bound *can* be
given lexical bindings (via FLET and LABELS). Symbol-macro
bindings in the top-level environment are made by
DEFINE-SYMBOL-MACRO, and things so bound *can* be given
lexical bindings -- via SYMBOL-MACROLET or via LET and
its friends.
You want to simulate a "lexical top-level environment".
What that means is that you want to be able to make
variable bindings at the top level that don't prevent
subsequent lexical bindings. You can do that by building
a variable-binding-lookalike out of two components:
a symbol-macro binding and a variable binding. The
first applies to the name you care about and can be
overridden lexically. The second is the actual variable
binding; it can't be overridden lexically, but that
doesn't matter because the variable name is a gensym
anyway so no one will be trying to override it lexically.
> Now the closure-function "test" was created in a lexical environment,
> where x was part of that lexical environment, or so it seems to me.
Kind of, but X isn't a variable in that environment, it's
a symbol-macro. It's only variables that don't have global
lexical bindings.
--
Gareth McCaughan ················@pobox.com
.sig under construc
I wrote:
> A better way to say all this: lexicality is not a property
> of environments but of bindings. A binding is lexical if
> its scope is the body of some form.
[etc]
On the other hand, the CL standard does use the term
"lexical environment", meaning "all lexical bindings".
That's fine, but note that "the top-level environment"
neither contains, nor is contained in, the "lexical
environment".
You can partition "the environment" (i.e., *all* bindings
active at any given point) in several different ways:
according to scope (so you get "the lexical environment"
and "the dynamic environment"), according to namespace
(so you get the "variable environment", the "function
environment", and so on), according to when and where
the bindings happened (so you get a chain of nested
"lexical environments" and a chain of differently nested
"dynamic environments", with a "global environment" at
the end of the chains) ... and there are probably other
plausible ways.
One of these gives you a thing called the "lexical
environment". One of them gives you a thing called
the "top-level environment". But you probably don't
want to be trying to use both partitions at once.
--
Gareth McCaughan ················@pobox.com
.sig under construc
In article <······························@g.local>, Gareth McCaughan
<················@pobox.com> wrote:
> > x is obviously a lexically scoped variable, because if we change its
> > value then there is no effect on our closure function "test"
>
> No, X is not a lexically scoped variable. X is a special kind
> of macro. I don't think it's unreasonable, though, to say
> that the definition of this macro is part of a "top-level
> lexical environment". But there is no top-level lexical
> environment *for variables*.
Yipes!, my head hurts.<g>
Give me a little time to let this all sink in.
> Consider:
>
> (define-symbol-macro x (list 1 2 3))
> (eql x x) ==> NIL
>
> This is not good.
Definitely not good, I agree. It is very hard to determine if the
first-x above is retrieved from the same memory location as the
second-x was retrieved from, considering that a lot of macro expansion
is going on behind-the-scenes.
Mark-
Mark Conrad wrote:
[I said:]
> > Consider:
> >
> > (define-symbol-macro x (list 1 2 3))
> > (eql x x) ==> NIL
> >
> > This is not good.
>
> Definitely not good, I agree. It is very hard to determine if the
> first-x above is retrieved from the same memory location as the
> second-x was retrieved from, considering that a lot of macro expansion
> is going on behind-the-scenes.
What (define-symbol-macro x <something>) means
is: textually substitute <something> for X
every time it appears. (Well, almost. That
doesn't happen in quoted data, and it doesn't
happen when X is in function position.)
So, after (define-symbol-macro x (list 1 2 3)),
there is no difference at all between (eql x x)
and (eql (list 1 2 3) (list 1 2 3)). And LIST
is guaranteed to cons up a fresh list each time
you call it.
--
Gareth McCaughan ················@pobox.com
.sig under construc
In article <······························@g.local>, Gareth McCaughan
<················@pobox.com> wrote:
> What (define-symbol-macro x <something>) means
> is: textually substitute <something> for X
> every time it appears. (Well, almost. That
> doesn't happen in quoted data, and it doesn't
> happen when X is in function position.)
I tried to imagine how I would get into trouble with the 'quoted' and
the 'function-position' thingy, but drew a blank.
Is relying on "define-symbol-macro" going to get me into trouble down
the road, in your estimation.
Mark-
From: Peter Seibel
Subject: Re: Implementation Favoritism, a question of Lisp mindsets
Date:
Message-ID: <m3n0i6k8wz.fsf@javamonkey.com>
Mark Conrad <······@iam.invalid> writes:
> In article <······························@g.local>, Gareth McCaughan
> <················@pobox.com> wrote:
>
> > What (define-symbol-macro x <something>) means
> > is: textually substitute <something> for X
> > every time it appears. (Well, almost. That
> > doesn't happen in quoted data, and it doesn't
> > happen when X is in function position.)
>
> I tried to imagine how I would get into trouble with the 'quoted'
> and the 'function-position' thingy, but drew a blank.
He meant, I imagine, that if you do this:
(define-symbol-macro x 2)
and then this:
(defun x () 10)
Lisp doesn't get confused when you say this:
(x) ==> 10
while:
x ==> 2
and
'(x) ==> (x)
That is, the macro is not expanded in contexts where it doesn't "look
like" a variable. (As opposed to, say, C "macros" which really are
textual substitution. Blech.)
> Is relying on "define-symbol-macro" going to get me into trouble down
> the road, in your estimation.
I'd say yes. Until you get a deeper understanding of what macros,
variables, closures, etc. actually are. I'd reiterate the point
someone made a couple weeks ago--learn Lisp. Use it the way it was
intended to be used. Get it under your fingers.
When you are an expert, you may figure out some clever hacks that you
can build on top of symbol macros, but until then you mostly seem to
be confusing yourself.
You really ought to consider starting back from the top--what's the
problem you're trying to solve? I.e. if you're trying to write some
software, what's it supposed to do? I imagine there are some folks
here might be willing to help you figure out the idiomatic Lisp way of
writing software that does whatever it is.
-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 wrote:
[I said:]
> > > What (define-symbol-macro x <something>) means
> > > is: textually substitute <something> for X
> > > every time it appears. (Well, almost. That
> > > doesn't happen in quoted data, and it doesn't
> > > happen when X is in function position.)
[Mark Conrad replied:]
> > I tried to imagine how I would get into trouble with the 'quoted'
> > and the 'function-position' thingy, but drew a blank.
[Peter:]
> He meant, I imagine, that if you do this:
>
> (define-symbol-macro x 2)
>
> and then this:
>
> (defun x () 10)
>
> Lisp doesn't get confused when you say this:
>
> (x) ==> 10
>
> while:
>
> x ==> 2
>
> and
>
> '(x) ==> (x)
Your imagination is correct.
[Mark again:]
> > Is relying on "define-symbol-macro" going to get me into trouble down
> > the road, in your estimation.
Depends what you mean. If you need something that behaves
like a global lexical then you need to use define-symbol-macro,
so relying on that is your only option.
But: Until you understand what define-symbol-macro is
doing, using it is liable to get you into trouble;
until you understand how variable bindings work in
Lisp, just about everything is going to get you into
trouble.
But the solution to this is to learn to understand,
not to put define-symbol-macro in a box labelled
"dangerous". Everything's dangerous until you
understand it.
On the other hand, if you weren't determined that
your first Lisp project *must* involve Paul Graham's
continuation stuff, I'd suggest that you could pick
better areas of Lisp to concentrate on for now...
--
Gareth McCaughan ················@pobox.com
.sig under construc
In article <··············@javamonkey.com>, Peter Seibel
<·····@javamonkey.com> wrote:
> > Is relying on "define-symbol-macro" going to get me into trouble down
> > the road, in your estimation.
>
> I'd say yes. Until you get a deeper understanding of what macros,
> variables, closures, etc. actually are. I'd reiterate the point
> someone made a couple weeks ago--learn Lisp. Use it the way it was
> intended to be used. Get it under your fingers.
So far as learning Lisp from books is concerned, I have not had any
luck resolving issues like the ones we are discussing here.
In other words, there are things that can only be learned by asking
specific questions in NG's like this one.
> You really ought to consider starting back from the top--what's the
> problem you're trying to solve?
I am trying to learn how to use Paul Graham's macros to implement
continuations in CL.
In order to do that, I have to learn enough about scope and extent
issues peculiar to his macros.
The text and examples in his book do not go into sufficient detail
about toplevel bindings and extent issues of his global variable
"*cont*" in his book.
Specifically, my present 'learning-project' is to try to implement
catch/throw using continuations only, i.e. to pretend that catch and
throw do not exist in CL.
Mark-
Mark Conrad wrote:
> I am trying to learn how to use Paul Graham's macros to implement
> continuations in CL.
>
> In order to do that, I have to learn enough about scope and extent
> issues peculiar to his macros.
>
> The text and examples in his book do not go into sufficient detail
> about toplevel bindings and extent issues of his global variable
> "*cont*" in his book.
>
> Specifically, my present 'learning-project' is to try to implement
> catch/throw using continuations only, i.e. to pretend that catch and
> throw do not exist in CL.
Mark, you seem to be going down a path that has led others to
destruction --- one, at least, in spectacular fashion.
The pattern is this.
Someone comes to Common Lisp. "Good language," he says, "but I don't
like `X'. Why isn't `X' the way it is in C#, or Scheme, or Intercal?"
"Because of ZZ," replies the Lisp community represented on
comp.lang.lisp.
"But I don't agree with ZZ."
"Well, maybe you will once you've learned a little more about how Lisp
works."
"Not a chance. Tell you what. Lisp is supposed to be mutable, right?
Well, I'll make it the way I want! That's it! I'll make it have
brackets instead of parentheses, or continuations instead of catch and
throw, or whatever. Oh, by the way, the Lisp standard is broken,
backquote doesn't work the way the standard says. And closures aren't
what you think they are, and...."
The next thing you know, there are black helicopters overhead and you
are being detained for questioning by the masses.
I take it you do have your personal affairs in order?
(For the humor impaired, the above is ENTIRELY tongue-in-cheek!)
--
Fred Gilham ······@csl.sri.com
Multiculturalism: The view that societal comity is best achieved by
dividing the country into groups that hate each other. -- Fred Reed
From: Tim Bradshaw
Subject: Re: Implementation Favoritism, a question of Lisp mindsets
Date:
Message-ID: <ey3he8du9kf.fsf@cley.com>
* Fred Gilham wrote:
> (For the humor impaired, the above is ENTIRELY tongue-in-cheek!)
Now come on, you know that's not true. You were in the room when we
voted to dispatch the helicopters.
--tim
In article <···············@cley.com>, Tim Bradshaw <···@cley.com>
wrote:
> * Fred Gilham wrote:
>
> > (For the humor impaired, the above is ENTIRELY tongue-in-cheek!)
>
> Now come on, you know that's not true. You were in the room when we
> voted to dispatch the helicopters.
>
> --tim
>
I am hiding!
Mark-
On 02 May 2003 07:49:52 +0100, Tim Bradshaw <···@cley.com> wrote:
> Now come on, you know that's not true. You were in the room when we
> voted to dispatch the helicopters.
(room t)
Paolo
--
Paolo Amoroso <·······@mclink.it>
In article <·························@iam.invalid>, Mark Conrad wrote:
> In article <··············@javamonkey.com>, Peter Seibel
><·····@javamonkey.com> wrote:
>
>> > Is relying on "define-symbol-macro" going to get me into trouble down
>> > the road, in your estimation.
>>
>> I'd say yes. Until you get a deeper understanding of what macros,
>> variables, closures, etc. actually are. I'd reiterate the point
>> someone made a couple weeks ago--learn Lisp. Use it the way it was
>> intended to be used. Get it under your fingers.
>
> So far as learning Lisp from books is concerned, I have not had any
> luck resolving issues like the ones we are discussing here.
It seems you have made up your mind in advance what is useful and what
is not, and you only accept from books information that confirms your
prejudices.
> In other words, there are things that can only be learned by asking
> specific questions in NG's like this one.
People in the newsgroup are able to react to your prejudices in ways
that books can't. This says more about your mental incapacity than
about the usefulness of the newsgroup as a learning tool.
Zach
Mark,
What (list ...) returns is the address in memory of a freshly-consed
Lisp list. This is known as "returning a list". As a previous poster
said, (list ...) always conses up a fresh list. (The objects contained
in the list needn't be fresh but the conses in the list are fresh; the
fresh conses can point to old, previously-existing objects.) A Lisp list
is a series of cons cells with the car of the cons containing the list
entry and the cdr of the cons pointing to the next cons in the list.
That's why a and c are "the same" below. Both a and c are variables
bound to the same cons cell, which is the first one in the list. (Note:
I never hear Lisp people talk about "point to". a is not a variable, it
is a symbol. It may be correct to say the symbol is bound to the list.
If that is not a correct phrasing, I expect quickly to be corrected.)
But there's a misuse in my code. I'm using eq, not eql. a and c always
will be eq - the object referred to is the same both for a and c. Think
of eq as comparing memory addresses, that is, eq asks if the two
parameters reside at the same memory address. (Implementations are
allowed to treat chars and numbers differently with eq. See below for
more.) Although in this example the (car a) or (car b) comparisons show
eq returning T, and many implementations may do so, that is not a
requirement. It's worse than that. It's back to the undefined behavior
discussions you've been through recently.
Look at eq in the hyperspec. eq may or may not return T when given "the
same" haracters and numbers. I included eq's here just to let you know
that you should use eq when comparing things like a and c, eql when
comparing numbers and characters, equal when comparing larger structures
such as lists (conses) or arrays (strings and bit-vectors are compared
element by element using eql). equalp is like equal except ignoring
case. eq may appear to work when comparing characters and numbers but
it is not guaranteed to work for that purpose.
It's easiest for beginners to use eql except when comparing strings,
when it is good to use equal (or equalp for case insensitivity). (I
think I have that part right.)
(By the way, in the Lisp implementation I'm using, the following code
gave the same result when I used eql instead of eq.)
CL-USER 18 > (let* ((a (list 1 2 3))
(b (list 1 2 3))
(c a))
(format t "~&1: ~a ~a eq?:~a" a b (eq a b))
(format t "~&2: ~a ~a eq?:~a" (car a) (car b)
(eq (car a) (car b)))
(format t "~&3: ~a ~a eq?:~a" a c (eq a c))
(rplaca a 4) ;; replace the car of 'a' with '4'
(format t "~&4: ~a ~a eq?:~a" a b (eq a b))
(format t "~&5: ~a ~a eq?:~a" (car a) (car b)
(eq (car a) (car b)))
(format t "~&6: ~a ~a eq?:~a" a c (eq a c)))
1: (1 2 3) (1 2 3) eq?:NIL
2: 1 1 eq?:T
3: (1 2 3) (1 2 3) eq?:T
4: (4 2 3) (1 2 3) eq?:NIL
5: 4 1 eq?:NIL
6: (4 2 3) (4 2 3) eq?:T
NIL
CL-USER 19 >
In the example below, x is a define-symbol-macro, which means that x is
replaced by (list 1 2 3) wherever x appears. x appears twice in (eql x
x). Therefore it is the same as (eql (list 1 2 3) (list 1 2 3)), which
is the same as a and b in my example above. Each invocation of list
created a fresh set of conses, the addresses in memory of which are
different. (eql x x) ==> NIL means that the two lists are not the same
list, the leading cons cells are not at the same memory address.
Compare that to my example #3 above, where a and c are the same list and
(eql a c) ==> T. a and c are symbols bound to the same variable, the
same cons cell, the same address in memory.
Mark Conrad wrote:
>>Consider:
>>
>> (define-symbol-macro x (list 1 2 3))
>> (eql x x) ==> NIL
>>
>>This is not good.
>
>
> Definitely not good, I agree. It is very hard to determine if the
> first-x above is retrieved from the same memory location as the
> second-x was retrieved from, considering that a lot of macro expansion
> is going on behind-the-scenes.
>
> Mark-
"Jeff Caldwell" <·····@yahoo.com> wrote in message
··························@news1.news.adelphia.net...
>
> It's easiest for beginners to use eql except when comparing strings,
> when it is good to use equal (or equalp for case insensitivity).
Wouldn't the best newbie advice be just use EQUAL until they start to care
about the subtle differences?
I tend to use equal for everything unless I want the added code documentary
benefits of = (means this is math), string= -equal or -equalp (means we are
using only strings), eq (means I am using symbols) and char= (means I know
these are characters)
Whenever things might be mixed and I don;t want an error (most often NIL can
slip in) it's back to EQUAL. (YMMV, IMHO, etc etc...)
--
Coby Beck
(remove #\Space "coby 101 @ bigpond . com")
From: Nils Goesche
Subject: Re: Implementation Favoritism, a question of Lisp mindsets
Date:
Message-ID: <lyr87k8dff.fsf@cartan.de>
"Coby Beck" <·····@mercury.bc.ca> writes:
> "Jeff Caldwell" <·····@yahoo.com> wrote in message
> ··························@news1.news.adelphia.net...
> >
> > It's easiest for beginners to use eql except when comparing
> > strings, when it is good to use equal (or equalp for case
> > insensitivity).
>
> Wouldn't the best newbie advice be just use EQUAL until they start
> to care about the subtle differences?
I think they should be taught about objects and object identity right
from start, and consequently use EQL. If they discover along the way
that sometimes strings that are STRING= are /not/ EQL and hence must
be two different objects, they'll have learned something useful. If
they use EQUAL all the time, however, they'll get bitten by FIND and
CASE and all the other places where EQL is the default equality
predicate. Also, how would you explain
CL-USER 11 > (equal '(a b c) '(a b c))
T
CL-USER 12 > (equal #(a b c) #(a b c))
NIL
to them, if you had told them just before that EQUAL was the generic
equality predicate?
Object identity is a fundamental notion; equality is not.
Regards,
--
Nils G�sche
"Don't ask for whom the <CTRL-G> tolls."
PGP key ID 0x0655CFA0
From: Joe Marshall
Subject: Re: Implementation Favoritism, a question of Lisp mindsets
Date:
Message-ID: <ade9h08q.fsf@ccs.neu.edu>
Mark Conrad <······@iam.invalid> writes:
> Here is my problem with that, perhaps you can enlighten me as to the
> correct terminology?
>
> If I create a closure function this way:
>
> (define-symbol-macro x 2)
>
> ? x
> 2
Woah, leave symbol macros out of it. What that says is that BEFORE
any evaluation happens, textually substitute a 2 for X.
> (defun test () x))
>
The compiler treats this *exactly* as if you typed:
(defun test () 2)
> We know that running the closure function (test) will return 2
>
> ? (test)
> 2
Yes. Note that there is no closure here, you simply defined a
function that returns the constant 2.
> Now x is "toplevel", I assume
>
> ? x
> 2
Before X is evaluated, it is macro-expanded to be the literal number
2.
> x is obviously a lexically scoped variable, because if we change its
> value then there is no effect on our closure function "test"
> - a dynamically scoped variable _would_ have an effect on (test) -
X is not a variable at all. It is an identifier that macro-expands
into the number 2.
> (define-symbol-macro x 'foo)
>
> ? x
> FOO
You have now changed the macro such that the identifier X will expand
into (QUOTE FOO)
> ? (test)
> 2
But this function has already been expanded and compiled. You
wouldn't expect it to change.
In article <············@ccs.neu.edu>, Joe Marshall <···@ccs.neu.edu>
wrote:
> Woah, leave symbol macros out of it. What that says is that BEFORE
> any evaluation happens, textually substitute a 2 for X.
Okay, I got several posts that enlighted me about what
"define-symbol-macro" could and could-not do.
This NG is great. The people here bring out points about CL that are
not at all apparent from reading CL books!
Mark-
On 8363 day of my life Mark Conrad wrote:
>
> If I create a closure function this way:
>
> (define-symbol-macro x 2)
>
> ? x
> 2
>
> (defun test () x))
>
> x is obviously a lexically scoped variable,
[1]> (define-symbol-macro x 2)
X
[2]> (boundp x)
*** - BOUNDP: 2 is not a symbol
Funny ;)
--
Ivan Boldyrev
"Assembly of Japanese bicycle require great peace of mind."
Ivan Boldyrev wrote:
> On 8363 day of my life Mark Conrad wrote:
>>
>> If I create a closure function this way:
>>
>> (define-symbol-macro x 2)
>>
>> ? x
>> 2
>>
>> (defun test () x))
>>
>
>> x is obviously a lexically scoped variable,
>
> [1]> (define-symbol-macro x 2)
> X
> [2]> (boundp x)
>
> *** - BOUNDP: 2 is not a symbol
>
> Funny ;)
Not really. First, BOUNDP expects a symbol, not a variable:
[1]> (let ((x 2)) (boundp x))
*** - BOUNDP: 2 is not a symbol
Next, BOUNDP, being an ordinary function, doesn't know about lexical
bindings:
[2]> (let ((x 2)) (boundp 'x))
NIL
Finally, clisp's BOUNDP (or perhaps DEFINE-SYMBOL-MACRO) seems to be
broken:
[3]> (define-symbol-macro x 2)
X
[4]> (boundp 'x)
T
Jeremy.
Matthew Danish wrote:
> On Tue, Apr 15, 2003 at 08:53:38PM +0200, M H wrote:
>
>>Name one CL book, targeted towards beginners, which resembles SICP in
>>how it teaches "how to think functionally". I know Graham's and
>>Norvig's books and I think they are outstanding. But they do not
>>explain how to work with functions returning functions and taking
>>functions as arguments. To beginners, these things are difficult to
>>grasp (not to speak about students who have already touched C or
>>Java).
>
> I don't have Graham's book on hand, but I do know that Norvig's book is
> not entirely devoid of functional programming techniques
I never claimed that either book is "entirely devoid of functional
programming techniques".
> (and even implements call/cc).
> However, you are making a mistake. You are
> assuming that ``thinking functionally'' is overwhelmingly important. A
> great thing about PAIP is that it covers many different ways of
> thinking. With *Lisp*, functional programming is not so important that
> it should trump all other paradigms. This is a Lisp group, and the OP
> asked about Lisp programming, so I think it's fair to say that FP is not
> held as the One True Way here.
I never claimed that functional programming was the only true way.
But: If you teach Lisp without stressing its functional aspects you will
end up having students program C in Lisp syntax, _heavily_ complaining
how complicated and ugly this is.
> So basically, we're going to have another 350 students who think that
> Scheme is Lisp and that you can only use recursion and lists. And Lisp
> is interpreted only.
They know that Scheme is _a_ Lisp. They built their own do-statement,
and they examined a simple closure-based OOP system. They know about
Scheme compilers and have been pointed to CMUCL. What point are you
trying to make?
> I really don't see any reason why you wouldn't want to use your delivery
> language for learning purposes.
The delivery languages for most of our students ultimately are Java and
C++. We found it hard to teach certain computer science concepts using
these languages. But of course, yes, it can be done. You can teach
programming and CS using almost any programming language. Depending on
a lot of factors it will be easier or harder.
If someone wants to learn Lisp because of a specific job or project in
mind where CL is involved I would also recommend to go for it directly.
The original poster just asked about learning Lisp. In my mind Lisp
is more than only CL, and I recommended an environment which I found
useful for beginners. That's all.
Matthias
From: Paul F. Dietz
Subject: Re: Implementation Favoritism, a question of Lisp mindsets
Date:
Message-ID: <bf6dnUPfAcP5oACjXTWcpw@dls.net>
M H wrote:
> But: If you teach Lisp without stressing its functional aspects you will
> end up having students program C in Lisp syntax, _heavily_ complaining
> how complicated and ugly this is.
I would much, MUCH rather have this than the opposite: the student developing
a nervous tick where all loops have to be expressed as recursive function
calls (that is, as if with gotos, but less understandably) and higher order
functions are used just for the sake of being functional. I've seen too
much of this from the Scheme-initiated.
A true appreciation of lisp also requires, IMO, study of actual real lisp
programs, not just toy examples.
Paul
Paul F. Dietz wrote:
> M H wrote:
>
>> But: If you teach Lisp without stressing its functional aspects you
>> will end up having students program C in Lisp syntax, _heavily_
>> complaining how complicated and ugly this is.
>
> I would much, MUCH rather have this than the opposite:
I do not want frustrated students.
> the student developing
> a nervous tick where all loops have to be expressed as recursive function
> calls (that is, as if with gotos, but less understandably) and higher order
> functions are used just for the sake of being functional. I've seen too
> much of this from the Scheme-initiated.
You won't see this from my students, though. :-)
> A true appreciation of lisp also requires, IMO, study of actual real lisp
> programs, not just toy examples.
Agreed. But my goal was to teach computer science to first year
students. Lisp was just the means, not the goal. Scheme worked well in
that most students now understand important key concepts of programming.
Which language they choose later for their projects and their job is
their thing. They know that they don't know everything yet to be a good
computer scientist or programmer.
Matthias
From: Kenny Tilton
Subject: Re: Implementation Favoritism, a question of Lisp mindsets
Date:
Message-ID: <3E9C7F42.5060603@nyc.rr.com>
M H wrote:
> [CL books] do not
> explain how to work with functions returning functions and taking
> functions as arguments.
Really? Not Graham? Hard to believe. Anyway...
> To beginners, these things are difficult to
> grasp (not to speak about students who have already touched C or Java).
>
> Background: At my university we just switched from Java to Scheme to
> teach computer science fundamentals to about 350 first-year students...
Nothing wrong with that, but the OP mentioned:
Andrew Burton wrote:
> I've used clisp, scsh, MIT Scheme,
> and I've even tinkered with Emacs Lisp and Dr. Scheme a little bit. In playing
> with these different Lisps, I can see the similarities, and I can see the
> differences.
This guy does not need training wheels and/or hand-holding.
Give him CL, the CLHS, and one of the CL books with a pedagogical bent
and get out of his way.
Andrew, go with the Real Deal, Common Lisp. The shortest distance
between two points and all that.
--
kenny tilton
clinisys, inc
http://www.tilton-technology.com/
---------------------------------------------------------------
"Everything is a cell." -- Alan Kay
From: Tim Bradshaw
Subject: Re: Implementation Favoritism, a question of Lisp mindsets
Date:
Message-ID: <ey3ptnnmn9q.fsf@cley.com>
* M H wrote:
> Name one CL book, targeted towards beginners, which resembles SICP in
> how it teaches "how to think functionally". I know Graham's and
> Norvig's books and I think they are outstanding. But they do not
> explain how to work with functions returning functions and taking
> functions as arguments. To beginners, these things are difficult to
> grasp (not to speak about students who have already touched C or Java).
You're making the mistake of assuming CL people think this is a
crucial skill. They don't, or at least not compared with the damage
done by the appalling theoretical-CS mindset often caused by exposure
to Scheme too early.
--tim
In article <·····················@lain.cheme.cmu.edu>, Matthew Danish
<·······@andrew.cmu.edu> wrote:
> Scheme's "simplicity" does not in any way aid the learning process, and
> it only discourages potential future Lispers. The several good books
> that use Scheme can easily be paralleled with CL.
Disclaimer:
1) I am a Lisp newbie (with both CL and Scheme) - so please forgive me
if what I post here might not be correct.
2) I have no axe to grind about either CL or Scheme, although I prefer
CL because it has much more stuff "included" as an intregal part of the
language.
3) I really hope this post of mine does not confuse the original poster
as to whether CL or Scheme is the "better" Lisp for initial learning.
All that said, I have a question about this part of your post, namely:
> The several good books that use Scheme can easily be paralleled with CL.
Consider two "hairy" Scheme books:
Essentials of Programming Languages
- - and - -
Scheme and the Art of Programming
It seems to me that CL would have an extremely difficult if not
impossible task of doing some of the things described in those two
books, especially the code relating to "continuations".
As I recall, in Scheme, continuations are "first class" objects, which
means among other things that they can be "returned" as the returned
value of a function.
I don't think this is possible in CL, because in CL continuations are
not first-class objects, are they?
Just a dumb newbie question :)
Mark-
"Matthew Danish" <·······@andrew.cmu.edu> wrote in message
··························@lain.cheme.cmu.edu...
> On Tue, Apr 15, 2003 at 09:59:05AM +0200, M H wrote:
> > Andrew Burton wrote:
> >
> > > So what
> > > I'm doing now, playing with as many dialects (which, I agree is a god
word), is
> > > prebably a more comman, generally accepted means of learning Lisp?
> >
> > If you want to learn how to program Lisp, I would recommend against this
> > strategy. Choose _one_ platform and learn this one properly. Then look
> > around and broaden your view (this will be easy once you understand the
> > fundamentals).
>
> This I agree with.
>
> > For a first Lisp-experience I would go for the Scheme-dialect of Lisp
> > (you mentioned Dr.Scheme which is a good platform for learning). There
> > is good literature on the web (Abelson & Sussman: "Structure and
> > Interpretation of Computer Programs", Felleisen et al. "How to design
> > programs") and this dialect is smaller than, e.g., Common Lisp.
>
> Why? I've found every Scheme environment I've tried--including
> DrScheme--to be lacking in comparison to the CL environments.
Would you care to give some concrete examples?
···········@aol.commune (Andrew Burton) writes:
> I'm not sure how to ask this, so I want to preface this by saying I'm not try
> start a language war. This is a question I had this weekend, and wanted to ask
> as part of my "trying to understand the Lisp mentality."
>
> Lately I've been trying to play with various (free) Lisp implementations just
> to get the feel of the overall language. I've used clisp, scsh, MIT Scheme,
> and I've even tinkered with Emacs Lisp and Dr. Scheme a little bit. In playing
> with these different Lisps, I can see the similarities, and I can see the
> differences. Now, I'm no where close to being anything but a hobbyist with it
> so far, but I'm worndering: when one gets to the point that one can program
> marvelous software with a specific implementation, does one kind of focus on
> that specific implementation? I mean, do Lisp hackers generally focus on
> learning one implementation, or is it better to kind of learn them at a
> paralell pace?
There is a difference between different "dialects" of Lisp, and
different implementations of one dialect. For example, Common Lisp is
a programming language distinct from Emacs Lisp and Scheme, while
CLISP, CMUCL and LispWorks are implementations of Common Lisp.
I'd say the different dialects are roughly about as far away from each
other as C and Java are - it is possible to learn how to write code
that works quite quickly in any of the dialects if you already know
one of them, but it may take some time until you know common idioms of
the dialect, and can write code that is actually beautiful. There is a
lot of similarity, but the mindsets differ significantly.
On the other hand, switching from one implementation of Common Lisp
to another one isn't really hard. Sure, the environment may be a
little different, non-standard extensions like for networking or
threads are notoriously incompatible, the performance characteristics
differ, but these are details.
> I'm wondering -- and again, this isn't trying to say one is better than the
> other -- should set MIT Scheme, Emacs Lisp, and such aside until I get better
> at clisp? Or should I continue working with each one as I have been? What do
> most Lisp hackers do? Any opinions are welcome. Thanks.
My impression is that most people more or less focus on one dialect,
probably mostly because they are good at different things and it is
hard to find someone who is interested in all of them. So the question
really is, what do you want to do with Lisp?
Regards
Henrik
BTW: This newsgroups is almost exclusively populated with users of
Common Lisp. You might want to ask in comp.lang.scheme and the various
*.emacs.* groups for opinions of Schemers and Elisp fans.
> So the question really is, what do you
> want to do with Lisp?
I have no idea really, aside from learning Lisp. Not to sound silly, but I
find the syntax very relaxing. Right now it's sort of an off-shoot of my
Spreadsheet fascination -- Lisp being much more powerful than a Spreadsheet and
friendlier at handling algorithms.
> You might want to ask in
> comp.lang.scheme and the various
> *.emacs.* groups for opinions of
> Schemers and Elisp fans.
Duly noted! The ANSI Common Lisp, clisp, was the first Lisp I played with, so
this was the only one, so far, I've subscribed to. Thanks. :)
Andrew Burton -- tuglyraisin at aol dot com
Felecia Station on Harvestgain
Jipi: Don't Believe everything the Net tell you.
Chip: I agree with this. My inputs are not to be trusted.
CROW: Quick, save the Robot Ashley!
···········@aol.commune (Andrew Burton) writes:
> The ANSI Common Lisp, clisp
Note that clisp is only one implementation of common lisp.
Regards,
Mario
On 8349 day of my life Mario S. Mommer wrote:
> ···········@aol.commune (Andrew Burton) writes:
> > The ANSI Common Lisp, clisp
>
> Note that clisp is only one implementation of common lisp.
Do you mean "is not only one"?
--
Ivan Boldyrev
PGP fp: 3640 E637 EE3D AA51 A59F 3306 A5BD D198 5609 8673 ID 56098673
Today is the first day of the rest of your life.
Ivan Boldyrev <···············@cgitftp.uiggm.nsc.ru> writes:
> On 8349 day of my life Mario S. Mommer wrote:
>> ···········@aol.commune (Andrew Burton) writes:
>> > The ANSI Common Lisp, clisp
>>
>> Note that clisp is only one implementation of common lisp.
>
> Do you mean "is not only one"?
"clisp" is usually a reference to the Common Lisp implementation
called "GNU CLISP", available from http://clisp.cons.org/ or
http://clisp.sf.net/
Overlaoding the term to refer to Common Lisp in general strikes me as
a bad idea, liable to lead to confusion, especially when "CL" already
does quite nicely in that latter role.
-dan
--
http://www.cliki.net/ - Link farm for free CL-on-Unix resources
On 8352 day of my life Daniel Barlow wrote:
> Ivan Boldyrev <···············@cgitftp.uiggm.nsc.ru> writes:
>
> > On 8349 day of my life Mario S. Mommer wrote:
> >> ···········@aol.commune (Andrew Burton) writes:
> >> > The ANSI Common Lisp, clisp
> >>
> >> Note that clisp is only one implementation of common lisp.
> >
> > Do you mean "is not only one"?
>
> "clisp" is usually a reference to the Common Lisp implementation
> called "GNU CLISP", available from http://clisp.cons.org/ or
First time I downloaded it 3 years ago :)
> Overlaoding the term to refer to Common Lisp in general strikes me as
> a bad idea, liable to lead to confusion, especially when "CL" already
> does quite nicely in that latter role.
Prbably, my English teacher will give me bad mark :)
"clisp is not only one implementation of Common Lisp" means "There are
lot of other implementations of Common Lisp standard", doesn't it?
And "clisp is only one implementation of Common Lisp" is "There are no
other implemntations". Or?
--
Ivan Boldyrev
PGP fp: 3640 E637 EE3D AA51 A59F 3306 A5BD D198 5609 8673 ID 56098673
Perl is a language where 2 x 2 is not equal to 4.
In article <·············@elaleph.borges.cgitftp.uiggm.nsc.ru>, Ivan
Boldyrev <···············@cgitftp.uiggm.nsc.ru> wrote:
> "clisp is not only one implementation of Common Lisp" means "There are
> lot of other implementations of Common Lisp standard", doesn't it?
No, but you can hardly be blamed for not knowing this. The word pair "not
only" is an idiom with very subtle shades of meaning and rules for usage.
In colloquial English, "X is not only Y" is usually used as an
introductory phrase in a sentence like: "X is not only Y, but also Z."
The meaning is: X has property Y, and furthermore it also has property Z.
Example: "The Pacific Ocean is not only the largest ocean on the planet,
but it is also the deepest." Saying "X is not only Y" by itself just
sounds weird.
You can also rearrange things thusly: "Not only is the Pacific the larges
ocean in the world, it is also the deepest."
By contrast, saying "X is not *the* only Y" is OK as a standalone
sentence, and it means that X has property Y, but other things also have
property Y.
> And "clisp is only one implementation of Common Lisp" is "There are no
> other implemntations". Or?
You need the "the" there. "CLisp is not *the* only implementation of
Common Lisp" or "CLisp is the only implementation of Common Lisp."
(If you want to get really fancy you can say something like: "Not only is
CLisp not the only implementation of Common Lisp, it is even not the only
free implementation." Meaning: Clisp is an implementation of Common Lisp,
it is free, and there other free implementations besides Clisp. All of
which happens coincidentally to be true.)
I don't know Russian, but I notice that Russians speaking English tend to
leave out articles ("a" and "the") as in:
> Prbably, my English teacher will give me bad mark :)
You should say "... will give me *a* bad mark." Then you will get a good
mark. :-)
This is not a universal rule in English. The French, for example, seem to
make the opposite mistake, putting in articles where they are not needed,
e.g.:
"My English teacher will give me the grief". This sounds weird. It
should be "My English teacher will give me grief."
I'm note sure if there's a rule to decide when articles are needed and
when they are not. English is the C++ of natural languges. There are
many pitfalls, and you just have to remember them all.
The world would be a better place if everyone spoke Esperanto. (Actually,
getting the world to use Esperanto is not so very different from getting
the world to use Lisp.)
E.
From: Nils Goesche
Subject: Re: Implementation Favoritism, a question of Lisp mindsets
Date:
Message-ID: <87he8vjx2l.fsf@darkstar.cartan>
···@jpl.nasa.gov (Erann Gat) writes:
> "My English teacher will give me the grief". This sounds
> weird. It should be "My English teacher will give me grief."
Beware: You are creating lots of people who'll say ``My English
teacher gives me creeps��
;-)
I gave up long ago -- it is absolutely impossible to understand
the grammar of the English language. Not that German were any
easier. Or Russian, for that matter.
> The world would be a better place if everyone spoke Esperanto.
> (Actually, getting the world to use Esperanto is not so very
> different from getting the world to use Lisp.)
Nah -- it is all those inconsistencies that make poetry possible
at all.
Regards,
--
Nils G�sche
Ask not for whom the <CONTROL-G> tolls.
PGP key ID #xD26EF2A0
Erann Gat wrote:
> The world would be a better place if everyone spoke Esperanto. (Actually,
> getting the world to use Esperanto is not so very different from getting
> the world to use Lisp.)
>
> E.
Glosa is better than Esperanto. It is a "language [almost] without
grammar." It is based on a very simple grammar, approaching
pidgin-languages and oriental languages, and wholly based on Greek and
Latin roots. It's very rational. For example, to say "I'll go" you say
"Mi fu ki" - fu = future particle; ki = kinesys. I went: "Mi pa ki."
http://www.glosa.org/
"U prima elektronika digita puta-me[for any thing "machine": typo-me =
"typewriter"], ge-tekto in US, ENIAK, pa gene ge-monstro a Pennsylvania
Universita 1946. Id pa ponde plu 30 tone, pa ple u space de u bi-vagona
garage, e pa kontena plu 18 000 vakuo tuba; qi pa fali medio ad u rata
mo singu septi minuta. Id pa kosto u semi-miliona dolar a 1946 preci."
"The first electronic digital computer built in the US, ENIAC, was
unveiled at the University of Pennsylvania in 1946. It weighed 300
tonnes, filled the space of a two-car garage, and contained 18 000
vacuum tubes, which failed on average at the rate of one every seven
minutes. It cost half a million dollars at 1946 prices."
(Ronald Clark, � GEO, 1988)
I like it better than any other "auxiliary (or "artifical") language"
I've seen (Esperanto, Interlingua, and I forgot the other). But since my
native language is Portuguese, I'm biased towards the Roman and Greek
word roots. But the rationale for including then in Glosa is that
they're widespread in the scientific literature.
Portuguese, by the way, is extremely rich in what grammars call verbal
"aspects", more so than other neo-roman languages, being quite good at
expressing temporal subleties in verbal conjugation.
Human languages are an interesting topic. Claude L�vi-Strauss was the
first (he was an anthropologist) to demonstrate that you have to be
carefull to judge human groups as "primitive", since they may have
developed "systems" that are very complex. The Yanomami language, for
instance, has one of the most complex verbal declension amongst all,
taking well over a decade to master, even harder than Turkish.
/Extremely/ off-topic, I apologize for that. :-)
Cheers
Henry Lenzi
In article <·············@elaleph.borges.cgitftp.uiggm.nsc.ru>, Ivan
Boldyrev wrote:
> "clisp is not only one implementation of Common Lisp" means "There are
> lot of other implementations of Common Lisp standard", doesn't it?
Preferable:
"clisp is not the only implementation of Common Lisp."
> And "clisp is only one implementation of Common Lisp" is "There are no
> other implemntations". Or?
Actually, it implies "one of many" as in:
"clisp is only one of many implementations of Common Lisp."
Your interpretation would be more correct for:
"clisp is the only implementation of Common Lisp."
Zach
From: Kenny Tilton
Subject: Re: Implementation Favoritism, a question of Lisp mindsets
Date:
Message-ID: <3EA0777B.6060208@nyc.rr.com>
Ivan Boldyrev wrote:
> Prbably, my English teacher will give me bad mark :)
>
> "clisp is not only one implementation of Common Lisp" means "There are
> lot of other implementations of Common Lisp standard", doesn't it?
> And "clisp is only one implementation of Common Lisp" is "There are no
> other implemntations". Or?
>
The phrase you are thinking of (and having bad luck mutating) is "the
only one":
"There are many languages, but Lisp is the only one I want to use."
"one" there refers to one member of a collection established earlier
(languages). Less flamboyantly:
"Lisp is the only language I want to use."
"language" is directly paired with "only", so the indirect reference to
some collection (not!) specified earlier has no place.
Note that the collection can be implicit:
"I am not the only one who likes Lisp."
--
kenny tilton
clinisys, inc
http://www.tilton-technology.com/
---------------------------------------------------------------
"Everything is a cell." -- Alan Kay
>> The ANSI Common Lisp, clisp
> Note that clisp is only one
> implementation of common lisp.
This was actually my eyes and my brain having a fight. When I got home that
night I made them sit down, talk it out, and they had great make up synapses.
;;
(defun (very) (list (format t "very~%") (very)))
;;
I saw a link to a page about "The ANSI Common Lisp" or something at
clisp.cons.org and thought it was "The ANSI Common Lisp." Suffice to say I was
(very) wrong in what I read.
Andrew Burton -- tuglyraisin at aol dot com
Felecia Station on Harvestgain
Jipi: Don't Believe everything the Net tell you.
Chip: I agree with this. My inputs are not to be trusted.
CROW: Quick, save the Robot Ashley!
"Andrew Burton" <···········@aol.commune> wrote in message
··································@mb-fc.aol.com...
> I'm wondering -- and again, this isn't trying to say one is better than
the
> other -- should set MIT Scheme, Emacs Lisp, and such aside until I get
better
> at clisp? Or should I continue working with each one as I have been?
What do
> most Lisp hackers do? Any opinions are welcome. Thanks.
I agree with the others in that you should really focus on one system, that
way you learn the important details of the language rather than the
important details of porting software across different implementations. The
former is much more useful.
If you're comfortable with EMACS, then learning EMACS Lisp is an interesting
exercise because the EMACS Lisp environment is pretty good, and you don't
have to set anything up or download and configure a bunch of different
things. The other nice advantage is that you have a reasonably simple
environment to do Interesting Things with your code. You don't necessarily
need to contrive applications to create, rather you can make stuff you need
in your everyday "real" world outside of your Lisp hobby. If you want to
learn a language, you need to apply it, preferably in "real time" on "real
projects" where you have to just Get It Done and then you can come back and
do a post mortem to make it better. Writing extesions and utilities in EMACS
that can support your real work (assuming you use EMACS daily anyway) is a
great breeding ground for Real World things to do.
The dark side of EMACS Lisp is that it's an old dialect. So you end up
learning idioms and techniques that were important back in the late '70's,
but less relevant today with modern CL systems.
On the other hand, as another poster mentioned, personal Lispworks is really
an incredible value for most folks trying to learn the language. It's a
fully complete and modern system with good support of the things like CLOS.
It has GUI bits, network bits, and multiprocessing bits. It's a double-click
install which makes it easy to get into quickly, with minimal frustrations,
and it's editor is EMACS enough where you don't have to learn a whole new
system just to get your text saved.
Regards,
Will Hartung
(·····@msoft.com)