unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
* Elisp / C inconsistency for reading "1."
@ 2014-03-14 12:13 Oleh Krehel
  2014-03-14 14:30 ` Paul Eggert
  0 siblings, 1 reply; 7+ messages in thread
From: Oleh Krehel @ 2014-03-14 12:13 UTC (permalink / raw)
  To: emacs-devel

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



^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Elisp / C inconsistency for reading "1."
  2014-03-14 12:13 Elisp / C inconsistency for reading "1." Oleh Krehel
@ 2014-03-14 14:30 ` Paul Eggert
  2014-03-14 16:46   ` Stefan
  0 siblings, 1 reply; 7+ messages in thread
From: Paul Eggert @ 2014-03-14 14:30 UTC (permalink / raw)
  To: Oleh Krehel, emacs-devel

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.)



^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Elisp / C inconsistency for reading "1."
  2014-03-14 14:30 ` Paul Eggert
@ 2014-03-14 16:46   ` Stefan
  2014-03-15 16:21     ` Wolfgang Jenkner
  0 siblings, 1 reply; 7+ messages in thread
From: Stefan @ 2014-03-14 16:46 UTC (permalink / raw)
  To: Paul Eggert; +Cc: Oleh Krehel, emacs-devel

> 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



^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Elisp / C inconsistency for reading "1."
  2014-03-14 16:46   ` Stefan
@ 2014-03-15 16:21     ` Wolfgang Jenkner
  2014-03-15 16:43       ` David Kastrup
                         ` (2 more replies)
  0 siblings, 3 replies; 7+ messages in thread
From: Wolfgang Jenkner @ 2014-03-15 16:21 UTC (permalink / raw)
  To: Stefan; +Cc: Paul Eggert, Oleh Krehel, emacs-devel

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



^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Elisp / C inconsistency for reading "1."
  2014-03-15 16:21     ` Wolfgang Jenkner
@ 2014-03-15 16:43       ` David Kastrup
  2014-03-15 18:39       ` Simon Leinen
  2014-03-16  1:31       ` Paul Eggert
  2 siblings, 0 replies; 7+ messages in thread
From: David Kastrup @ 2014-03-15 16:43 UTC (permalink / raw)
  To: emacs-devel

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




^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Elisp / C inconsistency for reading "1."
  2014-03-15 16:21     ` Wolfgang Jenkner
  2014-03-15 16:43       ` David Kastrup
@ 2014-03-15 18:39       ` Simon Leinen
  2014-03-16  1:31       ` Paul Eggert
  2 siblings, 0 replies; 7+ messages in thread
From: Simon Leinen @ 2014-03-15 18:39 UTC (permalink / raw)
  To: Stefan, Paul Eggert, Oleh Krehel, emacs-devel

[-- 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 --]

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Elisp / C inconsistency for reading "1."
  2014-03-15 16:21     ` Wolfgang Jenkner
  2014-03-15 16:43       ` David Kastrup
  2014-03-15 18:39       ` Simon Leinen
@ 2014-03-16  1:31       ` Paul Eggert
  2 siblings, 0 replies; 7+ messages in thread
From: Paul Eggert @ 2014-03-16  1:31 UTC (permalink / raw)
  To: Stefan, Oleh Krehel, emacs-devel

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.




^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2014-03-16  1:31 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-03-14 12:13 Elisp / C inconsistency for reading "1." Oleh Krehel
2014-03-14 14:30 ` Paul Eggert
2014-03-14 16:46   ` Stefan
2014-03-15 16:21     ` Wolfgang Jenkner
2014-03-15 16:43       ` David Kastrup
2014-03-15 18:39       ` Simon Leinen
2014-03-16  1:31       ` Paul Eggert

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).