[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Backtrace and enhanced catch
From: |
Neil Jerram |
Subject: |
Re: Backtrace and enhanced catch |
Date: |
Mon, 23 Jan 2006 20:11:11 +0000 |
User-agent: |
Gnus/5.1007 (Gnus v5.10.7) Emacs/21.4 (gnu/linux) |
Marius Vollmer <address@hidden> writes:
> Neil Jerram <address@hidden> writes:
>
>> The main part of this patch is appended below, and I would appreciate
>> any comments that anyone may have
>
> Looks very good to me. Please go ahead. Thanks!
Great; thanks for the review.
> One (minor?) point I have is the term "lazy". I am not sure if it is
> the right term to use. It has meaning for people who already know
> lazy-catch, but I'd say it is not really descriptive of what it does.
> Something like "pre-unwind" handler might give a better hint of how it
> differs from the 'post-unwind' handler.
>
> Hmm, what I'm trying to say here that "lazy" is not some standard,
> established terminology, and if we come up with something better, we
> should feel free to change terminology.
Yes, that makes good sense. I can't think of anything better than
"pre-unwind", so I'll use that in all new names. I don't think it's
worth changing any preexisting names though, such as struct lazy_catch
- do you agree?
>> One point is that I have removed the "SCM_API" from the declaration of
>> scm_i_with_continuation_barrier. My understanding is that
>> scm_i_with_continuation_barrier (like scm_i_* functions in general) is
>> a libguile-internal function and so does not need to be exported from
>> the libguile DLL in a Windows build (which is what SCM_API is for).
>
> Yeah. I have to say that I don't really understand the meaning of
> SCM_API. I mostly treat it is as a purely technical thing: you need
> to use it when you want code outside this DLL to call the function. I
> don't treat it as a way to document what is in the Guile API and what
> isn't.
>
> For example, macro or inline function that is in the Guile API might
> expand into a call to a scm_i_ function. That function than needs to
> be flagged with SCM_API although it is not part of the API.
>
> I see no point in preventing people from calling internal functions as
> long as they know that they are internal. That's why I put SCM_API on
> all functions with global scope.
OK, that makes sense too, so long as we don't have to worry about
preserving source compatibility for functions that have SCM_API but
are not part of the Guile API. And my understanding is that "part of
the Guile API" <=> "documented in the manual".
Regards,
Neil
- Re: No way out., Han-Wen Nienhuys, 2006/01/01
- Message not available
- Re: No way out., Han-Wen Nienhuys, 2006/01/01
- Re: No way out., Neil Jerram, 2006/01/02
- Re: No way out., Neil Jerram, 2006/01/02
- Backtrace and enhanced catch, Neil Jerram, 2006/01/04
- Re: Backtrace and enhanced catch, Neil Jerram, 2006/01/14
- Re: Backtrace and enhanced catch, Marius Vollmer, 2006/01/22
- Re: Backtrace and enhanced catch,
Neil Jerram <=
- Re: Backtrace and enhanced catch, Marius Vollmer, 2006/01/24
- Re: Backtrace and enhanced catch, Ludovic Courtès, 2006/01/16
- Re: Backtrace and enhanced catch, Neil Jerram, 2006/01/18
- Re: Backtrace and enhanced catch, Ludovic Courtès, 2006/01/19
- Re: Backtrace and enhanced catch, Neil Jerram, 2006/01/21
- Re: Backtrace and enhanced catch, Kevin Ryde, 2006/01/26
- Re: Backtrace and enhanced catch, Neil Jerram, 2006/01/27
- Re: Backtrace and enhanced catch, Kevin Ryde, 2006/01/31