🚀 go-pugleaf

In <6245@goanna.cs.rmit.oz.au> I wrote
> If something called catch/throw *does* undo my variable bindings, I am
> going to be _very_ annoyed, and I will write nasty letters to the
> vendor in question for providing me with a useless implementation of
> non-local exit.

In article <3946@n-kulcs.cs.kuleuven.ac.be>,
bimbart@hera.cs.kuleuven.ac.be (Bart Demoen) writes:
> catch/throw as currently defined by WG17, undo the variable bindings; still,
> that doesn't make them useless for an alternative SUCCESS continuation,
> because through the ball you 'throw' and its unification with the catcher,
> you can pass any information from deep down, higher up; e.g.
> 
> 	var(X), catch((X=1, throw(X)),X,true)
> 	=> X == 1
> 
> it doesn't look very nice, but at least you have the option.

No, I'm afraid that doesn't do the job.  It can only restore the
bindings of variables that (occur in the bindings of variables
that) are visible at the point of the throw.  If I do

	var(X), catch(Ball, (X = 1, p(Ball)), true)

there is no definition I can give to p/1 which will result in the
value of X being preserved.

My main points remain:
(1) The Lisp community, from which the names `catch' and `throw'
    were ``borrowed'', distinguishes between non-local control transfer
    (in Scheme, this is analogous to backtracking) and exception
    handling, and catch/throw are NOT the exception handling tools.
    The kind of unnecessary confusion this introduces (I'm reading
    a Mach manual set at the moment, and `catch' does _not_ refer to
    exception handling there either) could be compared, say, to
    forcing people to say ``interrupt'' instead of ``system call''.
    If we use operation names borrowed from another WIDELY KNOWN
    language or family of languages, we should not be so discourteous
    as to assign meanings to them so greatly at variance with what
    they meant in their ``home'' language.  (A linguistic parallel:
    I believe `divan' originally meant a bound book of poems.)

(2) The interaction of exception handling with coroutining needs to
    be explicitly addressed.  It is _not_ a trivial generalisation of
    the strictly ordered case.

I would again suggest that the dynamic-wind construct found in many
Schemes would repay study.

-- 
Q:  What should I know about quicksort?   A:  That it is *slow*.
Q:  When should I use it?  A:  When you have only 256 words of main storage.