Well we're all discussing radical new syntaxes (I'm looking at you,
Ingvar), I might as well propose my own.
One thing about JavaScript that has always really bothered me (and
probably several of you) is how JavaScript has opt-in local scope,
rather than opt-out local scope. That is, in order to
I agree with you 100% that JavaScript /almost/ gets lexical scope right
and that we should try to eliminate that almost as much as we can. I
don't, however, believe that the right solution is Python's implicit
binding semantics.
where everything assigned in ... results in a variable local to
On 2008-08-28, at 07:52EDT, Dave Herman wrote:
Lexical scope is in the air. :) Please take a look at the lexical
scope proposal on the wiki and offer any comments or suggestions:
http://wiki.ecmascript.org/doku.php?id=strawman:lexical_scope
Essentially, the above is a less radical
I like this, but wouldn't you want to provide escapes, like reformed
with and/or a way to declare an individual reference to be free?
Reformed `with' depended on type annotations and structural type syntax,
which are undergoing discussion. So I think reformed `with' is up in the
air for now.
On 2008-08-28, at 09:09EDT, Dave Herman wrote:
As for free references, what can you do with a free variable? If you
mean you want a way to look something up in the global object, then
use `this.id' or `this[expr]' (or `let global = this' followed by
global.id/global[expr]).
It might
Dave Herman wrote:
I think you're still going to have the same subtleties as hoisting with
this proposal, since all the variables assigned to in the block will be
in scope for the whole block; so they'll be `undefined' before being
assigned to and there will still be the same closure
For what value of global should the global keyword be global? };-
I'm not sure if this is what Erik meant, but my intention was just that
there's a variable bound in the standard library called `global' that's
bound to the global object. The only reason I suggested the name
`global' was that
On Thu, Aug 28, 2008 at 12:14 PM, Dave Herman [EMAIL PROTECTED] wrote:
For what value of global should the global keyword be global? };-
I interpreted Erik's point to be that the binding of `this' is not lexically
scoped, so it would be useful to have a lexically scoped variable initially
On Aug 28, 2008, at 12:14 PM, Dave Herman wrote:
I interpreted Erik's point to be that the binding of `this' is not
lexically scoped, so it would be useful to have a lexically scoped
variable initially bound to the global object. IOW, if I write:
this.print(blah blah blah)
and then I
On Aug 28, 2008, at 1:23 PM, P T Withington wrote:
I'd like to have a syntax where this is _not_ implicitly bound. One
idea would be to riff on default arguments:
function example (receiver=this, ...
Why wouldn't you use |this| for the parameter name? We did for type-
annotating |this|
On Thu, Aug 28, 2008 at 12:29, Dave Herman [EMAIL PROTECTED] wrote:
Would that really satisfy Erik's use case? He seemed to think that
doing, at the top level --
var global = this;
function foo() {
global.bar = 3;
}
is vulnerable to some ${person} going --
function foo() {
Dave Herman wrote:
Reformed `with' depended on type annotations and structural type syntax,
which are undergoing discussion. So I think reformed `with' is up in the
air for now.
I find it odd that reformed |with| required such exact type
annotations, when nothing else does. It would seem
On Aug 28, 2008, at 2:59 PM, Ingvar von Schoultz wrote:
Dave Herman wrote:
Reformed `with' depended on type annotations and structural type
syntax,
which are undergoing discussion. So I think reformed `with' is up
in the
air for now.
I find it odd that reformed |with| required such
On Aug 28, 2008, at 3:26 PM, Ingvar von Schoultz wrote:
Macros and functions are very, very different. My proposal
has only regular, run-of-the-mill functions. They don't have
do have, right?
parentheses around the arguments, but this detail doesn't
make them in any way related to macros
If you mean hygiene, that is not a practical problem so much as a
theoretical one. Dave knows a lot about this topic, so I'll defer to him.
No, hygiene is most certainly a practical problem! Hygiene is about
preventing very subtle bugs that are intermittent and extremely hard to
track down.
On Aug 28, 2008, at 5:35 PM, Dave Herman wrote:
If you mean hygiene, that is not a practical problem so much as a
theoretical one. Dave knows a lot about this topic, so I'll defer
to him.
No, hygiene is most certainly a practical problem!
*Lack* of hygiene is a problem. My statement in
Felix wrote:
ingvar-sugar isn't a macro system. it's pretty similar to python's
@decorator syntax. http://www.python.org/dev/peps/pep-3129/
Yeah, you're right -- IIUC it's very much like Python decorators, though
not class decorators but function decorators, right? IANA Python expert.
*Lack* of hygiene is a problem. My statement in reply to Ingvar's
citing problems with macro systems was that, if he meant by
problems anything like implementing hygienic macros, then
building such systems is a solved problem for certain languages --
albeit without complete
Ok, I'm really confused about the exact semantics of this new syntax. Can
you give explicit rules? As far as I can tell, this sugar function can
either desugar to a (const declaration + assignment + function call +
anonymous function) or just (function call + anonymous function), and I'm
not sure
19 matches
Mail list logo
