all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: "Drew Adams" <drew.adams@oracle.com>
To: "'Stefan Monnier'" <monnier@IRO.UMontreal.CA>,
	"'Chong Yidong'" <cyd@stupidchicken.com>
Cc: emacs-devel@gnu.org
Subject: RE: e and pi
Date: Fri, 17 Sep 2010 09:14:57 -0700	[thread overview]
Message-ID: <F99D50BB46EB4F908E6321EA6836A568@us.oracle.com> (raw)
In-Reply-To: <jwvsk18fmeu.fsf-monnier+emacs@gnu.org>

> because "e" happens to be a predefined global variable with
> dynamic-scoping semantics.  Now for people who use such magic 
> numerical constants often (e.g. in the context of Calc), this
> may seem like an obvious no-no, but for a poor theoretician
> like me who uses "e" days-in-days-out to mean "expression",
> not being able to reliably use "e" as a free variable of a
> closure is a real trap.
> 
> BTW, the worst of the two is `e' and AFAIK it only has a single use in
> Emacs, which is as the initial value of the register "e" in
> calculator.el.
> 
> At least `pi' is used a few more times, and it is not let-bound
> anywhere, so we could decide to make `pi' lexically-scoped 
> and it would apparently work OK, but `e' OTOH is let-bound at
> many places, so it's not at all obvious that making it
> lexically-scoped wouldn't introduce subtle bugs.  Of course,
> this idea of making `pi' and `e' lexically scoped itself depends
> on how one would force lexical-scoping for a few special vars in
> files compiled with dynamic-scoping; something which the
> current lexbind doesn't support right now.

I'll offer my view only once here - and no flames please.

It is _ridiculous_ to ever have given such global vars (constants) these names
in the first place.  I said it long ago and repeat it now that everyone is
trying to jump through fancy hoops to deal with this.

It is sufficient to define global constants with long, clear names, and let any
code that really wants to use short names bind vars locally to the constants.

Just cut the cord and deprecate the old names.  Don't create aliases to provide
compatibility in this case - just bite the bullet (and yes, force 3rd-party code
to do the same).  It's too bad, but this was a horrible design decision made
long ago, and it should just be dealt with summarily.

`float-e' is a longer name, but it is silly - this is not about whether the
value is a  float.  The name should say what the constant means/is - `math-e' or
whatever.  Even a longer name than that is good - it helps avoid conflicts.  The
name can also proclaim that the var is a constant: `math-constant-e' or
whatever.





  parent reply	other threads:[~2010-09-17 16:14 UTC|newest]

Thread overview: 61+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-09-16 13:25 e and pi Stefan Monnier
2010-09-16 13:44 ` Deniz Dogan
2010-09-16 15:37   ` Stefan Monnier
2010-09-16 13:47 ` Leo
2010-09-16 15:39   ` Stefan Monnier
2010-09-16 14:27 ` Helmut Eller
2010-09-16 15:44   ` Stefan Monnier
2010-09-16 18:52     ` Helmut Eller
2010-09-16 14:44 ` Jason Rumney
2010-09-16 22:54 ` Chong Yidong
2010-09-17  0:04   ` Deniz Dogan
2010-09-17  0:14   ` Wojciech Meyer
2010-09-17  7:00   ` David Kastrup
2010-09-17  8:09   ` Simon Leinen
2010-09-17  8:15     ` David Kastrup
2010-09-17  9:06       ` Stephen J. Turnbull
2010-09-17  9:21         ` David Kastrup
2010-09-17  9:47   ` Helmut Eller
2010-09-17 15:11   ` Stefan Monnier
2010-09-17 15:22     ` Lars Magne Ingebrigtsen
2010-09-17 15:56       ` Helmut Eller
2010-09-17 22:13         ` Stefan Monnier
2010-09-17 15:44     ` Wojciech Meyer
2010-09-17 15:50     ` Chong Yidong
2010-09-17 16:06       ` Wojciech Meyer
2010-09-17 16:18       ` Helmut Eller
2010-09-17 16:45         ` Glenn Morris
2010-09-17 17:14           ` Glenn Morris
2010-09-18 10:01         ` Eli Zaretskii
2010-09-18 10:21           ` Helmut Eller
2010-09-18 11:07             ` Eli Zaretskii
2010-09-18 11:26               ` Helmut Eller
2010-09-18 10:50           ` David Kastrup
2010-09-18 11:09             ` Eli Zaretskii
2010-09-18 14:27               ` Stephen J. Turnbull
2010-09-18 14:32               ` Andreas Schwab
2010-09-18 15:11           ` Drew Adams
2010-09-17 22:17       ` Stefan Monnier
2010-09-18  1:10         ` Chong Yidong
2010-09-18  8:30           ` Stefan Monnier
2010-09-18 19:10             ` Chong Yidong
2010-09-18 21:37               ` Uday S Reddy
2010-09-19  0:57                 ` Drew Adams
2010-09-18 13:43           ` Juanma Barranquero
2010-09-18 14:53             ` Stefan Monnier
2010-09-18 15:01               ` Lars Magne Ingebrigtsen
2010-09-18 16:00                 ` Stefan Monnier
2010-09-19 10:07               ` Juanma Barranquero
2010-09-17 16:14     ` Drew Adams [this message]
2010-09-18 15:12       ` tomas
2010-09-18 17:52         ` David Kastrup
2010-09-19 19:13           ` tomas
2010-09-17 23:35     ` Uday S Reddy
2010-09-17 16:55 ` Sam Steingold
2010-09-17 22:16   ` Stefan Monnier
2010-09-17 22:55     ` Drew Adams
  -- strict thread matches above, loose matches on Subject: below --
2010-09-17  4:20 MON KEY
2010-09-18  5:58 MON KEY
2010-09-18 14:50 ` Stefan Monnier
2010-09-19  2:03   ` MON KEY
2010-09-18 16:07 ` David De La Harpe Golden

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=F99D50BB46EB4F908E6321EA6836A568@us.oracle.com \
    --to=drew.adams@oracle.com \
    --cc=cyd@stupidchicken.com \
    --cc=emacs-devel@gnu.org \
    --cc=monnier@IRO.UMontreal.CA \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

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

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.