lilypond-devel
[Top][All Lists]
Advanced

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

Re: Likely a good frog project for someone with C knowledge


From: David Kastrup
Subject: Re: Likely a good frog project for someone with C knowledge
Date: Wed, 17 Aug 2011 14:41:26 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux)

Han-Wen Nienhuys <address@hidden> writes:

> On Wed, Aug 17, 2011 at 5:19 AM, David Kastrup <address@hidden> wrote:
>
>> That would be scm_is_null (x).  It is not exactly like the code gets
>> less readable by that substitution.
>
> it's not the same though. scm_is_null expands to
>
> pairs.h:#define scm_is_null(x)                (scm_is_null_or_nil(x))

That would be a newer development, I guess.  In the 1.8 sources this
just compares to SCM_EOL.

> on the plus side, if we use this, we will be the first GNU program to
> be compatible with the elisp compatibility mode in GUILE that has been
> almost ready for the last 15 years.

I should say that would be rather irrelevant as a design goal.  In any
case, the respective define in current master (2.whatever) is

/*
 * See the comments preceeding the definitions of SCM_BOOL_F and
 * SCM_MATCHES_BITS_IN_COMMON in tags.h for more information on
 * how the following macro works.
 */
#define scm_is_null_or_nil(x)  \
  (SCM_MATCHES_BITS_IN_COMMON ((x), SCM_ELISP_NIL, SCM_EOL))

Now that's presumably hardly less efficient, in particular not requiring
an additional branch.  I have a hard time imagining why it would make
sense to let Lisp compatibility invade the API like that, but short of
making the assembly code look somewhat unexpected, it would not likely
affect performance.

-- 
David Kastrup



reply via email to

[Prev in Thread] Current Thread [Next in Thread]