From: Tayssir John Gabbour
Subject: Flaw in Conditions System?
Date: 
Message-ID: <866764be.0403251054.468978d2@posting.google.com>
A handler "handles" a condition by performing a non-local transfer of
control: using go, return, or throw.  [hyperspec 9.1]  So that means
you get to use a subset of lisp while deciding whether to handle a
signal; if you go outside the subset, the decision is implicitly
forced.

A potential problem is you may wish your handler to scrutinize the
condition object using a do loop.  ("I can handle it if there's a list
with 'frobno-X in it.")  However, do loops may silently be implemented
in terms of return, which would force the decision to handle the
thing. [cltl2 7.8.2]

So we're in the situation where either:
a) we don't get to use the full power of lisp in deciding whether to
handle a condition
b) we accidentally handle them without intending it
c) make recursion not iteration!

Was this potential problem ever brought up?  I think the problem is
that if you wind things with more and more levels of abstraction,
little go/returns lurk hidden, and that kills referential
transparency.  That may be a slippery slope to get on.

From: Christophe Rhodes
Subject: Re: Flaw in Conditions System?
Date: 
Message-ID: <sqzna4rau2.fsf@lambda.dyndns.org>
···········@yahoo.com (Tayssir John Gabbour) writes:

> A handler "handles" a condition by performing a non-local transfer of
> control: using go, return, or throw.  [hyperspec 9.1]  So that means
> you get to use a subset of lisp while deciding whether to handle a
> signal; if you go outside the subset, the decision is implicitly
> forced.

My reading of this, specifically of the word 'non-local', is that your
concern simply doesn't arise: not all uses of GO, RETURN or THROW
cause non-local control transfer.  Specifically, those which do not
cause the handler function to return (i.e. internal control transfers)
I believe should not cause the system to believe that the condition
has been handled.

Is there an existing Common Lisp system which implements handlers as
your interpretation would suggest?  My interpretation is:

  (handler-bind ((error (lambda (c) (catch 'c (throw 'c 1))))) 
    (error "foo"))
  => ERROR "foo" is signalled

  (catch 'c (handler-bind ((error (lambda (c) (throw 'c 1)))) 
    (error "foo"))
  => 1

Christophe
-- 
http://www-jcsu.jesus.cam.ac.uk/~csr21/       +44 1223 510 299/+44 7729 383 757
(set-pprint-dispatch 'number (lambda (s o) (declare (special b)) (format s b)))
(defvar b "~&Just another Lisp hacker~%")    (pprint #36rJesusCollegeCambridge)
From: Tayssir John Gabbour
Subject: Re: Flaw in Conditions System?
Date: 
Message-ID: <866764be.0403251715.33578099@posting.google.com>
Christophe Rhodes <·····@cam.ac.uk> wrote in message news:<··············@lambda.dyndns.org>...
> ···········@yahoo.com (Tayssir John Gabbour) writes:
> > A handler "handles" a condition by performing a non-local transfer of
> > control: using go, return, or throw.  [hyperspec 9.1]  So that means
> > you get to use a subset of lisp while deciding whether to handle a
> > signal; if you go outside the subset, the decision is implicitly
> > forced.
> 
> My reading of this, specifically of the word 'non-local', is that your
> concern simply doesn't arise: not all uses of GO, RETURN or THROW
> cause non-local control transfer.  Specifically, those which do not
> cause the handler function to return (i.e. internal control transfers)
> I believe should not cause the system to believe that the condition
> has been handled.

"non-local exit n. a transfer of control (and sometimes values) to an
exit point for reasons other than a normal return. 'The operators go,
throw, and return-from cause a non-local exit.'"
http://www.lisp.org/HyperSpec/Body/glo_n.html#non-local_exit

I previously interpreted things in a similar way as you did, but upon
reading the spec it seemed to me that I must have been terribly wrong.
 As far as I can tell, everything in the spec appears to support my
new, unfortunate interpretation.  But whatever, as long as I'm the
only one who reads the standard in this manner, this is a non-issue.

Annoys the snot out of me though. ;(


> Is there an existing Common Lisp system which implements handlers as
> your interpretation would suggest?

Clisp does not, and I doubt others do either.  However they diverge
from my current understanding of the spec's text.  Which of course is
written in English, so a determined reader is bound to find ambiguity.
 But I tend to interpret specs fairly literally because names often
don't sound right.  For example, if I brought preconceptions to the
terms "conditions" and "restarts," I'd probably be sunk.

In fact, I'm not even sure I understand the term "dynamic/lexical
contour," which I see mentioned often in conversation but couldn't
find a good definition.  I have an intuition about it, but it's not
mentioned enough that I can test.

Again, as long as this is a non-issue, I'm not going to make a big
deal out of it.
From: Peter Seibel
Subject: Re: Flaw in Conditions System?
Date: 
Message-ID: <m3vfksmb4y.fsf@javamonkey.com>
···········@yahoo.com (Tayssir John Gabbour) writes:

> Christophe Rhodes <·····@cam.ac.uk> wrote in message news:<··············@lambda.dyndns.org>...
>> ···········@yahoo.com (Tayssir John Gabbour) writes:
>> > A handler "handles" a condition by performing a non-local transfer of
>> > control: using go, return, or throw.  [hyperspec 9.1]  So that means
>> > you get to use a subset of lisp while deciding whether to handle a
>> > signal; if you go outside the subset, the decision is implicitly
>> > forced.
>> 
>> My reading of this, specifically of the word 'non-local', is that your
>> concern simply doesn't arise: not all uses of GO, RETURN or THROW
>> cause non-local control transfer.  Specifically, those which do not
>> cause the handler function to return (i.e. internal control transfers)
>> I believe should not cause the system to believe that the condition
>> has been handled.
>
> "non-local exit n. a transfer of control (and sometimes values) to an
> exit point for reasons other than a normal return. 'The operators go,
> throw, and return-from cause a non-local exit.'"
> http://www.lisp.org/HyperSpec/Body/glo_n.html#non-local_exit
>
> I previously interpreted things in a similar way as you did, but
> upon reading the spec it seemed to me that I must have been terribly
> wrong. As far as I can tell, everything in the spec appears to
> support my new, unfortunate interpretation. But whatever, as long as
> I'm the only one who reads the standard in this manner, this is a
> non-issue.

Indeed. If it's any consolation to you while working on my chapter
about conditions I not only went over the spec in great detail but
read every other thing I could find on the topic such as Kent Pitman's
papers on the topic and I think your new interpretation is bizarre.
;-)

Here's why your interpretation can't be right:

 a) The behavior your describing makes no sense--suppose I have a
 handler that uses a DO loop or some macro that internally uses a
 "non-local exit". According to you the condition has been "handled"
 as a consequence of that non-local exit but I'm still in my handler
 code. What happens next? (Hint: it's not distinguishable from the
 condition *not* being handled.)

 b) Even if there was a sensibel answer to that question, nobody would
 want the behavior you're imagining for exactly the reason you
 describe--it makes handler code weirdly dependent on the internal
 implementation of code it calls.

 c) The condition system would require bizarre implementation hacks to
 work the way you imagine.

I believe (a) logically proves your interpretation wrong while (b) and
(c)--while not proofs--are highly-suggestive piling on.

-Peter

-- 
Peter Seibel                                      ·····@javamonkey.com

         Lisp is the red pill. -- John Fraser, comp.lang.lisp
From: Tayssir John Gabbour
Subject: Re: Flaw in Conditions System?
Date: 
Message-ID: <866764be.0403260805.62b3596b@posting.google.com>
Peter Seibel <·····@javamonkey.com> wrote in message news:<··············@javamonkey.com>...
> Indeed. If it's any consolation to you while working on my chapter
> about conditions I not only went over the spec in great detail but
> read every other thing I could find on the topic such as Kent Pitman's
> papers on the topic and I think your new interpretation is bizarre.

Yeah, well I read your chapter-in-progress, as well as that part of
the spec and everything I could find Kent wrote. ;)

At this point I just woke up and realized I was being hyper-literal; I
get into these moods if I've been reading certain things too much. 
I'm thankful for your and Wolfhard's replies; however I had already
looked at these points and had an answer for all of them.

You can stop reading now, but here are those responses:

Wolfhard pointed out that declining was mutually exclusive with
handling; however the language was "simply returning rather than
transferring control", which means construct a model like:

(cond ((transfer-control-p) ;go/return/throw
       (handle))
      ((simple-return-p)
       (decline))
      (t
       (defer)))

I actually co-opted your points (b) and (c) and used them to argue
that Conditions were flawed in my orig post.  Your point (a) however
did ask what the handler should return, and the spec seems silent on
this.  Unless there's some implicit block I missed.  So either we're
confronted "another weakness" in the Conditions spec to complain
about; or my interpretation is mitigated, and like a nondeterministic
machine we should backtrack and think of something else.  However,
there are irregularities like treating return as more primitive than
return-from, despite another part of the spec showing return
implemented in terms of return-from but not the other way around, so I
may be inclined to believe the former.
From: Rob Warnock
Subject: Re: Flaw in Conditions System?
Date: 
Message-ID: <vOKcncFKDvpU1fjd3czS-g@speakeasy.net>
Tayssir John Gabbour <···········@yahoo.com> wrote:
+---------------
| ...did ask what the handler should return, and the spec seems
| silent on this.  Unless there's some implicit block I missed.
+---------------

Read CHLS 9.1 again. If a handler declines (by simply returning), then:

	"...any values returned by the handler are ignored
	and the next most recently established handler is invoked."

Hardly "silent".


-Rob

-----
Rob Warnock			<····@rpw3.org>
627 26th Avenue			<URL:http://rpw3.org/>
San Mateo, CA 94403		(650)572-2607
From: Tayssir John Gabbour
Subject: Re: Flaw in Conditions System?
Date: 
Message-ID: <866764be.0403270700.5a3e16aa@posting.google.com>
····@rpw3.org (Rob Warnock) wrote in message news:<······················@speakeasy.net>...
> Tayssir John Gabbour <···········@yahoo.com> wrote:
> +---------------
> | ...did ask what the handler should return, and the spec seems
> | silent on this.  Unless there's some implicit block I missed.
> +---------------
> 
> Read CHLS 9.1 again. If a handler declines (by simply returning), then:
> 
> 	"...any values returned by the handler are ignored
> 	and the next most recently established handler is invoked."
> 
> Hardly "silent".

Not that this topic is still interesting to anyone, but I'm sure you
know I read that.  I mean, come on. ;)  That tired Tayssir would have
said this:

Peter asked, "According to you the condition has been 'handled' as a
consequence of that non-local exit but I'm still in my handler code.
What happens next?"

Now you chose part of the spec that talks about what happens when it's
DECLINED.  But Peter's question presupposes it was HANDLED.

Tricky nut to crack, eh?  I'm not glad with the wording, but it's
still the most brilliant "unusual situation" system I've seen so far,
and I've certainly asked around.

Though if you take it from the context of people who have been flamed
in the bad ol' days, when they were told READ THE CLHS!, that sucker
can be hard to read.  I maintain that a good newbie lisper will see a
term like "nonlocal exit," look it up dutifully in the glossary trying
not to have any preconceptions, and think it's something other than it
is.  What are you "exiting" from?  The normal shape of execution?  In
an age where goto-like effects are faddishly reviled, maybe it's an
"exit" from proper coding style?
From: David Fisher
Subject: Re: Flaw in Conditions System?
Date: 
Message-ID: <14030ca9.0403281140.1984879b@posting.google.com>
By the way, what is the point of condition system? The way I undestand
it, there is nothing the condition system can do that a combination of
special variables and first-class procedures ca not do just as easily.

Take the "full disk" example. The exception mechanism is not flexible
enough, because, we might want to ignore the error, or retry several
times, or page the admin and sleep for a few hours or do other things
we, library authors can not possibly anticipate.

So if the user of our library wants to ignore the error, he can just
call it with

(let ((*full-disk-handler* 
       (lambda (file-to-write) ) )) ;; skip the file
   (call-our-library))

or if he wants to return an error, he can do

(let ((*full-disk-handler*
          (lambda (file-to-write) 
             (error "disk full, could not write ~A"
                 (file-name file-to-write)))))
   (call-our-library))

So why complicate the language with the "condition system" ?
From: Tayssir John Gabbour
Subject: Re: Flaw in Conditions System?
Date: 
Message-ID: <866764be.0403281740.117972b7@posting.google.com>
·············@yahoo.com (David Fisher) wrote in message news:<····························@posting.google.com>...
> By the way, what is the point of condition system? The way I undestand
> it, there is nothing the condition system can do that a combination of
> special variables and first-class procedures ca not do just as easily.
> 
> Take the "full disk" example. The exception mechanism is not flexible
> enough, because, we might want to ignore the error, or retry several
> times, or page the admin and sleep for a few hours or do other things
> we, library authors can not possibly anticipate.
> 
> So if the user of our library wants to ignore the error, he can just
> call it with
> 
> (let ((*full-disk-handler* 
>        (lambda (file-to-write) ) )) ;; skip the file
>    (call-our-library))
> 
> or if he wants to return an error, he can do
> 
> (let ((*full-disk-handler*
>           (lambda (file-to-write) 
>              (error "disk full, could not write ~A"
>                  (file-name file-to-write)))))
>    (call-our-library))
> 
> So why complicate the language with the "condition system" ?

Computationally, I suspect you can emulate the Conditions System to a
strong distance, because if you couldn't... that would point out an
incompleteness in lisp.

But you would desire to add a few things to your example model.  For
one thing, you would want a number of handlers, which can each think
about the condition and decide to pass the buck because they aren't
really qualified.  (Maybe you had a couple handlers which just
passively log unusual situations, so you can later analyze hotspots in
your code where problems cluster.)

Also, it should be nice to name handlers by condition type, not by a
varname like *full-disk-handler*, for the engineering reason that code
changes.  Condition objects use CLOS, so you can subtype them when you
want to change behavior.  It is at least conceivable that keying only
by a varname would paint people into corners.  For each new unusual
situation, a new var would have to be invented, instead of maybe
having a couple fairly generic handlers which can deal with a range of
errors.  Statisically more breakage in app code when you upgrade the
library.

(Incidentally, I like how that demonstrates that objects may not be
particularly reusable, but the code which operates on them is.)

And it may be easier to write macros if you don't depend on a specific
varname, but rather on a general class of conditions that might come
up.


Um... I would like to think that your idea of a lighter-weight system
is not at all incompatible with Conditions.  There seems to be a lot
of redundancy in common lisp, because it's nicer than people
reinventing stuff or looking up some buggy package on the net... and
when those standards guys stuffed something into the language, they
seemed to try crafting a whoop-ass system.

I think the win is that someone like you might come along and augment
the existing constructs with even more power.

And Conditions seems intended for when code kind of hardens and needs
polishing, so it's not something one needs to know early on.  Like
optimization; one doesn't need to know all the nice optimizations
immediately, just build functionality cleanly.  Guided by a sense of
what exists.  Then specific optimizations can be researched.

The Conditions System is not actually hard to learn, but when I
learned it at first it seemed more difficult than anything else in
lisp...  it could really do with a couple illustrations, since people
are asked to visualize this invisible stack.  The idea of a signal
bouncing up the stack looking for handlers is a visual concept. 
Keene's little book on CLOS was full of illustrations, and Conditions
didn't have a polished book.  In fact, it probably didn't have
anything except what Kent Pitman wrote, no effort to create an
eloquent introduction.  But perhaps Peter Seibel's book will fix that.
 (No pressure!!!)
From: Rahul Jain
Subject: Re: Flaw in Conditions System?
Date: 
Message-ID: <87r7vcmopp.fsf@nyct.net>
·············@yahoo.com (David Fisher) writes:

> By the way, what is the point of condition system? The way I undestand
> it, there is nothing the condition system can do that a combination of
> special variables and first-class procedures ca not do just as easily.

I'm pretty sure that's how KMP's original condition system
implementation worked. IIUC, it was written portably using the rest of
what's in CL.

> Take the "full disk" example. The exception mechanism is not flexible
> enough, because, we might want to ignore the error, or retry several
> times, or page the admin and sleep for a few hours or do other things
> we, library authors can not possibly anticipate.
>
> So if the user of our library wants to ignore the error, he can just
> call it with
>
> (let ((*full-disk-handler* 
>        (lambda (file-to-write) ) )) ;; skip the file
>    (call-our-library))
>
> or if he wants to return an error, he can do
>
> (let ((*full-disk-handler*
>           (lambda (file-to-write) 
>              (error "disk full, could not write ~A"
>                  (file-name file-to-write)))))

ERROR is part of the condition system. You would get an error signalled
indicating an undefined function being called. Oh wait, you removed the
condition system. How would you guess which *foo-handler* variable the
implementation happened to use for this error. I guess the app would
just exit with status code -158392. :)

>    (call-our-library))

You haven't touched on the issue of restarts and dynamically examining
them at runtime, running some code (which might interact with the user)
to choose one of the restarts, and invoking that restart. Also, the
condition types are a complete type hierarchy, with the appropriate
ability to choose handlers based on any superclass of the condition's
class.

> So why complicate the language with the "condition system" ?

Why complicate the language with sequence operators? All you need is a
single iteration construct and you can build the rest from that.

-- 
Rahul Jain
·····@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
From: Peter Seibel
Subject: Re: Flaw in Conditions System?
Date: 
Message-ID: <m3r7vciqy7.fsf@javamonkey.com>
·············@yahoo.com (David Fisher) writes:

> By the way, what is the point of condition system? The way I
> undestand it, there is nothing the condition system can do that a
> combination of special variables and first-class procedures ca not
> do just as easily.

Well, I don't know about "just as easily". But yes, the condition
system (SIGNAL, RESTART-CASE, RESTART-BIND, HANDLER-CASE,
HANDLER-BIND, et. al) could in fact be built on top of
dynamic-variables, first-class procedures, and lexical closures over
non-local exits. But CLOS can likewise be built on top of closures,
symbol manipulation, and some simple data structure such as lists or
vectors. Doesn't mean you'd want everyone to have to do it themselves.

> Take the "full disk" example. The exception mechanism is not
> flexible enough, because, we might want to ignore the error, or
> retry several times, or page the admin and sleep for a few hours or
> do other things we, library authors can not possibly anticipate.

You can do all those things with the condition system so I'm not sure
how it's "not flexible enough". (I assume you meant "condition system"
when you wrote "exception mechanism". If not, I don't understand what
you're asking.) If you think you can't, you may have missed something.

> So if the user of our library wants to ignore the error, he can just
> call it with
>
> (let ((*full-disk-handler* 
>        (lambda (file-to-write) ) )) ;; skip the file
>    (call-our-library))

Actually you elided an important bit of this--how do you actually
write a *FULL-DISK-HANDLER* that skips the file? Return a special
value? THROW something? Whatever it is, the author of CALL-OUR-LIBRARY
has to document that protocol.

> or if he wants to return an error, he can do
>
> (let ((*full-disk-handler*
>           (lambda (file-to-write) 
>              (error "disk full, could not write ~A"
>                  (file-name file-to-write)))))
>    (call-our-library))
>
> So why complicate the language with the "condition system" ?

Same reason to "complicate" the language with an object system--to
save users of the language from having to reimplement it over and
over.

All the condition system does is provide a structured way to specify
exactly this kind of protocol you are discussing. The author of
CALL-OUR-LIBRARY documents that they will signal DISK-FULL error under
thus and such conditions (i.e. the same conditions you're imagining
they will invoke *FULL-DISK-HANDLER*) and further that certain
restarts, such as SKIP-FILE, RETRY, RETRY-WITH-DIFFERENT-FILE , will
be available. And it does so in such a way that these protocols can be
used both interactively and programatically.

-Peter

-- 
Peter Seibel                                      ·····@javamonkey.com

         Lisp is the red pill. -- John Fraser, comp.lang.lisp
From: Brian Downing
Subject: Re: Flaw in Conditions System?
Date: 
Message-ID: <xnW9c.30629$JO3.28836@attbi_s04>
In article <··············@javamonkey.com>,
Peter Seibel  <·····@javamonkey.com> wrote:

[ Replying to David Fisher ]

> Well, I don't know about "just as easily". But yes, the condition
> system (SIGNAL, RESTART-CASE, RESTART-BIND, HANDLER-CASE,
> HANDLER-BIND, et. al) could in fact be built on top of
> dynamic-variables, first-class procedures, and lexical closures over
> non-local exits. But CLOS can likewise be built on top of closures,
                       ~~~~

YM "CLAWS".  HTH.  HAND.

:-)

(For those who missed the "dependencies!" thread, this won't make much
sense.  Sorry.  Actually, no, you're lucky.)

-bcd
-- 
*** Brian Downing <bdowning at lavos dot net> 
From: Tim Bradshaw
Subject: Re: Flaw in Conditions System?
Date: 
Message-ID: <fbc0f5d1.0403290148.4aa5c1c@posting.google.com>
·············@yahoo.com (David Fisher) wrote in message news:<····························@posting.google.com>...
> By the way, what is the point of condition system? The way I undestand
> it, there is nothing the condition system can do that a combination of
> special variables and first-class procedures ca not do just as easily.


By the way, what is the point of Lisp? The way I undestand
it, there is nothing Lisp can do that a combination of
thermionic valves and wire can not do just as easily.
From: Tayssir John Gabbour
Subject: Re: Flaw in Conditions System?
Date: 
Message-ID: <866764be.0403252119.36b53d31@posting.google.com>
Christophe Rhodes <·····@cam.ac.uk> wrote in message news:<··············@lambda.dyndns.org>...
> ···········@yahoo.com (Tayssir John Gabbour) writes:
> 
> > A handler "handles" a condition by performing a non-local transfer of
> > control: using go, return, or throw.  [hyperspec 9.1]  So that means
> > you get to use a subset of lisp while deciding whether to handle a
> > signal; if you go outside the subset, the decision is implicitly
> > forced.
> 
> My reading of this, specifically of the word 'non-local', is that your
> concern simply doesn't arise: not all uses of GO, RETURN or THROW
> cause non-local control transfer.  Specifically, those which do not
> cause the handler function to return (i.e. internal control transfers)
> I believe should not cause the system to believe that the condition
> has been handled.

You know, perhaps I am too tired and have been dealing with things
where little natural language is used to describe things.  So I wish
they simply said that handling a condition involves transferring
control in a manner which PRECLUDES a normal return from the handler.

I miss the clarity of that Peano's axioms thing Steele/Sussman did in
the "Art of the Interpreter" memo.
From: Wolfhard Buß
Subject: Re: Flaw in Conditions System?
Date: 
Message-ID: <m3oeqjrhfd.fsf@buss-14250.user.cis.dfn.de>
* Tayssir John Gabbour writes:

> So I wish they simply said that handling a condition involves
> transferring control in a manner which PRECLUDES a normal return
> from the handler.


 CLHS 9.1 Condition System Concepts:  [...]

 If a handler is invoked, it can address the situation in one of three
 ways:
 
 Decline: It can decline to handle the condition. It does this by
 simply returning rather than transferring control.  [...]

 Handle: It can handle the condition by performing a non-local
 transfer of control. [...]

 Defer: It can put off a decision about whether to handle or decline
 [...]


-- 
"Hurry if you still want to see something. Everything is vanishing."
                                       --  Paul C�zanne (1839-1906)
From: Timothy Moore
Subject: Re: Flaw in Conditions System?
Date: 
Message-ID: <wdr1xngvih2.fsf@serveur5.labri.fr>
···········@yahoo.com (Tayssir John Gabbour) writes:

> A handler "handles" a condition by performing a non-local transfer of
> control: using go, return, or throw.  [hyperspec 9.1]  So that means
> you get to use a subset of lisp while deciding whether to handle a
> signal; if you go outside the subset, the decision is implicitly
> forced.
> 
> A potential problem is you may wish your handler to scrutinize the
> condition object using a do loop.  ("I can handle it if there's a list
> with 'frobno-X in it.")  However, do loops may silently be implemented
> in terms of return, which would force the decision to handle the
> thing. [cltl2 7.8.2]

I think you're confused. The handler handles the condition by doing a
non-local transfer *out* of the hander. Using go, return or throw
within your handler doesn't cause you to leave the handler and
"handle" the condition.

> 
> So we're in the situation where either:
> a) we don't get to use the full power of lisp in deciding whether to
> handle a condition
> b) we accidentally handle them without intending it
> c) make recursion not iteration!
No.
> 
> Was this potential problem ever brought up?  I think the problem is
> that if you wind things with more and more levels of abstraction,
> little go/returns lurk hidden, and that kills referential
> transparency.  That may be a slippery slope to get on.

It's not a problem. In fact, it's an example of adding very hairy
functionality, with a hairy implementation, while preserving semantics
and transparency.

Tim
From: Tayssir John Gabbour
Subject: Re: Flaw in Conditions System?
Date: 
Message-ID: <866764be.0403251737.4ac35704@posting.google.com>
Timothy Moore <·····@serveur5.labri.fr> wrote in message news:<···············@serveur5.labri.fr>...
> > A handler "handles" a condition by performing a non-local transfer of
> > control: using go, return, or throw.  [hyperspec 9.1]  So that means
> > you get to use a subset of lisp while deciding whether to handle a
> > signal; if you go outside the subset, the decision is implicitly
> > forced.
> 
> I think you're confused. The handler handles the condition by doing a
> non-local transfer *out* of the hander. Using go, return or throw
> within your handler doesn't cause you to leave the handler and
> "handle" the condition.

I am aware of that interpretation, but currently my apparently unusual
interpretation seems to align with the spec more closely than the
other, as I chase down definitions for the terms it uses.  Did you
find something there that contradicts my interpretation, to the extent
that it becomes a less clear interpretation than the alternative?

<shrug> It's not a big deal, just that you claim I am confused, and I
would like to know if it is that, or whether the spec is unclear.  I
have not read all of the spec, so it is fairly important to me to
understand how much interpretation I will need to bring to the table
as I read it.


> > Was this potential problem ever brought up?  I think the problem is
> > that if you wind things with more and more levels of abstraction,
> > little go/returns lurk hidden, and that kills referential
> > transparency.  That may be a slippery slope to get on.
> 
> It's not a problem. In fact, it's an example of adding very hairy
> functionality, with a hairy implementation, while preserving semantics
> and transparency.

Hairy?  Until I read the spec carefully, I thought it was completely
clean and smart.  I didn't subconsciously poke any holes in it. 
Though it's actually rather hard to explain to nonlispers, since most
people are not able to visualize dynamic things.  Due to the stack
being a relatively invisible structure.  That invisibility probably
also accounts for peoples' difficulty with recursion.
From: Kaz Kylheku
Subject: Re: Flaw in Conditions System?
Date: 
Message-ID: <cf333042.0403260945.48d163bf@posting.google.com>
···········@yahoo.com (Tayssir John Gabbour) wrote in message news:<····························@posting.google.com>...
> A handler "handles" a condition by performing a non-local transfer of
> control: using go, return, or throw.

I suspect that a non-local transfer in this context means that the
handler terminates other than by a normal return. A normal return
passes control back to the handler-searching subsystem which then
searches for the next handler. A non-local return will pass through
that subsystem, invoking just unwind-protect blocks embedded in it.
This is what causes the condition to be handled, this non-local jump
bypass over the search for the next handler.
From: Barry Margolin
Subject: Re: Flaw in Conditions System?
Date: 
Message-ID: <barmar-859698.06014129032004@comcast.ash.giganews.com>
In article <····························@posting.google.com>,
 ···@ashi.footprints.net (Kaz Kylheku) wrote:

> ···········@yahoo.com (Tayssir John Gabbour) wrote in message 
> news:<····························@posting.google.com>...
> > A handler "handles" a condition by performing a non-local transfer of
> > control: using go, return, or throw.
> 
> I suspect that a non-local transfer in this context means that the
> handler terminates other than by a normal return. A normal return
> passes control back to the handler-searching subsystem which then
> searches for the next handler. A non-local return will pass through
> that subsystem, invoking just unwind-protect blocks embedded in it.
> This is what causes the condition to be handled, this non-local jump
> bypass over the search for the next handler.

What I think the OP didn't realize is that "local" and "non-local" are 
inherently relative terms.  Thus, in the following code:

(block foo
  (tagbody
     (block bar
        (go target))
     target))

The GO is a non-local transfer out of the BAR block, but local within 
the FOO block.

The same should be understood for transfers in condition handlers.  It's 
only considered to be non-local if it the target is outside the handler 
function.

-- 
Barry Margolin, ······@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***