From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Simon Leinen Newsgroups: gmane.emacs.devel Subject: Re: Elisp / C inconsistency for reading "1." Date: Sat, 15 Mar 2014 19:39:43 +0100 Message-ID: References: <53231298.9090905@cs.ucla.edu> <85vbvf8m3j.fsf@iznogoud.viz> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a11c12d088877dc04f4a982ea X-Trace: ger.gmane.org 1394908782 29298 80.91.229.3 (15 Mar 2014 18:39:42 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 15 Mar 2014 18:39:42 +0000 (UTC) To: Stefan , Paul Eggert , Oleh Krehel , emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Mar 15 19:39:51 2014 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1WOtUs-0006Aq-Db for ged-emacs-devel@m.gmane.org; Sat, 15 Mar 2014 19:39:50 +0100 Original-Received: from localhost ([::1]:50862 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WOtUr-00059C-Rc for ged-emacs-devel@m.gmane.org; Sat, 15 Mar 2014 14:39:49 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:46522) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WOtUn-00058x-K6 for emacs-devel@gnu.org; Sat, 15 Mar 2014 14:39:46 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WOtUm-00072o-Ey for emacs-devel@gnu.org; Sat, 15 Mar 2014 14:39:45 -0400 Original-Received: from mail-qa0-x234.google.com ([2607:f8b0:400d:c00::234]:64460) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WOtUm-00072k-9z for emacs-devel@gnu.org; Sat, 15 Mar 2014 14:39:44 -0400 Original-Received: by mail-qa0-f52.google.com with SMTP id m5so3826216qaj.39 for ; Sat, 15 Mar 2014 11:39:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=OIgTw9UXG+votmbh3bM0ZYnHdcp6fo+mQ28nCJuY8gc=; b=CqtiUKI46q37aazt4v2tOwvAJ4Egg40e5kt65k9XlW00VtFkRhUjbOp0ETY9fX8+Or QJi8RzsVdwl/Apajz/EGQ2B4JZ7xb4Ud+7Biextf1PYSo3LhzglPEdx0U2QKRFANpObu +EwrybaAhnM/WjUn1VlzdJKgW1SH077xKx7Vk7x4cSYRw8tVMAXauaBJsB7pOYUG9P5j 18ovd6R3bvkQ42eZoucUOw8Bra/eX4C0kc0yvc/cSXwxlPj238L9B8s9yxTWA1lNWWkt DybYRYueVTFv6s8a/OU+DYeV+93jOBVPP5fEdao1/vNVHJpSlPCBFzBPLQ/7N5Oal6Iz I7nw== X-Received: by 10.140.81.198 with SMTP id f64mr16840689qgd.38.1394908783472; Sat, 15 Mar 2014 11:39:43 -0700 (PDT) Original-Received: by 10.229.79.200 with HTTP; Sat, 15 Mar 2014 11:39:43 -0700 (PDT) In-Reply-To: <85vbvf8m3j.fsf@iznogoud.viz> X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2607:f8b0:400d:c00::234 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:170399 Archived-At: --001a11c12d088877dc04f4a982ea Content-Type: text/plain; charset=ISO-8859-1 On Sat, Mar 15, 2014 at 5:21 PM, Wolfgang Jenkner 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. --001a11c12d088877dc04f4a982ea Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On S= at, 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],

=A0 =A0 =A0 =A0 Integers can be written as a sequence of digits [...]
=A0 =A0 =A0 =A0 optionally followed by a decimal point;
Thanks for the reminder!

In case anyo= ne wonders why Common Lisp does it this way: CL has *READ-BASE*, which allo= ws integers to be parsed and unparsed in bases other than decimal. =A0I thi= nk this came from Maclisp, one of the more important Lisp dialects that CL = wanted to unify. =A0Maclisp defaulted to interpreting digit-sequences as oc= tal(!).

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

Sorry for the digression. = =A0As for how Emacs should interpret numbers with a trailing dot: If we wan= t to keep Emacs Lisp aligned with Common Lisp, then we should continue to t= reat them as decimal integers, and live with the fact that users coming fro= m other languages may have to learn to type "1.0" instead of &quo= t;1." when they want floats. =A0Personally I don't have a strong o= pinion, although I have a slight preference to value CL compatibility highe= r than convenience for non-native Lisp speakers in this case. =A0"1.&q= uot; just doesn't look real float'y to me.
--=A0
Simon.
--001a11c12d088877dc04f4a982ea--