Re: non-local exits are icky Tom Lord 04 Jan 2004 01:19 UTC
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: <xxxxxx@informatik.uni-tuebingen.de> > Cc: srfi-50@srfi.schemers.org > From: Michael Sperber <xxxxxx@informatik.uni-tuebingen.de> > 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@srfi.schemers.org > X-Mailing-List: <srfi-50@srfi.schemers.org> archive/latest/135 > X-Loop: srfi-50@srfi.schemers.org > List-Post: <mailto:srfi-50@srfi.schemers.org> > List-Help: <mailto:srfi-50xxxxxx@srfi.schemers.org?subject=help> > List-Subscribe: <mailto:srfi-50xxxxxx@srfi.schemers.org?subject=subscribe> > List-Unsubscribe: <mailto:srfi-50xxxxxx@srfi.schemers.org?subject=unsubscribe> > Precedence: list > Resent-Sender: srfi-50xxxxxx@srfi.schemers.org > 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 <xxxxxx@emf.net> 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 > > >