<dancol@dancol.org> schrieb am So., 22. Apr. 2018 um 04:49 Uhr:
> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
>   > Of course we could to do that. Hopefully there isn't existing
>   > Emacs Lisp code that relies on unsafe arithmetic /anywhere/. If the
>   > functions + - * / operate on bignums (instead of dedicated bignum
>   > functions), would that mean we drop 32/64 bit integers entirely?
>
> To eliminate the current types for small integers would
> require rewriting of much of the C code in Emacs.
> It would be better to represent small integers as now,
> and have a different structure for larger integers.
>

I'd love to see Emacs get transparent bigint support. Python semantics are
fine, as is using a normal int representation at the C level. Adding
transparent bigints as Lisp types doesn't require us to increase various
Emacs core limits right away.



We need to be very careful with transparent bigint support though, as a naive design will break many invariants. For example, integers are currently documented to use modular arithmetic (https://www.gnu.org/software/emacs/manual/html_node/elisp/Integer-Type.htmlhttps://www.gnu.org/software/emacs/manual/html_node/elisp/Integer-Basics.html), and they are documented to be pure value types, i.e. same-valued integers are the same object (https://www.gnu.org/software/emacs/manual/html_node/elisp/Equality-Predicates.html). Especially the second property is widely used.