Re: Feature Proposal - async variables (like thread local storage from C)

m that request. >- Find how many database calls one async flow created. >- Keep pools of resources (buffers / connections / tokens) per request. > > In C/C++ one can use thread local storage ( > https://en.wikipedia.org/wiki/Thread-local_storage) to keep information > t

Re: Feature Proposal - async variables (like thread local storage from C)

> > Few examples: > >- Identify HTTP requests and print that a request ID in every log >print that was fan-out from that request. >- Find how many database calls one async flow created. > - Keep pools of resources (buffers / connections / tokens) per request. > >

Feature Proposal - async variables (like thread local storage from C)

- Keep pools of resources (buffers / connections / tokens) per request. In C/C++ one can use thread local storage (https://en.wikipedia.org/ wiki/Thread-local_storage) to keep information that automatically switches with the threads context switch. I imagine a similar mechanism, in the spirit of javasc

Re: Static local variables

-1 On Mon, Aug 10, 2015 at 2:39 PM, joe wrote: > Eek, this is even worse than I though. From the previous discussion: > > If "static" means "shared per-Function-object" or "shared per > activation of the enclosing scope of the > static's scope", we quickly run into weird behavior. Anoth

Re: Static local variables

Eek, this is even worse than I though. From the previous discussion: If "static" means "shared per-Function-object" or "shared per activation of the enclosing scope of the static's scope", we quickly run into weird behavior. Another example, on top of Waldemar's: function foo()

Re: Static local variables

var tmp = intersect_vector_tmp .load(v1).sub(v2); > //do something > v1.add(tmp); > } > > Basically, I was doing the following transform: > > * For each static local variable... > 1. Build unique name from hash of lexical scope chain >

Re: Static local variables

gt; function intersect_vector(v1, v2) { > var tmp = intersect_vector_tmp .load(v1).sub(v2); > //do something > v1.add(tmp); > } > > Basically, I was doing the following transform: > > * For each static local variable... > 1. Build un

Re: Static local variables

>> function intersect_vector(v1, v2) { >> var tmp = intersect_vector_tmp .load(v1).sub(v2); >> //do something >> v1.add(tmp); >> } >> >> Basically, I was doing the following transform: >> >> * For each static local vari

Re: Static local variables

var tmp = intersect_vector_tmp .load(v1).sub(v2); > //do something > v1.add(tmp); > } > > Basically, I was doing the following transform: > > * For each static local variable... > 1. Build unique name from hash of lexical scope chain > 2. Ren

Static local variables

vector_tmp = new Vector(); function intersect_vector(v1, v2) { var tmp = intersect_vector_tmp .load(v1).sub(v2); //do something v1.add(tmp); } Basically, I was doing the following transform: * For each static local variable... 1. Build unique name from hash of lex

Re: Fwd: local variables with inherited values

n my last message's closing. The inner variable is just a local variable, but it's initialized in the hoisting process with the value from the outer scope. That's unusual -- why would it take on the out same-named variable's value? Note it won't work for 'const'

Re: local variables with inherited values

On Tue, Dec 24, 2013 at 7:53 PM, Brendan Eich wrote: > ES4 had let (x = x) ... forms (where ... was an expression or a body), but > for ES6 we agreed on the temporal dead zone: > >> >> Or maybe there's no need for a new keyword :). Not sure I would like an additional body though.

Fwd: local variables with inherited values

What I want is both similar to A2 and B2, but it's different in that there is only 1 scope for the inner variable. The inner variable is just a local variable, but it's initialized in the hoisting process with the value from the outer scope. Initially I was thinking only about var scoped

Re: local variables with inherited values

may seem unusual compared to languages that do not have closures, or that require declarations to come before any closures. /be raul mihaila <mailto:raul.miha...@gmail.com> December 24, 2013 12:10 PM Merry Christmas! Did you consider adding a way for variables to automatically get the value from a

Re: local variables with inherited values

engines don't appreciate that one. :(  24.12.2013, 21:10, "raul mihaila" :Merry Christmas! Did you consider adding a way for variables to automatically get the value from a variable with the same name from the parent execution context? (function () {    var x = 2;        (function ()

local variables with inherited values

Merry Christmas! Did you consider adding a way for variables to automatically get the value from a variable with the same name from the parent execution context? (function () { var x = 2; (function () { local x; // x = 2 x = 100; x; // x = 100 local y

Re: 1js, local fundecls, and not-quite-conforming pre-es6 implementations

Claus Reinke wrote: But with 1JS, I'm no longer sure what happens when new code that relies on local FunDecls (and no other ES6 features) encounters an old implementation. It looks as if there will be no warning or error, just irreconcilable differences in behaviour? That's the ca

1js, local fundecls, and not-quite-conforming pre-es6 implementations

reaching local FunDecls. But with 1JS, I'm no longer sure what happens when new code that relies on local FunDecls (and no other ES6 features) encounters an old implementation. It looks as if there will be no warning or error, just irreconcilable differences in behaviour? Is the recommendation

Explicit local copies (was: Re: lexical for-in/for-of loose end)

for-loop environment. Instead, it is a local environment, whose parent is the for-loop environment. To make that case work, it is not enough to be able to modify the [[Scope]] environment of closures -- in general, you'd need to swap out arbitrary parts of an environment chain. Oww, tha

Re: Two kinds of [] (was: Re: shortcuts for defining block-local private names, plays nicely with @foo syntax)

Thaddee Tyl wrote: Related: this syntax doesn't prevent the user from naming its variable "at", does it? Not at all (heh). Contextual keyword is contextual (and not optional, so it will always be linking a module name to an MRL). /be ___ es-discus

Re: Two kinds of [] (was: Re: shortcuts for defining block-local private names, plays nicely with @foo syntax)

On Sat, Jan 28, 2012 at 1:10 AM, Brendan Eich wrote: >> Tom Van Cutsem >> January 27, 2012 10:53 AM >> >> >>    Off-topic: What is the recommended style for naming modules? >>    Capitalized and camel-cased? It’s nothing I couldn’t get used to, >>    but it seems like t

Re: Two kinds of [] (was: Re: shortcuts for defining block-local private names, plays nicely with @foo syntax)

Tom Van Cutsem January 27, 2012 10:53 AM Off-topic: What is the recommended style for naming modules? Capitalized and camel-cased? It’s nothing I couldn’t get used to, but it seems like the naming precedent would be JavaScript packages. Or is Reflect ca

Re: Two kinds of [] (was: Re: shortcuts for defining block-local private names, plays nicely with @foo syntax)

2012/1/27 Axel Rauschmayer > Off-topic: What is the recommended style for naming modules? Capitalized > and camel-cased? It’s nothing I couldn’t get used to, but it seems like the > naming precedent would be JavaScript packages. Or is Reflect capitalized, > because it is a built-in module? > I h

Re: Two kinds of [] (was: Re: shortcuts for defining block-local private names, plays nicely with @foo syntax)

Off-topic: What is the recommended style for naming modules? Capitalized and camel-cased? It’s nothing I couldn’t get used to, but it seems like the naming precedent would be JavaScript packages. Or is Reflect capitalized, because it is a built-in module? I love how this module is a new home fo

Re: Two kinds of [] (was: Re: shortcuts for defining block-local private names, plays nicely with @foo syntax)

2012/1/23 Herby Vojčík > But it gets harder with getters and setters... maybe if there was an API > for simulating proper legacy foo[bar] and foo[bar]=baz, (Object.get, > Object.set?) generic [] could be dropped without much of a loss. > We'll have Reflect.get and Reflect.set, see < http://wiki.

Re: shortcuts for defining block-local private names, plays nicely with @foo syntax

(resend to list; forgot) Sorry for late answer, but I lost mails from Monday 4:30-17:30 CET, so I waited for them to appear in .gz archive to download and import them to mu inbox again. Answers below. Brendan Eich wrote: Herby Voj??k January 22, 2012 12:34 PM Bre

Re: shortcuts for defining block-local private names, plays nicely with @foo syntax

>> 1. List (or Sequence or something else): same interface as Array (hence >> array-like). No holes, indices are non-negative integers, etc. >> 2. Map (possibly the SimpleMap that has already been specified). > > One reason I introduced this the OMR strawman when I did is because we are > alre

Re: shortcuts for defining block-local private names, plays nicely with @foo syntax

On Jan 24, 2012, at 12:35 PM, Axel Rauschmayer wrote: >>> Reiterating my support for the reformed object model (ROM): I love how the >>> ROM will finally end the clashes between application data (array elements, >>> entries in objects-as-maps) and program definition (methods, non-method >>> pr

Re: shortcuts for defining block-local private names, plays nicely with @foo syntax

>> Reiterating my support for the reformed object model (ROM): I love how the >> ROM will finally end the clashes between application data (array elements, >> entries in objects-as-maps) and program definition (methods, non-method >> properties). It’s a nice clean-up, with a clear migration stra

Re: shortcuts for defining block-local private names, plays nicely with @foo syntax

Axel Rauschmayer January 24, 2012 11:06 AM Reiterating my support for the reformed object model (ROM): I love how the ROM will finally end the clashes between application data (array elements, entries in objects-as-maps) and program definition (methods, non-method prop

Re: shortcuts for defining block-local private names, plays nicely with @foo syntax

Reiterating my support for the reformed object model (ROM): I love how the ROM will finally end the clashes between application data (array elements, entries in objects-as-maps) and program definition (methods, non-method properties). It’s a nice clean-up, with a clear migration strategy. > Reg

Re: shortcuts for defining block-local private names, plays nicely with @foo syntax

On Jan 23, 2012, at 7:43 PM, Axel Rauschmayer wrote: >> Also, the square bracket preference also currently shows up in the object >> literal computed property key proposal so we already have >> obj[privateNameValue] pattern manifesting itself as new ES6 syntax. > > > Would [] in object litera

Re: Two kinds of [] (was: Re: shortcuts for defining block-local private names, plays nicely with @foo syntax)

Allen Wirfs-Brock wrote: On Jan 23, 2012, at 1:14 PM, Herby Vojčík wrote: Axel Rauschmayer wrote: Losing generic [] as a way to access all "native" properties of the object is big price. ... For the few remaining cases, Object.getProperty() (or something similar) should do just fine. Hm.

Re: shortcuts for defining block-local private names, plays nicely with @foo syntax

> Also, the square bracket preference also currently shows up in the object > literal computed property key proposal so we already have > obj[privateNameValue] pattern manifesting itself as new ES6 syntax. Would [] in object literals still make sense if [] was to become a data-only operator?

Re: Two kinds of [] (was: Re: shortcuts for defining block-local private names, plays nicely with @foo syntax)

On Jan 23, 2012, at 1:14 PM, Herby Vojčík wrote: > Axel Rauschmayer wrote: >>> Losing generic [] as a way to access all "native" properties of the >>> object is big price. >> >> I wonder if it really is such a big price: isn’t [] mainly used for >> objects as maps from strings to values? Then yo

Re: shortcuts for defining block-local private names, plays nicely with @foo syntax

I think I'm largely in agreement with what you were saying below, but I do have some additional thoughts I added below... On Jan 23, 2012, at 11:28 AM, Brendan Eich wrote: >> Brendan Eich >> January 23, 2012 11:08 AM >> >> We run into this kind of trade-off all the

Re: shortcuts for defining block-local private names, plays nicely with @foo syntax

Gavin Barraclough January 23, 2012 1:22 PM On Jan 23, 2012, at 1:11 PM, Brendan Eich wrote: Ah, that's the detail that I'd missed! - if private names will be ignored if they are not to the right of @, then presumably my example *would* result in at least a referen

Re: shortcuts for defining block-local private names, plays nicely with @foo syntax

On Jan 23, 2012, at 1:11 PM, Brendan Eich wrote: > Then I think we considered a proposal where private x; bound in a separate > lexical chain but that chain was searched *only* on right of @. That proposal > seemed not to have the readability drawback. It also solves the problem you > show above

Re: Two kinds of [] (was: Re: shortcuts for defining block-local private names, plays nicely with @foo syntax)

Axel Rauschmayer wrote: Losing generic [] as a way to access all "native" properties of the object is big price. I wonder if it really is such a big price: isn’t [] mainly used for objects as maps from strings to values? Then you should use something else in ES6, anyway (SimpleMap, possibly dic

Re: shortcuts for defining block-local private names, plays nicely with @foo syntax

Gavin Barraclough January 23, 2012 12:54 PM On Jan 23, 2012, at 12:27 PM, Brendan Eich wrote: Is the intention here that the private name object would be in scope, and accessible to the user? – if so, this does seem useful, but using the plain name of the property

Re: shortcuts for defining block-local private names, plays nicely with @foo syntax

his module, use a block (but you'll have a harder time exporting -- export must come at module top level). In other way, it is impossible to have truly lexical-local private names. No, the private binding form that is desugared from private foo; to const foo = Name.create("foo&quo

Re: shortcuts for defining block-local private names, plays nicely with @foo syntax

On Jan 23, 2012, at 12:27 PM, Brendan Eich wrote: > No, the private binding form that is desugared from > > private foo; > > to > > const foo = Name.create("foo"); > > or better (with hygiene to use the right Name, etc.) is lexical in its > binding structure. Is the intention here that the

Re: Two kinds of [] (was: Re: shortcuts for defining block-local private names, plays nicely with @foo syntax)

> Losing generic [] as a way to access all "native" properties of the object is > big price. I wonder if it really is such a big price: isn’t [] mainly used for objects as maps from strings to values? Then you should use something else in ES6, anyway (SimpleMap, possibly dict, possibly other ma

Re: shortcuts for defining block-local private names, plays nicely with @foo syntax

secret from other contents of this module, use a block (but you'll have a harder time exporting -- export must come at module top level). In other way, it is impossible to have truly lexical-local private names. No, the private binding form that is desugared from private foo; to const

Two kinds of [] (was: Re: shortcuts for defining block-local private names, plays nicely with @foo syntax)

Allen Wirfs-Brock wrote: Below... Brendan Eich wrote: > Allen Wirfs-Brock > January 23, 2012 8:43 AM > On Jan 22, 2012, at 7:36 PM, Tab Atkins Jr. wrote: > ?.. > > const getIterator = Iterator.getIterator; > myCoolObject.prototype.@getIterator = function()

Re: shortcuts for defining block-local private names, plays nicely with @foo syntax

've done so. If > you, for some reason, want to keep them secret from other contents of > this module, use a block (but you'll have a harder time exporting -- > export must come at module top level). > In other way, it is impossible to have truly lexical-local private names. Y

Re: shortcuts for defining block-local private names, plays nicely with @foo syntax

Brendan Eich January 23, 2012 11:08 AM We run into this kind of trade-off all the time, but the fact is that right now, dot and brackets are equivalent for properties named by strings that match the IdentifierName lexical production. This isn't the case for private

Re: shortcuts for defining block-local private names, plays nicely with @foo syntax

Allen Wirfs-Brock January 23, 2012 11:01 AM Below... Brendan Eich wrote: > Allen Wirfs-Brock > January 23, 2012 8:43 AM > On Jan 22, 2012, at 7:36 PM, Tab Atkins Jr. wrote: > ?.. > > const getIterator = Iterator.getIterator; > myCoolO

Re: shortcuts for defining block-local private names, plays nicely with @foo syntax

Below...Brendan Eich wrote:> Allen Wirfs-Brock > January 23, 2012 8:43 AM > On Jan 22, 2012, at 7:36 PM, Tab Atkins Jr. wrote: > ?.. > > const getIterator = Iterator.getIterator; > myCoolObject.prototype.@getIterator = function() {...} Why wouldn't myCoolObject.pr

Re: shortcuts for defining block-local private names, plays nicely with @foo syntax

ype.@Iterator.getIterator parses as: ((myCoolObject.prototype).@Iterator).getIterator which probably is not what you desire. Taking just what is in my basic proposal, you would have to express this using a local variable: const getIterator = Iterator.getIterator; myCoolObject.prototype.@getIterat

Re: shortcuts for defining block-local private names, plays nicely with @foo syntax

ct will be > common patterns. > myCoolObject.prototype.@Iterator.getIterator parses as: ((myCoolObject.prototype).@Iterator).getIterator which probably is not what you desire. Taking just what is in my basic proposal, you would have to express this using a local variable: const getIterator = Iterator.ge

Re: shortcuts for defining block-local private names, plays nicely with @foo syntax

Herby Vojčík January 23, 2012 3:21 AM It can be solved this way: module { private foo, bar; export function factory1 (args) { ... } export function factory2 (args) { ... } but then foo and bar are known to the rest of the module. It was not the premise.

Re: shortcuts for defining block-local private names, plays nicely with @foo syntax

On Jan 23, 2012, at 12:21 , Herby Vojčík wrote: > Allen Wirfs-Brock wrote: >> I plan on proposing at the next TC39 meeting that we support .@ member >> accesses and that we replace the use of [expr ] to define private named >> properties in object literals ( >> http://wiki.ecmascript.org/doku.php?

Re: shortcuts for defining block-local private names, plays nicely with @foo syntax

f did not, it is bad idea to "globally" define something just for local use of little part of code. So, to do this right, one probably needs to: module { { private foo; export function factory1 (args) { return { @foo: ..., ...,

Re: shortcuts for defining block-local private names, plays nicely with @foo syntax

On 23 January 2012 01:31, Allen Wirfs-Brock wrote: > > 2)  elimination of arbitrary expression as direct keys in object literal > property definitions: > > The current "computed property keys" proposals allows things like: > > for (var n=0;n<10;) { >    a.push( { >       ["prop"+n]: n++ >    }); >

Re: shortcuts for defining block-local private names, plays nicely with @foo syntax

Note: JavaScript will never go the Java or C# route of including properties in local scope (which would be just like `with`), there will just be a shortcut for `this` (so IDEs won’t have a problem). But I agree with your other points: my taste is such that 5 chars are not worth the increase in

Re: shortcuts for defining block-local private names, plays nicely with @foo syntax

Just to confirm: you are not alone. I always thought that allowing to imply local this (‘this.’) was a bad idea (C#). Seriously, this is not 5 chars that’ll hurt but it could make IDE work a lot easier, and it make code reuse more efficient (if you need to copy/paste some code, if you stay in

Re: shortcuts for defining block-local private names, plays nicely with @foo syntax

>> function Point(everyone, secret) { >> .everyone = everyone; > > You're requiring manual semicolon insertion before lines like this. > Consciously? Sight. Right. Not a good idea, then. An important consideration is that eliminating `this` will increase the grawlix-factor of JavaScript (I

Re: shortcuts for defining block-local private names, plays nicely with @foo syntax

Axel Rauschmayer January 23, 2012 1:21 AM I wouldn’t mix public and private, but it would be nice to have symmetry – only having a `this` shortcut for private names feels odd. How about the following? function Point(everyone, secret) { this.everyone = everyone;

Re: shortcuts for defining block-local private names, plays nicely with @foo syntax

> It seems like an unfortunate inconvenience to require any code refactoring > and lose the shorthand @ this-access if you just want to make a private > property on an object be public. Instead of just restricting the token to > the right of a @ or .@ construct be a private name, perhaps it wou

Re: shortcuts for defining block-local private names, plays nicely with @foo syntax

On Jan 22, 2012, at 10:29 PM, Brendan Eich wrote: >> 1) should .@ member access and @ object literal property definitions permit >> he property key to be any toString-able value and not just private name >> values? The current plan of record does not require a private name value in >> the anal

Re: shortcuts for defining block-local private names, plays nicely with @foo syntax

, that's true. If so, then we need to preserve the [] form for use with private names in both the "baz[foo.bar]" form and the "{[foo.bar]: true}" form, unless we find it acceptable for authors to be forced to use a local variable to store the Name every time. Let's split the

Re: shortcuts for defining block-local private names, plays nicely with @foo syntax

alent to "baz[foo.bar]" or "baz[foo].bar"? Normal property-access semantics would give the latter. If so, then we need to preserve the [] form for use with private names in both the "baz[foo.bar]" form and the "{[foo.bar]: true}" form, unless we find it accep

Re: shortcuts for defining block-local private names, plays nicely with @foo syntax

Tab Atkins Jr. January 22, 2012 7:36 PM myCoolObject.prototype[Iterator.getIterator] = function(){...} Using @ for access, would "myCoolObject.prototype.@Iterator.getIterator = function(){...}" work, or would that attempt to retrieve a property using "Iterator" as a

Re: shortcuts for defining block-local private names, plays nicely with @foo syntax

Allen Wirfs-Brock January 22, 2012 4:31 PM I personally have come to the conclusions that obj.@foo would be a better than obj[foo] for accessing a property of obj that is keyed by the private name that is the value of the foo binding. My impression, is

Re: shortcuts for defining block-local private names, plays nicely with @foo syntax

Herby Vojčík January 22, 2012 12:34 PM Brendan Eich wrote: I suspect your very complicated translation with __prvTable__ etc. is intended to hoist private somehow, once per declaration in source rather than once per evaluation of declaration. That's too restrictive, sinc

Re: shortcuts for defining block-local private names, plays nicely with @foo syntax

On Sun, Jan 22, 2012 at 4:31 PM, Allen Wirfs-Brock wrote: > I personally have come to the conclusions that > >    obj.@foo > > would be a better than > >    obj[foo] > > for accessing a property of obj that is keyed by the private name that is > the value of the foo binding. > > My impression, is

Re: shortcuts for defining block-local private names, plays nicely with @foo syntax

On Jan 21, 2012, at 12:07 PM, Brendan Eich wrote: > This was already proposed. See the whole strawman, but in particular these > sections: > > http://wiki.ecmascript.org/doku.php?id=strawman:private_names#the_private_declaration > http://wiki.ecmascript.org/doku.php?id=strawman:private_names#pr

Re: shortcuts for defining block-local private names, plays nicely with @foo syntax

eant as a convenience only for singletion, as they are the hard case. The other cases are easy without need for help from 'private'. So user can put the local case there, by normal means. Or he can put the hard case (singletion with wrapper) with conenient 'private'. oute

Re: shortcuts for defining block-local private names, plays nicely with @foo syntax

I suspect your very complicated translation with __prvTable__ etc. is intended to hoist private somehow, once per declaration in source rather than once per evaluation of declaration. That's too restrictive, since private declarations can be placed in outer blocks or closures for singleton nami

Re: shortcuts for defining block-local private names, plays nicely with @foo syntax

Brendan Eich wrote: And _the_real_foo should be expanded: { private foo; ... } desugars to { const foo = Name.create("foo"); BTW, would this not mean it is different in every run? ... } with Name.create imported appropriately. /be Herby ___ e

Re: shortcuts for defining block-local private names, plays nicely with @foo syntax

Brendan Eich wrote: And _the_real_foo should be expanded: { private foo; ... } desugars to { const foo = Name.create("foo"); ... } with Name.create imported appropriately. No, I though more in lines of: // singleton code, in module level / program level // generated from all private occure

Re: shortcuts for defining block-local private names, plays nicely with @foo syntax

Brendan Eich wrote: Herby Vojčík January 21, 2012 2:21 PM Oh. I favor 1. Inspired by latest notes and for(let...) I would see { private foo; ... } desugared to { let foo = _the_real_foo; Er, const, I hope -- not let. Right? Of course. My mistake. /be Herby

Re: shortcuts for defining block-local private names, plays nicely with @foo syntax

Brendan Eich January 21, 2012 4:39 PM Er, const, I hope -- not let. Right? And _the_real_foo should be expanded: { private foo; ... } desugars to { const foo = Name.create("foo"); ... } with Name.create imported appropriately. /be __

Re: shortcuts for defining block-local private names, plays nicely with @foo syntax

Herby Vojčík January 21, 2012 2:21 PM Oh. I favor 1. Inspired by latest notes and for(let...) I would see { private foo; ... } desugared to { let foo = _the_real_foo; Er, const, I hope -- not let. Right? /be ___

Re: shortcuts for defining block-local private names, plays nicely with @foo syntax

Brendan Eich wrote: Herby Vojčík January 21, 2012 1:56 PM Brendan Eich wrote: private foo; @foo = bar; // this-relative private foo return @foo === other.@foo; return {@foo: bar}; This helps a lot, but there still _is_ an identifier foo having that private name in

Re: shortcuts for defining block-local private names, plays nicely with @foo syntax

Herby Vojčík January 21, 2012 1:56 PM Brendan Eich wrote: Herby Vojčík January 21, 2012 1:33 PM Brendan Eich wrote: http://wiki.ecmascript.org/doku.php?id=strawman:private_names#private_declarations_exist_in_a_separate_name_space_parallel_to_the

Re: shortcuts for defining block-local private names, plays nicely with @foo syntax

Brendan Eich wrote: Herby Vojčík January 21, 2012 1:33 PM Brendan Eich wrote: http://wiki.ecmascript.org/doku.php?id=strawman:private_names#private_declarations_exist_in_a_separate_name_space_parallel_to_the_variable_binding_environment The last really was too much for

Re: shortcuts for defining block-local private names, plays nicely with @foo syntax

Herby Vojčík January 21, 2012 1:33 PM Brendan Eich wrote: This was already proposed. See the whole strawman, but in particular these sections: http://wiki.ecmascript.org/doku.php?id=strawman:private_names#the_private_declaration http://wiki.ecmascript.org/doku.php?i

Re: shortcuts for defining block-local private names, plays nicely with @foo syntax

semicolon-delimited) blocks and ... { private [foo, bar], ... @foo: Date.now(), @bar: cowboys.length, ... aMethod () { ... use @foo and @bar } } in declarative (data-describing, comma-delimited) blocks. In both cases let it be the declaration of (one-time lexical block-local) private names foo and ba

Re: shortcuts for defining block-local private names, plays nicely with @foo syntax

ata-describing, comma-delimited) blocks. In both cases let it be the declaration of (one-time lexical block-local) private names foo and bar. For any curly block. Without need to define these singletons explicitly and wrap them so they are only visible where due, Herby _

shortcuts for defining block-local private names, plays nicely with @foo syntax

... aMethod () { ... use @foo and @bar } } in declarative (data-describing, comma-delimited) blocks. In both cases let it be the declaration of (one-time lexical block-local) private names foo and bar. For any curly block. Without need to define these singletons explicitly and wrap them so

Re: Tennent's correspondence principle and loop-local variable capture

On Thu, Jun 30, 2011 at 4:59 PM, Brendan Eich wrote: > On Jun 30, 2011, at 4:47 PM, Mark S. Miller wrote: > > The whole thread is at >> >> >> https://mail.mozilla.org/pipermail/es-discuss/2008-October/thread.html#7844 >> >> Please see Jon Zeppieri's reply in particular, quote: >> >> I think the r

Re: Tennent's correspondence principle and loop-local variable capture

On Jun 30, 2011, at 4:47 PM, Mark S. Miller wrote: > The whole thread is at > > https://mail.mozilla.org/pipermail/es-discuss/2008-October/thread.html#7844 > > Please see Jon Zeppieri's reply in particular, quote: > > I think the real problem here is > that the , as written by the user, is (or,

Re: Tennent's correspondence principle and loop-local variable capture

On Thu, Jun 30, 2011 at 4:39 PM, Brendan Eich wrote: > On Jun 30, 2011, at 4:27 PM, Mark S. Miller wrote: > > The old C-style for(;;) loop is a hard case. It really does want a single >> shared-mutable loop control variable. Making 'let' instead of var in for >> (let i = 0; i < N; i++) ... bind a

Re: Tennent's correspondence principle and loop-local variable capture

On Jun 30, 2011, at 4:27 PM, Mark S. Miller wrote: > The old C-style for(;;) loop is a hard case. It really does want a single > shared-mutable loop control variable. Making 'let' instead of var in for (let > i = 0; i < N; i++) ... bind afresh on each iteration and communicate the ++ > update a

Re: Tennent's correspondence principle and loop-local variable capture

On Thu, Jun 30, 2011 at 7:27 PM, Mark S. Miller wrote: > > > On Thu, Jun 30, 2011 at 4:07 PM, Brendan Eich wrote: >> >> The old C-style for(;;) loop is a hard case. It really does want a single >> shared-mutable loop control variable. Making 'let' instead of var in for >> (let i = 0; i < N; i++)

Re: Tennent's correspondence principle and loop-local variable capture

On Thu, Jun 30, 2011 at 4:07 PM, Brendan Eich wrote: > On Jun 30, 2011, at 3:33 PM, Vladimir Sedach wrote: > > > Hello, > > > > I was recently pointed to the block scoping and TCP discussions by > > Peter Michaux, and have a question as to how this will affect

Re: Tennent's correspondence principle and loop-local variable capture

On Jun 30, 2011, at 3:33 PM, Vladimir Sedach wrote: > Hello, > > I was recently pointed to the block scoping and TCP discussions by > Peter Michaux, and have a question as to how this will affect the > capture of loop-local variables by closures created in loops. A well-known s

Tennent's correspondence principle and loop-local variable capture

Hello, I was recently pointed to the block scoping and TCP discussions by Peter Michaux, and have a question as to how this will affect the capture of loop-local variables by closures created in loops. Some programming languages (Common Lisp in particular) assign a new binding to loop-local

Re: Proposal: opt-out local scoping

Yes, Dave Herman already mentioned that, and I replied with this: While this is true, this is far less of a problem than opt-in local scoping, because the errors with opt-out local scoping are always going to be local to the block/function the variable was assigned in. Because of this, I believe

Re: Proposal: opt-out local scoping

With this proposal you just get the dual problem: You think you're assigning to an outer-scope variable while in fact you're creating and later discarding a local variable. This would just flip the confusion you worry about to the other case without eliminating it. ES proposa

Code blocks (was Re: Proposal: opt-out local scoping)

Mark S. Miller wrote: > Since ES is not an expression language, it's useful to divide the question > into > > * TC for expressions >expr equiv (function(){return expr;})() >ES violations: this, arguments. >'this' breakage can possibly be addressed with '.bind(this)' as in > my previous

Re: Proposal: opt-out local scoping

correctly, Tennent correspondence says: > > t1: any expr should be equivalent to > (function() {expr}) () > > and one of the difficulties is, what if expr has control-flow > statements, such as break or return. another difficulty is, what if > expr has lexically-scoped sta

Re: Proposal: opt-out local scoping

ficulties is, what if expr has control-flow statements, such as break or return. another difficulty is, what if expr has lexically-scoped statements, such as local variable declarations. assume N is a unique generated symbol. Tennant correspondence could also be stated as t2: any expr sho

Re: Proposal: opt-out local scoping

On 2008-08-28, at 16:52EDT, Brendan Eich wrote: > 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|

Re: Proposal: opt-out local scoping

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

Re: Proposal: opt-out local scoping

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

Re: Proposal: opt-out local scoping

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

Re: Proposal: opt-out local scoping

or you. My sugar embraces the many paradigms of JavaScript. You get clear syntax for many different paradigms. > 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. It&#

  1   2   >