From: Zelphir Kaltstahl <zelphirkaltstahl@posteo.de>
To: Catonano <catonano@gmail.com>, Chris Vine <vine35792468@gmail.com>
Cc: Guile User <guile-user@gnu.org>
Subject: Re: "Missing" libraries/concepts found in other languages/ecosystems?
Date: Sun, 12 Jul 2020 22:33:22 +0200 [thread overview]
Message-ID: <fc6b8fbe-19e0-a73e-e45f-97896316adf1@posteo.de> (raw)
In-Reply-To: <CAJ98PDztX4_aa=7si_oCLTLQxCSFCQyNOfMCvzZ-K=9MuF7ddg@mail.gmail.com>
Hi!
On 7/12/20 6:08 PM, Catonano wrote:
> Il giorno sab 11 lug 2020 alle ore 12:14 Chris Vine <vine35792468@gmail.com>
> ha scritto:
>
>> 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 it can be of any help, I applied your suggestions to the original
> example
>
> This is supposed to be compatible with Guile 3.x only
>
> Here it is (a question follows)
>
> (define even-simpler-display
> (lambda (sth)
> (display
> (simple-format
> #f "~a\n" sth))))
>
>
> (define divide
> (lambda (a b)
> (cond
> [(= b 0)
> (raise-continuable
> (make-exception
> (make-exception-with-message "division by zero")
> (make-exception-with-irritants (list a b))
> (make-exception-with-origin 'divide)))]
> [else
> (/ a b)])))
>
>
> (with-exception-handler
> (lambda (conditions-or-value)
> (even-simpler-display
> ;; We can get the simple exceptions from a compound exception with
> the
> ;; `simple-exceptions` getter.
> (simple-exceptions conditions-or-value)))
> (lambda ()
> (divide 2 0))
> #:unwind? #t)
>
> I run this in the REPL and it seems to work
>
> The question, now, is:
>
> say that the exception handler knows (somehow) that the correct divisor is
> 1 rather than 0
>
> So we are saying that this exception is continuable
>
> How would we continue ?
>
> Can "divide" return as if it had been called with 1 as its second argument ?
>
> Or have I misunderstood ?
>
> How would you go about that ?
Ah, I started putting "to do changes" in a list to apply them later,
with better understanding:
https://notabug.org/ZelphirKaltstahl/guile-examples/src/d670fa02369918cd3fa896cc19d5aa82966f64a3/exception-handling/notes.org
I was going to come back to points, if I do not understand anything
properly.
Perhaps I can already copy some parts from here^^
Thanks!
Zelphir
next prev parent reply other threads:[~2020-07-12 20:33 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <mailman.75.1594224014.21222.guile-user@gnu.org>
2020-07-08 18:22 ` "Missing" libraries/concepts found in other languages/ecosystems? Zelphir Kaltstahl
2020-07-09 18:12 ` Leo Butler
2020-07-09 19:34 ` Zelphir Kaltstahl
2020-07-10 7:39 ` Aleix Conchillo Flaqué
2020-07-10 8:14 ` Alex Sassmannshausen
2020-07-10 8:49 ` Catonano
2020-07-10 10:21 ` Chris Vine
2020-07-10 11:20 ` Catonano
2020-07-11 0:19 ` Zelphir Kaltstahl
2020-07-11 0:34 ` Zelphir Kaltstahl
2020-07-11 10:14 ` Chris Vine
2020-07-11 13:45 ` Stefan Israelsson Tampe
2020-07-11 14:46 ` Linus Björnstam
2020-07-11 10:13 ` Chris Vine
2020-07-11 18:20 ` John Cowan
2020-07-11 22:39 ` Chris Vine
2020-07-11 22:41 ` John Cowan
2020-07-11 23:09 ` Chris Vine
2020-07-12 1:52 ` John Cowan
2020-07-12 20:26 ` Chris Vine
2020-07-13 10:10 ` Chris Vine
2020-07-12 16:08 ` Catonano
2020-07-12 16:10 ` Catonano
2020-07-12 17:46 ` John Cowan
2020-07-12 19:14 ` Chris Vine
2020-07-12 19:32 ` Chris Vine
2020-07-14 10:32 ` Catonano
2020-07-14 11:06 ` Catonano
2020-07-14 16:21 ` Chris Vine
2020-07-12 20:33 ` Zelphir Kaltstahl [this message]
2020-07-08 7:38 Simen Endsjø
2020-07-08 8:15 ` Vladimir Zhbanov
2020-07-08 10:08 ` Catonano
2020-07-08 11:29 ` Chris Vine
2020-07-10 12:15 ` Christopher Lam
2020-07-10 15:52 ` Chris Vine
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/guile/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=fc6b8fbe-19e0-a73e-e45f-97896316adf1@posteo.de \
--to=zelphirkaltstahl@posteo.de \
--cc=catonano@gmail.com \
--cc=guile-user@gnu.org \
--cc=vine35792468@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).