Yegge's js2-mode for emacs

[Dave Herman]

FYI: I see Steve Yegge has implemented a new emacs mode that he intends 
to support ES4 eventually:

http://steve-yegge.blogspot.com/2008/03/js2-mode-new-javascript-mode-for-emacs.html

I haven't tried it out but it sounds like a pretty significant chunk of 
code so people here may be interested.

Dave
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss

Re: Strict mode recap

[Jon Zeppieri]

On Fri, Apr 4, 2008 at 2:42 PM, Mark Miller <[EMAIL PROTECTED]> wrote:
> On Fri, Apr 4, 2008 at 11:24 AM, Jon Zeppieri <[EMAIL PROTECTED]> wrote:
>  >  >  (and the latter does not handle shadowing, for better or worse).
>  >
>  >  Heh.  Someone should revive Mark Miller.
>
>  [startles] What? I'm awake. Can someone summarize the issue in a
>  self-contained manner?

It was just a joke -- I figured that Lars's example was exactly kind
of use of lexically scoped eval that would trigger the allergic
reaction you mentioned earlier in this thread.
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss

Re: Strict mode recap

[Mark Miller]

On Fri, Apr 4, 2008 at 11:24 AM, Jon Zeppieri <[EMAIL PROTECTED]> wrote:
>  >  (and the latter does not handle shadowing, for better or worse).
>
>  Heh.  Someone should revive Mark Miller.

[startles] What? I'm awake. Can someone summarize the issue in a
self-contained manner?


-- 
Text by me above is hereby placed in the public domain

 Cheers,
 --MarkM
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss

Re: Strict mode recap

[Jon Zeppieri]

On Fri, Apr 4, 2008 at 1:45 PM, Lars Hansen <[EMAIL PROTECTED]> wrote:
>
>  That could be true.  But it could also be the case that people
>  find that it is easier to say
>
>   var x = ...
>   var y = ...
>   var n = "x"  // but could be y
>
>   ...
>   // n may change here by assigning another string to it
>   ...
>   eval(n)
>
>  than
>
>   var x = ...
>   var y = ...
>   var n = function () { return x } // but could be y
>
>   ...
>   // n may change here by assigning another function to it
>   ...
>   n()

Like I wrote in previous messages, what these programmers need is an
actual data structure:

var m = { x: ..., y: ... };
var n = "x";

// n may change, &c.
...
m[n]

>
>  (and the latter does not handle shadowing, for better or worse).

Heh.  Someone should revive Mark Miller.

-Jon
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss

RE: Strict mode recap

[Lars Hansen]

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On 
> Behalf Of Jon Zeppieri
> Sent: 4. april 2008 11:38
> To: Lars Hansen
> Cc: liorean; es4-discuss@mozilla.org
> Subject: Re: Strict mode recap
> 
> >  I disagree, based on my experience analyzing uses of eval in
scripts  
> > written for the web, which to an astonishing degree evaluate simple

> > variable names or object.property phrases.
> 
> I've seen this, too, but rather than proving the utility of 
> this feature, I tend to consider it as evidence of a silent 
> epidemic of brain damage among ES programmers...

That could be true.  But it could also be the case that people 
find that it is easier to say

  var x = ...
  var y = ...
  var n = "x"  // but could be y

  ...
  // n may change here by assigning another string to it
  ...
  eval(n)

than 

  var x = ...
  var y = ...
  var n = function () { return x } // but could be y

  ...
  // n may change here by assigning another function to it
  ...
  n()

(and the latter does not handle shadowing, for better or worse).

--lars
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss

Re: Strict mode recap

[Jon Zeppieri]

On Fri, Apr 4, 2008 at 1:25 PM, Lars Hansen <[EMAIL PROTECTED]> wrote:
>
>  I hope the forthcoming spec on names will clarify
>  this, so I suggest we hold off arguing about this particular point for
>  the moment.

Happily.

>
>  You can argue, and I think you are arguing, that there is no utility in
>  allowing ns to be variable and allowing id to be replaced by [expr].

Specifically for local variables, yes.

>  I disagree, based on my experience analyzing uses of eval in scripts
>  written for the web, which to an astonishing degree evaluate simple
>  variable names or object.property phrases.

I've seen this, too, but rather than proving the utility of this
feature, I tend to consider it as evidence of a silent epidemic of
brain damage among ES programmers...

-Jon
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss

RE: Strict mode recap

[Lars Hansen]

> -Original Message-
> From: Jon Zeppieri [mailto:[EMAIL PROTECTED] 
> Sent: 4. april 2008 11:02
> To: Lars Hansen
> Cc: liorean; es4-discuss@mozilla.org
> Subject: Re: Strict mode recap
> 
> On Fri, Apr 4, 2008 at 12:57 PM, Lars Hansen 
> <[EMAIL PROTECTED]> wrote:
> >
> > (BTW I believe that locally bound names in ES4 cannot have explicit

> > namespaces, but that these names are defined in the common public  
> > namespace (the one Jon calls 'null' though it will probably end  up 
> > being called 'public').  The forthcoming spec on names and name  
> > lookup will clarify.)
> 
> Wait... so what have we been arguing about?

I don't know what *you* have been arguing about :)  I have been arguing
that allowing a general reference form ns::[expr] where both ns and expr
can be arbitrary expressions does not inhibit optimizations in a
significant way, nor does a form ns::id where ns is an arbitrary
expression, and furthermore that these forms have utility.

Classes can have namespaced properties and globals can too.  These
objects are in scope in a method (say), so in order to reference a
property in them from the method, at a minimum the form ns::id must be
available to the program (for constant ns and id).  But since ns can be
'public' such a name can (as far as I understand it know) also match a
local binding (parameter, let, var -- whatever), so this syntax is not
at present restricted to finding properties in true (non activation
record) objects.  I hope the forthcoming spec on names will clarify
this, so I suggest we hold off arguing about this particular point for
the moment.

When ns and id are indeed constant then all sorts of early binding
optimizations can be performed.  If ns is not constant, or if id is
actually some [expr], then the lookup is still by the same rules as for
early binding, clearly, but it will have to be performed at run-time.

You can argue, and I think you are arguing, that there is no utility in
allowing ns to be variable and allowing id to be replaced by [expr].  I
disagree, based on my experience analyzing uses of eval in scripts
written for the web, which to an astonishing degree evaluate simple
variable names or object.property phrases.

--lars
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss

Re: Strict mode recap

[Jon Zeppieri]

On Fri, Apr 4, 2008 at 11:30 AM, Lars Hansen <[EMAIL PROTECTED]> wrote:
>
>  I don't get it.
>
>  Your comment about inhibiting static analysis isn't right; if ns::x is a
>  name then either ns is known to be constant at compile time or not, and
>  if it is, then nothing prevents early binding.  ES3 systems perform
>  analyses that are inhibited by eval and with, and statically detect
>  whether eval and with are used in order to decide whether to perform the
>  analyses.

I think we understand different things by "inhibiting static
analysis."  I'm not claiming that the inclusion of the feature makes
static analysis impossible -- only that the use of the feature can
severely limit its effectiveness.  E.g.:

ns::[expr] = ...

... kills assignment analysis for any bindings in scope, and

ns1::[expr1] = ns2::[expr2]

... kills escape analysis similarly.  (I think... although I'll
happily defer to you on this.)


Now, if you want to say that it's pay as you go -- that if you use the
feature, you incur the expense, and otherwise you don't -- I agree.  I
just don't yet understand why anyone would want to do this with
activation objects.  What are you paying *for*?

>
>  Anyway, what's the distinction between "dynamic lookup of first-class
>  object properties", as you write in a later message, and looking up a
>  name in general, once you introduce namespaced bindings in packages and
>  global objects (though not in local variables) and couple everything
>  with 'with'?

I'm not sure I understand this.  I can't answer your question about
namespaced bindings in packages, since I don't know what ES4 packages
are.  I have some vague idea that they are sugar for namespaces, but
that may be wrong/obsolete.  As for global objects, how does the
inclusion of namespaces affect lookup?  Unlike activation objects,
globals aren't notional.

Oh, okay -- I think I follow you.  So, in any given scope, ns::[expr]
may refer to a local activation object binding or it may refer to a
global one.  (Forget 'with' for the moment.)  I've been arguing that
this kind of name shouldn't be allowed for local lookups, but it
should be allowed for global ones.  The problem is that you don't know
which it is until the lookup is actually performed.

Well, I'd be happy making the criterion purely syntactic:  assuming we
aren't in a 'with' statement, ns::[expr] always refers to a global
binding (not including ns::[expr] to the right of a property operator,
of course.)  In a 'with' statement, the with-ed object has to be
searched first.  'with' certainly complicates lookup, but as you've
pointed out before, its use is visible.

By the way, can a 'use namespace' pragma refer to a namespace via a variable?


> Are you saying I should be allowed to say (supposing
>  namespace 'French' exists):
>
>   French::hello()
>
>  but not
>
>   var language = French
>   language::hello()
>
>  ?  What purpose does it serve to have this restriction if static
>  analysis is not inhibited in the former case, as you wrongly claim it
>  is?

Are you claiming that it's possible to perform early binding of
language::hello?  (Assuming the example isn't actually as simple as
what you've written, I mean.)

-Jon
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss

RE: Strict mode recap

[Lars Hansen]

> -Original Message-
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] On Behalf Of liorean
> Sent: 4. april 2008 10:47
> To: es4-discuss@mozilla.org
> Subject: Re: Strict mode recap
> 
> On 04/04/2008, Lars Hansen <[EMAIL PROTECTED]> wrote:
> >  Your comment about inhibiting static analysis isn't right; if ns::x

> > is a  name then either ns is known to be constant at compile time or

> > not, and  if it is, then nothing prevents early binding. ES3 systems

> > perform  analyses that are inhibited by eval and with, and
statically 
> > detect  whether eval and with are used in order to decide whether to

> > perform the  analyses.
> 
> I thought the argument was about the ns::[name] form... While 
> the namespace may be known at compile time, the actual 
> variable name is not - which means that the implementation 
> actually has to be able to look local variable names up as 
> strings, instead of just object members.
> 
> That is similar in effect to locally scoped eval. ES3 allows 
> restricting eval such that this string look up only has to 
> work if the compiler actually sees an "eval" in the fucntion 
> body, though. I guess the same argument can be made for these 
> dynamic namespace lookups too, however.

Sure, the situation with a variable namespace name and variable
identifier string is the same, and it is always visible to the
compiler.

(BTW I believe that locally bound names in ES4 cannot have explicit
namespaces, but that these names are defined in the common public
namespace (the one Jon calls 'null' though it will probably end
up being called 'public').  The forthcoming spec on names and name
lookup will clarify.)

--lars
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss

Re: Strict mode recap

[liorean]

>  > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
>  > Behalf Of Jon Zeppieri
> > > Let me turn it around.
>  > From my perspective, it isn't an E4X vs. ES4 distinction;
>  > it's a "looking up a property of a first-class object" vs.
>  > "using a local variable" (or, if you prefer, "looking up a
>  > property of an activation
>  > object") distinction.  It's not as if this is an uncommon
>  > distinction in programming languages, and the advantage of
>  > keeping the distinction is better static analysis, better
>  > performance, more tractable code.

On 04/04/2008, Lars Hansen <[EMAIL PROTECTED]> wrote:
>  Your comment about inhibiting static analysis isn't right; if ns::x is a
>  name then either ns is known to be constant at compile time or not, and
>  if it is, then nothing prevents early binding.  ES3 systems perform
>  analyses that are inhibited by eval and with, and statically detect
>  whether eval and with are used in order to decide whether to perform the
>  analyses.

I thought the argument was about the ns::[name] form... While the
namespace may be known at compile time, the actual variable name is
not - which means that the implementation actually has to be able to
look local variable names up as strings, instead of just object
members.

That is similar in effect to locally scoped eval. ES3 allows
restricting eval such that this string look up only has to work if the
compiler actually sees an "eval" in the fucntion body, though. I guess
the same argument can be made for these dynamic namespace lookups too,
however.
-- 
David "liorean" Andersson
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss

RE: Strict mode recap

[Lars Hansen]

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On 
> Behalf Of Jon Zeppieri
> Sent: 3. april 2008 21:35
> To: Lars Hansen
> Cc: es4-discuss@mozilla.org
> Subject: Re: Strict mode recap
> 
> >
> > Let me turn it around.
> >
> >  The syntax ns::v is in the language, for constant identifier v.
> >  If E4X is implemented in an implementation (as it will be in  
> > ActionScript and presumably in Firefox, at least), so is  
> ns::[expr].  
> > How would a restriction to require ns to be a  compile-time 
> constant 
> > (in either form) and not a run-time  value, or a restriction to 
> > disallow the latter form in ES4  but not in E4X, benefit ES4?
> >
> 
> From my perspective, it isn't an E4X vs. ES4 distinction; 
> it's a "looking up a property of a first-class object" vs. 
> "using a local variable" (or, if you prefer, "looking up a 
> property of an activation
> object") distinction.  It's not as if this is an uncommon 
> distinction in programming languages, and the advantage of 
> keeping the distinction is better static analysis, better 
> performance, more tractable code.

I don't get it.

Your comment about inhibiting static analysis isn't right; if ns::x is a
name then either ns is known to be constant at compile time or not, and
if it is, then nothing prevents early binding.  ES3 systems perform
analyses that are inhibited by eval and with, and statically detect
whether eval and with are used in order to decide whether to perform the
analyses.

Anyway, what's the distinction between "dynamic lookup of first-class
object properties", as you write in a later message, and looking up a
name in general, once you introduce namespaced bindings in packages and
global objects (though not in local variables) and couple everything
with 'with'?  Are you saying I should be allowed to say (supposing
namespace 'French' exists):

  French::hello()

but not 

  var language = French
  language::hello()

?  What purpose does it serve to have this restriction if static
analysis is not inhibited in the former case, as you wrongly claim it
is?

--lars
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss

Re: Strict mode recap

[Mark Miller]

On Thu, Apr 3, 2008 at 8:34 PM, Jon Zeppieri <[EMAIL PROTECTED]> wrote:
>  ... treats the environment as if it were a datum.  I know that in the
>  ES3 spec all bindings are referred to as properties of objects, but
>  activation objects are only notional entities.  The current ES4
>  proposal seems to raise their status by giving programmers a simple
>  mechanism to (practically) reify them.

If it's not too violent a change to the spec language, I would like to
see the ES3.1 spec fix that. If we were modifying the spec to document
only ES3.1 strict mode, that would probably be easy. But the new spec
must account for both ES3.1 strict  mode and ES3.1 loose mode.

A separate question: What do people think of "loose" for the opposite
of "strict"?

-- 
Text by me above is hereby placed in the public domain

 Cheers,
 --MarkM
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss