Elisp / C inconsistency for reading "1."

Elisp / C inconsistency for reading "1."

[Oleh Krehel]

Hi all,

I understand that it's documented in the manual that "1." is an
integer and not a float, but this feels very wrong coming from a C
background.

And a nuisance when I want to quickly compute a percentage in
*scratch*:

    (/ 123. 338)
    ;; => 0

Then I see the error, get annoyed and change to "123.0".
This happens a lot.

Is there any chance for this to be changed?

I did rgrep for "[0-9]\.[^0-9a-zA-Z]" across the emacs/lisp directory
and got 2250 hits.  Filtering that by code-only gives 38 hits, more
then half in vc-annotate.el.  Out of the ELPA/MELPA packages that I
use, the only hits were in zenburn-theme.el.

So it seems to me that this is an easy change to make: since most
Elisp code almost never uses the trailing decimal point in integers
anyway, make the changes to the 38 hits I mentioned above (just remove
the dot) and enforce this style with a compile-time warning/error. At
the same time change the reader to interpret "1." as a float thus
increasing the convenience of an interactive eval.

regards,
Oleh

Re: Elisp / C inconsistency for reading "1."

[Paul Eggert]

Oleh Krehel wrote:
> I understand that it's documented in the manual that "1." is an
> integer and not a float, but this feels very wrong coming from a C
> background.

More important, it feels wrong coming from a Lisp background, as Common 
Lisp and Scheme both interpret "1." to be a floating point number.  I 
would support changing Emacs Lisp to be consistent with common practice, 
as there seems no point to being different and there are advantages to 
being consistent.  (Not during the feature freeze though, of course.)

Re: Elisp / C inconsistency for reading "1."

[Stefan]

> More important, it feels wrong coming from a Lisp background, as Common Lisp
> and Scheme both interpret "1." to be a floating point number.  I would
> support changing Emacs Lisp to be consistent with common practice, as there
> seems no point to being different and there are advantages to being
> consistent.  (Not during the feature freeze though, of course.)

I'd tend to agree, indeed.


        Stefan

Re: Elisp / C inconsistency for reading "1."

[Wolfgang Jenkner]

On Fri, Mar 14 2014, Stefan wrote:

>> More important, it feels wrong coming from a Lisp background, as Common Lisp
>> and Scheme both interpret "1." to be a floating point number.  I would
>> support changing Emacs Lisp to be consistent with common practice, as there
>> seems no point to being different and there are advantages to being
>> consistent.  (Not during the feature freeze though, of course.)
>
> I'd tend to agree, indeed.

But please don't base your opinion on a wrong assumption about Common
Lisp, see [1],

	Integers can be written as a sequence of digits [...]
	optionally followed by a decimal point;
        
And, to be really pedantic, let's add that `integer' and `float' are
disjoint types, see [2],

	The types rational and float are disjoint subtypes of type real.

and [3],

	The types integer and ratio are disjoint subtypes of type
	rational.
        
This remark is actually pertinent here, because the emacs CL package
seems to emulate these type relations (as far as corresponding objects
exist in emacs-lisp).

(cl-typep 1. 'integer)
=> t
(cl-typep 1. 'float)
=> nil

[1] http://www.lispworks.com/documentation/HyperSpec/Body/02_cbaa.htm
[2] http://www.lispworks.com/documentation/HyperSpec/Body/t_real.htm
[3] http://www.lispworks.com/documentation/HyperSpec/Body/t_ration.htm

Wolfgang

Re: Elisp / C inconsistency for reading "1."

[David Kastrup]

Wolfgang Jenkner <wjenkner@inode.at> writes:

> On Fri, Mar 14 2014, Stefan wrote:
>
>>> More important, it feels wrong coming from a Lisp background, as Common Lisp
>>> and Scheme both interpret "1." to be a floating point number.  I would
>>> support changing Emacs Lisp to be consistent with common practice, as there
>>> seems no point to being different and there are advantages to being
>>> consistent.  (Not during the feature freeze though, of course.)
>>
>> I'd tend to agree, indeed.
>
> But please don't base your opinion on a wrong assumption about Common
> Lisp, see [1],
>
> 	Integers can be written as a sequence of digits [...]
> 	optionally followed by a decimal point;
>         
> And, to be really pedantic, let's add that `integer' and `float' are
> disjoint types, see [2],
>
> 	The types rational and float are disjoint subtypes of type real.
>
> and [3],
>
> 	The types integer and ratio are disjoint subtypes of type
> 	rational.
>         
> This remark is actually pertinent here, because the emacs CL package
> seems to emulate these type relations (as far as corresponding objects
> exist in emacs-lisp).
>
> (cl-typep 1. 'integer)
> => t
> (cl-typep 1. 'float)
> => nil
>
> [1] http://www.lispworks.com/documentation/HyperSpec/Body/02_cbaa.htm
> [2] http://www.lispworks.com/documentation/HyperSpec/Body/t_real.htm
> [3] http://www.lispworks.com/documentation/HyperSpec/Body/t_ration.htm

And indeed:

$ clisp
  i i i i i i i       ooooo    o        ooooooo   ooooo   ooooo
  I I I I I I I      8     8   8           8     8     o  8    8
  I  \ `+' /  I      8         8           8     8        8    8
   \  `-+-'  /       8         8           8      ooooo   8oooo
    `-__|__-'        8         8           8           8  8
        |            8     o   8           8     o     8  8
  ------+------       ooooo    8oooooo  ooo8ooo   ooooo   8

Welcome to GNU CLISP 2.49 (2010-07-07) <http://clisp.cons.org/>

Copyright (c) Bruno Haible, Michael Stoll 1992, 1993
Copyright (c) Bruno Haible, Marcus Daniels 1994-1997
Copyright (c) Bruno Haible, Pierpaolo Bernardi, Sam Steingold 1998
Copyright (c) Bruno Haible, Sam Steingold 1999-2000
Copyright (c) Sam Steingold, Bruno Haible 2001-2010

Type :h and hit Enter for context help.

[1]> 1.
1
[2]> 1.0
1.0
[3]> 


-- 
David Kastrup

Re: Elisp / C inconsistency for reading "1."

[Simon Leinen]

[-- Attachment #1: Type: text/plain, Size: 1420 bytes --]

On Sat, Mar 15, 2014 at 5:21 PM, Wolfgang Jenkner <wjenkner@inode.at> wrote:

> But please don't base your opinion on a wrong assumption about Common
> Lisp, see [1],
>
>         Integers can be written as a sequence of digits [...]
>         optionally followed by a decimal point;


Thanks for the reminder!

In case anyone wonders why Common Lisp does it this way: CL has
*READ-BASE*, which allows integers to be parsed and unparsed in bases other
than decimal.  I think this came from Maclisp, one of the more important
Lisp dialects that CL wanted to unify.  Maclisp defaulted to interpreting
digit-sequences as octal(!).

So in Common Lisp, when you want to make sure you're in "decimal" mode,
    (SETQ *READ-BASE* 10.)
makes more sense than just
    (SETQ *READ-BASE* 10)
and reads better than e.g.
    (SETQ *READ-BASE* (+ 1 1 1 1 1 1 1 1 1 1))

Sorry for the digression.  As for how Emacs should interpret numbers with a
trailing dot: If we want to keep Emacs Lisp aligned with Common Lisp, then
we should continue to treat them as decimal integers, and live with the
fact that users coming from other languages may have to learn to type "1.0"
instead of "1." when they want floats.  Personally I don't have a strong
opinion, although I have a slight preference to value CL compatibility
higher than convenience for non-native Lisp speakers in this case.  "1."
just doesn't look real float'y to me.
-- 
Simon.

[-- Attachment #2: Type: text/html, Size: 1965 bytes --]

Re: Elisp / C inconsistency for reading "1."

[Paul Eggert]

Wolfgang Jenkner wrote:
> But please don't base your opinion on a wrong assumption about Common
> Lisp, see [1],

Ah, sorry, I relied on the Common Lisp specification's EBNF for 
floating-point-number, which is incorrect.  Never mind, then.