guile-user
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: "Missing" libraries/concepts found in other languages/ecosystems?


From: Chris Vine
Subject: Re: "Missing" libraries/concepts found in other languages/ecosystems?
Date: Sat, 11 Jul 2020 11:13:59 +0100

On Sat, 11 Jul 2020 02:19:43 +0200
Zelphir Kaltstahl <zelphirkaltstahl@posteo.de> wrote:
[snip]
> I would be glad, if any non-optimal example was extended or updated by a
> more knowledgeable person or I was told what I could improve in some
> example. The examples in the repository are only, what I was able to
> understand and I often find myself looking up, how to do something again.
> 
> If anyone wants to take any example and put it in the docs, go ahead.
> Only don't think that my examples are the last word on how to do things.
> Far from it!
> 
> About the exceptions thing: Aha! I should look into that again. I
> thought the "conditions" thing was already pretty cool and useful. Once
> an exception happens, you can react on it. I did not understand the
> "call/ec helper" part, but perhaps I can understand it, when I check the
> docs for the new exceptions in Guile 3.

The issue is that "non-continuable" in "non-continuable exception" does
not mean an exception that the program cannot survive, it means an
exception for which, after handling, control cannot return to the point
at which the exception was raised[1].  (To answer the question in your
following email, continuable exceptions are in some sense analogous to
common lisp restarts.)  Most guile exceptions are non-continuable.  The
point arising from this is that in the case of a non-continuable
exception the handler procedure passed to with-exception-handler must
not return, or a &non-continuable exception will be raised when
control does attempt to return.

With R6RS/R7RS's with-exception-handler, for non-continuable exceptions
the handler procedure should normally therefore either invoke a call/ec
continuation object to unwind the stack to the point where the
exception is handled, or it should (after it has done what it is
intended to do) re-raise the exception to be handled and/or unwound
elsewhere.  Guile-3.0's with-exception-handler procedure will do the
former for you automatically if you set its #:unwind? argument to
true.  The nearest to guile-2.2's catch expression in guile-3.0's
exception system is to use with-exception-handler with #:unwind? set
as #t.  R6RS/R7RS's guard form is a wrapper for this which also
incorporates a cond form to enable different exception types to be
handled by different handlers. 

I therefore suggest that your first example using
with-exception-handler should set #:unwind? to #t so that the program
does not end with a &non-continuable exception.  I also suggest that,
if intended for guile-3.0 and not guile-2.2, you should use guile's
exception objects rather than R6RS conditions (basically you use
'make-exception' instead of 'condition' - the two are in effect the
same).

If intended also for guile-2.2 the other issue is that its R6RS/R7RS
exception procedures can only handle R6RS/R7RS exceptions emitted by
raise or raise-continuable, and not guile exceptions raised by throw.
This means that your divide by 0 example will not work in guile-2.2.

Chris

[1]  Microsoft in its C++ and .NET languages amalgamates machine
exceptions, and some signal exceptions, with language exceptions.  In
their nomenclature "non-continuable exception" does mean an exception
that the program cannot survive, such as SIGSEGV or an irrecoverable
hardware exception.  This is not however its general meaning.  Most
languages do not have continuable exceptions.  Scheme, common lisp and
smalltalk do.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]