Re: non-local exits are icky

[Tom Lord <lord@xxxxxxx>]

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.

-t






    > 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 (1.212.2.1-2003-12-09-exp) 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
    > 
    > 
    >