emacs-devel
[Top][All Lists]
Advanced

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

Re: Using the GNU GMP Library for Bignums in Emacs


From: Paul Eggert
Subject: Re: Using the GNU GMP Library for Bignums in Emacs
Date: Tue, 10 Jul 2018 19:35:15 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0

I read this thread and I still don't know what a use case for this would be.

Yes, I'm not seeing it either.

it's simpler to explain that there are just integers.

Yes, and this is a significant win.

If interning bignums (so that eq works on them) is what it takes to satify Stefan's concerns, then I'm all for interning them. The idea is to avoid unnecessary distinctions between fixnums and bignums, so that Lisp programmers can focus on their problems rather than worry about integer representation. Although it's OK to have user-visible predicates fixnump and bignump for the few programmers who really need to know, I'm not seeing use cases for why these predicates should be any more special than characterp or natnump are.


>> why would someone want to specialize a method just for fixnums, as
>> opposed to a method for integers?
>
> cl-generic has no trouble dispatching on a supertype of that returned by
> `type-of`.

That's fine, but I was asking for use cases not implementation motivation. THat is, I was wondering why a Lisp programmer would want to use cl-generic that way. Having cl-generic distinguish fixnums from bignums sounds like more a solution looking for a problem than a truly useful feature.

>> The basic operations +, -, * etc. aren't specialized for fixnums.
>
> Actually, they are, but this is done by manual type-testing in the
> C code, not with cl-defmethod.

Yes, of course: with basic operations it's done under the hood, and Lisp programmers don't need to worry about the details. This is a reasonable programming style for Emacs Lisp, and it'd be a good thing if this style were used as consistently as possible, to keep things simpler.



reply via email to

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