Dan Eble <d...@faithful.be> writes:
> On Jul 4, 2018, at 07:29, David Kastrup <d...@gnu.org> wrote:
>>
>> Having our own ly_is_integer variant map to the Guile-2 version
>> conditionally is simple, and when we do it wrong, there is an obvious
>> missing symbol at link time. Or stuff works without complaint.
>
> That’s fine, but if it’s going to be a proxy for scm_is_exact_integer
> in the long run, the name ly_is_exact_integer gets my vote.
I don't like the verbosity (basically it can make expressions wrap
around that fit previously). But I admit that this does not really make
for a compelling argument.
One argument not to use scm_is_exact_integer is that we cannot know
whether this is going to be a macro or a function, and our type error
messages actually look up function addresses.
So in order to check, I did one git fetch and discovered that someone is
committing to the 1.8 release branch (Thien-Thi Nguyen) bringing it back
into compilability. That should be interesting information for
self-compilers.
At any rate:
origin:libguile/numbers.c-
origin:libguile/numbers.c-int
origin:libguile/numbers.c:scm_is_exact_integer (SCM val)
origin:libguile/numbers.c-{
origin:libguile/numbers.c- return scm_is_true (scm_exact_integer_p (val));
origin:libguile/numbers.c-}
At least this one is at least at the current point of time in current
master a function (and not a macro).
--
David Kastrup
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
