Han-Wen Nienhuys <hanw...@gmail.com> writes: > On Wed, Aug 17, 2011 at 5:19 AM, David Kastrup <d...@gnu.org> 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 _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
