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
> *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
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.
Dave Herman wrote:
> Sorry, I didn't mean to come across so dismissive. I'm not trying to
> ignore you, I just don't have time to keep up with everything. This
> isn't my day job. :)
Wow, I thought it was the day job for most people involved.
>> Since you made that incorrect claim without readi
Brendan Eich wrote:
> 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?
No, they don't have parentheses:
use sugar frozen, Constructo
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 statemen
> 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.
> Dave, your claim that I'm proposing macros will make many
> people ignore and never see the real proposal.
>
> Macros and functions are very, very different. My proposal
> has only regular, run-of-the-mill functions. They don't have
> parentheses around the arguments, but this detail doesn't
> m
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 a
Dave, your claim that I'm proposing macros will make many
people ignore and never see the real proposal.
Macros and functions are very, very different. My proposal
has only regular, run-of-the-mill functions. They don't have
parentheses around the arguments, but this detail doesn't
make them in an
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| requ
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 t
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 --
>>
Yuh-Ruey Chen wrote:
> Well we're all discussing radical new syntaxes (I'm looking at you,
> Ingvar), I might as well propose my own.
Radical? I find my proposal far less radical than, for example, the
Java classes discussed elsewhere.
With Java classes, a paradigm is chosen for you. My sugar emb
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 |thi
On 2008-08-28, at 15:47EDT, Brendan Eich wrote:
> Indeed, Doug Crockford proposed at the January TC39 meeting this
> year to make 'this' act like a lexically bound variable, with the
> only magic to it applying to the case of obj.method() call
> expressions (and variatons, obj[name] where na
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
> Cool. Would there be a 'global' for each module (for some
> interpretation of "module" but assuming each module has its own
> separate top-level lexical scope, as appears to be the growing
> concensus)?
My intention was for the `use lexical scope' mini-proposal to be
orthogonal to any module pr
On Aug 28, 2008, at 10:36 AM, Yuh-Ruey Chen wrote:
> I've taken a look at that, and while it does address free
> variables, I'd
> still rather not have to sprinkle redundant |var|s everywhere.
Those vars are helpful to some readers, who otherwise have to learn
the Python/Ruby/TCL model and lo
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 ini
> 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
> Dave, I really like the lexical scope proposal. However, I do find
> the sections regarding the global a bit confusing. Are the following
> assumptions correct?
If we assume there is no standard library function called `print'...
> this.print = function(s) { ... };
Then this dynamically ad
global as speced for ES4 was equivalent to this in global scope.
There are several use cases for having global. Most of them involves
some kind of reflection. For example finding all global functions
that start with 'test' or finding out if there is an object called
'google.gears.factory'. Anot
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 haz
On Thu, Aug 28, 2008 at 9:44 AM, Erik Arvidsson
<[EMAIL PROTECTED]> wrote:
> I hope we can still have "global" in Harmony. It is ugly to have to do:
> const global = this;
> and rely on that no one moves that code into a closure with a different
> "this".
For what value of "global" should the "g
I hope we can still have "global" in Harmony. It is ugly to have to do:
const global = this;
and rely on that no one moves that code into a closure with a different "this".
Dave, I really like the lexical scope proposal. However, I do find
the sections regarding the global a bit confusing.
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 mi
> 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 n
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 radica
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 t
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 h
31 matches
Mail list logo
