[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: non-local exits are icky
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,
> 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 (184.108.40.206-2003-12-09-exp) on
> 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.
> 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