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

Re: non-local exits are icky

This page is part of the web mail archives of SRFI 50 from before July 7th, 2015. The new archives for SRFI 50 contain all messages, not just those from before July 7th, 2015.

Thank you.   

I'd like to take this (the non-local exit) issue up -- but I _think_
that will be far easier if we first fix the calling conventions.

Better non-local exit handling gives additional excuses for changing
the calling conventions -- so maybe we should take this up now.

But on the other hand, we have plenty of reasons for new calling
conventions already -- and once we pick the Pika conventions ( :-), 
better solutions for non-local exits will be pretty easy to motivate.


    > Old-Return-Path: <sperber@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
    > Cc: srfi-50@xxxxxxxxxxxxxxxxx
    > From: Michael Sperber <sperber@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
    > Date: Sat, 03 Jan 2004 17:16:00 +0100
    > User-Agent: Gnus/5.090019 (Oort Gnus v0.19) XEmacs/21.5 (celeriac,
    >  berkeley-unix)
    > Content-Type: text/plain; charset=iso-8859-1
    > Resent-From: srfi-50@xxxxxxxxxxxxxxxxx
    > X-Mailing-List: <srfi-50@xxxxxxxxxxxxxxxxx> archive/latest/135
    > X-Loop: srfi-50@xxxxxxxxxxxxxxxxx
    > List-Post: <mailto:srfi-50@xxxxxxxxxxxxxxxxx>
    > List-Help: <mailto:srfi-50-request@xxxxxxxxxxxxxxxxx?subject=help>
    > List-Subscribe: <mailto:srfi-50-request@xxxxxxxxxxxxxxxxx?subject=subscribe>
    > List-Unsubscribe: <mailto:srfi-50-request@xxxxxxxxxxxxxxxxx?subject=unsubscribe>
    > Precedence: list
    > Resent-Sender: srfi-50-request@xxxxxxxxxxxxxxxxx
    > X-Spam-Checker-Version: SpamAssassin 2.61 ( on 
    > 	mail.42inc.com
    > X-Spam-DCC: sonic.net: mail 1156; Body=2 Fuz1=2 Fuz2=2
    > X-Spam-Status: No, hits=-2.3 required=4.5 tests=AWL autolearn=no version=2.61
    > X-42email-MailScanner-Information: Please contact http://www.42inc.com/support.html for more information.
    > X-42email-MailScanner: Found to be clean
    > X-UIDL: 0e0ec4f8ba19dd44eec9b04fda5b6887
    > >>>>> "Tom" == Tom Lord <lord@xxxxxxx> writes:
    > Tom> To test my understanding, and before replying to the proposal further,
    > Tom> let me just say back to you two things that I think you would agree
    > Tom> with (and think are obviously true):
    > Tom> 1) Non-local exits to upward continuations currently afford no
    > Tom>    general mechanism for cleanups in FFI-using C.
    > Yes.
    > Tom>    Later SRFIs will have to add
    > Tom>    additional mechanisms to the FFI to handle such situations.
    > Yes, provided that they are necessary.  I'm not convinced they are,
    > but that's irrelevant here.
    > Tom> 2) The specification of error signalling could be made clearer:
    > That's probably true.
    > Tom>    but is could say something more like:
    > Tom>         The following macros explicitly signal certain errors.
    > Tom>         If an error is signalled, either: [...]
    > That's arguable, but not what I intended.  What I intended was that
    > the "an error is signalled" means the same thing as in R5RS, whatever
    > that is for a given Scheme implementation.  In particular, what you
    > propose ...
    > Tom>           1) the computation must be terminated
    > Tom>           2) the computation may be continued in part by invoking
    > Tom>              a continuation which is upwards relative to the 
    > Tom>              C call that triggered the error.  (see "Calling Scheme
    > Tom>              procedures from C".)
    > ... seems to leave as much room for interpretation as what's in there now.
    > -- 
    > Cheers =8-} Mike
    > Friede, V?ölkerverst?ändigung und ?überhaupt blabla