e and pi

e and pi

[Stefan Monnier]

As you may have noticed, I have added a new warning to the byte-compiler
for defvars of variables that don't have a prefix.  This is in
preparation for the introduction of lexical scoping: in order not to
have to rewrite all the code, the lexbind branch uses `let' both for
dynamically-scoped let-bindings and for lexically-scoped let-bindings;
where the distinction is based on whether or not a variable has
been defvar'd.  This is the same system as used in Common-Lisp and it
works well in practice, but it requires a bit of care, because every
defvar has a global effect: it declares that this variable will use
dynamic-scoping wherever it gets let-bound.  So if a file uses `len' as
a lexically-scoped variable and another file does a (defvar len), we get
a conflict that results in the first file being evaluated with
a different semantic than expected by the author.

So, the end result is that (defvar <prefix>-<foo>) is OK because the
"<prefix>-" ensures you only mess with your own variable, but (defvar
<foo>) is not OK because you may interfere with some other package.

Now, we have a lot of offending (defvar <foo>) in Emacs currently, so we
will want to fix them, and to get things started, we want to fix the two
predefined float constants `e' and `pi'.

In their case, the solution is to rename them to `float-e' and
`float-pi', but this introduces a backward incompatibility.
I figure we could define-obsolete-variable-alias (which leaves the
problem of `e' and `pi' being dynamically scoped, but hopefully only
for a few versions until we remove the obsolete name), but this means
that every code that does (let ((e <foo>)) ...) would now get a stupid
warning about using an obsolete variable `e'.

So I intend to do the following:
- in Emacs-23.3, define `e', `float-e', `pi', and `float-pi' and declare
  `e' and `pi' obsolete, but without a make-obsolete-variable
  (i.e. only in NEWS and in docstrings).
- in Emacs-24 keep float-e and float-pi but get rid of `e' and `pi'.

Can anyone think of a better solution?


        Stefan

Re: e and pi

[Deniz Dogan]

2010/9/16 Stefan Monnier <monnier@iro.umontreal.ca>:
> As you may have noticed, I have added a new warning to the byte-compiler
> for defvars of variables that don't have a prefix.  This is in
> preparation for the introduction of lexical scoping: in order not to
> have to rewrite all the code, the lexbind branch uses `let' both for
> dynamically-scoped let-bindings and for lexically-scoped let-bindings;
> where the distinction is based on whether or not a variable has
> been defvar'd.  This is the same system as used in Common-Lisp and it
> works well in practice, but it requires a bit of care, because every
> defvar has a global effect: it declares that this variable will use
> dynamic-scoping wherever it gets let-bound.  So if a file uses `len' as
> a lexically-scoped variable and another file does a (defvar len), we get
> a conflict that results in the first file being evaluated with
> a different semantic than expected by the author.
>
> So, the end result is that (defvar <prefix>-<foo>) is OK because the
> "<prefix>-" ensures you only mess with your own variable, but (defvar
> <foo>) is not OK because you may interfere with some other package.
>
> Now, we have a lot of offending (defvar <foo>) in Emacs currently, so we
> will want to fix them, and to get things started, we want to fix the two
> predefined float constants `e' and `pi'.
>
> In their case, the solution is to rename them to `float-e' and
> `float-pi', but this introduces a backward incompatibility.
> I figure we could define-obsolete-variable-alias (which leaves the
> problem of `e' and `pi' being dynamically scoped, but hopefully only
> for a few versions until we remove the obsolete name), but this means
> that every code that does (let ((e <foo>)) ...) would now get a stupid
> warning about using an obsolete variable `e'.
>
> So I intend to do the following:
> - in Emacs-23.3, define `e', `float-e', `pi', and `float-pi' and declare
>  `e' and `pi' obsolete, but without a make-obsolete-variable
>  (i.e. only in NEWS and in docstrings).
> - in Emacs-24 keep float-e and float-pi but get rid of `e' and `pi'.
>
> Can anyone think of a better solution?
>
>
>        Stefan
>
>

I don't have any ideas for a solution, but I wonder how this will
affect libraries that use the foo/bar (non-)convention, e.g. the
defvar yas/keymap in yasnippet?

-- 
Deniz Dogan

Re: e and pi

[Stefan Monnier]

> I don't have any ideas for a solution, but I wonder how this will
> affect libraries that use the foo/bar (non-)convention, e.g. the
> defvar yas/keymap in yasnippet?

Not a problem: they do use a prefix, so they don't affect other packages
(except those using the same prefix, of course).
OTOH, the regexp I use currently will incorrectly complain about
"foo/bar" as lacking a prefix.  Will fix it soon,


        Stefan

Re: e and pi

[Leo]

Hello Stefan,

Thanks for the exciting news.

On 2010-09-16 14:25 +0100, Stefan Monnier wrote:
> Can anyone think of a better solution?

Is the warning at compile time only? I think if loading a source file
can silently break things, it is bad.

Any idea whether it is easy to add some simple namespace support?

Leo

Re: e and pi

[Stefan Monnier]

>> Can anyone think of a better solution?
> Is the warning at compile time only? I think if loading a source file
> can silently break things, it is bad.

We will try to detect conflicts at run-time as well, but that's
a separate issue.

> Any idea whether it is easy to add some simple namespace support?

We already have "simple namespace support": it's called "the prefix
convention" ;-)


        Stefan

Re: e and pi

[Helmut Eller]

* Stefan Monnier [2010-09-16 13:25] writes:

> In their case, the solution is to rename them to `float-e' and
> `float-pi', but this introduces a backward incompatibility.
> I figure we could define-obsolete-variable-alias (which leaves the
> problem of `e' and `pi' being dynamically scoped, but hopefully only
> for a few versions until we remove the obsolete name), but this means
> that every code that does (let ((e <foo>)) ...) would now get a stupid
> warning about using an obsolete variable `e'.
>
> So I intend to do the following:
> - in Emacs-23.3, define `e', `float-e', `pi', and `float-pi' and declare
>   `e' and `pi' obsolete, but without a make-obsolete-variable
>   (i.e. only in NEWS and in docstrings).
> - in Emacs-24 keep float-e and float-pi but get rid of `e' and `pi'.
>
> Can anyone think of a better solution?

Lexically scoped constants.  I mean 

(defconstant e ...)

could declare that e is lexically scoped (but has a global binding).

So (let ((e <foo>)) e) would be legal, but it binds a lexical local
variable and not the dynamic variable.  Functions called in the dynamic
scope would not "see" the lexical binding and would use the global

A possible problem are macros that assume that e is a true constant and
never rebound.  That seems rare for e but would be a real problem for t.

Helmut

Re: e and pi

[Stefan Monnier]

>> - in Emacs-23.3, define `e', `float-e', `pi', and `float-pi' and declare
>> `e' and `pi' obsolete, but without a make-obsolete-variable
>> (i.e. only in NEWS and in docstrings).
>> - in Emacs-24 keep float-e and float-pi but get rid of `e' and `pi'.
>> Can anyone think of a better solution?

> Lexically scoped constants.  I mean 
> (defconstant e ...)
> could declare that e is lexically scoped (but has a global binding).

Indeed, `pi' is a defconst and currently `e' is a defvar but wants to be
a defconst as well.  And indeed if `defconst' really defines a constant,
then it can be considered as a lexically scoped variable.

But such a convention would introduce a lot more breakage, since many
packages still use defconst for variables which they later on modify via
`let' or `setq', expecting dynamic scoping semantics.  Admittedly, such
packages should be getting more rare since I've added warnings in the
byte-compiler in Emacs-23 (or maybe even Emacs-22?) about setq and let
applied to defconst'd vars.

Still, I think this is more dangerous than renaming e and pi (which are
admittedly very rarely used).

OTOH maybe you meant to introduce a new `defconstant' that's like
`defconst' except that it declares the var as lexically scoped.
Hmm... I guess that could work.


        Stefan

Re: e and pi

[Helmut Eller]

* Stefan Monnier [2010-09-16 15:44] writes:

> Still, I think this is more dangerous than renaming e and pi 

Yes, probably.

> (which are
> admittedly very rarely used).

If we assume that e is a commonly used name for local variables, then it
would be rather unreliable to use e as constant in a function (since
callers are likely to bind e).  About the only place one could use it
safely would be top-level code (defvar etc.).  So I guess that e the
constant is indeed used very rarely.

Helmut

Re: e and pi

[Jason Rumney]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> Now, we have a lot of offending (defvar <foo>) in Emacs currently, so we
> will want to fix them, and to get things started, we want to fix the two
> predefined float constants `e' and `pi'.

They shouldn't be defvars at all. They are constants.

Re: e and pi

[Chong Yidong]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> So I intend to do the following:
> - in Emacs-23.3, define `e', `float-e', `pi', and `float-pi' and declare
>   `e' and `pi' obsolete, but without a make-obsolete-variable
>   (i.e. only in NEWS and in docstrings).
> - in Emacs-24 keep float-e and float-pi but get rid of `e' and `pi'.
>
> Can anyone think of a better solution?

I don't like the idea of `float-e' and `float-pi'.

What is the problem with dynamically scoping `e' and `pi'?  If it's only
the compiler warning, we can give the compiler a whitelist of variables
not to complain about.

Re: e and pi

[Deniz Dogan]

2010/9/17 Chong Yidong <cyd@stupidchicken.com>:
> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>
>> So I intend to do the following:
>> - in Emacs-23.3, define `e', `float-e', `pi', and `float-pi' and declare
>>   `e' and `pi' obsolete, but without a make-obsolete-variable
>>   (i.e. only in NEWS and in docstrings).
>> - in Emacs-24 keep float-e and float-pi but get rid of `e' and `pi'.
>>
>> Can anyone think of a better solution?
>
> I don't like the idea of `float-e' and `float-pi'.
>
> What is the problem with dynamically scoping `e' and `pi'?  If it's only
> the compiler warning, we can give the compiler a whitelist of variables
> not to complain about.
>

Possibly as a temporary solution, but if one heads down that road and
finds out it will not work in the long run, it could be messy to "fix"
later.

-- 
Deniz Dogan

Re: e and pi

[Wojciech Meyer]

Hi Yidong,

Chong Yidong <cyd@stupidchicken.com> writes:

> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>
> I don't like the idea of `float-e' and `float-pi'.
>
> What is the problem with dynamically scoping `e' and `pi'?  If it's only
> the compiler warning, we can give the compiler a whitelist of variables
> not to complain about.

I like the idea of `float-' prefix, at least it tells the type plus it
might tell the module name too (mentioned `prefix convention'), any
language that provides these constants hides it, most likely it lands in
`Math' or `Float' module, so why Elisp should be different? Short names
should be really reserved in the local scope. I agree that `float-pi' is
less expressive than `pi' but if we got a construct (someday) for
opening module it will immediately become visible as `pi'. (we could
have local aliases too, in the scope of file, or toplevel expressions
inside module declarations etc., list of exposed functions...).

Wojciech

Re: e and pi

[David Kastrup]

Chong Yidong <cyd@stupidchicken.com> writes:

> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>
>> So I intend to do the following:
>> - in Emacs-23.3, define `e', `float-e', `pi', and `float-pi' and declare
>>   `e' and `pi' obsolete, but without a make-obsolete-variable
>>   (i.e. only in NEWS and in docstrings).
>> - in Emacs-24 keep float-e and float-pi but get rid of `e' and `pi'.
>>
>> Can anyone think of a better solution?
>
> I don't like the idea of `float-e' and `float-pi'.
>
> What is the problem with dynamically scoping `e' and `pi'?  If it's only
> the compiler warning, we can give the compiler a whitelist of variables
> not to complain about.

What is the problem with doing a defconst on them and letting defconst
_not_ work like defvar with regard to introducing dynamic scoping?

-- 
David Kastrup

Re: e and pi

[Simon Leinen]

On Fri, Sep 17, 2010 at 00:54, Chong Yidong <cyd@stupidchicken.com> wrote:
> What is the problem with dynamically scoping `e' and `pi'?

Once programmers get used to lexical binding, they will reasonably
assume that they can use variable names such as "e" in a LET or in a
function/lambda parameter list without affecting outside code.
Letting such likely-to-be-used names be dynamically scoped violates
this assumption.  Let's try to keep the number of these pitfalls as
low as possible.

Maybe we cannot expect to get rid of "t" and "nil", but making "e" and
"pi" available for lexical binding is a worthy goal.
-- 
Simon.

Re: e and pi

[David Kastrup]

Simon Leinen <simon.leinen@gmail.com> writes:

> On Fri, Sep 17, 2010 at 00:54, Chong Yidong <cyd@stupidchicken.com> wrote:
>> What is the problem with dynamically scoping `e' and `pi'?
>
> Once programmers get used to lexical binding, they will reasonably
> assume that they can use variable names such as "e" in a LET or in a
> function/lambda parameter list without affecting outside code.
> Letting such likely-to-be-used names be dynamically scoped violates
> this assumption.  Let's try to keep the number of these pitfalls as
> low as possible.

So what's wrong with letting defconst _not_ introduce dynamic scoping,
and using it on e and pi?

> Maybe we cannot expect to get rid of "t" and "nil",

I have yet to see any code that reassigns t and nil, dynamically scoped
or not.

> but making "e" and "pi" available for lexical binding is a worthy
> goal.

Using defconst on them would appear to do that.

-- 
David Kastrup

Re: e and pi

[Stephen J. Turnbull]

David Kastrup writes:

 > > Maybe we cannot expect to get rid of "t" and "nil",

 > I have yet to see any code that reassigns t and nil, dynamically
 > scoped or not.

Well, Monkey seems to make a habit of uninterning them, though.
Presumably he does that so he can reuse them somehow (maybe just for
the sake of keeping the bandwidth on emacs-devel > 0? ;-)

Re: e and pi

[David Kastrup]

"Stephen J. Turnbull" <stephen@xemacs.org> writes:

> David Kastrup writes:
>
>  > > Maybe we cannot expect to get rid of "t" and "nil",
>
>  > I have yet to see any code that reassigns t and nil, dynamically
>  > scoped or not.
>
> Well, Monkey seems to make a habit of uninterning them, though.
> Presumably he does that so he can reuse them somehow (maybe just for
> the sake of keeping the bandwidth on emacs-devel > 0? ;-)

Maybe he is able to expect to get rid of "t" and "nil".

-- 
David Kastrup

Re: e and pi

[Helmut Eller]

* Chong Yidong [2010-09-16 22:54] writes:

> I don't like the idea of `float-e' and `float-pi'.

Perhaps we should use uppercase names like E and PI for such things.

Helmut

Re: e and pi

[Stefan Monnier]

>> Can anyone think of a better solution?
> I don't like the idea of `float-e' and `float-pi'.
> What is the problem with dynamically scoping `e' and `pi'?  If it's only
> the compiler warning, we can give the compiler a whitelist of variables
> not to complain about.

It's not a question of compiler warning.  It's a question of semantics.
Let's take a classic example where lexical-scoping matters: currying.
E.g. the following function

  (defun make-inc (n)
    (lambda (m) (+ n m)))
    
means that (make-inc 3) returns a function which adds 3 to its argument:

  (let ((f (make-inc 3)))
    (funcall f 5))
    
should evaluate to 8.
Now, this only works because "n" is statically scoped.  So in the
current lexbind branch (where e is defined as a global/dynamic
variable), the below code would not do the same:

  (defun make-inc (e)
    (lambda (f) (+ e f)))
 
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.


        Stefan

        
PS: Oddly enough, SML has a similar trap where "o" is predefined as the
function-composition operator and "op" is a rarely used reserved
keyword, and I think everyone agrees by now that these were
bad decisions.

Re: e and pi

[Lars Magne Ingebrigtsen]

Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

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

I think renaming these two to `float-*' makes the most sense.  Having
defconst not introduce special variables would be non-ideal (in my
opinion), since defconst does do that in Common Lisp.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: e and pi

[Helmut Eller]

* Lars Magne Ingebrigtsen [2010-09-17 15:22] writes:

> Having
> defconst not introduce special variables would be non-ideal (in my
> opinion), since defconst does do that in Common Lisp.

In CL it's called DEFCONSTANT and constants are not special.  Using a
constant in SETQ, LET, or LAMBDA is not allowed (it's an error in most
implementations, just like setq on t is an error in Elisp).  Even
evaluating DEFCONSTANT twice is only specified if the old and new value
are sufficiently similar (some implementations ask before redefining a
constant with a non-eql value).

Helmut

Re: e and pi

[Stefan Monnier]

>> Having defconst not introduce special variables would be non-ideal
>> (in my opinion), since defconst does do that in Common Lisp.
> In CL it's called DEFCONSTANT and constants are not special.  Using a
> constant in SETQ, LET, or LAMBDA is not allowed (it's an error in most
> implementations, just like setq on t is an error in Elisp).

In Elisp it's not (yet) an error, but the byte-compiler will complain.


        Stefan "don't worry about the «yet», it's likely to stay that
                way for another decade"

Re: e and pi

[Wojciech Meyer]

On Fri, Sep 17, 2010 at 4:11 PM, Stefan Monnier
<monnier@iro.umontreal.ca> wrote:

> PS: Oddly enough, SML has a similar trap where "o" is predefined as the
> function-composition operator and "op" is a rarely used reserved
> keyword, and I think everyone agrees by now that these were
> bad decisions.

Yes but in Standard ML type checker most likely caught it before program run
(at least if the signatures are different `o' would have (a' -> b') ->
(c' -> a') -> (c' -> b')).

Wojciech

Re: e and pi

[Chong Yidong]

Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

> in the current lexbind branch (where e is defined as a global/dynamic
> variable), the below code would not do the same:
>
>   (defun make-inc (e)
>     (lambda (f) (+ e f)))
>
> because "e" happens to be a predefined global variable with
> dynamic-scoping semantics.

This doesn't sound right---it means that people will have to make sure
their function args do not coincide with any defvar, defined anywhere.
It won't just be "e" and "pi" causing problems.  Someone might write

  (defun froob (argv)
     (lambda (f) (cons f argv)))

and have that fail, because "argv" is a defvar defined in startup.el.

Re: e and pi

[Wojciech Meyer]

On Fri, Sep 17, 2010 at 4:50 PM, Chong Yidong <cyd@stupidchicken.com> wrote:
> Stefan Monnier <monnier@IRO.UMontreal.CA> writes:
>
>> in the current lexbind branch (where e is defined as a global/dynamic
>> variable), the below code would not do the same:
>>
>>   (defun make-inc (e)
>>     (lambda (f) (+ e f)))
>>
>> because "e" happens to be a predefined global variable with
>> dynamic-scoping semantics.
>
> This doesn't sound right---it means that people will have to make sure
> their function args do not coincide with any defvar, defined anywhere.
> It won't just be "e" and "pi" causing problems.  Someone might write
>
>  (defun froob (argv)
>     (lambda (f) (cons f argv)))
>
> and have that fail, because "argv" is a defvar defined in startup.el.

That's why defvars should be with prefix.

Wojciech

Re: e and pi

[Helmut Eller]

* Chong Yidong [2010-09-17 15:50] writes:

> This doesn't sound right---it means that people will have to make sure
> their function args do not coincide with any defvar, defined anywhere.
> It won't just be "e" and "pi" causing problems.  Someone might write
>
>   (defun froob (argv)
>      (lambda (f) (cons f argv)))
>
> and have that fail, because "argv" is a defvar defined in startup.el.

I once had a function with an argument called system-name.  Suddenly
Emacs started to complain that some files are locked by some other user.
How many people now that system-name is a global variable and used by
the file-locking code?  The lesson is that Emacs should not pre-define
global variables with names that are likely candidates for local
variables.

Helmut

Re: e and pi

[Glenn Morris]

Helmut Eller wrote:

> I once had a function with an argument called system-name. 

Which won't be flagged by this warning. Nor will any other commonly
named variable with a hyphen in, eg temp-file, file-name, system-time,
start-time, this-one, etc, etc.

Re: e and pi

[Glenn Morris]

Glenn Morris wrote:

> Which won't be flagged by this warning. Nor will any other commonly
> named variable with a hyphen in, eg temp-file, file-name, system-time,
> start-time, this-one, etc, etc.

Plus we also have Lisp files in Emacs now that share the same
basename, so it's not like using `filename-' in filename.el is safe
either.

Re: e and pi

[Eli Zaretskii]

> From: Helmut Eller <eller.helmut@gmail.com>
> Date: Fri, 17 Sep 2010 18:18:25 +0200
> 
> >   (defun froob (argv)
> >      (lambda (f) (cons f argv)))
> >
> > and have that fail, because "argv" is a defvar defined in startup.el.
> 
> I once had a function with an argument called system-name.  Suddenly
> Emacs started to complain that some files are locked by some other user.
> How many people now that system-name is a global variable and used by
> the file-locking code?  The lesson is that Emacs should not pre-define
> global variables with names that are likely candidates for local
> variables.

What you describe as a big surprise is actually known to every C/C++
programmer: some names are "reserved by the implementation" and should
not be used by the application code.

Re: e and pi

[Helmut Eller]

* Eli Zaretskii [2010-09-18 10:01] writes:

>> From: Helmut Eller <eller.helmut@gmail.com>
>> Date: Fri, 17 Sep 2010 18:18:25 +0200
>>
>> I once had a function with an argument called system-name.  Suddenly
>> Emacs started to complain that some files are locked by some other user.
>> How many people now that system-name is a global variable and used by
>> the file-locking code?  The lesson is that Emacs should not pre-define
>> global variables with names that are likely candidates for local
>> variables.
>
> What you describe as a big surprise is actually known to every C/C++
> programmer: some names are "reserved by the implementation" and should
> not be used by the application code.

I don't see how that could be relevant here.  C/C++ doesn't use dynamic
scoping; function arguments are statically scoped.  And C++ has
namespaces so it's even less relevant.

Helmut

Re: e and pi

[Eli Zaretskii]

> From: Helmut Eller <eller.helmut@gmail.com>
> Date: Sat, 18 Sep 2010 12:21:02 +0200
> 
> > What you describe as a big surprise is actually known to every C/C++
> > programmer: some names are "reserved by the implementation" and should
> > not be used by the application code.
> 
> I don't see how that could be relevant here.

It's relevant because such limitations are common in other languages.

Re: e and pi

[Helmut Eller]

* Eli Zaretskii [2010-09-18 11:07] writes:

>> From: Helmut Eller <eller.helmut@gmail.com>
>> Date: Sat, 18 Sep 2010 12:21:02 +0200
>> 
>> > What you describe as a big surprise is actually known to every C/C++
>> > programmer: some names are "reserved by the implementation" and should
>> > not be used by the application code.
>> 
>> I don't see how that could be relevant here.
>
> It's relevant because such limitations are common in other languages.

No it's not relevant, because languages without dynamic scoping or wich
support namespaces don't have this limitation.

Helmut

Re: e and pi

[David Kastrup]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Helmut Eller <eller.helmut@gmail.com>
>> Date: Fri, 17 Sep 2010 18:18:25 +0200
>> 
>> >   (defun froob (argv)
>> >      (lambda (f) (cons f argv)))
>> >
>> > and have that fail, because "argv" is a defvar defined in startup.el.
>> 
>> I once had a function with an argument called system-name.  Suddenly
>> Emacs started to complain that some files are locked by some other user.
>> How many people now that system-name is a global variable and used by
>> the file-locking code?  The lesson is that Emacs should not pre-define
>> global variables with names that are likely candidates for local
>> variables.
>
> What you describe as a big surprise is actually known to every C/C++
> programmer: some names are "reserved by the implementation" and should
> not be used by the application code.

For a function argument?  I beg to differ.  The only way to get a
conflict is using extern declarations.

And identifiers reserved by the implementation start with two
underlines.

-- 
David Kastrup

Re: e and pi

[Eli Zaretskii]

> From: David Kastrup <dak@gnu.org>
> Date: Sat, 18 Sep 2010 12:50:22 +0200
> 
> And identifiers reserved by the implementation start with two
> underlines.

Every identifier mentioned in the appropriate ANSI or Posix standards
as a standard function is also reserved.

Re: e and pi

[Stephen J. Turnbull]

Eli Zaretskii writes:

 > Every identifier mentioned in the appropriate ANSI or Posix
 > standards as a standard function is also reserved.

"Reserved" means "we reserve to right to produce garbage or a syntax
error if you try to use these as regular identifiers".  If you
redefine a standard function, though, the compiler and linker are
still supposed to do the right thing, and your program should still
work (as long as you're consistent, and understand that you can't have
the standard version of a function, and your replacement).  And of
course if you export those identifiers, you're not allowed to claim
standard conformance.

Re: e and pi

[Andreas Schwab]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: David Kastrup <dak@gnu.org>
>> Date: Sat, 18 Sep 2010 12:50:22 +0200
>> 
>> And identifiers reserved by the implementation start with two
>> underlines.
>
> Every identifier mentioned in the appropriate ANSI or Posix standards
> as a standard function is also reserved.

But only at file scope.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

RE: e and pi

[Drew Adams]

> > I once had a function with an argument called system-name.  Suddenly
> > Emacs started to complain that some files are locked by 
> > some other user. How many people now that system-name is a global
> > variable and used by the file-locking code?
> >
> > The lesson is that Emacs should not pre-define global variables with
> > names that are likely candidates for local variables.
> 
> What you describe as a big surprise is actually known to every C/C++
> programmer: some names are "reserved by the implementation" and should
> not be used by the application code.

And can you imagine the fun if C/C++ reserved the name `e'? ;-)

Please read what the OP wrote: "should not pre-define global variables with
names that are _likely candidates for local variables_".  That likelihood is
very high for `e', whether in C/C++ or Emacs Lisp.  It is presumably not so high
for the implementation-reserved names of C/C++.  (And since when did their
design become a guide for Emacs Lisp?)

Re: e and pi

[Stefan Monnier]

>> in the current lexbind branch (where e is defined as a global/dynamic
>> variable), the below code would not do the same:
>> 
>> (defun make-inc (e)
>> (lambda (f) (+ e f)))
>> 
>> because "e" happens to be a predefined global variable with
>> dynamic-scoping semantics.

> This doesn't sound right---it means that people will have to make sure
> their function args do not coincide with any defvar, defined anywhere.
> It won't just be "e" and "pi" causing problems.  Someone might write

>   (defun froob (argv)
>      (lambda (f) (cons f argv)))

> and have that fail, because "argv" is a defvar defined in startup.el.

Exactly: hence the new warning.


        Stefan

Re: e and pi

[Chong Yidong]

Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

>> This doesn't sound right---it means that people will have to make sure
>> their function args do not coincide with any defvar, defined anywhere.
>> It won't just be "e" and "pi" causing problems.  Someone might write
>
>>   (defun froob (argv)
>>      (lambda (f) (cons f argv)))
>
>> and have that fail, because "argv" is a defvar defined in startup.el.
>
> Exactly: hence the new warning.

This sounds fragile.

If function argument names are the problem, why not just give them
static scope, overriding any existing dynamic bindings?  While it's
idiomatic elisp to use `let' to bind dynamic variables, AFAICT no one
uses function arguments to do the same.

Re: e and pi

[Stefan Monnier]

>>> This doesn't sound right---it means that people will have to make sure
>>> their function args do not coincide with any defvar, defined anywhere.
>>> It won't just be "e" and "pi" causing problems.  Someone might write
>> 
>>> (defun froob (argv)
>>> (lambda (f) (cons f argv)))
>> 
>>> and have that fail, because "argv" is a defvar defined in startup.el.
>> 
>> Exactly: hence the new warning.

> This sounds fragile.

That's been used for ages in Common-Lisp.  And it's the only reasonable
way to convert Elisp packages from dynamic-scoping to static-scoping
without having to change all `let' to something else (like lexical-let).

> If function argument names are the problem, why not just give them
> static scope, overriding any existing dynamic bindings?  While it's
> idiomatic elisp to use `let' to bind dynamic variables, AFAICT no one
> uses function arguments to do the same.

No, the issue is:

  does (let ((foo bar)) ...) bind `foo' lexically or dynamically?

  
-- Stefan

Re: e and pi

[Chong Yidong]

Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

>> If function argument names are the problem, why not just give them
>> static scope, overriding any existing dynamic bindings?  While it's
>> idiomatic elisp to use `let' to bind dynamic variables, AFAICT no one
>> uses function arguments to do the same.
>
> No, the issue is:
>
>   does (let ((foo bar)) ...) bind `foo' lexically or dynamically?

You're switching examples.  Remember, I originally asked what's the
exact problem with binding `e' dynamically.  You came up with this
example:

  (defun make-inc (e)
    (lambda (m) (+ e m)))

  (let ((f (make-inc 3)))
    (funcall f 5))

I agree that static scoping is much better in this example.  But we
could fix this simply by imposing static scope on function arguments.
So, is there an equivalent scenario in which the proposed change to
`let' is clearly desireable?

> That's been used for ages in Common-Lisp.  And it's the only
> reasonable way to convert Elisp packages from dynamic-scoping to
> static-scoping without having to change all `let' to something else
> (like lexical-let).

My question is, what's the advantage that we gain from automagically
converting to static scoping?  If 99% of the static scoping advantage
involves static scoping of function args, while 99% of the disruption
comes from converting `let' forms, then maybe we should do one and not
the other.

Re: e and pi

[Uday S Reddy]

On 9/18/2010 8:10 PM, Chong Yidong wrote:

> You came up with this
> example:
>
>    (defun make-inc (e)
>      (lambda (m) (+ e m)))
>
>    (let ((f (make-inc 3)))
>      (funcall f 5))
>
> I agree that static scoping is much better in this example.  But we
> could fix this simply by imposing static scope on function arguments.
> So, is there an equivalent scenario in which the proposed change to
> `let' is clearly desireable?

Consider this:

(defvar funny nil)
(let ((e 25))
    (setq funny (lambda (m) (+ e m))))

Now, (funcall funny 2) should return 27.  Instead, with dynamic binding, it 
returns 4.7182...

The point is not whether `e' is being bound in a let or a defun.  Rather, the 
point is that we should be able to use a variable like `e' as a free variable 
in a closure.  We can do so only if it is governed by lexical binding.

Cheers,
Uday

RE: e and pi

[Drew Adams]

> The point is not whether `e' is being bound in a let or a defun.  

Correct.  The point is that one should easily be able to know which `e' is
involved at any point.  In particular (see the Subject), a global variable
(constant) intended to represent a math constant should have a global name that
proclaims that unambiguously: "I'm a global math constant".

> Rather, the point is that we should be able to use a variable like `e' as 
> a free variable in a closure.

No, that is a completely separate point - not the point of this thread.  Or at
least it should not be, even if lexical binding might be one way to circumvent
the `e' constant naming issue (without actually addressing and solving it
properly).

To see this, just substitute `x' or `frobfroth' for `e' in your last sentence
above.  Your point remains.  It is a valid point, but it is independent of the
question about the math constant `e'.

> We can do so only if it is governed by lexical binding.

Right.

So let's start another thread to sing hurrahs for the possibility of easier and
clearer lexical binding in Emacs.  It's just (logically) a different question
than that of poorly named constants `e' and `pi'.

Re: e and pi

[Juanma Barranquero]

On Sat, Sep 18, 2010 at 03:10, Chong Yidong <cyd@stupidchicken.com> wrote:

> If function argument names are the problem, why not just give them
> static scope, overriding any existing dynamic bindings?  While it's
> idiomatic elisp to use `let' to bind dynamic variables, AFAICT no one
> uses function arguments to do the same.

I don't have the Emacs source at hand and won't for a couple days, but
I'm sure there are a few places where default args to functions are
used to bind dynamic variables to (default) nil.

    Juanma

Re: e and pi

[Stefan Monnier]

>> If function argument names are the problem, why not just give them
>> static scope, overriding any existing dynamic bindings?  While it's
>> idiomatic elisp to use `let' to bind dynamic variables, AFAICT no one
>> uses function arguments to do the same.

> I don't have the Emacs source at hand and won't for a couple days, but
> I'm sure there are a few places where default args to functions are
> used to bind dynamic variables to (default) nil.

Indeed, there are a few places where Elisp code binds dynamic variables
not with a let but with a function argument.  I find this revolting, and
would welcome a byte-compiler warning to "flog the author with a wet
noodle".


        Stefan

Re: e and pi

[Lars Magne Ingebrigtsen]

Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

> Indeed, there are a few places where Elisp code binds dynamic variables
> not with a let but with a function argument.  I find this revolting, and
> would welcome a byte-compiler warning to "flog the author with a wet
> noodle".

I think Gnus does this a few places.  Feel free to add a noodly compiler
warning, and I'll fix it up.

I think the plan to make bindings be lexical is great, but I'm not sure
what all the discussion about e, argv and pi is.  :-)

This is my understanding: You want bindings to behave like in Common
Lisp, and have all special variables (i.e., things that have been
defined with defvar) to have dynamic scope (like today), and have all
the rest have lexical bindings.  And the problem is that some variables
(well, constants) like `e' and `pi' are likely to be used by people in
bindings, so they'll get dynamic bindings where they don't expect it.
Is that a fair summary?

In that case, just go ahead and rename the variables.

(Although I don't really see how not using function arguments as dynamic
bindings really help much, but I agree that it's confusing.)

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: e and pi

[Stefan Monnier]

> This is my understanding: You want bindings to behave like in Common
> Lisp, and have all special variables (i.e., things that have been
> defined with defvar) to have dynamic scope (like today), and have all
> the rest have lexical bindings.  And the problem is that some variables
> (well, constants) like `e' and `pi' are likely to be used by people in
> bindings, so they'll get dynamic bindings where they don't expect it.
> Is that a fair summary?

Yes.

> (Although I don't really see how not using function arguments as dynamic
> bindings really help much, but I agree that it's confusing.)

It's only remotely related, indeed.


        Stefan

Re: e and pi

[Juanma Barranquero]

On Sat, Sep 18, 2010 at 16:53, Stefan Monnier <monnier@iro.umontreal.ca> wrote:

> Indeed, there are a few places where Elisp code binds dynamic variables
> not with a let but with a function argument.  I find this revolting, and
> would welcome a byte-compiler warning to "flog the author with a wet
> noodle".

Oh, I agree. Just pointing out to Chong that it really happens in the sources.

    Juanma

RE: e and pi

[Drew Adams]

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

Re: e and pi

[tomas]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Fri, Sep 17, 2010 at 09:14:57AM -0700, Drew Adams wrote:

[...]

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

+1 for math-e

Those are constants in some hypothetical "math" package.

(Besides, float-e reminds me fatally of Hungarian notation, but of
course not everyone has to share my allergies :)

Regards
- -- tomás
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFMlNbDBcgs9XrR2kYRAr9nAJ9UQGEbaXeDYryUBVg2+L1idabiKgCfTeag
cpv/sYYM1RKU65CxQObkZ4A=
=+LGZ
-----END PGP SIGNATURE-----

Re: e and pi

[David Kastrup]

tomas@tuxteam.de writes:

> On Fri, Sep 17, 2010 at 09:14:57AM -0700, Drew Adams wrote:
>
> [...]
>
>> `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 [...]
>
> +1 for math-e
>
> Those are constants in some hypothetical "math" package.

calc is not hypothetical.  It already occupies the math- prefix.

math-e-cache is a variable defined in `calc-ext.el'.
Its value is 
(float
 (bigpos 9045 2845 2818 2718)
 -15)

math-e is a compiled Lisp function in `calc-ext.el'.

(math-e)

Not documented.

[back]

> (Besides, float-e reminds me fatally of Hungarian notation, but of
> course not everyone has to share my allergies :)
>
> Regards
> -- tomás

-- 
David Kastrup

Re: e and pi

[tomas]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sat, Sep 18, 2010 at 07:52:57PM +0200, David Kastrup wrote:
> tomas@tuxteam.de writes:
[...]
> > Those are constants in some hypothetical "math" package.
> 
> calc is not hypothetical.  It already occupies the math- prefix.

Oh -- oops.

Thanks for setting me straight.

Regards
- -- tomás
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFMlmDdBcgs9XrR2kYRAn2DAJ4hOU9u8E5elh/f5WVUs8PV+IA51ACeMyp6
Mt7QRqrOZSyPjZhSP+IOoZA=
=pDQS
-----END PGP SIGNATURE-----

Re: e and pi

[Uday S Reddy]

On 9/17/2010 4:11 PM, Stefan Monnier wrote:

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

Such people can do (defconst e float-e) and happily use it for their favourite 
constant.  So, this is hardly a problem.

Cheers,
Uday

Re: e and pi

[Sam Steingold]

Stefan Monnier wrote:
> 
> Now, we have a lot of offending (defvar <foo>) in Emacs currently, so we
> will want to fix them, and to get things started, we want to fix the two
> predefined float constants `e' and `pi'.

why does the constant e exist in the first place?
e=exp(1) and that is what people should use instead of the constant.
the compiler should recognize that exp(1) is a constant and compute it at 
compile time.

Re: e and pi

[Stefan Monnier]

>> Now, we have a lot of offending (defvar <foo>) in Emacs currently, so we
>> will want to fix them, and to get things started, we want to fix the two
>> predefined float constants `e' and `pi'.
> why does the constant e exist in the first place?

Beats me: it's only used at one place in emacs/lisp.
But that's what we have to live with,


        Stefan

RE: e and pi

[Drew Adams]

> > why does the constant e exist in the first place?
> 
> Beats me: it's only used at one place in emacs/lisp.
> But that's what we have to live with,

Why?  This seems like a good case for turning the page if there ever was one.

These names never should have been used for global constants.  Pretty much
everyone agrees with that and has agreed for a long time.  This has only caused
problems/confusion.  It will continue to do so.  There is no good reason not to
get rid of this now.

Any code that wants to use a shorter name can bind one locally to the new, more
verbose name.  No big deal.

And that includes any 3rd-party code that the change might break.  This is a
smaller break than many that you guys effect from time to time.  Just do it and
don't look back.

The following 2007 thread is enlightening.  See what you all said 3 years ago.
;-) -
http://lists.gnu.org/archive/html/emacs-devel/2007-02/msg00414.html

But for some reason, that Web page only shows a small part of the thread (a
bug?).  This link shows some more:
http://lists.gnu.org/archive/html/emacs-devel/2007-02/msg00432.html

To get all of the thread you probably need to look at a Date sort:
http://lists.gnu.org/archive/html/emacs-devel/2007-02/index.html


FWIW - what I suggested way back then for `e':

> `numeric-constant-e', and adopt that (or similar) as the
> convention for numeric constants: `numeric-constant-pi', etc.
>
> However, I still prefer, in descending order or preference:
>
> 1. (exp 1) ; that is, drop the variable altogether
> 2. (e); that is, make it a function that does (exp 1) or
>    picks up the memoized value after doing (exp 1 once).

And to Eli's (2007) complaint that he wants the convenience of just typing `e':

EZ> Please don't: I frequently use Emacs to calculate trigonometric
EZ> expression; typing these monster names would make it very hard
EZ> for me to do that.
>
> Very hard for you?  Make a local binding.  If you need a short
> name for interactive or local program use, define one.  I see no
> reason to dedicate `e' and `pi' for this uncommon use (uncommon
> in both Emacs-Lisp files and interactive Emacs use).

I still feel that's right: anyone or any library that wants to use a short name
can easily bind one.

Re: e and pi

[MON KEY]

> This is in preparation for the introduction of lexical scoping:

Wow! Thank you.

--
/s_P\

re: e and pi

[MON KEY]

> Not a problem: they do use a prefix, so they don't affect other packages
> (except those using the same prefix, of course).
> OTOH, the regexp I use currently will incorrectly complain about
> "foo/bar" as lacking a prefix.  Will fix it soon,

What about adding `%' and `+' as prefix/suffix to your regexp?

Likewise, could the CL semi-convention of naming "vars with *stars*" e.g.:

(defvar *my-special-frobomatic* {...} )

and constants with + (no equally nice mnemonic here):

(defconst +my-privileged-froboid+ {...} )

be of use to help (textually not syntactically) keep track of variable scoping?

Obv. where a non-existing convention in existing code isn't these won't
help (not without changing _a lot_ of symbol names).

However, maybe as part of the lexbind integration something as above
should be encouraged
in addition to "the prefix namespace".

My impression is that the CL convention for `+' and `*' wrappers is an
idiom born
of lexical/dynamic scoping tensions.

--
/s_P\

Re: e and pi

[Stefan Monnier]

>> Not a problem: they do use a prefix, so they don't affect other packages
>> (except those using the same prefix, of course).
>> OTOH, the regexp I use currently will incorrectly complain about
>> "foo/bar" as lacking a prefix.  Will fix it soon,
> What about adding `%' and `+' as prefix/suffix to your regexp?

I've never seen % used that way.  * is already accepted as a char that
marks the variable as "OK to use with defvar".  As for +, I've never
seen Elisp code use it, so I don't see a need for it.

Note also that Using *...* for dynamic vars doesn't save the author from
using a prefix, since that is needed for modularity reasons.


        Stefan

Re: e and pi

[MON KEY]

On Sat, Sep 18, 2010 at 10:50 AM, Stefan Monnier
<monnier@iro.umontreal.ca> wrote:
>  * is already accepted as a char that
> marks the variable as "OK to use with defvar".

Yes, I saw. Thanks for that!

> As for +, I've never seen Elisp code use it, so I don't see a need for it.
>

It is a fine convention though.
No doubt one like it will probably spring up in the absence of an
informal hint from the devels...

And, with lexbind integration maybe more Common Lisp code should be
able run with only minor modification esp. the older pre-CLOS stuff.
Maybe I'm dreaming...

> Note also that Using *...* for dynamic vars doesn't save the author from
> using a prefix, since that is needed for modularity reasons.

Yes, of course.

Though, as mentioned in a recent bug report these types of vars
don't/won't get font-locked in "*Help*".

bug#6601: help-make-xref doesn't buttonize `help-variable-def'  as per
         `help-xref-symbol-regexp
http://lists.gnu.org/archive/html/bug-gnu-emacs/2010-07/msg00309.html


>        Stefan
>

--
/s_P\

Re: e and pi

[David De La Harpe Golden]

On 18/09/10 06:58, MON KEY wrote:

> My impression is that the CL convention for `+' and `*' wrappers is an
> idiom born of lexical/dynamic scoping tensions.
>

Yeah, there's near-universal adherence to the *earmuffs* naming 
convention for dynamically scoped stuff in common lisp land, which is 
probably _why_ things "work well in practice" (as Stefan wrote) there.

It's Perl that I associate with mixing lexicals ("my") and dynamics 
("local") without a naming convention (or full separate namespace).

islisp's dynamic-let/dynamic etc. was cleaner than common lisp's 
approach. Probably backward compat is too much of a concern to make that 
feasible for emacs lisp though (cl presumably had similar backward 
compat concerns...).