After many years of absence, I am rediscovering CL. When I did play
with Lisp back in the early 90's, it was strictly as a newbie.
I have no interest in becoming productive, just wanna have fun.
Among other shiny ornaments on the Common-Lisp tree, there are
"continuations", thanks to Paul Graham and his older book. (the entire
book is available free, online, name is "On Lisp")
THE FOLLOWING CODE WON'T WORK UNLESS PAUL GRAHAM'S MACROS ARE LOADED
FIRST - - -
Anyone interested in playing with this, let me know and I will post the
macros and a bit of other code along with them.
Anyhow -
Assume we have a simple 'progn' form:
(progn
(print 'first)
(print 'second)
(print 'third)
(print 'fourth)
(print 'fifth)
nil)
...and we want to create a continuation in it.
(progn
(print 'first)
(print 'second)
<== create a contin' here
(print 'third)
(print 'fourth)
(print 'fifth)
nil)
Now once our continuation is wedged in there, we are empowered to jump
out of our 'progn' form any time we want to.
If we want to come back to the progn form later and finish up what it
does, fine and dandy.
If we don't want to ever come back, that is also fine and dandy.
Okay, let's jam our continuation in:
(progn
(print 'first)
(print 'second)
(=bind () (=values)
(setq k #'(lambda ()
(print 'third)
(print 'fourth)
(print 'fifth)
nil) )))
Now when we run our simple progn form, it displays:
FIRST
SECOND
#<Anonymous Function #x1EC0ACBE>
Okay, the jump-out part works, now let's *use* the continuation we
created to "continue" the interupted progn-form.
(progn
(print 'first)
(print 'second)
(=bind () (=values)
(setq k #'(lambda ()
(print 'third)
(print 'fourth)
(print 'fifth)
nil) ))
(funcall k) )
Running the above progn form displays:
FIRST
SECOND
THIRD
FOURTH
FIFTH
NIL
Okay, we have our simple progn form 'spiked' with a continuation, so
now we can jump in and out of the progn form at will, anytime we want
to do so.
Here we do just that. Randomly, according to the "if" section of code,
we *might* jump out of the progn form after it prints FIRST, SECOND
and go to a function named "elsewhere". It takes 'elsewhere' about two
seconds to finish running, and elsewhere's last act is to use our
continuation to kick control back to our humble 'progn' form whereupon
the 'progn' form "continues" from where it was interupted, printing
THIRD, FOURTH, FIFTH.
(progn
(print 'first)
(print 'second)
(=bind () (=values)
(setq k #'(lambda ()
(print 'third)
(print 'fourth)
(print 'fifth)
nil) ))
(if (= (random 2) 0)
(elsewhere)
(funcall k) ))
Mark-
I was intrested in learning about A.I.
I learned about Lisp because most A.I. programs were
written in Lisp. I than came to love Lisp as a language
coming from Basic I picked it up rather quick.
When I stated learning C at my Community College I realized how
lucky I was for choosing Lisp.
I could do a lot in Lisp that I couldn't even approch in C--when I
tried to rewrite some applications I've written in Lisp into C to
learn that language I realized that one line of Lisp code usually
required several lines of C code--then I realized why the people who
do A.I. choose Lisp--it's easier to use for the harder problems. And, it's
easier to extend.
In article <···················@news02.roc.ny.frontiernet.net>, Franz
Kafka < @> wrote:
> When I stated learning C at my Community College I realized how
> lucky I was for choosing Lisp.
>
> I could do a lot in Lisp that I couldn't even approch in C--when I
> tried to rewrite some applications I've written in Lisp into C to
> learn that language I realized that one line of Lisp code usually
> required several lines of C code--then I realized why the people who
> do A.I. choose Lisp--it's easier to use for the harder problems. And, it's
> easier to extend.
Yes, I agree.
A lot of AI problems are very complex in nature.
With Lisp, a person has the freedom to to make a program in "layers".
The top-layer of a complex Lisp program can look almost trivial in
nature, making it very easy to "follow-the-flow" of logic in one's own
program.
One can't appreciate how important this is, until one has gotten "lost"
in one's own program code, as the complexity of the program builds up
and overwhelms the programmer.
That is one reason why tools like "continuations" have to be used with
extreme care, because they aggravate the perceived-complexity of Lisp
code, making it hard to follow-the-flow of cracking a problem.
Mark-
In article <·························@iam.invalid>, Mark Conrad
<······@iam.invalid> wrote:
> Anyone interested in playing with this, let me know and I will post the
> macros and a bit of other code along with them.
Here are Paul Graham's six macros from his "On Lisp" book.
Copy and paste *everything* from between the asterisk lines to your
own file. This code is necessary to be loaded into Lisp _before_
the examples in this thread will run.
;****************************************
(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)
;; Below are Paul Graham's six macros. About the only changes
;; that I made were to change his "*cont*" to "%cont%", in order
;; to emphasize that %cont% is not a dynamically-scoped
;; variable.
;;
;; Another change I made was to use "=setq" to ensure that %cont%
;; does not act like a dynamically-scoped variable.
;;
;; =setq is just a convenient shorter abbreviation for CL's built-in
;; macro named "define-symbol-macro"
(=setq
%cont%
#'(lambda (&rest args)
(if (cdr args)
args
(car args) )))
(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))
;*******************************************
;; End of Paul Graham's six macros from his "On Lisp" book.
Mark-
From: Joe Marshall
Subject: Re: Recreational Common Lisp :)
Date:
Message-ID: <8ytjddkd.fsf@ccs.neu.edu>
Mark Conrad <······@iam.invalid> writes:
> ;; Below are Paul Graham's six macros. About the only changes
> ;; that I made were to change his "*cont*" to "%cont%", in order
> ;; to emphasize that %cont% is not a dynamically-scoped
> ;; variable.
> ;;
> ;; Another change I made was to use "=setq" to ensure that %cont%
> ;; does not act like a dynamically-scoped variable.
Well.... it definitely won't behave like a dynamically scoped
variable, but it won't behave quite like a lexically scoped one,
either. You will have some strange behavior in the edge cases.
Since what you want is a `top-level' value for %cont% in those cases
where it is not lexically bound, your best bet is to set the
symbol-value.
(eval-when (:load-toplevel :execute)
(setf (symbol-value '%cont%)
(lambda (&rest args)
(if (cdr args)
args
(car args)))))
> (=setq
> %cont%
> #'(lambda (&rest args)
> (if (cdr args)
> args
> (car args) )))
>
> (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))
>
> ;*******************************************
> ;; End of Paul Graham's six macros from his "On Lisp" book.
>
>
> Mark-
In article <············@ccs.neu.edu>, Joe Marshall <···@ccs.neu.edu>
wrote:
> > ;; Another change I made was to use "=setq" to ensure that %cont%
> > ;; does not act like a dynamically-scoped variable.
>
> Well.... it definitely won't behave like a dynamically scoped
> variable, but it won't behave quite like a lexically scoped one,
> either. You will have some strange behavior in the edge cases.
>
> Since what you want is a `top-level' value for %cont% in those cases
> where it is not lexically bound, your best bet is to set the
> symbol-value.
>
> (eval-when (:load-toplevel :execute)
> (setf (symbol-value '%cont%)
> (lambda (&rest args)
> (if (cdr args)
> args
> (car args)))))
Thanks, I wish I knew what I am doing with this stuff, instead of
groping around in the dark.
What I am primarily worried about is the fact that the HyperSpec does
not spell out how to handle top level variable-binding.
(am I correct in this assumption?)
If a CL implementor decides to make all his top level variables have
dynamic scope, the HyperSpec might not stop him. That would "break"
Paul Graham's six macros.
Wow! - I just skim-read the definition of eval-when in CLtL2.
They were not kidding about "Its uses are relatively esoteric".
I will have to re-read that definition at least ten times before it
even begins to make sense to me!
I think the best way I can appreciate what eval-when does is to create
a program where a continuation "relies" on the value of %cont% as being
the initial defined value of %cont%.
I assume my present initial-defined-value of %cont% might "break" in
such cases, whereas the eval-when version would be less likely to
break.
Mark-
In article <············@ccs.neu.edu>, Joe Marshall <···@ccs.neu.edu>
wrote:
> You will have some strange behavior in the edge cases.
AAARG !!! - I already ran into a lot of those "edge cases" :-(
Your "eval-when" suggestion really came to my rescue.
Now code works as I want it to work, with eval-when in the act.
Here is the transcript as to how things stand now.
Welcome to the demo version of Macintosh Common Lisp Version 4.3!
? (define-symbol-macro %cont% 'foo)
%CONT%
? %cont%
FOO
? (eval-when (:load-toplevel :execute)
(setf (symbol-value '%cont%)
(lambda (&rest args)
(if (cdr args)
args
(car args)) )))
#<Anonymous Function #x1EFB8686>
? (let () (defun test () (print %cont%)))
TEST
? (test)
FOO
FOO
? %cont%
FOO
? (unintern '%cont%)
T
? (test)
FOO
FOO
?
? %cont%
> Error: Unbound variable: %CONT%
> While executing: "Unknown"
> Type Command-/ to continue, Command-. to abort.
> If continued: Retry getting the value of %CONT%.
That error message is as it should be, after the unintern.
Thanks again for the eval-when suggestion.
Mark-
Mark Conrad <······@iam.invalid> writes:
> ? (eval-when (:load-toplevel :execute)
> (setf (symbol-value '%cont%)
> (lambda (&rest args)
> (if (cdr args)
> args
> (car args)) )))
I do not have the slightest idea what you are trying to do here,
but I seem to remember that I told you quite a while ago that if
you simply do
(define-symbol-macro *cont* #'identity)
instead of the global setq, Graham's continuation macros will
work just fine.
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:
> > ? (eval-when (:load-toplevel :execute)
> > (setf (symbol-value '%cont%)
> > (lambda (&rest args)
> > (if (cdr args)
> > args
> > (car args)) )))
>
> I do not have the slightest idea what you are trying to do here,
> but I seem to remember that I told you quite a while ago that if
> you simply do
>
> (define-symbol-macro *cont* #'identity)
>
> instead of the global setq, Graham's continuation macros will
> work just fine.
Hi Nils, thanks for the post, I can use all the help I can get :)
Joe Marshall and myself were thrashing out a situation that occurs when
a continuation tries to go all the way to toplevel and terminate the
entire program.
As you know, seldom are continuations used in that fashion, usually
they just hop around inside the program.
For that matter, a standard "throw" would get us to toplevel and
program-termination if that was really what we wanted to do.
Also, if I wanted to, I could setq the initial global value of
"*cont*" (or %cont% ) to 'foo instead of "#'identity" and Paul's
macros would still work as advertised, except in the case that I
refered to above. (a very unlikely special case)
There is also a nasty side issue here. The HyperSpec does not "forbid"
a CL implementor from causing all his toplevel variables to be special
variables, which would definately break Paul's macros.
So far, no CL implementations do that nasty trick, but what is to stop
them - nothing in the HyperSpec that I am aware of would stop them.
BTW, the business of departing from #'identity is Paul's code at the
bottom of page 395 of his "On Lisp" book, very handy whenever one wants
to return multiple values to toplevel when terminating the program.
Hope this explains what is going on -
Mark-
Mark Conrad <······@iam.invalid> writes:
> In article <··············@darkstar.cartan>, Nils Goesche
> <···@cartan.de> wrote:
>
> > > ? (eval-when (:load-toplevel :execute)
> > > (setf (symbol-value '%cont%)
> > > (lambda (&rest args)
> > > (if (cdr args)
> > > args
> > > (car args)) )))
> >
> > I do not have the slightest idea what you are trying to do here,
> > but I seem to remember that I told you quite a while ago that if
> > you simply do
> >
> > (define-symbol-macro *cont* #'identity)
> >
> > instead of the global setq, Graham's continuation macros will
> > work just fine.
>
> Hi Nils, thanks for the post, I can use all the help I can get :)
Not that you listen.
> Also, if I wanted to, I could setq the initial global value of
> "*cont*" (or %cont% ) to 'foo instead of "#'identity" and Paul's
> macros would still work as advertised, except in the case that I
> refered to above. (a very unlikely special case)
Except that you'd be invoking undefined behavior. There is no concept
of global lexicals in CL.
> There is also a nasty side issue here. The HyperSpec does not "forbid"
> a CL implementor from causing all his toplevel variables to be special
> variables, which would definately break Paul's macros.
This is not a side issue, this is at the heart of the matter.
> So far, no CL implementations do that nasty trick, but what is to stop
> them - nothing in the HyperSpec that I am aware of would stop them.
Yes, a major CL implementation (CMUCL) does just this, although it's
*not* a nasty trick. A toplevel SETQ on a symbol that has not been
DEFVARed has no defined meaning. DEFINE-SYMBOL-MACRO was added to the
language to address *exactly* the use that Graham made of a toplevel
SETQ here.
> BTW, the business of departing from #'identity is Paul's code at the
> bottom of page 395 of his "On Lisp" book, very handy whenever one wants
> to return multiple values to toplevel when terminating the program.
>
> Hope this explains what is going on -
It sure explains that you don't pay attention to anything you don't
want to hear.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
In article <···············@conquest.OCF.Berkeley.EDU>, Thomas F.
Burdick <···@conquest.OCF.Berkeley.EDU> wrote:
> > Hi Nils, thanks for the post, I can use all the help I can get :)
>
> Not that you listen.
Oh I listen. If what you write has merit, I listen very closely.
If what you write has no merit (IMO of course), I ignore it.
> > Also, if I wanted to, I could setq the initial global value of
> > "*cont*" (or %cont% ) to 'foo instead of "#'identity" and Paul's
> > macros would still work as advertised, except in the case that I
> > refered to above. (a very unlikely special case)
>
> Except that you'd be invoking undefined behavior.
So what? If it is good enough for a CL guru like Paul Graham to use
"undefined-behavior", it is also good enough for me to do the same
thing. The only thing that concerns me whenever I use
"undefined-behavior" is the issue of whether my code will run on all
HyperSpec-compliant CL implementations.
It appears that the combination of "define-symbol-macro" and
"eval-when" will allow my continuation code to run on all compliant
implementations of CL, so what is the big deal?
> > There is also a nasty side issue here. The HyperSpec does not "forbid"
> > a CL implementor from causing all his toplevel variables to be special
> > variables, which would definately break Paul's macros.
>
> This is not a side issue, this is at the heart of the matter.
I disagree. To me, CL is a tool. As such, I use it to accomplish
results. I care less about whether the tool I am using has the
blessing of the HyperSpec, as long as that tool works with all
HyperSpec compliant CL implementations.
> There is no concept of global lexicals in CL.
That may be correct, depending on your interpretation of various
passages in the HyperSpec. If you are thinking of:
'lexical scope of a toplevel variable in the toplevel environment'
...then things start getting a little hazy.
One interpretation could be that the variable in question in the
toplevel environment is "visible" to every part of your program, except
when shadowed by a variable with the same name. If the variable in
question is not declared to have dynamic scope, then you have only one
other type of scope that the variable can have, namely lexical scope.
There are only two types of scope when writing about the "scope" of a
variable, dynamic scope or lexical scope.
Now whether the variable scope is "blessed" by the HyperSpec or whether
the scope of the variable is "undefined" is beside the point, because
the scope of a variable *still* has to be one or the other,
dynamically-scoped or lexically-scoped in so far as how it acts in your
program.
For example, in my MCL ver 4.3 all toplevel variables created by setq
act as if they are lexically-scoped throughout the program.
You say that CMUCL toplevel variables are different. That means to me
that toplevel variables in CMUCL act as if they were
dynamically-scoped.
> A toplevel SETQ on a symbol that has not been
> DEFVARed has no defined meaning.
It still has to act in the program in only one of two ways, either as
if it is dynamically-scoped or lexically-scoped.
For example, a toplevel SETQed variable in my MCL acts like it is
lexically-scoped throughout my program.
The only reason I am using "define-symbol-macro" and "eval-when" is to
ensure that my code will run properly on other CL implementations like
CMUCL for example.
> > Hope this explains what is going on -
>
> It sure explains that you don't pay attention to anything you don't
> want to hear.
Of course not, neither do you.
Mark-
On Thu, May 08, 2003 at 10:00:03AM +0000, Mark Conrad wrote:
> In article <···············@conquest.OCF.Berkeley.EDU>, Thomas F.
> Burdick <···@conquest.OCF.Berkeley.EDU> wrote:
>
> > > Hi Nils, thanks for the post, I can use all the help I can get :)
> >
> > Not that you listen.
>
> Oh I listen. If what you write has merit, I listen very closely.
>
> If what you write has no merit (IMO of course), I ignore it.
The problem is that you haven't the knowledge to judge merit yet. You have
demonstrated time and time again that you discard informative material.
> > > Also, if I wanted to, I could setq the initial global value of
> > > "*cont*" (or %cont% ) to 'foo instead of "#'identity" and Paul's
> > > macros would still work as advertised, except in the case that I
> > > refered to above. (a very unlikely special case)
> >
> > Except that you'd be invoking undefined behavior.
>
> So what? If it is good enough for a CL guru like Paul Graham to use
> "undefined-behavior", it is also good enough for me to do the same
> thing.
So if Paul Graham jumped off the Brooklyn Bridge, you would do so too?
We have already told you several times, but you never listen: Paul Graham wrote
his book just before the ANSI standard was finalized. His code therefore
reflects a slightly older style which IS NO LONGER COMPLETELY CORRECT. The
book is correct enough to be useful. But it is not the epitome of perfection.
> The only thing that concerns me whenever I use "undefined-behavior" is the
> issue of whether my code will run on all HyperSpec-compliant CL
> implementations.
If behavior is "undefined" YOU CANNOT USE IT AND GUARENTEE SIMILAR BEHAVIOR ON
ALL CONFORMING IMPLEMENTATIONS.
What you are trying to do is very similar to trying to work with the result of
dividing 1 by 0. Since you have demonstrated much ignorance, I will inform you
that the result of 1/0 is UNDEFINED.
> It appears that the combination of "define-symbol-macro" and
> "eval-when" will allow my continuation code to run on all compliant
> implementations of CL, so what is the big deal?
>
> > > There is also a nasty side issue here. The HyperSpec does not "forbid"
> > > a CL implementor from causing all his toplevel variables to be special
> > > variables, which would definately break Paul's macros.
> >
> > This is not a side issue, this is at the heart of the matter.
>
> I disagree. To me, CL is a tool. As such, I use it to accomplish
> results. I care less about whether the tool I am using has the
> blessing of the HyperSpec, as long as that tool works with all
> HyperSpec compliant CL implementations.
Are you mad? You don't care that X is false, so long as X is true. At least I
understand your world now; when you have a contradiction, you can prove
anything! Not to mention invoking religion. No wonder.
> > There is no concept of global lexicals in CL.
>
> That may be correct, depending on your interpretation of various
> passages in the HyperSpec. If you are thinking of:
>
> 'lexical scope of a toplevel variable in the toplevel environment'
>
> ...then things start getting a little hazy.
>
> One interpretation could be that the variable in question in the
> toplevel environment is "visible" to every part of your program, except
> when shadowed by a variable with the same name. If the variable in
> question is not declared to have dynamic scope, then you have only one
> other type of scope that the variable can have, namely lexical scope.
>
> There are only two types of scope when writing about the "scope" of a
> variable, dynamic scope or lexical scope.
>
> Now whether the variable scope is "blessed" by the HyperSpec or whether
> the scope of the variable is "undefined" is beside the point, because
> the scope of a variable *still* has to be one or the other,
> dynamically-scoped or lexically-scoped in so far as how it acts in your
> program.
>
> For example, in my MCL ver 4.3 all toplevel variables created by setq
> act as if they are lexically-scoped throughout the program.
>
> You say that CMUCL toplevel variables are different. That means to me
> that toplevel variables in CMUCL act as if they were
> dynamically-scoped.
The key point is not that they are some kind of "Weird scope" but that you
cannot know which kind they will be. You are also making a false assumption:
that some variable would be created at all! Who said that "undefined" means
"create a variable of arbitrary scope"?
For all you know, typing "(setq a 1)" into a freshly loaded Lisp could cause
demons to fly out of your nose!
Would you bet your life that any arbitrarily chosen CL-conforming
implementation chooses to scope said variables in a particular way, if at all?
> > > Hope this explains what is going on -
> >
> > It sure explains that you don't pay attention to anything you don't
> > want to hear.
>
> Of course not, neither do you.
What are you, some kind of paranoid lunatic? You are making a good case for
corporal punishment in schools (particularly the grade where they teach you how
to read).
Prove me wrong. Or stop making broad statements about an issue which you are
clueless about, at least in a forum that better-informed people are reading.
--
; 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
··························@mapcar.org...
>
> So if Paul Graham jumped off the Brooklyn Bridge, you would do so too?
>
> We have already told you several times, but you never listen: Paul Graham
wrote
> his book just before the ANSI standard was finalized. His code therefore
> reflects a slightly older style which IS NO LONGER COMPLETELY CORRECT.
The
> book is correct enough to be useful. But it is not the epitome of
perfection.
>
If you are writing code that is CLtL1, or CLtL2 compliant you should
advertise it as such rather than trying to do cheap hacks to make it ANSI
compliant--if you know what the code is doing and are not just blindly
following Garham you might even rewrite it to work under ANSI.
If you really feel the need you could use the #+ #- macro's to
make sure it works under most implementations. Then you would have to tell
people what Lisp's it worked under ala Screamer.
You could also write Lisp code to add the features missing from ANSI but
even that might not be portable.
If you want it to run across all ANSL compliant Lisps it's going to take
some more work that copying code from "On Lisp." + If you want it to also
work with CLtL1 & CLtL2 Lisps it will take even more work.
Peter Novig's Paradigms book gives a few examples of how much work this
could take for a simple timer function. + He has a Scheme compiler that is
written in Lisp and has call/cc BTW, I don't know if it is ANSI compliant or
not. & you can only use his call/cc with the Scheme not the Lisp--he warns
that what you are trying to do is non-trivial & requires a Code-Walker. This
must be diff. to write--I've read a lot of Lisp books and only LiSP in Small
Pieces an advanced text talks about them, and no book I've found talks about
how to write one in Lisp.
Matthew Danish <·······@andrew.cmu.edu> writes:
> For all you know, typing "(setq a 1)" into a freshly loaded Lisp could cause
> demons to fly out of your nose!
That would indeed be a most unexpected behavior. I think something
like beer or coffee would have a higher probability of flying out of
the nose, with devestating effects to a computer keyboard.
On Thu, May 08, 2003 at 07:20:57PM +0000, David Steuber wrote:
> Matthew Danish <·······@andrew.cmu.edu> writes:
>
> > For all you know, typing "(setq a 1)" into a freshly loaded Lisp could cause
> > demons to fly out of your nose!
>
> That would indeed be a most unexpected behavior. I think something
> like beer or coffee would have a higher probability of flying out of
> the nose, with devestating effects to a computer keyboard.
Hrm. Do you have any references for such a statement? Perhaps someone should
commission a study to determine for various objects the probability that they
will fly out of your nose when you invoke undefined behavior. That would
certainly clear this matter up. And on a per-implementation basis too; for
example: with CLISP, the probability of Richard Stallman emerging from your
olfactory organ is probably a great deal higher than with Allegro.
One possible drawback I could see is that there might be a call for an
extension to the CL standard for a `tissue system' by which these objects may
be caught and dealt with, and perhaps a way to resume from a sniffle.
P.S. I am sure that nasal demons, or even RMS, could cause quite a bit of
damage to your keyboard and more, depending on how they landed upon emerging
from your nose, and with how much energy they were ejected.
--
; 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> writes:
> P.S. I am sure that nasal demons, or even RMS, could cause quite a bit of
> damage to your keyboard and more, depending on how they landed upon emerging
> from your nose, and with how much energy they were ejected.
Quite true I'm sure. But I've actually had beer come out of my nose
and it wasn't pretty.
It was a nice Belgian too.
--
(describe 'describe)
David Steuber <·············@verizon.net> writes:
> Matthew Danish <·······@andrew.cmu.edu> writes:
>
> > For all you know, typing "(setq a 1)" into a freshly loaded Lisp could cause
> > demons to fly out of your nose!
>
> That would indeed be a most unexpected behavior. I think something
> like beer or coffee would have a higher probability of flying out of
> the nose, with devestating effects to a computer keyboard.
Is that a nasal daemon infestation?
Gregm
In article <·····················@mapcar.org>, Matthew Danish
<·······@andrew.cmu.edu> wrote:
> So if Paul Graham jumped off the Brooklyn Bridge, you would do so too?
Darn tootin', I would be right behind him. We would both gracefully
glide down to earth on our parafoils.
I have immense respect for whatever Paul Graham writes, with the
possible exception of some stray example code in his books.
> For all you know, typing "(setq a 1)" into a freshly loaded Lisp could
> cause demons to fly out of your nose!
That is why I always wear a nose-clip when typing "(setq a 1)".
> Prove me wrong.
Why should I bother. That is a bunch of work.
> Or stop making broad statements about an issue which you are
> clueless about, at least in a forum that better-informed people are
> reading.
I most certainly will not! Making those broad statements has a decided
benefit for me. If my statement is wrong, I get ample replies
informing me exactly how the cookie crumbles.
From those replies, I can ignore the hate mongers, and sift out
knowledge that is understandable to me.
Why should I abandon such a good learning tool.
Other Lisp newbies won't be influenced by my remarks, because I have
stated up front that I am a Lisp newbie also, many times.
My "clueless" broad remarks merely reflect the present stage of my
understanding, which is subject to daily change and improvement.
That is why I get a kick out of those guys who dig up old erroneous
remarks of mine, that I have long since rejected as wrong, in their
vain efforts to discredit me.
I just ignore them, they obviously have some sort of ego thing where
they feel the need to look clever-by-comparison to a newbie.
If you can't stand the heat in the "clueless" kitchen, stay out.
Mark-
Mark Conrad <······@iam.invalid> writes:
> In article <·····················@mapcar.org>, Matthew Danish
> <·······@andrew.cmu.edu> wrote:
> > Prove me wrong.
>
> Why should I bother. That is a bunch of work.
Because this is how discussions between *adults*
work. And yes it is a lot of work to do this,
that is how knowledge is produced.
>
>
> > Or stop making broad statements about an issue which you are
> > clueless about, at least in a forum that better-informed people are
> > reading.
>
> I most certainly will not! Making those broad statements has a decided
> benefit for me. If my statement is wrong, I get ample replies
> informing me exactly how the cookie crumbles.
You do not seem to understand that the rest of us are not here
for your pleasure. You are not the center of creation and you
should not act like it
>
> From those replies, I can ignore the hate mongers, and sift out
> knowledge that is understandable to me.
At least you admit you do not understand the correct answers
that people have posted to your questions, you only understand
the answers that agree with your preconceived ideas. This is
so stupid when you consider that even you know that you do not
know what you are talking about.
>
> Why should I abandon such a good learning tool.
Because you do not learn.
>
> Other Lisp newbies won't be influenced by my remarks, because I have
> stated up front that I am a Lisp newbie also, many times.
From your observed behavior I am leaning more towards fool.
>
> My "clueless" broad remarks merely reflect the present stage of my
> understanding, which is subject to daily change and improvement.
>
> That is why I get a kick out of those guys who dig up old erroneous
> remarks of mine, that I have long since rejected as wrong, in their
> vain efforts to discredit me.
No one is trying to discredit you, you are doing an excellent job
by your self.
>
> I just ignore them, they obviously have some sort of ego thing where
> they feel the need to look clever-by-comparison to a newbie.
Well I am beginning to think my mouse pad may be smarter then you,
just because it has never talked to me.
>
> If you can't stand the heat in the "clueless" kitchen, stay out.
Do you see what happens when Erik goes away???
marc
--
who likes his 'c' more and more
Marc Spitzer <········@optonline.net> writes:
> Do you see what happens when Erik goes away???
Yeah. As much time and effort is spent on flaming insensitive,
abusive, selfish jerks that seem unwilling to do the world a favour by
breaking both wrists and dying obscure unobserved deaths as ever was,
but now the load is spread more equitably than it used to be, and
there's no secondary "why is Erik being mean to me" thread that also
needs killing.
-dan
--
http://www.cliki.net/ - Link farm for free CL-on-Unix resources
Daniel Barlow wrote:
> Marc Spitzer <········@optonline.net> writes:
>
>
>>Do you see what happens when Erik goes away???
>
>
> Yeah. As much time and effort is spent on flaming insensitive,
> abusive, selfish jerks that seem unwilling to do the world a favour by
> breaking both wrists and dying obscure unobserved deaths as ever was,..
not. nonerikkians, upon working out that positive articles are lost on
their misbegotten correspondents, simply offer no more help. aside:
congrats to mark conrad for being harder to recognize by the CLL immune
system than many predecessor infections. what is the sound of one troll
clapping? They are gone overnight when the last CLLer (god bless their
faith in humanity and their own powers of persuasion) gives up on them.
erik, having made the same determination, spewed abuse until the idiots
worked out that only erik (the black hole into which every troll got
sucked) was ever going to respond to them. then they went away. but that
takes longer. so it is a lot more than "as much".
for those of you who like math in a dissertaion: erik got to his
conclusions much faster (without loss of accuracy) than have
nonerikkians recognized asininity, but that edge in performance is lost
many times over in the amount of time it takes for idiots to recognize
the futility of perpetuating any CLL thread.
that is the flaw in erik's strategy for driving trolls away: it relies for
its effectiveness on the wit of trolls. uh-oh...
--
kenny tilton
clinisys, inc
http://www.tilton-technology.com/
---------------------------------------------------------------
"Everything is a cell." -- Alan Kay
Kenny Tilton <·······@nyc.rr.com> writes:
> Daniel Barlow wrote:
> > Marc Spitzer <········@optonline.net> writes:
> >
> >>Do you see what happens when Erik goes away???
> > Yeah. As much time and effort is spent on flaming insensitive,
> > abusive, selfish jerks that seem unwilling to do the world a favour by
> > breaking both wrists and dying obscure unobserved deaths as ever was,..
>
> for those of you who like math in a dissertaion:
[ ooh ooh! er, so long as there aren't Greek letters... ]
> erik got to his conclusions much faster (without loss of accuracy)
> than have nonerikkians recognized asininity, but that edge in
> performance is lost many times over in the amount of time it takes
> for idiots to recognize the futility of perpetuating any CLL thread.
[ awright, no Greek! ]
My gut impulse was to argue against "without loss of accuracy", but
then I realized it's probably true. It's not that he didn't have
false positives, but every group of people will, too. I'm thinking of
Erann Gat[*] here -- he wasn't quite driven off by Erik -- but a
slightly worse [ (signal/noise) / thick-skin ] version of him probably
would have been. But then, any community will drive some valuable
people off.
[*] Sorry Erann for using you personally as an example here.
Hopefully you won't take offense to either (a) not getting along
well with Erik; nor (b) being human [ie, a non-infinite
signal/noise ratio].
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
In article <···············@conquest.OCF.Berkeley.EDU>,
···@conquest.OCF.Berkeley.EDU (Thomas F. Burdick) wrote:
> Kenny Tilton <·······@nyc.rr.com> writes:
>
> > Daniel Barlow wrote:
> > > Marc Spitzer <········@optonline.net> writes:
> > >
> > >>Do you see what happens when Erik goes away???
> > > Yeah. As much time and effort is spent on flaming insensitive,
> > > abusive, selfish jerks that seem unwilling to do the world a favour by
> > > breaking both wrists and dying obscure unobserved deaths as ever was,..
> >
> > for those of you who like math in a dissertaion:
>
> [ ooh ooh! er, so long as there aren't Greek letters... ]
>
> > erik got to his conclusions much faster (without loss of accuracy)
> > than have nonerikkians recognized asininity, but that edge in
> > performance is lost many times over in the amount of time it takes
> > for idiots to recognize the futility of perpetuating any CLL thread.
>
> [ awright, no Greek! ]
>
> My gut impulse was to argue against "without loss of accuracy", but
> then I realized it's probably true. It's not that he didn't have
> false positives, but every group of people will, too. I'm thinking of
> Erann Gat[*] here -- he wasn't quite driven off by Erik -- but a
> slightly worse [ (signal/noise) / thick-skin ] version of him probably
> would have been. But then, any community will drive some valuable
> people off.
>
> [*] Sorry Erann for using you personally as an example here.
> Hopefully you won't take offense to either (a) not getting along
> well with Erik; nor (b) being human [ie, a non-infinite
> signal/noise ratio].
Actually, I'm flattered that you would cite me as an example of a false
positive. That hardly seems to be a universal sentiment around here even
now.
I'd cite Pascal Costanza as a false positive. Erik ragged pretty hard on
him when he first arrived.
But what has always concerned me more is the lurkers Erik might have
driven away who might otherwise have become Lispers. How many of those
there are we will never know. (I know of at least one.)
What is most astonishing to me is that the people who complain most loudly
about trolls are the some ones who feed them. The most effective way of
getting rid of someone is to ignore them.
E.
···@jpl.nasa.gov (Erann Gat) writes:
> Actually, I'm flattered that you would cite me as an example of a false
> positive. That hardly seems to be a universal sentiment around here even
> now.
I guess almost everyone (at least me) will say that your influence here is
more positive than negative. But I think the same of Erik.
> I'd cite Pascal Costanza as a false positive. Erik ragged pretty hard on
> him when he first arrived.
Same goes for Pascal. Nevertheless, please look through your archives:
Erik did not attack him when he first arrived, but only later when he did
not pay attention to the ongoing conversation and started to waste time
Nicolas.
"Nicolas Neuss" <·············@iwr.uni-heidelberg.de> wrote in message
···················@ortler.iwr.uni-heidelberg.de...
> Same goes for Pascal. Nevertheless, please look through your archives:
> Erik did not attack him when he first arrived, but only later when he did
> not pay attention to the ongoing conversation and started to waste time
That is not my interpretation of what went on at all. But we're all
different, right? That's why tempered responses are generally much better.
--
Coby Beck
(remove #\Space "coby 101 @ bigpond . com")
"Coby Beck" <·····@mercury.bc.ca> writes:
> "Nicolas Neuss" <·············@iwr.uni-heidelberg.de> wrote in message
> ···················@ortler.iwr.uni-heidelberg.de...
> > Same goes for Pascal. Nevertheless, please look through your archives:
> > Erik did not attack him when he first arrived, but only later when he did
> > not pay attention to the ongoing conversation and started to waste time
>
> That is not my interpretation of what went on at all. But we're all
> different, right? That's why tempered responses are generally much better.
I wanted to reply privately to this (for not making this thread longer).
Unfortunately, your machine refuses my mail.
So be it.
Nicolas.
P.S.: Some anti-spam filter?
The original message was received at Mon, 12 May 2003 15:10:39 +0200 (MET DST)
from ····@ortler.iwr.uni-heidelberg.de [129.206.120.136]
----- The following addresses had permanent fatal errors -----
<·····@mercury.bc.ca>
(reason: 553 5.1.8 <·····@ortler>... Domain of sender address ·····@ortler does not exist)
----- Transcript of session follows -----
... while talking to smtp.mercury.bc.ca.:
>>> MAIL From:<·····@ortler> SIZE=2780
<<< 553 5.1.8 <·····@ortler>... Domain of sender address ·····@ortler does not exist
501 5.6.0 Data format error
Reporting-MTA: dns; mail.iwr.uni-heidelberg.de
Received-From-MTA: DNS; ortler.iwr.uni-heidelberg.de
Arrival-Date: Mon, 12 May 2003 15:10:39 +0200 (MET DST)
Final-Recipient: RFC822; ·····@mercury.bc.ca
Action: failed
Status: 5.1.8
Diagnostic-Code: SMTP; 553 5.1.8 <·····@ortler>... Domain of sender address ·····@ortler does not exist
Last-Attempt-Date: Mon, 12 May 2003 15:10:41 +0200 (MET DST)
Kenny Tilton <·······@nyc.rr.com> writes:
> Daniel Barlow wrote:
> > Marc Spitzer <········@optonline.net> writes:
> >
> >>Do you see what happens when Erik goes away???
> > Yeah. As much time and effort is spent on flaming insensitive,
> > abusive, selfish jerks that seem unwilling to do the world a favour by
> > breaking both wrists and dying obscure unobserved deaths as ever was,..
>
> not. nonerikkians, upon working out that positive articles are lost on
> their misbegotten correspondents, simply offer no more help. aside:
> congrats to mark conrad for being harder to recognize by the CLL
> immune system than many predecessor infections. what is the sound of
I do not think that is fair to all the other trolls, back then
Erik was part of the defense.
> one troll clapping? They are gone overnight when the last CLLer (god
> bless their faith in humanity and their own powers of persuasion)
> gives up on them.
>
> erik, having made the same determination, spewed abuse until the
> idiots worked out that only erik (the black hole into which every
> troll got sucked) was ever going to respond to them. then they went
> away. but that takes longer. so it is a lot more than "as much".
>
> for those of you who like math in a dissertaion: erik got to his
> conclusions much faster (without loss of accuracy) than have
> nonerikkians recognized asininity, but that edge in performance is
> lost many times over in the amount of time it takes for idiots to
> recognize the futility of perpetuating any CLL thread.
>
> that is the flaw in erik's strategy for driving trolls away: it relies for
> its effectiveness on the wit of trolls. uh-oh...
admit it Kenny you want him back also.
marc
Daniel Barlow <···@telent.net> writes:
> Marc Spitzer <········@optonline.net> writes:
>
> > Do you see what happens when Erik goes away???
>
> Yeah. As much time and effort is spent on flaming insensitive,
> abusive, selfish jerks that seem unwilling to do the world a favour by
> breaking both wrists and dying obscure unobserved deaths as ever was,
> but now the load is spread more equitably than it used to be, and
> there's no secondary "why is Erik being mean to me" thread that also
> needs killing.
>
By George I think he's got it.
marc
Marc Spitzer <········@optonline.net> writes:
> >
> > If you can't stand the heat in the "clueless" kitchen, stay out.
>
> Do you see what happens when Erik goes away???
Remember Ilias? He took enormous amounts of abuse and didn't go
away. He disappeared when people stopped feeding him. If you think
flames help, go look at sci.math and witness how utterly useless they
can be.
Just
Dont Feed The Trolls!
Mario.
Marc Spitzer <········@optonline.net> wrote:
> Mark Conrad <······@iam.invalid> writes:
> > If you can't stand the heat in the "clueless" kitchen, stay out.
> Do you see what happens when Erik goes away???
A person has to demonstrate cluelessness for more than two posts before
aspersions get cast on their intelligence or reading comprehension?
Michael
·······@bcect.com (Michael Sullivan) writes:
> Marc Spitzer <········@optonline.net> wrote:
> > Mark Conrad <······@iam.invalid> writes:
>
> > > If you can't stand the heat in the "clueless" kitchen, stay out.
>
> > Do you see what happens when Erik goes away???
>
> A person has to demonstrate cluelessness for more than two posts before
> aspersions get cast on their intelligence or reading comprehension?
but 2 post demonstrate a pattern, after all.
marc
On Thu, May 08, 2003 at 08:22:25PM +0000, Mark Conrad wrote:
> In article <·····················@mapcar.org>, Matthew Danish
> <·······@andrew.cmu.edu> wrote:
> > Or stop making broad statements about an issue which you are
> > clueless about, at least in a forum that better-informed people are
> > reading.
>
> I most certainly will not! Making those broad statements has a decided
> benefit for me. If my statement is wrong, I get ample replies
> informing me exactly how the cookie crumbles.
This is fine. What's the problem is when you repeat those wrong statements
even after you have been corrected. This shows that you do not learn, and that
is what is causing people to become angry at you.
Will you learn this?
--
; 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 <······@iam.invalid> writes:
> Let me point out that the term "undefined behavior" is not at all
> obvious to a newbie, nor is that term even explained in any of my CL
> tutorial books, and I have plenty of them.
>
But undefined behavior is defined in the specification of Common Lisp,
specifically in section 1.4.2. and perhaps elsewhere.
http://www.lispworks.com/reference/HyperSpec/Body/01_db.htm
Perhaps you ought to expand your reading list to include the specification.
--
Howard Ding
<·····@prairieinet.net>
In article <··············@Frisell.localdomain>,
<·····@prairieinet.net> wrote:
> But undefined behavior is defined in the specification of Common Lisp,
> specifically in section 1.4.2. and perhaps elsewhere.
>
> http://www.lispworks.com/reference/HyperSpec/Body/01_db.htm
>
> Perhaps you ought to expand your reading list to include the specification.
For reasons explained to me in this thread, I *finally* view
undefined behavior the same as everyone else here does.
Took me a long while to listen to reason.
Mark-
From: Joe Marshall
Subject: Re: Recreational Common Lisp :)
Date:
Message-ID: <d6isxid4.fsf@ccs.neu.edu>
I'm not sure why I'm responding, but.....
Mark Conrad <······@iam.invalid> writes:
> No one here has yet presented a valid case for not using
> "undefined behavior".
You yourself have presented the *most* valid argument for not using
undefined behavior: It isn't guaranteed to work! This is the very
reason you came on to this list. Paul Graham made a slight error in
his book and depended upon a common, but technically undefined
behavior. You stumbled into a case where it did not work as Paul
intended.
> On the contrary, a gentleman who is a better Lisp expert than anyone in
> this thread, uses "undefined behavior".
That is a rather ignorant statement. Paul Graham is an intelligent
guy, but there are several people who post to this list who were
instrumental in the *creation* and *definition* of Common Lisp. If
you don't value their opinions, I suggest you correspond directly (and
solely) with Paul Graham.
> Paul Graham, being the CL expert that he is, was well aware of using
> "undefined-behavior" back in 1994, in his "On Lisp" book.
Paul Graham is an intelligent person, but I hardly expect that he
knows the quirks of every Common Lisp system in existence. Virtually
*every* Common Lisp system allows you to SETQ an undefined free
variable at `top-level', despite the fact that the Common Lisp
standard expresses no opinion upon what that might mean. The
traditional interpretation is that this will set the value cell of the
relevant symbol. CMUCL is exceptional in that it does *not* follow
this interpretation by default (you can set a flag to get it to do
so). This idiosyncracy has tripped up many Common Lisp programmers.
Paul Graham doesn't use CMUCL (see his web page).
"Joe Marshall" <···@ccs.neu.edu> wrote in message
·················@ccs.neu.edu...
. Virtually
> *every* Common Lisp system allows you to SETQ an undefined free
> variable at `top-level', despite the fact that the Common Lisp
> standard expresses no opinion upon what that might mean.
You also could try:
setf
defvar
defconstant if the var. doensn't change.
I don't know what would work
but because Lisp is interactive you
could try the diff. functs. for setting the
var.
One thing I like about Lisp is that it
has many ways to skin a cat--if one
don't work try the other, you'll eventually
find something that works. :)
"Franz Kafka" <Symbolics _ XL1201 _ Sebek _ Budo _ Kafka @ hotmail . com>
wrote in message ·······················@news01.roc.ny.frontiernet.net...
>
> "Joe Marshall" <···@ccs.neu.edu> wrote in message
> ·················@ccs.neu.edu...
> . Virtually
> > *every* Common Lisp system allows you to SETQ an undefined free
> > variable at `top-level', despite the fact that the Common Lisp
> > standard expresses no opinion upon what that might mean.
>
> You also could try:
>
> setf
This is the same as setq wrt undefined behaviour. In fact setf (a macro) on
a symbol will expand to setq.
CL-USER 1 > (macroexpand '(setf foo 6))
(SETQ FOO 6)
T
> defvar
This is the normal way to introduce a new variable at top level and is not
the same as setf as it is defined to create a special variable.
> defconstant if the var. doensn't change.
You should not use defconstant unless you are not going to ever change its
value. I know what you want to accomplish and you should use defparameter.
This will bind the new value even if it has been defined before:
CL-USER 4 > (defvar var nil)
VAR
CL-USER 5 > var
NIL
CL-USER 6 > (defvar var t)
VAR
CL-USER 7 > var
NIL
CL-USER 8 > (defparameter parm nil)
PARM
CL-USER 9 > parm
NIL
CL-USER 10 > (defparameter parm t)
PARM
CL-USER 11 > parm
T
> I don't know what would work
> but because Lisp is interactive you
> could try the diff. functs. for setting the
> var.
> One thing I like about Lisp is that it
> has many ways to skin a cat--if one
> don't work try the other, you'll eventually
> find something that works. :)
I am very guilty of doing this myself all the time, but trial and error has
some risks when it comes to learning a language. You are at the mercy of an
implementation which may have bugs and you may end up learning to rely on
undefined behaviours and implementation specific functionality. For subtle
points, you can't beat reading the spec and asking experts (and hopefully
listening to them). But yes, I love Lisp too for letting me just type it at
the top level and see if it works...
--
Coby Beck
(remove #\Space "coby 101 @ bigpond . com")
>
In article <············@ccs.neu.edu>, Joe Marshall <···@ccs.neu.edu>
wrote:
> > No one here has yet presented a valid case for not using
> > "undefined behavior".
>
> You yourself have presented the *most* valid argument for not using
> undefined behavior: It isn't guaranteed to work!
Okay, all that is slowly starting to dawn on me, call me dense.
Coby Beck's post was instrumental in changing my attitude, because he
furnished example code, rather than just flapping his lips as others
did.
Now that leaves me with the big problem of converting Graham's code so
that it is ANSI compliant.
Specifically, if I adopt your reasoning about "undefined behavior",
then ANSI CL does not seem to have any way to create a toplevel
variable which is "non-special" - it can only legitimately create a
"special" (dynamic) variable at toplevel.
That seems very odd for a language which claims to be a
lexically-scoped language by default.
(Scheme, by comparison, *is* a lexically-scoped language, even for
their toplevel variables)
The half-vast "fix" of "define-symbol-macro" does not fix this basic
problem of ANSI CL being incapable of creating a toplevel non-special
variable either, as I demonstrated with this code:
**********************************************
Welcome to the demo version of Macintosh Common Lisp Version 4.3!
? (define-symbol-macro %cont% #'identity)
%CONT%
? (define-symbol-macro k 'meow)
K
? (let ((r %cont%))
(defun test ()
(print(funcall %cont% 'woof))
(setq r 'bow-wow) r))
;Compiler warnings :
; Undeclared free variable %CONT%, in an anonymous lambda form.
> Error: Unbound variable: %CONT%
> While executing: #<Anonymous Function #x1EF2B69E>
> Type Command-/ to continue, Command-. to abort.
> If continued: Retry getting the value of %CONT%.
See the Restarts� menu item for further choices.
1 >
Aborted
? (test)
> Error: Undefined function TEST called with arguments () .
> While executing: "Unknown"
> Type Command-/ to continue, Command-. to abort.
> If continued: Retry applying TEST to NIL.
See the Restarts� menu item for further choices.
1 >
Aborted
? (funcall %cont% k)
MEOW
?
*********************************************
This version below seems to work better, when it is kludged-up with
eval-when:
###################################
Welcome to the demo version of Macintosh Common Lisp Version 4.3!
? (define-symbol-macro %cont% #'identity)
%CONT%
? (eval-when (:load-toplevel :execute)
(setf (symbol-value '%cont%)
(lambda (&rest args)
(if (cdr args)
args
(car args)))))
#<Anonymous Function #x1EFB84DE>
? (define-symbol-macro k 'meow)
K
? (let ((r %cont%))
(defun test ()
(print(funcall %cont% 'woof))
(setq r 'bow-wow) r))
;Compiler warnings :
; Undeclared free variable %CONT%, in an anonymous lambda form.
TEST
? (test)
WOOF
BOW-WOW
? (funcall %cont% k)
MEOW
?
###################################
Lisp still complains about %cont% being "undeclared", even though I
used CL's own 'approved' function "define-symbol-macro" to declare to
the compiler what I intended to do with the toplevel variable
"%cont%".
(namely make %cont% a non-special variable)
Given the present sorry state of the ANSI standard regarding this
specific issue, it seems I have no option except to modify Graham's
code the following way:
(let (( %cont% nil ))
...<rest of Graham's six macros go into body of 'let'>... )
...and then rely on CL's "catch" and "throw" to get me to toplevel
"above" the 'let' form.
This is a bad situation for demonstrating the 'power' of continuations,
because continuations should be able to *replace* both 'catch' and
'throw', instead of having to rely on them to get to toplevel.
Mark-
From: Tim Bradshaw
Subject: Re: Recreational Common Lisp :)
Date:
Message-ID: <ey3k7cz0z8x.fsf@cley.com>
* Mark Conrad wrote:
> The half-vast "fix" of "define-symbol-macro" does not fix this basic
> problem of ANSI CL being incapable of creating a toplevel non-special
> variable either, as I demonstrated with this code:
I'm sorry. We've been through this before, and at least two versions
of the DEFINE-SYMBOL-MACRO hack were given that worked. You should
*look at them*, rather than trying to reinvent what they do and
getting it wrong because you don't understand enough. This refusal to
listen to, and learn from, what people are saying is why you aren't
getting on very well.
One of them (mine) is available at
http://www.tfeb.org/lisp/toys.html#GLEX. The others are available
from google groups.
--tim
Mark Conrad wrote:
> So what? If it is good enough for a CL guru like Paul Graham to use
> "undefined-behavior", it is also good enough for me to do the same
> thing. The only thing that concerns me whenever I use
> "undefined-behavior" is the issue of whether my code will run on all
> HyperSpec-compliant CL implementations.
Section 1.5 of the HyperSpec tells you _exactly_ what you can and must
not assume with regard to portability of your programs across conforming
implementations. See
http://www.lispworks.com/reference/HyperSpec/Body/01_e.htm
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 <············@f1node01.rhrz.uni-bonn.de>, Pascal Costanza
<········@web.de> wrote:
> Section 1.5 of the HyperSpec tells you _exactly_ what you can and must
> not assume with regard to portability of your programs across conforming
> implementations. See
> http://www.lispworks.com/reference/HyperSpec/Body/01_e.htm
Do you happen to know where I can buy a hardcopy of the HyperSpec.
Just curious if a hardcopy is available, and where.
My Mac, running OS 10.2.4 (so-called "OS X") - froze up when I was
using the downloadable version. That is the first time in six months
that OS X froze on anything.
I usually leave my Mac powered up all the time. I have plenty of RAM
in my "Pismo" powerbook, 1024 MBs, so that was probably not the cause
of the freeze.
Mark-
In article <·························@iam.invalid>,
Mark Conrad <······@iam.invalid> wrote:
> In article <············@f1node01.rhrz.uni-bonn.de>, Pascal Costanza
> <········@web.de> wrote:
>
> > Section 1.5 of the HyperSpec tells you _exactly_ what you can and must
> > not assume with regard to portability of your programs across conforming
> > implementations. See
> > http://www.lispworks.com/reference/HyperSpec/Body/01_e.htm
>
> Do you happen to know where I can buy a hardcopy of the HyperSpec.
There are no hardcopies of the HyperSpec available. You can get
hardcopies of the ANSI spec, but they are very expensive.
> Just curious if a hardcopy is available, and where.
>
> My Mac, running OS 10.2.4 (so-called "OS X") - froze up when I was
> using the downloadable version. That is the first time in six months
> that OS X froze on anything.
I am also running OS X and don't have this problem. Just try again.
Pascal
Pascal Costanza <········@web.de> writes:
> In article <·························@iam.invalid>,
> Mark Conrad <······@iam.invalid> wrote:
>
> > In article <············@f1node01.rhrz.uni-bonn.de>, Pascal Costanza
> > <········@web.de> wrote:
> >
> > > Section 1.5 of the HyperSpec tells you _exactly_ what you can and must
> > > not assume with regard to portability of your programs across conforming
> > > implementations. See
> > > http://www.lispworks.com/reference/HyperSpec/Body/01_e.htm
> >
> > Do you happen to know where I can buy a hardcopy of the HyperSpec.
>
> There are no hardcopies of the HyperSpec available. You can get
> hardcopies of the ANSI spec, but they are very expensive.
You can also buy a PDF of the ANSI spec from INICTS for a mere $18 and
however long it takes to download (it's pretty big.) The license
allows you to make a "copy" for "backup" purposes. Dunno if that
technically includes printing out a hardcopy.
<http://webstore.ansi.org/ansidocstore/product.asp?sku=ANSI+INCITS+226%2D1994+%28R1999%29>
-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:
> You can also buy a PDF of the ANSI spec from INICTS for a mere $18 and
> however long it takes to download (it's pretty big.) The license
> allows you to make a "copy" for "backup" purposes. Dunno if that
> technically includes printing out a hardcopy.
>
>
> <http://webstore.ansi.org/ansidocstore/product.asp?sku=ANSI+INCITS+226%2D1994+
> %28R1999%29>
Thanks, that sounds like a reasonable price.
Mark-
Pascal Costanza <········@web.de> writes:
> In article <·························@iam.invalid>,
> Mark Conrad <······@iam.invalid> wrote:
>
> > Do you happen to know where I can buy a hardcopy of the HyperSpec.
>
> There are no hardcopies of the HyperSpec available. You can get
> hardcopies of the ANSI spec, but they are very expensive.
You can get the Postscript files of the latest draft (which IIRC has
the same contents as the final ANSI spec and only differs with respect
to formatting) and print them yourself. See the thread "HyperSpec in
other formats" for URLs.
Or you can buy a copy of CLtL2 and "convert" it to ANSI CL:
<http://bc19191.home.attbi.com/cltl2-ansi.htm>.
(Of course this is not the same as the ANSI spec but it's a good start
and you'll most likely learn something while you do that. I'm going to
do it this weekend... :)
Edi.
In article <··············@bird.agharta.de>, Edi Weitz <···@agharta.de>
wrote:
> Or you can buy a copy of CLtL2 and "convert" it to ANSI CL:
>
> <http://bc19191.home.attbi.com/cltl2-ansi.htm>.
>
> (Of course this is not the same as the ANSI spec but it's a good start
> and you'll most likely learn something while you do that. I'm going to
> do it this weekend... :)
Lemme know how you make out, I already have CLtL2 so your approach
should save me some bucks.
Mark-
In article <······························@news.netcologne.de>, Pascal
Costanza <········@web.de> wrote:
> > My Mac, running OS 10.2.4 (so-called "OS X") - froze up when I was
> > using the downloadable version. That is the first time in six months
> > that OS X froze on anything.
>
> I am also running OS X and don't have this problem. Just try again.
Thanks, I will pass it off as just a random occurance, and reload the
HyperSpec back into the Mac.
If it happens again for some unknown reason, I will get hardcopy.
Mark-
Mark Conrad <······@iam.invalid> writes:
> My Mac, running OS 10.2.4 (so-called "OS X") - froze up when I was
> using the downloadable version. That is the first time in six months
> that OS X froze on anything.
This is an off topic response.
You should go to software update and get 10.2.5. It might help you
there. Are you using the Safari browser? It is still a beta but it
is quite nice.
--
(describe 'describe)
In article <··············@verizon.net>, David Steuber
<·············@verizon.net> wrote:
> > My Mac, running OS 10.2.4 (so-called "OS X") - froze up when I was
> > using the downloadable version. That is the first time in six months
> > that OS X froze on anything.
> You should go to software update and get 10.2.5.
That is the special "server" version of OS X, which I think now is up
to version 10.2.6
Most everyone, including me, has the regular personal version which
right now is only up to version 10.2.4 last time I checked.
> Are you using the Safari browser? It is still a beta but it
> is quite nice.
No - Bill Gates is pleading poverty so I am still using IE.
Maybe when Safari gets out of beta I will switch.
Mark-
Mark Conrad <······@iam.invalid> writes:
> In article <··············@verizon.net>, David Steuber
> <·············@verizon.net> wrote:
>
> > You should go to software update and get 10.2.5.
>
> That is the special "server" version of OS X, which I think now is up
> to version 10.2.6
>
> Most everyone, including me, has the regular personal version which
> right now is only up to version 10.2.4 last time I checked.
I don't think the server version would be on a PowerBook G4 ;-)
> > Are you using the Safari browser? It is still a beta but it
> > is quite nice.
>
> No - Bill Gates is pleading poverty so I am still using IE.
>
> Maybe when Safari gets out of beta I will switch.
I think you will like Safari. Very clean, very fast, and very Aqua.
--
(describe 'describe)
Mark Conrad <······@iam.invalid> writes:
> That is the special "server" version of OS X, which I think now is up
> to version 10.2.6
>
> Most everyone, including me, has the regular personal version which
> right now is only up to version 10.2.4 last time I checked.
Huh? I updated _regular_ OS X to 10.2.6 a couple of days ago.
> No - Bill Gates is pleading poverty so I am still using IE.
>
> Maybe when Safari gets out of beta I will switch.
Switch immediately, compared to the latest safari, IE is an alpha.
--
(espen)
Mark Conrad <······@iam.invalid> wrote:
What I personally find amazing is your ability to twist evidence into shape
that is pleasing to you, no matter what happens to the integrity of the
evidence.
>> Except that you'd be invoking undefined behavior.
> So what? If it is good enough for a CL guru like Paul Graham to use
> "undefined-behavior", it is also good enough for me to do the same
> thing. The only thing that concerns me whenever I use
How many times have people explained this to you? I've lost count. Grahams
book was published *before* there was an ANSI standard.
And re. undefined behaviour:
>> This is not a side issue, this is at the heart of the matter.
> I disagree. To me, CL is a tool. As such, I use it to accomplish
> results. I care less about whether the tool I am using has the
How many times have people examplained *this* to you? By invoking undefined
behaviour you have no guarantee that what you do will work tomorrow. Not
even on the same version of Lisp you have now.
> For example, in my MCL ver 4.3 all toplevel variables created by setq
> act as if they are lexically-scoped throughout the program.
How many times have *you* said: "Oh, now I see it. Now I understand why I
should not do this." ?
>> A toplevel SETQ on a symbol that has not been
>> DEFVARed has no defined meaning.
> It still has to act in the program in only one of two ways, either as
> if it is dynamically-scoped or lexically-scoped.
No, it can even signal en error. Or as someone so succintly put it: it can
fire missiles to France.
FWIW: I believe that the reason most implementations allow this is to let
you stuff things into toplevel variables during an interactive session
without first defining them.
Cheers,
-- Nikodemus
In article <··············@midnight.cs.hut.fi>, Nikodemus Siivola
<········@kekkonen.cs.hut.fi> wrote:
> How many times have people explained this to you? I've lost count. Grahams
> book was published *before* there was an ANSI standard.
I am well aware of that. His "old" book is still quite useful for
learning purposes.
I am not at all convinced that using "undefined behavior" is as bad a
thing as some make it out to be.
After all, Paul Graham must have known that the behavior of variables
at the time of his book work was "undefined behavior", even at that
time. Despite all that, he still used "undefined behavior".
Once a programmer demonstrates to his clients that a problem is
"solvable" by using CL "behavior", undefined or otherwise, it becomes a
lot easier to gain funding for the project in order to re-code the
"bandit-Lisp" into production code that is reliable.
The clients have the priceless knowledge that their funds will not be
wasted on a project that has no chance of success, because the Lisp
version works in so far as cracking the problem is concerned.
Mark-
Mark Conrad <······@iam.invalid> wrote:
> In article <··············@midnight.cs.hut.fi>, Nikodemus Siivola
> <········@kekkonen.cs.hut.fi> wrote:
>
> > How many times have people explained this to you? I've lost count. Grahams
> > book was published *before* there was an ANSI standard.
>
> I am well aware of that. His "old" book is still quite useful for
> learning purposes.
>
> I am not at all convinced that using "undefined behavior" is as bad a
> thing as some make it out to be.
>
> After all, Paul Graham must have known that the behavior of variables
> at the time of his book work was "undefined behavior", even at that
> time. Despite all that, he still used "undefined behavior".
Because, at the time, before the standard, there was no "defined
behavior". When there is no standard *all* behavior is undefined. All
you can do is use your implementation's definition, or trust in a shared
sense of what is reasonable if you are planning to port around.
You don't seem to understand the *reason* not to use undefined behavior.
It's not that it won't work on your system. It might. It's not that
it will make demons fly out your nose. It probably won't. It's that it
*could* make demons fly out your nose, and your lisp vendor would not be
responsible. Using undefined behavior means that your code *can* break
without any change to the standard or any bug in your implementation.
When there *is no standard*, there's not actually any such thing as
defined or undefined behavior. So Paul Graham *wasn't* using undefined
behavior at the time, and if he rewrote _On Lisp_ today, he would almost
certainly modify it so that it does not do so now either.
Using undefined behavior only makes sense when you won't be porting
around, *and* you can't easily solve your problem another way -- because
it really could break the next time you upgrade or patch your
implementation.
> Once a programmer demonstrates to his clients that a problem is
> "solvable" by using CL "behavior", undefined or otherwise, it becomes a
> lot easier to gain funding for the project in order to re-code the
> "bandit-Lisp" into production code that is reliable.
You've been shown simple ways to rework the Paul Graham macros to
exhibit no undefined behavior with the current standards. Why are you
unwilling to make these changes? You wish to take PG's 1992 code as
some kind of gospel truth?
That's reminiscent of using Genesis 1-2 as a literal scientific
document. At the time it was written, it told a story containing
powerful emotional and spiritual truths (if you are of that religious
bent) and using as metaphor a tale whose literal accuracy *could not be
determined*. At the time, it may not have been unreasonable for people
to believe and act as though it were literal truth. To do the same
today, you would need to ignore thousands of years of new revelation.
Yet the emotional and spiritual truth (for believers) stands the test of
time. The "historical" details are exposed as myth, but the story
itself is still powerful, as long as you can get over the need to
question the accuracy of every historical claim and treat it as you
would a novel or poem. Treating every word as literal truth is only
going to make you look stupid. Even the original writers probably
didn't intend for you do that.
So consider again, PG and his pre-ANSI code. It contains powerful
algorithms. But it also contains things that are today considered
mistakes (of course, it's only 12 years old, so there are a lot fewer
than in a 5000 year old myth that was an oral tradition for about half
of its history). Your intention is to completely ignore everything
that has been changed in or learned about lisp since _On Lisp_?
You seem to imply that there is no gray area between throwing out PG's
code as worthless and taking every last character as *the* way.
If you have to be better at writing than the author to offer any
critique, then a lot of editors are going to have to find another
career.
Michael
In article <······························@bcect.com>, Michael Sullivan
<·······@bcect.com> wrote:
> Using undefined behavior only makes sense when...<snipped>...
Okay, I am finally convinced that using "Undefined behavior" is a
Bad-Thing.
Thanks to all who beat on my head and made me see the light.
> You've been shown simple ways to rework the Paul Graham macros to
> exhibit no undefined behavior with the current standards. Why are you
> unwilling to make these changes?
I thought you would never ask ;-)
The way I was shown was unreliable, did not work:
*************************************
Welcome to the demo version of Macintosh Common Lisp Version 4.3!
? (define-symbol-macro %cont% #'identity)
%CONT%
? (define-symbol-macro k 'meow)
K
? (let ((r %cont%))
(defun test ()
(print(funcall %cont% 'woof))
(setq r 'bow-wow) r ))
;Compiler warnings :
; Undeclared free variable %CONT%, in an anonymous lambda form.
> Error: Unbound variable: %CONT%
> While executing: #<Anonymous Function #x1EB2116E>
> Type Command-/ to continue, Command-. to abort.
> If continued: Retry getting the value of %CONT%.
See the Restarts� menu item for further choices.
1 >
Aborted
? (test)
> Error: Undefined function TEST called with arguments () .
> While executing: "Unknown"
> Type Command-/ to continue, Command-. to abort.
> If continued: Retry applying TEST to NIL.
See the Restarts� menu item for further choices.
1 >
Aborted
? (funcall %cont% k)
MEOW
?
**************************************
The following way, with the kludge of "eval-when", did work but
even here "warned" about "undeclared free variable %CONT%,
despite using CL's own 'approved' eval-when to tell the compiler
what I intended to do with %cont%
##############################
Welcome to the demo version of Macintosh Common Lisp Version 4.3!
? (define-symbol-macro %cont% #'identity)
%CONT%
? (eval-when (:load-toplevel :execute)
(setf (symbol-value '%cont%)
(lambda (&rest args)
(if (cdr args)
args
(car args)))))
#<Anonymous Function #x1EFB84DE>
? (define-symbol-macro k 'meow)
K
? (let ((r %cont%))
(defun test ()
(print(funcall %cont% 'woof))
(setq r 'bow-wow) r ))
;Compiler warnings :
; Undeclared free variable %CONT%, in an anonymous lambda form.
TEST
? (test)
WOOF
BOW-WOW
? (funcall %cont% k)
MEOW
?
###############################
This leaves me with the nasty task of converting %cont% to approved
ANSI code - - - there appears to be no reliable way of doing this,
because ANSI CL will not allow the "approved" creation of anything
except special-variables (dynamic) - at toplevel.
Unless I use "define-symbol-macro" which obviously can't do the job.
Very strange behavior for a language that is supposed to be
lexically-scoped by default.
Mark-
Mark Conrad <······@iam.invalid> writes:
> I am not at all convinced that using "undefined behavior" is as bad a
> thing as some make it out to be.
In my programming experience (not in Lisp), there have been two types
of behavior not specified by the language standard. One (which seems
to be the case you are dealing with) was "implementation dependent".
In this case, the behavior was well defined by the compiler. However,
that behavior could change in a future release. Then there was the
"undefined behavior". This was truly nasty. The compiler did not
define what would happen. If you were lucky, the program would
immediatly crash in a reproducible way so you could fix it. That
happened most of the time. The other times were worse. Some bit of
memory could get corrupted and a crash may or may not occur at some
indefinate time in the future. Debug that.
Just my two cents, inflation adjusted.
--
(describe 'describe)
In article <··············@verizon.net>, David Steuber
<·············@verizon.net> wrote:
> The other times were worse. Some bit of memory could get
> corrupted and a crash may or may not occur at some
> indefinate time in the future. Debug that.
I am gradually (finally!) coming around to view "undefined-behavior" as
a Bad Thing.
Just took me a lot longer than other newbies.
Mark-
"Mark Conrad" <······@iam.invalid> wrote in message
······························@iam.invalid...
> > A toplevel SETQ on a symbol that has not been
> > DEFVARed has no defined meaning.
>
> It still has to act in the program in only one of two ways, either as
> if it is dynamically-scoped or lexically-scoped.
The following are examples of reasonable and compliant behaviour:
1 > (setq foo 4)
4
2 > foo
Error: The variable FOO is unbound.
1 > (setq bar 4)
Error: Attempt to bind undeclared variable BAR
The following are still examples of compliant behaviour, though more
inconvenient:
1 > (setq foo 4)
Error: Segmentation fault
(lisp freezes and you must reboot)
1 > (setq foo 4)
4
2 > (+ 5 foo)
37
3 >
Undefined means, hmm, not defined. Which means it isn't defined what will
happen. Which means don't count on anything. Which means if you write your
code this way, don't come work for me.
> > > Hope this explains what is going on -
> >
> > It sure explains that you don't pay attention to anything you don't
> > want to hear.
>
> Of course not, neither do you.
Ignoring what you don't want to hear is not a good way to learn anything,
nor is it the most common way. I know it is a tendency we all share, but
fight it, don't boast about it!
--
Coby Beck
(remove #\Space "coby 101 @ bigpond . com")
In article <············@otis.netspace.net.au>, Coby Beck
<·····@mercury.bc.ca> wrote:
> Ignoring what you don't want to hear is not a good way to learn anything,
> nor is it the most common way. I know it is a tendency we all share, but
> fight it, don't boast about it!
I ignored it because it did not make any sense to me.
When something does not make sense, I tend to boast about being clever
enough to spot it as not making sense.
Now I am an admitted newbie to all this *very* confusing Lisp stuff,
so a lot of things don't make sense to me.
For that matter, some of the things I brought up in past threads did
not make sense to others who have a lot more experience than I do,
namely whether or not "binding" refers to a location in memory, or a
value, or both.
Because of obvious complex issues like the above, CL is particularly
hard to understand. For example, try to steer a newbie to a book that
will explain the the complex function "eval-when" to them in a manner
they can understand. Just for starters, none of my CL tutorial books
address that function, much less explain how it works.
I don't appreciate the abuse being heaped upon my because of my
stubborn refusal to change my opinion about "undefined behavior", when
no valid reason so far has led me to consider changing.
If this is the way the CLL newsgroup members treat newbies, I see no
reason whatever to study Lisp. I can't pick up these complex points
from the recommended textbooks.
Your recent post comes closest to changing my present opinion about
"undefined behavior", which none of the other abusive posters have been
able to do.
They did not bother to do what you did, namely post example code like
the following:
> The following are still examples of compliant behaviour, though more
> inconvenient:
>
> 1 > (setq foo 4)
> Error: Segmentation fault
> (lisp freezes and you must reboot)
>
> 1 > (setq foo 4)
> 4
> 2 > (+ 5 foo)
> 37
> 3 >
>
> Undefined means, hmm, not defined. Which means it isn't defined what
> will happen. Which means don't count on anything.
That "37" line caught my attention real fast. Are there actually
ANSI Common Lisp implementations that do that, or are you just making
it up to try to impress me as to what *might* happen.
BTW, don't bother answering that question if you don't feel like doing
so, because I don't want to be accused of turning this NG into a newbie
instruction forum.
No one is twisting anyone's arm here to answer questions, and I for
certain do not want advice from those who do not desire to give advice.
Stop whining about how much a pain in the kazoo I am, just shut-up and
don't participate in the discussion. That is easy enough for anyone to
understand, I hope.
Disgusted with CLL -
Mark-
Mark Conrad <······@iam.invalid> wrote:
> In article <············@otis.netspace.net.au>, Coby Beck
> <·····@mercury.bc.ca> wrote:
>
> > Ignoring what you don't want to hear is not a good way to learn anything,
> > nor is it the most common way. I know it is a tendency we all share, but
> > fight it, don't boast about it!
> I ignored it because it did not make any sense to me.
> When something does not make sense, I tend to boast about being clever
> enough to spot it as not making sense.
When you are an *expert* in a field and someone says something about it
that doesn't make sense to you, then you have probably spotted an error
or miscommunication on the part of the speaker/writer.
When you are an "admitted newbie" and someone says something that
doesn't make sense to you, it's probably because you don't understand
the terms they are using, or some other concept that they are taking for
granted.
It's not unreasonable to say "That doesn't make sense to me." But it's
a bit rude to say *only* that. 1. It may imply that the person you are
talking to has made a mistake, when you have no good way of knowing
whether that is the case. 2. It gives them *no* help in understanding
*what* doesn't make sense to you, and *why*. Since you're asking for
information, it's only polite to help the process along a bit by asking
people to explain terms you don't know. Or if you *think* you know, and
your own definitions are leading to a contradiction, to go through the
logical process
> Now I am an admitted newbie to all this *very* confusing Lisp stuff,
> so a lot of things don't make sense to me.
> For that matter, some of the things I brought up in past threads did
> not make sense to others who have a lot more experience than I do,
> namely whether or not "binding" refers to a location in memory, or a
> value, or both.
> Because of obvious complex issues like the above, CL is particularly
> hard to understand. For example, try to steer a newbie to a book that
> will explain the the complex function "eval-when" to them in a manner
> they can understand. Just for starters, none of my CL tutorial books
> address that function, much less explain how it works.
What you don't seem to realize is that you don't need to know this stuff
in great detail to use CL. A language newsgroup is not the same as a
tutorial book. A good tutorial would completely avoid terms like
"binding" unless a very good explanation was given. If you read other
language newsgroups like comp.lang.c++ or comp.lang.java, you will
notice the term "binding" being passed around much the same as it is
here. Why? Because lots of people in language newsgroups are CS
experts and Programming language theory experts. Don't expect to
understand programming language theory as it applies to a language,
before you are even comfortable with the basic syntax and metaphors of
the language.
messing about with eval is considered "hairy". Pretty much everything
in _On Lisp_ is considered better learned *after* you have gotten some
comfort with the language. And a great number of people here have
mentioned this to you. That you would be far better off starting with a
book like _Successful Lisp_, or _ANSI Common Lisp_ which is aimed at
lisp *beginners*. After working through such a book and getting a few
actual programs written on your own -- you will be much better equipped
to deal with the questions you are encountering in _On Lisp_, which was
written for people who are already comfortable with lisp, or lisp family
languages, and who want to do things that can't easily be done in other
languages at all. You want to run and jump hurdles before you can even
walk holding on to furniture.
I'm all for optimism and confidence and *trying* to run to see if you
can. But when you do that and fall on your face, it's not reasonable to
then conclude that the whole business of moving around on two legs at
all is just too frustrating and difficult, so you might as well just
keep crawling for the rest of your life.
Michael
In article <·····························@bcect.com>, Michael Sullivan
<·······@bcect.com> wrote:
> What you don't seem to realize is that you don't need to know this stuff
> in great detail to use CL.
Oh I realize that.
It is just that I am using CL strictly for recreation, so I tend to
grab at the shiny stuff like continuations, closures, macros.
Then I see I am in over my head, so go seeking help for understanding
stuff like "bindings".
A very long recent thread help me get my head glued on straight about
"bindings", so I feel more or less confident about that subject now.
Another subject that people here helped me with *very* recently is
"undefined-behavior". I finally came around to everyone else's view
that undefined behavior is a Bad Thing.
BTW, thanks for your recent post with all that good advice.
About my only remaining problem, before I tackle CL continuations in
ernest, is to figure out a legitimate ANSI way of handling Graham's
toplevel variable "*cont*" , which I named %cont% to stress that it
is not a special variable as the asterisks imply.
All the rest of Graham's code presents no problems as far as porting it
to ANSI Common Lisp is concerned - - - only that %cont% variable is
the problem.
The ANSI "solution" to my dilemna, namely the function
"define-symbol-macro" does not really help, for reasons that I posted
in other recent posts.
When "define-symbol-macro" is coupled with "eval-when" the situation
improves dramatically. %cont% runs as intended, almost.
(by "almost", I mean that I can't get rid of compiler "warnings")
Near as I can determine, ANSI Lisp has no *reliable* way of creating
any toplevel variable that is *not* special. (not dynamic, that is)
The only "reliable" variables that ANSI seems able to create at
toplevel are "special" variables. (dynamic variables)
So presently I am going to stick with the combination of "eval-when"
and "define-symbol-macro" in my attempt to convert Graham's code to
ANSI Lisp.
If I get into Big Trouble with that conversion attempt, I will have to
resort to throwing %cont% into a "let" form to force it to be
"non-special".
I don't want to take that approach, because it further weakens what CL
continuations can do.
Mark-
Mark Conrad <······@iam.invalid> writes:
> In article <·····························@bcect.com>, Michael Sullivan
> <·······@bcect.com> wrote:
>
> > What you don't seem to realize is that you don't need to know this stuff
> > in great detail to use CL.
>
> Oh I realize that.
>
> It is just that I am using CL strictly for recreation, so I tend to
> grab at the shiny stuff like continuations, closures, macros.
That's not recreation, that's abuse :)
...
>
> The ANSI "solution" to my dilemna, namely the function
> "define-symbol-macro" does not really help, for reasons that I posted
> in other recent posts.
>
> When "define-symbol-macro" is coupled with "eval-when" the situation
> improves dramatically. %cont% runs as intended, almost.
> (by "almost", I mean that I can't get rid of compiler "warnings")
>
That's the wrong track, dude.
> Near as I can determine, ANSI Lisp has no *reliable* way of creating
> any toplevel variable that is *not* special. (not dynamic, that is)
>
How about:
(defmacro deflex (var &optional val)
(let ((backing-var (gensym)))
`(progn
(defvar ,backing-var ,val)
(define-symbol-macro ,var ,backing-var))))
Tim
Mark Conrad <······@iam.invalid> writes:
> Near as I can determine, ANSI Lisp has no *reliable* way of creating
> any toplevel variable that is *not* special. (not dynamic, that is)
http://groups.google.com/groups?selm=sfwzp4s2cqk.fsf%40world.std.com
> The only "reliable" variables that ANSI seems able to create at
> toplevel are "special" variables. (dynamic variables)
Just not built in.
IMO, This was a casualty of the design process wherein users came to the
first few meetings and then felt it was too expensive to stay in the
process, so they left it to the vendors. The vendors didn't have enough
experience with user needs, and imagined that this was a stray thing that
not many people wanted. Jonathan Rees and I tried to get through a
lexical variable proposal
http://nhplace.com/kent/CL/Issues/proclaim-lexical.html
but my recollection (which doesn't quite match my notes, but might mean
my notes are not complete) is that many voting worried it would
somehow interfere with other things, and they tried to make a billion
modifications to it. When it got all done, they were ready to vote it
in, but it was nothing like the original proposal-- the original
proposers didn't want it, and the others who had heavily modified it
were only voting yes because they thought they had made it palatable
to everyone. (Typical problem in democratic process.) Fortunately,
we noticed in time to keep something stupid from happening and we just
backed out.
Anyway, it can be added EASILY as an extension so leaving it out is
harmless.
In article <···············@shell01.TheWorld.com>, Kent M Pitman
<······@world.std.com> wrote:
> > The only "reliable" variables that ANSI seems able to create at
> > toplevel are "special" variables. (dynamic variables)
>
> Just not built in.
>
> Anyway, it can be added EASILY as an extension so leaving it out is
> harmless.
That is what I am in the process of doing now, adding an extension
using ordinary functions so I don't have to worry about the finicky
read macro's generated by "define-symbol-macro".
I am trying to get by without using catch and throw also, because one
of the things I want to demonstrate with Graham's simulated CL
continuations is their ability to *implement* catch/throw if those
constructs were not already part of CL.
In any event, playing with Paul Graham's macros is a lot of fun, and I
might accidentally learn a bit of CL in the process :)
Mark-
Mark Conrad <······@iam.invalid> writes:
> In article <···············@shell01.TheWorld.com>, Kent M Pitman
> <······@world.std.com> wrote:
>
> > Anyway, [lexical variables] can be added EASILY as an extension
> > so leaving it out is
> > harmless.
>
> That is what I am in the process of doing now, adding an extension
> using ordinary functions so I don't have to worry about the finicky
> read macro's generated by "define-symbol-macro".
define-symbol-macro does not generate "read macros".
> I am trying to get by without using catch and throw also, because one
> of the things I want to demonstrate with Graham's simulated CL
> continuations is their ability to *implement* catch/throw if those
> constructs were not already part of CL.
? I haven't been following this thread. Probably with special variables
and lexical block/return, you can implement something like catch/throw,
but since it's in the language, why bother?
> In any event, playing with Paul Graham's macros is a lot of fun, and I
> might accidentally learn a bit of CL in the process :)
hmmm
In article <···············@shell01.TheWorld.com>, Kent M Pitman
<······@world.std.com> wrote:
> define-symbol-macro does not generate "read macros".
Sorry, a wrong assumption on my part.
> ? I haven't been following this thread. Probably with special
> variables and lexical block/return, you can implement something
> like catch/throw, but since it's in the language, why bother?
Just for practice in using Graham's continuations, without using *any*
of the escape constructs like block/return, only using continuations.
When I get good enough using the beasties, I have hopes of implementing
"wind" in CL. "wind" is a Scheme thingy that allows upward escape
procedures. CL has "unwind-protect", but according to the literature
that construct only supports downward escape procedures when control
leaves/enters a function by unorthodox means. (by continuations, for
example)
> > In any event, playing with Paul Graham's macros is a lot of fun, and I
> > might accidentally learn a bit of CL in the process :)
>
> hmmm
Really, it's lotsa fun - wish Paul Graham would get active and grind
out an updated ANSI compatable updated version of his "On Lisp" book.
CLL'ers need the recreation involved in doing "just for fun"
continuations, otherwise they will get even grouchier than they are
now.
(boy are they grouchy lately) - - -
Think I am going to hide until their mood improves.
Bye bye people -
Mark-
In article <··············@darkstar.cartan>, Nils Goesche
<···@cartan.de> wrote:
> (define-symbol-macro *cont* #'identity)
Nils, that by itself, without the help of "eval-when", broke on me.
Give me a little time and I will find my notes about the specific
situation where it broke, and I will get back to you.
Mark-
In article <··············@darkstar.cartan>, Nils Goesche
<···@cartan.de> wrote:
> ...lotsa interesting stuff...
I could not locate the example I was looking for about
define-symbol-macro breaking, so I whiped up another example quickly.
It is not as good an example because I get a compiler 'warning' in this
case, but it will get across the idea.
Example #1 with eval-when
*********************************************
Welcome to the demo version of Macintosh Common Lisp Version 4.3!
? (define-symbol-macro %cont% #'identity)
%CONT%
? (eval-when (:load-toplevel :execute)
(setf (symbol-value '%cont%)
(lambda (&rest args)
(if (cdr args)
args
(car args)))))
#<Anonymous Function #x1EFB84DE>
? (define-symbol-macro k 'meow)
K
? (let ((r %cont%))
(defun test () (print(funcall %cont% 'woof)) (setq r 'bow-wow) r
) )
;Compiler warnings :
; Undeclared free variable %CONT%, in an anonymous lambda form.
TEST
? (test)
WOOF
BOW-WOW
? (funcall %cont% k)
MEOW
?
*******************************************
Example #2 without eval-when
#################################
Welcome to the demo version of Macintosh Common Lisp Version 4.3!
? (define-symbol-macro %cont% #'identity)
%CONT%
? (define-symbol-macro k 'meow)
K
? (let ((r %cont%))
(defun test () (print(funcall %cont% 'woof)) (setq r 'bow-wow) r
) )
;Compiler warnings :
; Undeclared free variable %CONT%, in an anonymous lambda form.
> Error: Unbound variable: %CONT%
> While executing: #<Anonymous Function #x1EF2B69E>
> Type Command-/ to continue, Command-. to abort.
> If continued: Retry getting the value of %CONT%.
See the Restarts� menu item for further choices.
1 >
#################################
Mark-
From: Nils Goesche
Subject: Re: Recreational Common Lisp :)
Date:
Message-ID: <lyd6it63bq.fsf@cartan.de>
Mark Conrad <······@iam.invalid> writes:
> Example #2 without eval-when
> #################################
> Welcome to the demo version of Macintosh Common Lisp Version 4.3!
>
> ? (define-symbol-macro %cont% #'identity)
> %CONT%
>
>
> ? (define-symbol-macro k 'meow)
> K
>
>
>
> ? (let ((r %cont%))
> (defun test () (print(funcall %cont% 'woof)) (setq r 'bow-wow) r
> ) )
>
> ;Compiler warnings :
> ; Undeclared free variable %CONT%, in an anonymous lambda form.
> > Error: Unbound variable: %CONT%
> > While executing: #<Anonymous Function #x1EF2B69E>
> > Type Command-/ to continue, Command-. to abort.
> > If continued: Retry getting the value of %CONT%.
> See the Restarts� menu item for further choices.
> 1 >
> #################################
Heh. Looks like a bug to in MCL to me. Please learn to indent your
code correctly. The last form should look like
(let ((r %cont%))
(defun test ()
(print (funcall %cont% 'woof))
(setq r 'bow-wow)
r))
As a fix, you might try
(eval-when (:load-toplevel :compile-toplevel :execute)
(define-symbol-macro %cont% #'identity))
Does it work then?
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:
> Heh. Looks like a bug to in MCL to me.
Anything is possible in that piece of code. I will take the easy way
out and use eval-when, as long as it works:
**********************************************
Welcome to the demo version of Macintosh Common Lisp Version 4.3!
? (define-symbol-macro %cont% #'identity)
%CONT%
? (eval-when (:load-toplevel :execute)
(setf (symbol-value '%cont%)
(lambda (&rest args)
(if (cdr args)
args
(car args)))))
#<Anonymous Function #x1EFB84DE>
? (define-symbol-macro k 'meow)
K
? (let ((r %cont%))
(defun test ()
(print (funcall %cont% 'woof))
(setq r 'bow-wow) r ))
;Compiler warnings :
; Undeclared free variable %CONT%, in an anonymous lambda form.
TEST
? (test)
WOOF
BOW-WOW
? (funcall %cont% k)
MEOW
?
************************************************
Actually, eval-when frightens me. At the present time, I find it
extremely difficult to comprehend that built-in CL function.
None of my tutorials explain eval-when, so I am left with trying to
comprehend it by reading CLtL2.
Not an ideal way to learn.
Mark-
Mark Conrad wrote:
> In article <··············@cartan.de>, Nils Goesche <······@cartan.de>
> wrote:
>
> > Heh. Looks like a bug to in MCL to me.
>
> Anything is possible in that piece of code. I will take the easy way
> out and use eval-when, as long as it works:
>
If it works for your project in your Lisp that is all that really matters.
It depends on wheather or not you want to make it portable. If you are happy
with the app. running in MCL you can leave it just the way it is, even with
the 'undefined behavior' because it is working in MCL.
If some one else should want to port it to a different CL compiler thay
might have to make changes to get it to run.
However it is not wrong to relie on 'undefined behavior' -- it is the same
as reling on an implementation specific function such as streams, or a web
server.
If the code works, undefined or not, use it. :)
Seasoned Users Note:We should not try to scare a CL newbe away from the
lang. we're having enough troble attracting them to Lisp in the first place.
& what does jumping off the Brooklyn Bridge have to do with barrowing some
of Paul Garhams CL code from 'On Lisp.'
Even though commonp and define-setf-method are no longer ANSI it is not
wrong for a user to write code to implement them--in fact it could be easier
to add two functions, that it would be to rewrite all the code that depends
on them. I just chose those funcs. of the top of my head /w no rhyme or
reason.
"Franz Kafka" <Symbolics _ XL1201 _ Sebek _ Budo _ Kafka @ hotmail . com> writes:
> If it works for your project in your Lisp that is all that really matters.
>
> It depends on wheather or not you want to make it portable. If you are happy
> with the app. running in MCL you can leave it just the way it is, even with
> the 'undefined behavior' because it is working in MCL.
In the version of MCL he currently uses, that is. And unless he does
anything else that might cause this version to behave differently.
> Seasoned Users Note:We should not try to scare a CL newbe away from the
> lang. we're having enough troble attracting them to Lisp in the first place.
Thanks for educating us. I'm sure letting newbies run in all sorts of
needless trouble will do wonders for Lisp popularity.
Regards
Henrik
"Henrik Motakef" <··············@web.de> wrote in message
···················@interim.henrik-motakef.de...
>
> Thanks for educating us. I'm sure letting newbies run in all sorts of
> needless trouble will do wonders for Lisp popularity.
>
> Regards
> Henrik
I think asking him if he'd jump off a bridge with Paul Garham was going a
little too far. He already decided that he's going to write his program--I
think we should help him.
a.)
Teach him about #+ #- reader macros.
b.)
Teach him how to add the feature he needs to Lisp so
it is not undefined.
c.)
Teach him how to check for the error so he can run his code.
d.)
Show him an other way to implement continuations in Lisp because
that is what he wants to do. If he knew of a better or safer way to
do it--I'm sure he would.
But it would be a waste of bandwidth to try to talk him out of doing what he
already decided he was going to do. We warned him it might be dangerous--but
he might have 2 find out 4 himself.
(Debugging the code and getting it to run might even be his best teacher.)
Someone should tell him what might work, not why his code might not--because
that would help him more
----------
#+(MCL) ;; informs user that code runs in MCL
;; but other code might be needed for other CLs.
(eval-when (:load-toplevel :execute)
(setf (symbol-value '%cont%)
(lambda (&rest args)
(if (cdr args)
args
(car args)) )))
#-(MCL) (+ 3 4) ;; does not get evaluated in MCL.
The #+ & #- macros are used to write non-portable code in
a portable way. The non-portable parts are written with the
#- or #+ reader function to make sure the right Lisp uses
the right functions.
I don't know much about #- or #+ except that thay could
be used to make your code run in all CLs. Someone on this
list might know.
In article <···················@news02.roc.ny.frontiernet.net>, Franz
Kafka < @> wrote:
> I think asking him if he'd jump off a bridge with Paul Garham was going a
> little too far. He already decided that he's going to write his program--I
> think we should help him.
I would like to clear up one point.
I have no intention of turning this NG into a Newbie Education Forum,
because I believe one is responsible for one's own education, and
should not expect others to spoon-feed him instruction.
If resondents *want* to reply to questions, that is a different
matter, and I welcome that approach, obviously.
I warned about abusive people here "turning on anyone" who happens to
agree with me. I see it is already happening with Henrik's sarcastic
remarks below:
"Henrik Motakef" <··············@web.de> wrote in message
···················@interim.henrik-motakef.de...
>
> Thanks for educating us. I'm sure letting newbies run in all sorts of
> needless trouble will do wonders for Lisp popularity.
>
> Regards
> Henrik
Mark-
In article <···················@news02.roc.ny.frontiernet.net>, Franz
Kafka < @> wrote:
> If the code works, undefined or not, use it. :)
I intend to, as a learning vehicle.
Thanks very much for your kindly post. Such posts are becoming so rare
lately that I am really learning to appreciate the few that I get.
> It depends on wheather or not you want to make it portable.
I had hopes of doing that, however other posters have presented good
reasons why trying to port "undefined behavior" might not work.
Usually their reasons were buried in their posts amid abusive remarks
to me, so decided not to give them the satisfaction of knowing that
their reasons for not using "undefined behavior" were being taken
seriously by me.
> However it is not wrong to rely on 'undefined behavior' -- it is the
> same as relying on an implementation specific function such as streams,
> or a web server.
I agree wholeheartedly. As I tried to point out to others, Paul Graham
was well aware that he was using "undefined behavior", even in 1994
when his book was published, before the half-vast "fix" of eval-when
ever became part of the ANSI standard.
You realize of course, that you are letting yourself in for attack by
others by agreeing with me on these points. I hope you have a thick
skin. ;-)
> If some one else should want to port it to a different CL compiler thay
> might have to make changes to get it to run.
I *would* like to be able to post some code about learning to use
Paul Graham's continuations, for the benefit of other newbies who might
be interested in learning how to use those continuations in ANSI CL.
Graham's macros to implement continuations rely on macros and closures,
which *are* "defined behavior in ANSI Commom Lisp.
The only thing unusual in Graham's code is that he relies on a toplevel
variable named "*cont*" to *not* be a dynamically-scoped variable
anywhere in his code for implementing continuations.
That variable has to "act like" a lexically-scoped variable, in order
for Graham's continuations to work.
If interested newbies can ensure that "*cont*" works that way, all
the rest of Graham's code should present no problem to them.
(other than the usual problems of handling macros and closures)
Mark-
Mark Conrad <······@iam.invalid> writes:
> Usually their reasons were buried in their posts amid abusive
> remarks to me, so decided not to give them the satisfaction of
> knowing that their reasons for not using "undefined behavior" were
> being taken seriously by me.
This is unproductive behavior. If you showed that you took seriously
stuff that was worth taking seriously and ignored the abuse, you would
gain respect. As it is, the view people in CLL have of you seems to
be deteriorating over time. You can quantify the deterioration by
plotting over time the percentage of posts responding to you that
contain the word "ilias".
> I agree wholeheartedly. As I tried to point out to others, Paul
> Graham was well aware that he was using "undefined behavior", even
> in 1994 when his book was published, before the half-vast "fix" of
> eval-when ever became part of the ANSI standard.
The problem is that setq at the top level wasn't undefined in pre-ANSI
lisp. Here is the stuff from CLTL2, which was a revision of CLTL1
that tried to take some of the ANSI work into account (apparently
failing and causing some confusion....).
From Section 5.1.2 on Variables:
Symbols are used as names of variables in Common Lisp
programs. When a symbol is evaluated as a form, the value of the
variable it names is produced. For example, after doing (setq
items 3), which assigns the value 3 to the variable named items,
then items => 3. Variables can be assigned to, as by setq, or
bound, as by let. Any program construct that binds a variable
effectively saves the old value of the variable and causes it to
have a new value, and on exit from the construct the old value is
reinstated.
...
The value a special variable has when there are currently no
bindings of that variable is called the global value of the
(special) variable. A global value can be given to a variable
only by assignment, because a value given by binding is by
definition not global.
Then skipping to section 7.1.2 on Assignment:
The following facilities allow the value of a variable (more
specifically, the value associated with the current binding of
the variable) to be altered. Such alteration is different from
establishing a new binding. Constructs for establishing new
bindings of variables are described in section 7.5.
[Special Form]
setq {var form}*
The special form (setq var1 form1 var2 form2 ...) is the ``simple
variable assignment statement'' of Lisp. First form1 is evaluated
and the result is stored in the variable var1, then form2 is
evaluated and the result stored in var2, and so forth. The
variables are represented as symbols, of course, and are
interpreted as referring to static or dynamic instances according
to the usual rules. Therefore setq may be used for assignment of
both lexical and special variables.
Note that from the combination of the two above sections, I would
infer that setq at the top level was legal. That's because it says,
"A global value can be given to a variable only by assignment..." in
the first quotation and "The special form (setq var1 form1 var2 form2
...) is the ``simple variable assignment statement'' of lisp" in the
second quotation.
So you see that the standard made a difference, and ON LISP, being
written before the standard was accepted, did not necessarily take
that into account.
BTW, these sections in CLTL2 give some interesting insights into the
use of the term "binding" that seem to make considerable sense....
Your comments about eval-when make no sense to me. They seem to
reflect a tendency on your part to criticize what you don't
understand. This is exactly why people are annoyed with you. You
give the appearance of considering yourself a coryphaeus of
programming; if it doesn't make sense to you it is wrong and should be
gotten rid of or fixed.
--
Fred Gilham ······@csl.sri.com
...Please don't assume Lisp is only useful for Animation and Graphics,
AI, Bioinformatics, B2B and E-Commerce, Data Mining, EDA/Semiconductor
applications, Expert Systems, Finance, Intelligent Agents, Knowledge
Management, Mechanical CAD, Modeling and Simulation, Natural Language,
Optimization, Research, Risk Analysis, Scheduling, Telecom, and Web
Authoring just because these are the only things they happened to
list. -- Kent Pitman
In article <··············@snapdragon.csl.sri.com>, Fred Gilham
<······@snapdragon.csl.sri.com> wrote:
> The problem is that setq at the top level wasn't undefined in pre-ANSI
> lisp. Here is the stuff from CLTL2 , which was a revision of CLTL1
> that tried to take some of the ANSI work into account (apparently
> failing and causing some confusion....).
Okay, I did not realize that.
Thanks for digging up that specification.
In any event, I have *finally* came around to everyone else's view
concerning undefined behavior.
Merk-
"Franz Kafka" <Symbolics _ XL1201 _ Sebek _ Budo _ Kafka @ hotmail . com>
wrote in message ························@news02.roc.ny.frontiernet.net...
>
> If it works for your project in your Lisp that is all that really matters.
>
Sure, and if your bridge is still there after you walk over and jump up and
down a few times on it, that's all that really matters.
http://www.enm.bris.ac.uk/research/nonlinear/tacoma/tacoma.html
http://washington.pacificnorthwestmovies.com/TacomaNarrowsBridgeCollapse/
Every time my Windows session crashes with a blue screen full of giberish, I
can hear some code monkey in the Redmond dungeons saying to himself, "hmm,
it works right now on my machine, that's all that really matters"
--
Coby Beck
(remove #\Space "coby 101 @ bigpond . com")
In article <·························@iam.invalid>, Mark Conrad
<······@iam.invalid> wrote:
> ...some erroneous stuff...
Here is the *CORRECTED* version of Paul Graham's "six macros" code
from his 1994 "On Lisp" book
Joe Marshall kindly pointed out that some of my added code would break
Paul's macros, and suggested that I use the CL "eval-when" here.
After some brief tests, the addition of eval-when does indeed appear to
eliminate difficulties experienced by me when a continuation tries to
go to toplevel
Copy and paste *everything* from between the asterisk lines to your
own file. This code is necessary to be loaded into Lisp _before_
the examples in this thread will run.
;; CORRECTED VERSION - REPLACE YOUR OLDER VERSION
;****************************************
(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)
;; Below are Paul Graham's six macros. About the only changes
;; that I made were to change his "*cont*" to "%cont%", in order
;; to emphasize that %cont% is not a dynamically-scoped
;; variable.
;;
;; Another change I made was to use "=setq" to ensure that %cont%
;; does not act like a dynamically-scoped variable.
;;
;; =setq is just a convenient shorter abbreviation for CL's built-in
;; macro named "define-symbol-macro"
;;
;; Regarding the "=setq" form immediately below, it might not be
;; necessary however I think it should be left in because a few CL
;; implementors might try to turn toplevel variables like %cont% into
;; special variables, which would break Paul Graham's six macros.
(=setq
%cont%
#'(lambda (&rest args)
(if (cdr args)
args
(car args) )))
(eval-when (:load-toplevel :execute)
(setf (symbol-value '%cont%)
(lambda (&rest args)
(if (cdr args)
args
(car args)) )))
(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))
;*******************************************
;; End of Paul Graham's six macros from his "On Lisp" book.
Mark-
In article <·························@iam.invalid>, Mark Conrad
<······@iam.invalid> wrote:
> ...lotsa strange stuff...<g>
Notice that we have succeeded in demonstrating continuations in CL by
using only two of Paul Graham's six macros. ( "=bind" and "=values")
It is inconvenient to have to run the progn form just to demonstrate
continuations. It would be nice if we could put the progn form into a
function named "demo".
Unfortunately, when we are dealing with macros as we are doing now,
subtle 'bugs' can occur due tothe way that CL handles macros.
I tried throwing our simpleprogn-form into a regular function named
"demo", but the progn form 'broke' and ceased to produce random output
displays, as it was designed to do.
Below is the only way I know of (presently) to preserve correct way
that our progn form runs.
(defvar demo)
(setq demo
(quote (progn
(print 'first)
(print 'second)
(=bind () (=values)
(setq k #'(lambda ()
(print 'third)
(print 'fourth)
(print 'fifth)
nil) ))
(if (= (random 2) 0)
(elsewhere)
(funcall k) ))) )
Now we can run demo, and it will flip between the two types of output
displays in a random manner, as it should.
Typical runs of (eval demo) below -
Whenever it prints the line WENT-ELSEWHERE-FOR-AWHILE
...a little two-second delay occurs to simulate the time spent
executing the function "elsewhere"
(eval demo)
FIRST
SECOND
WENT-ELSEWHERE-FOR-AWHILE
THIRD
FOURTH
FIFTH
NIL
(eval demo)
FIRST
SECOND
THIRD
FOURTH
FIFTH
NIL
(eval demo)
FIRST
SECOND
WENT-ELSEWHERE-FOR-AWHILE
THIRD
FOURTH
FIFTH
NIL
(eval demo)
FIRST
SECOND
WENT-ELSEWHERE-FOR-AWHILE
THIRD
FOURTH
FIFTH
NIL
We have not done anything really interesting with continuations yet,
but what-the-heck, we are just starting to learn this stuff.
Mark-