Re: Allow specify numbers with suffixes

[Andreas Rossberg]

On 13 December 2017 at 02:26, J Decker  wrote:

>
> My concern would be the non-symmetry/irreversability of this (can't
> get out what you put in)
> Factorio uses such suffixes in their mods but that's a total one-off.
> I've not seen real standards anywhere for this sort of thing in any
> language generally.
>

F# includes a system of user-definable units of measure, based on Andrew
Kennedy's pioneering work. The type system checks that they are used
consistently and it can infer that e.g. acceleration (m/s^2) multiplied by
time (s) yields velocity (m/s).

However, the main benefit of all this is the type checking, so I doubt
there is much value for JavaScript. If you just want dynamic checking you
can build respective classes yourself.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Break out of non-loops

[Andreas Rossberg]

That is already supported in JS, for all statements. Even

label: break label;

is legal in JavaScript, and a convoluted way to write a nop.

On 27 October 2017 at 17:40, Sebastian Malton  wrote:

> Something that is very useful that was recently released into Rust was the
> idea of using a break statement to break out of the current level. This is
> already the case for loops but in Rust it was extended to all statements
> encased in {}.
>
> This would make some code a lot easier to understand as it can eliminate
> flag variables
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: super return

[Andreas Rossberg]

On 29 August 2017 at 14:30, Sebastian Malton  wrote:

> If a function outlives its creation scope then this would do exactly what
> a normal return would do.
>

That makes no sense, because that's a completely different continuation,
usually expecting different, unrelated types of results. It needs to be an
error at least. (In a language with proper continuations the outer
continuation would be captured by the inner closure and invoking it later
would reestablish the execution context to return to. But TC39 always
agreed that we don't want full-blown continuations in JS.)


> *From:* rossb...@google.com
> *Sent:* August 29, 2017 6:55 AM
> *To:* sebast...@malton.name
> *Cc:* es-discuss@mozilla.org
> *Subject:* Re: super return
>
> On 28 August 2017 at 21:29, Sebastian Malton 
> wrote:
>
>> Thus I propose the new syntax `super return` and any other positive
>> number of supers. This syntax is currently not valid in any scenario and
>> with the current meaning of super seems, to me at least, relativity easy to
>> understand.
>>
>> The outcome of this basically means "return from current context up one
>> level and then return from there".
>>
>
> What if that context is no longer live? A function can outlive its
> creation scope. You could even try returning twice from the same function.
>
> Allowing returns from outer functions has been discussed extensively in
> the ES6 phase (e.g. under the term "blocks"), but has been decided against
> in favour of arrow functions. One problem is that it introduces quite
> complex dynamic behaviour in general (it's halfway to introducing delimited
> continuations), and many new ways to fail.
>
>
> A current method of doing this is by using try / catch but it is not
>> ideal. Using the above method I believe that it would be able to be better
>> optimized.
>>
>
> That's unlikely, since it is just as dynamic in the general case (and the
> less general cases can be optimised equally well for both).
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: super return

[Andreas Rossberg]

On 28 August 2017 at 21:29, Sebastian Malton  wrote:

> Thus I propose the new syntax `super return` and any other positive number
> of supers. This syntax is currently not valid in any scenario and with the
> current meaning of super seems, to me at least, relativity easy to
> understand.
>
> The outcome of this basically means "return from current context up one
> level and then return from there".
>

What if that context is no longer live? A function can outlive its creation
scope. You could even try returning twice from the same function.

Allowing returns from outer functions has been discussed extensively in the
ES6 phase (e.g. under the term "blocks"), but has been decided against in
favour of arrow functions. One problem is that it introduces quite complex
dynamic behaviour in general (it's halfway to introducing delimited
continuations), and many new ways to fail.


A current method of doing this is by using try / catch but it is not ideal.
> Using the above method I believe that it would be able to be better
> optimized.
>

That's unlikely, since it is just as dynamic in the general case (and the
less general cases can be optimised equally well for both).
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Removal of language features

[Andreas Rossberg]

On 27 July 2017 at 14:23, Mark  wrote:

>
> if Joe User observes that a website suddenly got notably slower with a new
> version of their browser then they will blame the browser.
>
> This is a rather large assumption to make and, at the same time, I don’t
> think it is true. When users go to a slow-loading website, I think it’s
> much more likely they’ll blame the website developer. If an application
> runs slow on your OS, you wouldn’t blame it on the OS vendor. Similarly, if
> an application I just upgraded runs slow on my mobile device, I wouldn’t
> automatically assume it's the phone manufacturer.
>
I'm talking about the situation were they upgrade the browser and observe
that a known site runs slower afterwards than it did before. Nothing else
changed. Of course they gonna blame it on the browser update, and correctly
so.



> ​
>
> On Thu, Jul 27, 2017 at 7:55 AM kai zhu  wrote:
>
>> On Jul 27, 2017, at 5:43 PM, Andreas Rossberg 
>> wrote:
>>
>>
>> That is not always true. For example, ES6 has caused some notable
>> performance regressions for ES5 code initially, due to extensions to the
>> object model that made it even more dynamic. The new @@-hooks were
>> particularly nasty and some cases required substantial amounts of work from
>> implementers just to get back close to the previous baseline performance.
>> Parsing also slowed down measurably. Moreover, many features tend to add
>> combinatorial complexity that can make the surface of "common cases" to
>> optimise for in preexisting features much larger.
>>
>>
>> I’ve noticed chrome 59 freezing more when initially loading pages.  Maybe
>> its due to performance-penalty of extra parser complexity, maybe not.
>> Also, the chrome-based electron-browser has gotten slower with each release
>> over the past year, when I use it to test mostly es5-based browser-code.
>> Can’t say about the other browser-vendors as I don’t use them as much.
>>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Re: FW: Removal of language features

[Andreas Rossberg]

On 27 July 2017 at 12:07, Mark  wrote:

> I think it is a mistake to assume that a developer has a right to always
> have optimal performance without requiring anything to get it.  It almost
> sounds like you're saying that there should be no cost to the consumer for
> choosing not to evolve with the language.
>

In an ideal world, I would agree. But that's not how the game theory works
out on the web. What Brendan already pointed out wrt breaking sites also
applies to performance regressions: if Joe User observes that a website
suddenly got notably slower with a new version of their browser then they
will blame the browser. That effect is further elevated by tech reviews
often performing measurements with hopelessly outdated benchmarks. So no
browser vendor can afford significant regressions, unless they have an urge
to look bad in public perception.



>
> Things we buy into in life (not just a coding language) will depreciate in
> value and will require either an upgrade or a replacement or significant
> maintenance and, if not done, the consumer will suffer the consequences of
> choosing to remain stagnant. And the longer the stagnation, the greater the
> change needed to put the consumer in the same (or better) position they
> were in before the depreciation got so bad.
>
> That said, I'm still struggling to see a real need to remove older JS
> features.
>
> On Thu, Jul 27, 2017 at 5:44 AM Andreas Rossberg 
> wrote:
>
>> On 27 July 2017 at 11:00, Mark  wrote:
>>
>>> It has already been mentioned that there is likely no performance
>>> degradation when adding new features.
>>>
>>
>> That is not always true. For example, ES6 has caused some notable
>> performance regressions for ES5 code initially, due to extensions to the
>> object model that made it even more dynamic. The new @@-hooks were
>> particularly nasty and some cases required substantial amounts of work from
>> implementers just to get back close to the previous baseline performance.
>> Parsing also slowed down measurably. Moreover, many features tend to add
>> combinatorial complexity that can make the surface of "common cases" to
>> optimise for in preexisting features much larger.
>>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Re: FW: Removal of language features

[Andreas Rossberg]

On 27 July 2017 at 11:00, Mark  wrote:

> It has already been mentioned that there is likely no performance
> degradation when adding new features.
>

That is not always true. For example, ES6 has caused some notable
performance regressions for ES5 code initially, due to extensions to the
object model that made it even more dynamic. The new @@-hooks were
particularly nasty and some cases required substantial amounts of work from
implementers just to get back close to the previous baseline performance.
Parsing also slowed down measurably. Moreover, many features tend to add
combinatorial complexity that can make the surface of "common cases" to
optimise for in preexisting features much larger.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Re: FW: Removal of language features

[Andreas Rossberg]

On 26 July 2017 at 18:10, Mike Samuel  wrote:

> On Wed, Jul 26, 2017 at 5:55 AM, Andreas Rossberg 
> wrote:
> > And clearly, modes or versions only make things worse in that regard.
> Strict
> > mode already is a pig when it comes to implementation complexity (in
> > retrospect, it does not carry its weight IMHO). ES6 made it worse. Our
>
> IIRC, the primary argument for strict mode wasn't implementation
> simplicity, but the ability to do sound static analysis.
>

Right, I was merely lumping a reply to two different suggestions into a
single reply.



> var x;
> function f(a, b) {
>   a(b);
>   return x;
> }
>
> isn't analyzable because f(eval, 'var x = 1;') could cause the
> returned x to refer to a local instead of the outer x but add "use
> strict" to either scope and suddenly it is statically analyzable.
>

Actually, it cannot. An indirect call to eval cannot inject anything into
the caller scope.

On the other hand, any use of indirect eval can inject something into the
global scope, whether the caller is in strict mode or not. Overall, I thus
don't think that strict mode makes JavaScript sufficiently better.



> When you say that strict mode "does not carry its weight," are you
> saying that that the ability to do sounds static analysis doesn't
> warrant the additional complexity or are you referring to a different
> bundle of benefits?
>

The "ability to do sound static analysis" is not a binary characteristics.
You can do analysis on JS. With strict mode you have a couple more
invariants, so can do slightly better, but from my perspective it's not
even close to a game changer.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Re: FW: Removal of language features

[Andreas Rossberg]

On 26 July 2017 at 17:38, Brendan Eich  wrote:

> Hi Andreas, is this the best link to the Strong Mode post-mortem?
>
> https://groups.google.com/d/msg/strengthen-js/ojj3TDxbHpQ/5ENNAiUzEgAJ
>

Yup.


On Wed, Jul 26, 2017 at 2:56 AM Andreas Rossberg 
> wrote:
>
>> As for the reoccurring assumption that deprecation would help simplifying
>> JavaScript implementations: no, not to a relevant degree. 80+% of the
>> complexity in a JS VM comes from the plethora of (sometimes ridiculous)
>> edge cases in the core semantics of JavaScript, its object model, implicit
>> conversions, etc., and the desire to make all that fast in the common case
>> without breaking correctness of the million special cases. None of that can
>> be deprecated without creating a completely new language.
>>
>> And clearly, modes or versions only make things worse in that regard.
>> Strict mode already is a pig when it comes to implementation complexity (in
>> retrospect, it does not carry its weight IMHO). ES6 made it worse. Our
>> experiments with strong mode a while ago increased complexity even further,
>> so much that the urge to rip it out again overtook very quickly. I for one
>> am eternally healed of modes.
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Re: FW: Removal of language features

[Andreas Rossberg]

As for the reoccurring assumption that deprecation would help simplifying
JavaScript implementations: no, not to a relevant degree. 80+% of the
complexity in a JS VM comes from the plethora of (sometimes ridiculous)
edge cases in the core semantics of JavaScript, its object model, implicit
conversions, etc., and the desire to make all that fast in the common case
without breaking correctness of the million special cases. None of that can
be deprecated without creating a completely new language.

And clearly, modes or versions only make things worse in that regard.
Strict mode already is a pig when it comes to implementation complexity (in
retrospect, it does not carry its weight IMHO). ES6 made it worse. Our
experiments with strong mode a while ago increased complexity even further,
so much that the urge to rip it out again overtook very quickly. I for one
am eternally healed of modes.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Sealed & Frozen Object/Array Syntax

[Andreas Rossberg]

https://web.archive.org/web/20110509070204/http://wiki.ecmascript.org:80/doku.php?id=strawman:records
https://web.archive.org/web/20110509070209/http://wiki.ecmascript.org:80/doku.php?id=strawman:tuples

On 17 July 2017 at 10:51, Keith Cirkel  wrote:

> As functional programming because more mainstream - developers are leaning
> more and more on immutability - with tools like immutable.js. However there
> exists perfectly good solutions inside of JS with Object.seal &
> Object.freeze.
>
> I propose making a short syntax to allow for creating of sealed/frozen
> objects that looks like this:
>
> ```js
> {| foo: 1 |} // same as Object.seal({ foo: 1 })
> {# foo: 1 #} // same as Object.freeze({ foo: 1 })
>
> [| 1, 2, 3 |] // same as Object.seal([ 1, 2, 3 ])
> [# 1, 2, 3 #] // same as Object.freeze([ 1, 2, 3 ])
>
> // Deep frozen objects becomes a case of using frozen notation all the way
> down:
> {# foo: {# bar: 1 #} #} // same as Object.freeze({ foo: Object.freeze({
> bar: 1 }) })
> [# [# 1, 2 #], [# 3, 4 #] #] // same as Object.freeze([Object.freeze([1,2]),
> Object.freeze([3, 4]])
> ```
>
> This short syntax allows for a much more expressive way of writing/reading
> sealed & frozen objects. I look forward to a discussion about this.
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Pattern matching?

[Andreas Rossberg]

On 30 June 2017 at 15:55, Henrik Sommerland 
wrote:

> Why is there no support for pattern matching in JavaScript?
> I would guess that it has been proposed before, and if so why hasn't it
> been included?
>
> I have been thinking about it and I think it would integrate nicely into
> JavaScript.
> If it hasn't been proposed already I would propose it, and I would gladly
> look into it more and try to examine what kind of semantics would be
> suitable.
>

Long ago there was a proposal:

https://web.archive.org/web/20111206195512/http://wiki.ecmascript.org/doku.php?id=strawman:pattern_matching
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Deterministic Proposal

[Andreas Rossberg]

On 22 June 2017 at 01:24, Guy Ellis  wrote:

> My thoughts are along the lines that the developer would decide what a
> deterministic function was and decorate/tag it as such. That's why I used
> the word deterministic and not pure. Basically the developer is signaling
> the compiler that given an identical parameter signature the result
> received back from the first call can be used for all subsequent results.
>
> The developer implementing compiler optimization would then have a flag
> available against any method that would signal if it is deterministic or
> not and would decide to use that information or not.
>

Except in a very small set of uninteresting cases, such an optimisation is
not allowed, because it changes the semantics of the function. A "tag" as a
compiler hint would not change that. The semantics of every language
construct has to be well-defined, and must not depend on whether or not a
compiler chooses to apply certain optimisations.




> The question is: Would that extra information provide the Compiler
> Optimizing Developer with information that they could use to improve
> performance or anything else? If you are/were such a
> Compiler-Optimizing-Developer how would you use this information?
>
>
> On Wed, Jun 21, 2017 at 9:59 AM Andreas Rossberg 
> wrote:
>
>> On 21 June 2017 at 18:40, Bradley Meck  wrote:
>>
>>> You probably mean "pure", not "deterministic", which has nothing to do
>>>> with this. However, JavaScript is far, far too impure for any such
>>>> annotation to ever make sense or enable any sort of memoization. Consider
>>>> let i = 0
>>>> let o = {valueOf() {return i++}}
>>>> sum(o, 0)
>>>> sum(o, 0)
>>>
>>>
>>> If type coercion was disabled within "pure" functions I am not sure this
>>> would be a problem.
>>>
>>
>> A new language mode with modified semantics is a whole new dimension that
>> is far from simple to add to JS. And even then the pure subset of JS would
>> remain tiny.
>>
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Deterministic Proposal

[Andreas Rossberg]

On 21 June 2017 at 18:40, Bradley Meck  wrote:

> You probably mean "pure", not "deterministic", which has nothing to do
>> with this. However, JavaScript is far, far too impure for any such
>> annotation to ever make sense or enable any sort of memoization. Consider
>> let i = 0
>> let o = {valueOf() {return i++}}
>> sum(o, 0)
>> sum(o, 0)
>
>
> If type coercion was disabled within "pure" functions I am not sure this
> would be a problem.
>

A new language mode with modified semantics is a whole new dimension that
is far from simple to add to JS. And even then the pure subset of JS would
remain tiny.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Deterministic Proposal

[Andreas Rossberg]

On 21 June 2017 at 00:58, Guy Ellis  wrote:

> I have an idea rattling around that allowing the developer to mark a
> function as deterministic would allow the compiler to determine if a
> speed/memory memoization trade-off will improve performance.
>
> Possible syntax:
>
> deterministic function sum(a, b) { return a + b; }
>
> Use case:
>
> I can only think of one right now: compiler memoization
>

You probably mean "pure", not "deterministic", which has nothing to do with
this. However, JavaScript is far, far too impure for any such annotation to
ever make sense or enable any sort of memoization. Consider

let i = 0
let o = {valueOf() {return i++}}
sum(o, 0)
sum(o, 0)

 On 21 June 2017 at 17:34, Isiah Meadows  wrote:

> I'd like to note that even Haskell compilers (which can check for this
> trivially) never memoize implicitly. They only memoize infinite data
> structures.
>
> [...]
>
> The only time I have found memoization to be very useful is in one
> specific case: lazy evaluation (run once). But that is constrained to
> just evaluating a thunk and storing the result.
>

I think you are confused. Laziness and memoization are different
mechanisms. And neither takes the finiteness of a data structure into
account.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Arrow function followed by divide or syntax error?

[Andreas Rossberg]

Note that the arrow function can only form an ExpressionStatement, which
requires a terminating semicolon. There is none in this example, nor a line
break that would allow one to be inserted implicitly. So when reaching the
first `/` a syntax error is apparent, since there is no way the input can
still form a well-formed statement at that point.

On 24 May 2017 at 10:32, Peter van der Zee  wrote:

> > Unlike an ordinary function expression, which is a PrimaryExpression, an
> arrow function is merely an AssigmentExpression, so has much lower
> precedence than any arithmetic operator.
>
> I'm curious how this should be parsed so let's break this down.
>
> Given the following "Script" (I don't think the actual goal matters much
> here):
> ```
> x=x=>{}/alert(1)/+alert(2)//
> ```
>
> Script :
>   ScriptBody opt
>
> ScriptBody :
>   StatementList
>
> StatementList [Yield, Return] :
>   StatementListItem [?Yield, ?Return]
>   StatementList [?Yield, ?Return] StatementListItem [?Yield, ?Return]
>
> StatementListItem [Yield, Return] :
>   Statement [?Yield, ?Return]
>   Declaration [?Yield]
>
> Statement [Yield, Return] :
>   BlockStatement [?Yield, ?Return]
>   VariableStatement [?Yield]
>   EmptyStatement
>   ExpressionStatement [?Yield]
>   ... (trunced)
>
> ExpressionStatement [Yield] :
>   [lookahead ∉ { { , function , class , let [ }] Expression [In, ?Yield] ;
>
> Expression [In, Yield] :
>   AssignmentExpression [?In, ?Yield]
>   Expression [?In, ?Yield] , AssignmentExpression [?In, ?Yield]
>
> AssignmentExpression [In, Yield] :
>   ConditionalExpression [?In, ?Yield]
>   [+Yield]
>   YieldExpression [?In]
>   ArrowFunction [?In, ?Yield]LeftHandSideExpression [?Yield] =
> AssignmentExpression [?In, ?Yield]
>   LeftHandSideExpression [?Yield] AssignmentOperator
> AssignmentExpression [?In, ?Yield]
>
> I hope we can agree that the leading `x=` is consumed by
> "LeftHandSideExpression [?Yield] AssignmentOperator" in the very last
> rule above. Proceeding with "AssignmentExpression" from the arrow arg.
>
> Note that there is no other rule that applies up to this point.
>
> ArrowFunction [In, Yield] :
>   ArrowParameters [?Yield] [no LineTerminator here] => ConciseBody [?In]
>
> ArrowParameters [Yield] :
>   BindingIdentifier [?Yield]
>   CoverParenthesizedExpressionAndArrowParameterList [?Yield]
>
> Here "CoverParenthesizedExpressionAndArrowParameterList" will consume
> the second `x` and then the only rule in "ArrowFunction" will consume
> the arrow (`=>`). Continueing to parse the remainder
> `{}/alert(1)/+alert(2)//` starting at "ConciseBody".
>
> ConciseBody [In] :
>   [lookahead ≠ {] AssignmentExpression [?In]
>   { FunctionBody }
>
> Obviously only the second rule applies so we parse the function body
> and the curlies. We parse greedy but the function body is empty so
> only the next two chars are consumed (`{}`). Parser has
> `/alert(1)/+alert(2)//` left to parse and the "Statement" rule has
> depleted it's options. So we go back to "StatementList" and parse
> another statement. This should result in a regular expression, a plus
> operator, a call expression, and a single line comment.
>
> I don't think there's a rule here that allows parsing operators after
> an explicit arrow function body as being part of the arrow function.
> In fact, I remember that this was explicitly designed this way to
> prevent this ambiguity. Beyond that I agree that it parses similar to
> function expressions.
>
> If this was wrong I'd love to know the right way to parse this.
>
> - peter
>
>
>
> On Wed, May 24, 2017 at 9:18 AM, Andreas Rossberg 
> wrote:
> > On 24 May 2017 at 08:57, Gareth Heyes 
> wrote:
> >>
> >>
> >>>
> >>> you'll get a SyntaxError in all browsers but Edge, which interprets it
> as
> >>> `(x => {}) * alert(1)`.
> >>>
> >>> Given how confusing that expression is, I think that the SyntaxError is
> >>> the right choice.
> >>
> >>
> >>  Well it is a function expression. So IMO Edge is right. It's equivalent
> >> to:
> >> x=function(){} * alert(1)
> >
> >
> > Edge is wrong. Unlike an ordinary function expression, which is a
> > PrimaryExpression, an arrow function is merely an AssigmentExpression, so
> > has much lower precedence than any arithmetic operator. The rationale is
> > that its body doesn't necessarily have braces, so `x => x * 1` would be
> > ambiguous.
> >
> > ___
> > es-discuss mailing list
> > es-discuss@mozilla.org
> > https://mail.mozilla.org/listinfo/es-discuss
> >
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Arrow function followed by divide or syntax error?

[Andreas Rossberg]

On 24 May 2017 at 08:57, Gareth Heyes  wrote:

>
>
>> you'll get a SyntaxError in all browsers but Edge, which interprets it as
>> `(x => {}) * alert(1)`.
>>
>> Given how confusing that expression is, I think that the SyntaxError is
>> the right choice.
>
>
>  Well it is a function expression. So IMO Edge is right. It's equivalent
> to:
> x=function(){} * alert(1)
>

Edge is wrong. Unlike an ordinary function expression, which is a
PrimaryExpression, an arrow function is merely an AssigmentExpression, so
has much lower precedence than any arithmetic operator. The rationale is
that its body doesn't necessarily have braces, so `x => x * 1` would be
ambiguous.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Proxy

[Andreas Rossberg]

On 15 December 2016 at 03:26, Boris Zbarsky  wrote:

> I presume most implementations define scope
>> variables much like object properties internally.
>>
>
> That's not clear to me at all.  In general, non-object environments don't
> need to support all the operations objects do (e.g. you can't delete
> bindings), so the implementation tradeoffs are quite different and using a
> separate codepath for environments and object properties is likely to be
> appropriate.  Certainly the one implementation for which I know this
> details (SpiderMonkey) has quite different implementations for scope
> variables and object properties.


Indeed, the two couldn't be more different. In general, there isn't even a
self-contained data structure representing a scope, let alone a unique one.
Some variables might live in registers, some on the stack, some on the
heap, some in several of those places at different points in time, some are
optimised away entirely. Their names are not generally kept around either.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Code smell? Iterator prototype has iterator method that returns "this"

[Andreas Rossberg]

The ES6 iterator/iterable story has been criticised more than once, by a
number of people. Too lazy to dig up all those threads, but if you search
es-discuss for iterable and iterator you will find it a reoccurring scheme.
AFAIK, this thread contained the first such discussion:
https://mail.mozilla.org/pipermail/es-discuss/2013-March/029004.html

The short story from my POV is: the notion of iterators vs. iterables in
ES6 makes no coherent sense, but many people want their implicit
conversions despite any smell, and this basically provides (a
user-definable) one from anything to an iterator.

On 26 July 2016 at 04:16, Allen Wirfs-Brock  wrote:

>
> > On Jul 25, 2016, at 4:38 PM, John Lenz  wrote:
> >
> > Yes, but at the cost of being able to reason / declare what kind of
> object is actually required.  But, I'm sure there is nothing that can be
> changed here.
>
> The kind of object that is required is one that implements the Iterable
> interface (i.e., has a Symbol.interable method that returns an object that
> implements the Iterator interface).  What is unclear about that?
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: ES7 - the standard

[Andreas Rossberg]

Async functions are coming along fine and are on track for ES8. There has
been little to zero progress on value types, because they have no active
champion but many, many open questions.

On 19 June 2016 at 13:00, Dan Peddle  wrote:

> Two things I was hoping to see appear to be absent from the spec doc as
> kindly shared by Raul - async / await (
> https://tc39.github.io/ecmascript-asyncawait/) and value types/objects (
> https://github.com/sebmarkbage/ecmascript-immutable-data-structures etc).
>
> Is it straightforward to summarise what's happening on those fronts..? How
> are they coming on..?
>
>
> On Fri, Jun 17, 2016 at 6:32 PM, Leo Balter 
> wrote:
>
>> There are some other changes, like the removal of Proxy trap and Reflect
>> method for enumerate, includes is also a new method for TypedArrays, as it
>> is different than Array#includes as it validates `this` as a valid
>> typedArray instance. ECMAScript code is now expressed using Unicode 8.0.0
>> or later (from 5.1 or later), etc.
>>
>>
>> One way to track this is searching for Normative changes on
>> github.com/tc39/ecma262 commits until Mar/2016.
>> While the commits are not perfectly flagged, it's another way to find
>> some other minor changes.
>>
>> On Fri, Jun 17, 2016 at 3:50 AM, Thaddee Tyl 
>> wrote:
>>
>>> (Small typo, the path was changed to
>>> , since that is the
>>> direction we go for naming.)
>>> ___
>>> es-discuss mailing list
>>> es-discuss@mozilla.org
>>> https://mail.mozilla.org/listinfo/es-discuss
>>>
>>
>>
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>>
>
>
> --
>
> Dan Peddle
> *tel*: +49 157 3918 2066
> *email*: d...@flarework.com
> *www*: http://flarework.com
> *in*: http://pt.linkedin.com/in/danpeddle
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Can strict parameters shadow strict function names?

[Andreas Rossberg]

On 9 June 2016 at 19:58, Bergi  wrote:

> Mark S. Miller wrote:
>
>> var foo = function bar(bar) {'use strict'};
>>
>> On all version of Safari/JSC I just tested, this code gives a
>> SyntaxError: Invalid parameters or function name in strict mode.
>>
>> On all versions of Chrome/v8 and FF/SpiderMonkey I just tested, this code
>> is accepted without error.
>>
>> Which behavior is incorrect?
>>
>
> This appears to be a bug in Safari/JSC.
>
> Is this an ES5 vs ES2015 issue?
>>
>
> No, both ES5  and ES6 <
> http://www.ecma-international.org/ecma-262/6.0/#sec-function-definitions-static-semantics-early-errors>
> only have a syntax error if there are duplicate *parameter* names,
> regardless of the name of the function.


In particular, the function name is in its own singleton scope outside the
parameter scope. My guess is that this semantics was chosen so that
collision doesn't differ between function declarations and expressions.

/Andreas
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Process of proposing targeted deconstruction

[Andreas Rossberg]

Can't wait til we've reached ES15 in 2024!

On 1 June 2016 at 16:01, Caitlin Potter  wrote:

> Oh sure you have,
>
> https://chromium.googlesource.com/v8/v8/+/master/test/mjsunit/es8/ for
> instance :p
>
> On Jun 1, 2016, at 9:59 AM, Leo Balter  wrote:
>
> I haven't seen anyone referring to ES2017 as ES8, so I imagine we won't
> have this problem anymore in a couple years. In anyway, this is an addition
> that won't happen to ES2016, it's too late for that.
>
> On Wed, Jun 1, 2016 at 9:36 AM, John Gardner 
> wrote:
>
>> *> There is no such thing as ES7.*
>>
>> You say that as though you can control how people index language versions
>> in their minds...
>>
>> On 1 June 2016 at 23:33, Mark S. Miller  wrote:
>>
>>> ES2015 was the last version for which the short for ("ES6") was also in
>>> common use. After that, there is only ES2016 etc. There is no such thing as
>>> ES7.
>>>
>>>
>>> On Wed, Jun 1, 2016 at 3:03 PM, John Gardner 
>>> wrote:
>>>
 I'd like to propose a simple yet potent syntax addition
 
 for /ECMAScript\d+/. What's the most direct approach to get this
 officially considered? I've seen differing procedures mentioned in places
 and I'm unsure.

 BTW, am I the only one getting confused by the year-based naming
 convention? I skip over intermediate letters when reading and only absorb
 the last digit, which makes me mistake ES2017 as ES7, which is actually
 ES2016, which I get mixed up with ES6, which is ES2015.

 ___
 es-discuss mailing list
 es-discuss@mozilla.org
 https://mail.mozilla.org/listinfo/es-discuss


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

Re: Is `undefined` garabage collectable?

[Andreas Rossberg]

Arrays are probably your best bet (but don't ever `delete` elements, or
change the size of your array!).

I don't understand what you mean by "placeholder". But FWIW, array keys
(i.e., small integers) are usually unboxed, i.e., not heap-allocated.

A general advise, though: don't be over-concerned with GC. There are a lot
of misconceptions about its performance. It is quite efficient in most
practical cases -- much more so than most attempts to work around it and
manage life-times manually.

On 9 May 2016 at 20:06, /#!/JoePea  wrote:

> Thanks Andreas, that's helpful to know. In general, is there some way to
> keep a list (adding removing things over time) while avoiding GC?
>
> For example, I thought I could place and remove items into a list (f.e.
> Set or Map, while having my own references to all the items and the list
> and outside of the list as well as to the list itself), but as you pointed
> out that still can have need for GC.
>
> I know you said
>
> > In general, there is very little you can do in JavaScript that does not
> potentially cause allocation and thus GC
>
> But, I would at least want to know that I minimized GC as much as
> possible. My first hunch (for my case) would be to make a linked list out
> of the items I need to have a "list" of, where each item's link (reference)
> to the next item is also one of the references that I already hold outside
> of the list?
>
> It seems that with Arrays (and Sets and Maps) that deleting an item from
> the list also deletes the placeholder that was used for that item (in the
> case of Array, the placeholders would be the numerical keys that are
> deleted when an item is popped for example), and I'm guessing (with my
> still expanding VM knowledge) that those placeholders are GCed separately
> from the thing that was referenced to by the placeholder (so even if the
> placeholder contained `null` there would still be GC). Is that a good guess?
>
> I'll be experimenting...
>
> On Mon, May 9, 2016 at 2:28 AM, Andreas Rossberg 
> wrote:
>
>> The `undefined` value is represented in exactly the same way as `true`,
>> `false`, and `null` in V8. They're so called "oddballs" internally, global
>> values that are neither allocated nor freed.
>>
>> Either way, the key/values of a (regular) map do not keep anything alive
>> about the map. Adding or removing entries from a set or map can of course
>> cause allocation/deallocation, regardless of the keys/values themselves.
>> (Similarly if you are using regular objects as maps, btw.)
>>
>> There are also lots of other things that cause allocation/deallocation
>> under the hood of a JavaScript engine, e.g. compilation, optimisation,
>> deoptimisation, etc. Some of that predominantly happens at start-up. If you
>> want to reduce random noise from your experiments, try to warm up the code
>> first. But even then, don't read too much into micro-benchmarks -- JS VMs
>> are far too complicated, dynamic, and heuristics-based to draw useful
>> conclusions from tiny tests (that's e.g. why JSPerf tests are often
>> bollocks).
>>
>> In general, there is very little you can do in JavaScript that does not
>> potentially cause allocation and thus GC. Certainly nothing involving
>> dynamic data structures.
>>
>> /Andreas
>>
>>
>> On 5 May 2016 at 07:48, /#!/JoePea  wrote:
>>
>>> > The only v8 shell I have lying around is too old (3.14.5.10) to have
>>> Set, so I can't tell you what it would do.
>>>
>>> On my first attempt, I noticed 8 Major GCs:
>>> https://cloud.githubusercontent.com/assets/297678/15036715/f41ea4d4-1247-11e6-8823-f153c3c1b7bb.png
>>>
>>> On second attempt, no Major GCs:
>>> https://cloud.githubusercontent.com/assets/297678/15036788/c066483a-1248-11e6-970b-3f9d20710bbc.png
>>>
>>> I wonder why. I'm in Chrome 50.
>>>
>>> So, the second attempt looks good. I'm not sure why the first is so
>>> different. I tried it a few times, but I only got that Major GC zig-zag the
>>> first time.
>>>
>>> Thanks for pointing out Set!
>>>
>>> On Wed, May 4, 2016 at 7:30 PM, Boris Zbarsky  wrote:
>>>
>>>> On 5/4/16 5:03 PM, Steve Fink wrote:
>>>>
>>>>> The only v8 shell I have lying around is too old (3.14.5.10) to have
>>>>> Set, so I can't tell you what it would do.
>>>>>
>>>>
>>>> I have v8 "4.8.0 (candidate)" (meaning whatever rev I checked out), and
>>>> it does 1163 minor ("Scav

Re: Is `undefined` garabage collectable?

[Andreas Rossberg]

The `undefined` value is represented in exactly the same way as `true`,
`false`, and `null` in V8. They're so called "oddballs" internally, global
values that are neither allocated nor freed.

Either way, the key/values of a (regular) map do not keep anything alive
about the map. Adding or removing entries from a set or map can of course
cause allocation/deallocation, regardless of the keys/values themselves.
(Similarly if you are using regular objects as maps, btw.)

There are also lots of other things that cause allocation/deallocation
under the hood of a JavaScript engine, e.g. compilation, optimisation,
deoptimisation, etc. Some of that predominantly happens at start-up. If you
want to reduce random noise from your experiments, try to warm up the code
first. But even then, don't read too much into micro-benchmarks -- JS VMs
are far too complicated, dynamic, and heuristics-based to draw useful
conclusions from tiny tests (that's e.g. why JSPerf tests are often
bollocks).

In general, there is very little you can do in JavaScript that does not
potentially cause allocation and thus GC. Certainly nothing involving
dynamic data structures.

/Andreas


On 5 May 2016 at 07:48, /#!/JoePea  wrote:

> > The only v8 shell I have lying around is too old (3.14.5.10) to have
> Set, so I can't tell you what it would do.
>
> On my first attempt, I noticed 8 Major GCs:
> https://cloud.githubusercontent.com/assets/297678/15036715/f41ea4d4-1247-11e6-8823-f153c3c1b7bb.png
>
> On second attempt, no Major GCs:
> https://cloud.githubusercontent.com/assets/297678/15036788/c066483a-1248-11e6-970b-3f9d20710bbc.png
>
> I wonder why. I'm in Chrome 50.
>
> So, the second attempt looks good. I'm not sure why the first is so
> different. I tried it a few times, but I only got that Major GC zig-zag the
> first time.
>
> Thanks for pointing out Set!
>
> On Wed, May 4, 2016 at 7:30 PM, Boris Zbarsky  wrote:
>
>> On 5/4/16 5:03 PM, Steve Fink wrote:
>>
>>> The only v8 shell I have lying around is too old (3.14.5.10) to have
>>> Set, so I can't tell you what it would do.
>>>
>>
>> I have v8 "4.8.0 (candidate)" (meaning whatever rev I checked out), and
>> it does 1163 minor ("Scavenge") GCs on your testcase.  It also does 1163
>> minor GCs if I take out the add() calls.  It does none if I remove the
>> clear() calls, no matter whether the add() calls are there or not.
>>
>> -Boris
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Error stack strawman

[Andreas Rossberg]

On 24 February 2016 at 02:01, John Lenz  wrote:

> To be clear I meant, the VM knows *statically* whether to write code for a
> regular call or a tail call and that it is *possible* to do something
> *clever* by inspecting and rewriting the stack.  Specifically, if you can
> inspect the stack for something that is inserted before performing the
> first tail call it is *possible* possible to distinguish.   This is both
> complicated and potentially costly and very likely not worth the effort.
>

A function can only find out whether it is performing the "first" tail call
if it can find out whether it was tail-called itself. So _every_ tail call
would have to inspect the stack to look for the special tail call frame, in
order to decide whether it should push that special frame itself. So yes,
that would make tail calls prohibitively expensive.

/Andreas


On Fri, Feb 19, 2016 at 1:53 AM, Andreas Rossberg 
> wrote:
>
>>
>>
>> On 19 February 2016 at 10:29, Andreas Rossberg 
>> wrote:
>>
>>> On 19 February 2016 at 06:29, John Lenz  wrote:
>>>
>>>> However, at the CPU level, it seems like you would be better pushing an
>>>> return address for a special function that indicated the start of a
>>>> sequence of tail calls.  That way you trade only some
>>>> complexity/performance for tail calls (an inspection of the last entry of
>>>> the call stack) and some stack frame building complexity (to recognize this
>>>> "special" frame).
>>>>
>>>
>>> There is no way of knowing, neither statically nor dynamically, that you
>>> are at "the start of a sequence of tail calls". And doing it for every tail
>>> call would of course defeat tail calls.
>>>
>>
>> Or to put that differently: if there was, then the very problem wouldn't
>> exist. ;)
>>
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Error stack strawman

[Andreas Rossberg]

On 19 February 2016 at 10:29, Andreas Rossberg  wrote:

> On 19 February 2016 at 06:29, John Lenz  wrote:
>
>> However, at the CPU level, it seems like you would be better pushing an
>> return address for a special function that indicated the start of a
>> sequence of tail calls.  That way you trade only some
>> complexity/performance for tail calls (an inspection of the last entry of
>> the call stack) and some stack frame building complexity (to recognize this
>> "special" frame).
>>
>
> There is no way of knowing, neither statically nor dynamically, that you
> are at "the start of a sequence of tail calls". And doing it for every tail
> call would of course defeat tail calls.
>

Or to put that differently: if there was, then the very problem wouldn't
exist. ;)
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Error stack strawman

[Andreas Rossberg]

On 19 February 2016 at 06:29, John Lenz  wrote:

> However, at the CPU level, it seems like you would be better pushing an
> return address for a special function that indicated the start of a
> sequence of tail calls.  That way you trade only some
> complexity/performance for tail calls (an inspection of the last entry of
> the call stack) and some stack frame building complexity (to recognize this
> "special" frame).
>

There is no way of knowing, neither statically nor dynamically, that you
are at "the start of a sequence of tail calls". And doing it for every tail
call would of course defeat tail calls.

/Andreas
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Error stack strawman

[Andreas Rossberg]

On 19 February 2016 at 03:13, Gary Guo  wrote:

> Andreas  wrote:
> > This would be fairly difficult to support by implementations. In V8, for
> example, we currently have no way of reconstructing that information, nor
> would it be easy or cheap to add that. A frame is created by the callee,
> but that does not know how it got called. Funnelling through that
> information would effectively require a hidden extra argument to _every_
> call.
>
> Placing a boolean flag theoretically should not introduce too much
> overhead.
>

Practically, though, as I said, it would require passing an extra argument
with every call, even if its information content is just a bit (or
equivalently, having two entry points to every function, which would be
"fun"). It also requires storing this bit in every stack frame, which, for
V8 at least, would require allocating an additional word in every stack
frame, because there is no other space left for it. So, it would likely be
_substantial_ overhead in calling conventions, in both time and space.



> If we are not going to indicate tail call some way, debugging might be
> extremely difficult, and the stack result might be making no sense at all.
>

A tail call is a jump. Just like other jumps, you shouldn't expect their
history to be visible in the continuation (which is what a stack trace
represents). I agree that JS programmers might be surprised, and will have
to relearn what they know. But wrt to debugging the situation is the same
as for loops: you can't inspect their history either. (And functional
programmers in fact see loops as just an ugly way to express self tail
recursion. :) )

I'd argue that the real problem is that ES6 repurposed existing return
syntax for tail calls. This would probably be much less of an issue if tail
calls were a syntactically explicit feature. I wonder if we can still fix
that...

/Andreas
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Error stack strawman

[Andreas Rossberg]

On 18 February 2016 at 02:36, Gary Guo  wrote:

> * isTail will be set when the frame indicates a frame created by tail call
> instead of normal function call. Caller's frame is already removed so we
> need some indication for that to help debugging.
>

This would be fairly difficult to support by implementations. In V8, for
example, we currently have no way of reconstructing that information, nor
would it be easy or cheap to add that. A frame is created by the callee,
but that does not know how it got called. Funnelling through that
information would effectively require a hidden extra argument to _every_
call.

/Andreas
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Garbage collection in generators

[Andreas Rossberg]

On 17 February 2016 at 09:40, Benjamin Gruenbaum 
wrote:

> If you starve a generator it's not going to get completed, just like other
>> control flow won't.
>>
>
> I'm not sure starving is what I'd use here - I definitely do see users do
> a pattern similar to:
>
> ```js
> function getResults*() {
>  try {
>  var resource = acquire();
>  for(const item of resource) yield process(item);
>  } finally {
>  release(resource);
>  }
> }
> ```
>

Yes, exactly the kind of pattern I was referring to as "bogus forms of
resource management". This is an anti-pattern in ES6. It won't work
correctly. We should never have given the illusion that it does.


garbage collection is a form of automatic resource management.


Most GC experts would strongly disagree, if by resource you mean anything
else but memory.

/Andreas
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Garbage collection in generators

[Andreas Rossberg]

On 17 February 2016 at 09:08, Benjamin Gruenbaum 
wrote:

> In the following example:
>
> ```js
>
> function* foo() {
> try {
>yield 1;
> } finally {
> cleanup();
> }
> }
> (function() {
>   var f = foo();
>   f.next();
>   // never reference f again
> })()
>
> ```
>
>  - Is the iterator created by the function `foo` ever eligible for garbage
> collection?
>

The spec does not talk about GC, but in typical implementations you should
expect yes.


>  - If it is - does it run the `finally` blocks?
>

No, definitely not. Try-finally has nothing to do with GC, it's just
control flow. If you starve a generator it's not going to get completed,
just like other control flow won't. (Which is why some of us think that
iterator `return` is a misfeature, because it pretends to provide a
guarantee that does not exist, and only encourages bogus forms of resource
management.)


Related resources:
>
>  - Python changed the behavior to "run `return` on gc" in 2.5
> https://docs.python.org/2.5/whatsnew/pep-342.html
>  - C# doesn't run finalizers, but iterators are disposable and get aborted
> automatically by foreach (for... of) - on break. this is similar to what we
> do:
> http://blogs.msdn.com/b/dancre/archive/2008/03/14/yield-and-usings-your-dispose-may-not-be-called.aspx
>  - PHP is debating this issue now, I was contacted by PHP internals people
> about it which is how I came into the problem in the first place:
> https://bugs.php.net/bug.php?id=71604
>  - Related issue I opened on async/await :
> https://github.com/tc39/ecmascript-asyncawait/issues/89
>

Even if we want to make GC observable via finalisation, then it should at
least be done in a controlled and explicit manner rather than silently
tacking it onto an unrelated feature. See the revived weakref proposal.
Python's idea is just confused and crazy.

/Andreas
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: How to modify the scope chain without `with` ?

[Andreas Rossberg]

On 15 February 2016 at 18:49, Coroutines  wrote:

> On Mon, Feb 15, 2016 at 4:48 AM, Benjamin Gruenbaum 
> wrote:
> > For what it's worth very popular templating libraries like KnockoutJS use
> > `woth` heavily.
> >
> > I think the consensus is that writing DSLs should be done as a
> > transformation into JavaScript (like JSX) and not inside JavaScript (like
> > Knockout and your library)
> >
> > The dynamic nature of `with` is why it is forbidden in strict mode, when
> > import/export land in browsers things will run in strict mode by default
> > which means `with` is gone.
>
> Aside from this, I wish JS would provide the ability to modify the
> scope chain - and it should be just objects that can inherit from one
> another through prototypes.  I think it would be too perfect/clean to
> handle scope in the existing way we handle inheritance.  My example
> isn't completely justified to say "I need this" - but I think having
> direct control over scope would be important in the future and should
> be considered for ES7.  Especially if the existing way is not portable
> anymore...
>

That would be a total and complete disaster for implementations, as it
would make scopes observable and mutable in a way that absolutely breaks
all conventional compilation and optimisation techniques for local
variables, closures, etc. JavaScript would easily become 10-100x slower.
Like when you use `with` today.

I don't think it would be a security concern either, as you could only
> make objects you have reference to your new scope.
>

It would totally break security as well, given that functions could then
peek into local variables on their call chain through __proto__. And I
cannot even fathom what it would mean to mutable some __proto__!

/Andreas
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: How to modify the scope chain without `with` ?

[Andreas Rossberg]

On 15 February 2016 at 10:13, Coroutines  wrote:

> This post might be overly wordy.  Sorry.  It relates to the
> functionality provided by the `with` keyword and why I think it's
> important in the future.
>
> I am currently rewriting a templating module that I think is very
> useful for it's ability to turn a function in coffeescript syntax into
> a sort of DSL - something that looks like this:
>
> template = ->
>   doctype 5
>   html ->
> head ->
>   title @title
> body ->
>   div id: 'content', ->
> if @posts?
>   for p in @posts
> div class: 'post', ->
>   p p.name
>   div p.comment
>   form method: 'post', ->
> ul ->
>   li -> input name: 'name'
>   li -> textarea name: 'comment'
>   li -> input type: 'submit'
>
> For those not familiar with Coffeescript, "= ->" creates a function
> with no arguments, the indented sub-block is the body of the function.
>
> All of these things essentially compile into nested functions like:
> html(head(title(this.title))
>
> (not an exact translation)
>
> Anyway, this library/module called (ck) exploits the little-used
> `with` keyword.  It creates a function like this:
>
> function (scope, template) { with (scope) { template(); } }
>
> So the template is just a series of functions that lookup within
> `scope` for a function creating HTML.  The problem is this module
> (imo) wastefully creates a lot of closures to create the HTML tags.
>
> It was my plan to create a Proxy object to use like: with (proxy) {
> ... } - so html() called within that `with` block would redirect
> through the proxy to something like: makeTag('html', children...)
>
> This does not work.  Proxies as objects provided to `with` does not
> work.  I don't know if this is intended but I'm disappointed.  `with`
> itself is a keyword discouraged from use (it seems).
>
> I am from Lua, where in Lua we have 2 variables called _ENV and _G.
> In Javascript terms _G would point to `global` in node (the main
> execution context/object).  _ENV has no direct mapping to JS - it
> would be the current context/object, which might not be _G anymore.
>
> I wish it were possible to create objects that functions could run
> within - you can seemingly only do this with the outmoded `with` or
> with the 'vm' module in Node.  People seem to discourage `with` and it
> (iirc) is ignored in strict mode - and you can't use the `vm` module
> in the browser.
>
> I think there is a need for the ability to do this in ES7, and I wish
> it were as simple as assigning an object to _ENV to change the
> environment the function dereferences/resolves through.
>
> Am I crazy or is this a good idea?  The MDN posting on the `with`
> keyword says you should just create a short reference to make use of
> things - like: ck.p("this is a paragraph"); - but then this isn't as
> natural as exploiting the context of what the function is running in
> for the above `template` function.  Again - I am NOT talking about how
> `this` is defined but the outer scope/object.  I wish scope lookup
> were as simple as following a prototype chain.  I wish I could easily
> create a scope to run in from an object.
>
> Would this be something useful - or is `with` just not in style
> anymore?  (I'm still mad I can't use a Proxy in with):
>
>   require('harmony-reflect');
>
>   let f = function() {
> cats('abc');
> dogs('123');
> thisshouldjustlog('damnit');
>   };
>
>   let tmp = new Proxy({}, {
> get: function() {
>   return console.log;
> }
>   });
>
>   // disappointment abound
>   with (tmp) { f() };


Without wanting to say much on the overall viability of your plan, but
proxies do work with `with`. However, your code has at least two bugs:

(1) It's not defining a custom `has` trap. That is needed for `with`,
otherwise it will just check the target object, which has no `f`.

(2) You cannot return `console.log` first-class and expect it to work (at
least not on all browsers). Known JavaScript issue.

This fixed version works fine on V8 4.9 / Chrome 49:

function f() { console.log("failure") }

let p = new Proxy({}, {
  has() { return true },
  get() { return x => console.log(x) }
});

with (p) { f("success") };

/Andreas
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Paren-free heads strawman

[Andreas Rossberg]

This refactoring hazard is intimately tied to the infinite look-ahead
problem. Teaching a parser to handle the latter case or examples like `if
(x) (y) -z {}` correctly is gonna be all but easy. Either backtracking or
terrifying grammar refactorings would be needed.

On 1 February 2016 at 18:46, Brendan Eich  wrote:

> On Mon, Feb 1, 2016 at 8:02 AM kdex  wrote:
>
>> [Douglas Crockford](https://www.youtube.com/watch?v=Nlqv6NtBXcA) and
>> [Brendan Eich](https://brendaneich.com/2010/11/paren-free/) seem
>>
>> to be in favor of making them optional; that's why the strawman exists.
>>
>>
> The strawman exists because I wrote it, yes.
>
> I was inspired by the common (not ubiquitous) style of always bracing
> sub-statements. The paren-free meme did "stick" with Rust, but it seems
> doomed for JS on account of the problems Waldemar Horwat raised:
>
>  https://esdiscuss.org/topic/another-paren-free-gotcha
>
> Not the cited example, that seemed to forget that paren-free requires
> braces around the sub-statement in absence of leading left paren after
> controlling keyword. I pointed this out here:
>
> https://esdiscuss.org/topic/another-paren-free-gotcha#content-9
>
> Waldemar's other example showed a refactoring hazard:
>
> """
>
> if (a + b/g > f) f = a + b/g
>
> Convert it to paren-free:
>
> if a + b/g > f {f = a + b/g}
>
> So far so good; it works. However, later someone discovers that the code
> had a logic error, the fix to which is to divide the sum a+b by c instead
> of dividing only b by c. So he fixes the code to:
>
> if (a + b)/g > f {f = (a + b)/g}
>
> """
>
> Anyway, the proposal predates 1JS (note my last message talks about "opt
> in") and needs a champion who can resolve the refactoring hazard worry (if
> possible).
>
> /be
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Paren-free heads strawman

[Andreas Rossberg]

Will

  if x (y) (z);

parse as

  if (x) ((y)(z));

or

  if (x(y)) (z);

? And how do you parse it without infinite look-ahead?

/Andreas


On 1 February 2016 at 17:01, kdex  wrote:

> Well, try and define "natural" in the context of constructed languages.
>
> If this was a question of "naturalness" (whatever that may be), then
> really any deviation from what the language currently is, is "unnatural".
>
> Anyway, we're here to discuss, not to blindly judge. :)
>
>
>
> Note that the parens serve no purpose whatsoever.
>
> They're actually just a relic dating back to Ken Thompson's
> re-interpretation of BCPL, B (1969), which in turn did this, because in
> FORTRAN,
>
> `if x` and `ifx` looked the same to the parser; the parens were thus
> needed for the parser to differentiate between the two.
>
>
>
> Since C derived from B, virtually any language that derived from it
> adapted to this redundant syntax; nowadays, the parens exist solely for
> decoration.
>
>
>
> [Douglas Crockford](https://www.youtube.com/watch?v=Nlqv6NtBXcA) and
> [Brendan Eich](https://brendaneich.com/2010/11/paren-free/) seem
>
> to be in favor of making them optional; that's why the strawman exists.
>
>
>
> On Montag, 1. Februar 2016 15:47:52 CET Alican Çubukçuoğlu wrote:
>
> > Isn't this very unnatural? If you are into this kind of thing, why don't
>
> > you code Coffee for example? (Or don't since saving a few keystrokes
> isn't
>
> > worth your dignity.)
>
> >
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Is \u006eew a valid Identifier?

[Andreas Rossberg]

Allen, what was the motivation for allowing random escapes in
identifiers but not in keywords? AFAICS, it would be simpler and more
consistent to allow them anywhere and render "escape normalisation" a
uniform prepass before tokenisation. IIUC, that's what other languages
do. The current ES rules are far from ideal, and require jumping
through extra hoops, in particular, to handle context-dependent
keywords like `yield`.

/Andreas


On 7 November 2015 at 20:34, Eric Suen  wrote:
> Like Caitlin said, logically
>
> Escaped ReservedWords is IdentifierName
> Escaped ReservedWords is not ReservedWord
> Identifier is IdentifierName but not ReservedWord
> Escaped ReservedWords is not Identifier?
>
> I'm writing javascript parser myself, those inconsistency really confuse me...
>
> On Sun, Nov 8, 2015 at 2:07 AM, Allen Wirfs-Brock  
> wrote:
>>
>>> On Nov 7, 2015, at 9:58 AM, Eric Suen  wrote:
>>>
>>> I see, I thought you were refer 'get'/'set'. Indeed escaped
>>> ReservedWords should be ReservedWords.
>>>
>>> Class a = \u006eew Class()
>>>
>>> is valid in Java and C#.
>>
>> But not in ECMAScript 2015.  JavaScript is neither Java or C#
>>
>>
>>
>
>
>
> --
> 
> Spket IDE - Development Tool for RIA.
>
> http://www.spket.com
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Status of Chrome Proxy in face of Object.observe removal

[Andreas Rossberg]

On 6 November 2015 at 19:16, Simon Blackwell
 wrote:
> In the face of the announcment that the  Object.observe standard proposal is
> being revoked and commentary that seems to indicate that at a minimum either
> Proxy or Object.observe is needed, does anyone know the status of
> re-introduction of Proxy into Chrome and v8?

We currently have like half a dozen people working on bringing proxies
to V8. It's a lot of work that leaves almost no stone unturned. But we
hope to be able to ship them early next year. Removing O.o will
actually help.

/Andreas
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: An update on Object.observe

[Andreas Rossberg]

On 3 November 2015 at 14:58, David Bruant  wrote:
> Le 03/11/2015 12:26, Alexander Jones a écrit :
>>
>> In my opinion, the fundamental record type we build our JS on should be
>> getting dumber, not smarter. It feels inappropriate to be piling more
>> difficult-to-reason-about mechanismson top before reeling in exotic host
>> objects.

JS objects have never been simple. Since at least ES5, which
officially added accessors, attribute reflection, and irregular
inheritance rules, the last illusion of simplicity has been eternally
lost. But before that there already were various quirks and hidden
complexities.

>> With Proxy out of the bag, I'm not so hopeful for the humble Object
>> anymore.
>
> This is a surprising statement. By exposing the low-level object API as
> userlang API (proxy traps + Reflect API), proxies make the low-level object
> API subject to the same backward-compat constraints as every other API.
> If nothing else, the very existence of proxies puts an end to the evolution
> of the object model.

There is no end to evolution. The object model will grow more
features, like private properties, which are orthogonal to proxies.

/Andreas
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Decorators for functions

[Andreas Rossberg]

On 22 October 2015 at 19:25, Jordan Harband  wrote:
> Andreas, thanks for correcting me on the optimization angle. I've been under
> that impression for awhile.
>
> Are you saying that to achieve the optimization I envision, we'd need
> declarative syntax for descriptor properties (like enumerability etc),
> rather than function calls?

Yes, there would need to be a sufficient degree of phase separation,
such that these annotations can be reliably gathered and inspected at
compile time, and are known to be invariant at runtime.

/Andreas


> On Thu, Oct 22, 2015 at 9:20 AM, Jonathan Bond-Caron
>  wrote:
>>
>> On Thu Oct 22 07:44 AM, Andreas Rossberg wrote:
>> > > determined at creation time, allowing for massive engine optimization,
>> >
>>
>> Ya I'm not sure from which hat "massive engine optimization" comes from?
>>
>> What's meant is likely using decorators as annotations (compile time
>> optimizations hints):
>> http://www.google.com/patents/US7013458
>>
>> Or 'ambient decorators':
>>
>> https://github.com/jonathandturner/brainstorming/blob/master/README.md#c6-ambient-decorators
>>
>> There's 2 patterns (maybe more?):
>> (a) Tagging a 'tree transformation'  on a node.
>> (b) Metadata at compile time on a node.
>>
>> The thing about (b) is it can easily live outside of the code (like in
>> typescript where you have an optional header/declaration file)
>>
>> With (a), it seems more conservative to see how it gets used with classes
>> before bolting on to functions (opinion: end result in java is not something
>> to be proud of).
>>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Decorators for functions

[Andreas Rossberg]

On 22 October 2015 at 18:20, Jonathan Bond-Caron
 wrote:
> On Thu Oct 22 07:44 AM, Andreas Rossberg wrote:
>> > determined at creation time, allowing for massive engine optimization,
>
> Ya I'm not sure from which hat "massive engine optimization" comes from?
>
> What's meant is likely using decorators as annotations (compile time 
> optimizations hints):
> http://www.google.com/patents/US7013458

Note that this patent indeed defines _declarative_ metadata
annotations. That's the exact opposite of the imperative decorator
proposal we are discussing right now, which completely conflates
computation level and meta level and thus is pretty much unusable for
compile-time hints.

/Andreas


> Or 'ambient decorators':
> https://github.com/jonathandturner/brainstorming/blob/master/README.md#c6-ambient-decorators
>
> There's 2 patterns (maybe more?):
> (a) Tagging a 'tree transformation'  on a node.
> (b) Metadata at compile time on a node.
>
> The thing about (b) is it can easily live outside of the code (like in 
> typescript where you have an optional header/declaration file)
>
> With (a), it seems more conservative to see how it gets used with classes 
> before bolting on to functions (opinion: end result in java is not something 
> to be proud of).
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Decorators for functions

[Andreas Rossberg]

On 22 October 2015 at 06:34, Jordan Harband  wrote:
> One thing that seems to be missing from this thread is acknowledgement that
> decorators are not just simple function wrappers. They take a property
> descriptor as an argument, and they can return a new property descriptor -
> which allows an object or "class" to have its shape determined at creation
> time, allowing for massive engine optimization,

Er. I don't know where this myth is coming from, but let me debunk it
right there:

Decorators do not enable optimisations. If anything, they _prevent_
optimisations.

What enables optimisations is a more declarative semantics with more
invariants, less mutation, less reflection, and less intercession.
That was one significant advantage of class syntax over previous
imperative JS patterns.

Decorators pretty much revert that (hard-fought) progress, because
despite their looks, they are all but declarative, and just as
imperative as the old-style patterns. Or function wrappers. A class
that uses decorators will very likely have to go through all the same
(or even worse) runtime overhead.

/Andreas
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Destructuring: Add early errors for empty patterns?

[Andreas Rossberg]

On 21 October 2015 at 20:19, Standards Zakas
 wrote:
> In playing with destructuring, it seems like there are some syntax gotchas
> that really should trigger some sort of error and instead fail silently. For
> instance:
>
> ```
> let {} = foo;
> ```
>
> This line does absolutely nothing

Not true. It checks that foo converts to an object, which may throw a
type error for null or undefined.

/Andreas
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Decorators for functions

[Andreas Rossberg]

Drive-by-comment:

On 20 October 2015 at 14:40, Bob Myers  wrote:
> AFAICS, hoisting is not an issue if the decorator has no side effects.

Not so. Initialisation order is another issue. Consider:

  var x = 0
  @bla(x) function f() {}

Also, as a side note, pretty much *everything* in JavaScript
potentially has side effects.

/Andreas
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Swift style syntax

[Andreas Rossberg]

All this is well-known from functional languages, with well-known
solutions. The only real problem is:

let f = (-)

Is this unary or binary `-`?

On 13 October 2015 at 08:06, Isiah Meadows  wrote:
> +1 for operators as functions (I frequently is them in languages that have
> them), but there is an ambiguous case that frequently gets me: does `(-)`
> represent subtraction or negation. It's usually the former in languages with
> operators as functions.
>
> But here's a couple other potential syntactical ambiguities, dealing with
> ASI:
>
> ```js
> // Is this `x => f(x)` or `x = (>); f(x)`
> x =>
> f(x)
>
> // Is this `-x` or `-; x`?
> -
> x
> ```
>
> Those can be addressed with a cover production to be used for expression
> statements and direct value assignment, requiring parentheses to clarify the
> latter case in each.
>
> A similar ambiguity problem, arguably harder to resolve, is partially
> applied subtraction, such as `(- 2)`. Is that a -2 or is it equivalent to `x
> => x - 2`? I will caution on this idea, as I know that's the next logical
> step.
>
>
> On Mon, Oct 12, 2015, 06:43 Thomas  wrote:
>>
>>
>> Is it possible to extend JavaScript syntax to support Swift style block
>> syntax[1]?
>>
>> In Swift it's possible to omit return keyword
>> ```
>>
>> reversed = names.sort( { s1, s2 in s1 > s2 } )
>>
>> ```
>>
>>
>> As you note below this is already possible in es6, and might I add, has
>> much more intuitive syntax in Es6. The swift syntax looks like a list
>> comprehension gone wrong.
>>
>> or omit argument declaration like this:
>>
>> ```
>>
>> reversed = names.sort( { $0 > $1 } )
>>
>> ```
>>
>>
>> I for one think this is a bad idea - use rest arguments instead. It's
>> pretty terrible as far as readability goes, although I'd like to see more
>> examples of it being used in Swift code.
>>
>> or apply an operator to arguments of a function
>>
>> ```
>>
>> reversed = names.sort(>)
>>
>> ```
>>
>>
>> This might actually be possible - I can't think of any ambiguous
>> situations for passing operators as if they were first class functions. If
>> it is possible, I'd like to see this done.
>>
>> We have the first feature in ES2015 already:
>>
>> ```
>> let sorted = names.sort((a, b)=> a > b);
>> ```
>>
>> But for omitting argument declaration we need to find an alternative to
>> $0, $1... since those are valid variable names in JS. Maybe we can use #0,
>> #1... instead.
>>
>> This is very useful for functional programming aspect of JS. For example
>> in a filter function:
>>
>> ```
>> let passed = objs.filter(#0.passed)
>> ```
>>
>>
>> [1][https://developer.apple.com/library/ios/documentation/Swift/Conceptual/Swift_Programming_Language/Closures.html]
>>
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Exponentiation operator precedence

[Andreas Rossberg]

On 24 September 2015 at 17:19, Brendan Eich  wrote:

> Even nicer:
>
> http://jsbin.com/baquqokujo
>
> I hate email.


You are holding it wrong.

/Andreas
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Global lexical tier

[Andreas Rossberg]

On 3 September 2015 at 20:57, Brendan Eich  wrote:

> Andreas Rossberg wrote:
>
>> On 3 September 2015 at 03:50, Brendan Eich > bren...@mozilla.org>> wrote:
>>
>> I don't remember you overcoming the counterarguments about async
>> scripts and event handlers in async-generated/written markup
>> twisting the nested scopes unexpectedly.
>>
>>
>> The only cases where the scope order would make an observable difference
>> are ones that produce conflicts right now. So you'd only allow a few more
>> programs -- somewhat ill-behaved (non-deterministic) ones, but no more
>> ill-behaved than those that you can write with `var` today (or could with
>> `let` if it was a property on the global object! -- non-deterministic
>> shadowing  is still a less drastic effect than non-deterministic
>> overwriting).
>>
>
> The problem is the cognitive model and load. Nothing helps
> non-deterministic loading of scripts with global effects, but making every.
> last. script! nest a fresh lexical scope means "now you have two problems".
>

What I mean is that in a model with mutable scope (or worse, the global
object) _declarations_ themselves become global effects. Later conflicts
can affect all code that has been loaded _before_, e.g. by smashing over an
existing binding.

/Andreas
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Global lexical tier

[Andreas Rossberg]

On 3 September 2015 at 03:50, Brendan Eich  wrote:

> Andreas Rossberg wrote:
>
>> On 3 September 2015 at 01:58, Brendan Eich > bren...@mozilla.org>> wrote:
>>
>> I was there, I just re-read and re-remembered. I do not agree with
>> Allen that some tiny needle was uniquely threaded. Rather, an
>> aesthetic preference for the new ES6 binding forms to have a
>> lexical contour of their own when used at top level prevailed.
>> This leads to problems, not all of which were known at the time --
>> but some problems were noted.
>>
>> The REPL problem, where let z=z; makes a poison pill, could be
>> coped with by ad-hoc REPL deviations from the spec -- at some
>> cost. Let's set it aside.
>>
>> The one-time change to a reference, from global object to lexical
>> shadowing binding, is a serious flaw. Yes, it could happen due to
>> explicit scope nesting, but the global scope is apparently
>> uniform. There's no explicit delimiter.
>>
>>
>> I still maintain that a tower-of-nested-scopes model would have been
>> cleaner AND would have avoided both the shadowing issue and the REPL
>> restriction. A mutable scope that gets extended under your feet is
>> terrible, lexical or not.
>>
>
> I don't remember you overcoming the counterarguments about async scripts
> and event handlers in async-generated/written markup twisting the nested
> scopes unexpectedly.


The only cases where the scope order would make an observable difference
are ones that produce conflicts right now. So you'd only allow a few more
programs -- somewhat ill-behaved (non-deterministic) ones, but no more
ill-behaved than those that you can write with `var` today (or could with
`let` if it was a property on the global object! -- non-deterministic
shadowing  is still a less drastic effect than non-deterministic
overwriting).

So from my perspective, there is nothing to overcome, at least not relative
to other alternatives. :)  In particular, this one:

Or unless one makes toplevel binding semantics completely different (and
>> insane), which I also hope nobody wants (though I'm not so sure).
>>
>
> Something has to give. This seems least bad.


I disagree. In particular, since this solution is even less well-behaved,
see above.


The main thing holding back sloppy let in V8 right now is the parsing
>> nonsense and extra look-ahead required, which turns out to be a major pain
>> for us (and FWIW, slows down the V8 parser by a couple of percent with
>> little hope for recovery :( ).
>>
>
> I thought we resolved this (non-simple parameter list in function makes
> "use strict"; directive prologue an early error). What's left?


It's unrelated. The grammar is LL(2) regarding sloppy `let`, so the scanner
needs the ability to do one extra token of look-ahead to let the
recursive-decent parser deal with it (unless, perhaps, you completely
transform all the grammar; not sure if that would be possible). Enabling
that creates a slight performance bottleneck. Plus, look-ahead in a JS
scanner is very brittle, given the lexical ambiguities and context
dependencies around regexps.

/Andreas
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Global lexical tier

[Andreas Rossberg]

On 3 September 2015 at 01:58, Brendan Eich  wrote:

> I was there, I just re-read and re-remembered. I do not agree with Allen
> that some tiny needle was uniquely threaded. Rather, an aesthetic
> preference for the new ES6 binding forms to have a lexical contour of their
> own when used at top level prevailed. This leads to problems, not all of
> which were known at the time -- but some problems were noted.
>
> The REPL problem, where let z=z; makes a poison pill, could be coped with
> by ad-hoc REPL deviations from the spec -- at some cost. Let's set it aside.
>
> The one-time change to a reference, from global object to lexical
> shadowing binding, is a serious flaw. Yes, it could happen due to explicit
> scope nesting, but the global scope is apparently uniform. There's no
> explicit delimiter.
>

I still maintain that a tower-of-nested-scopes model would have been
cleaner AND would have avoided both the shadowing issue and the REPL
restriction. A mutable scope that gets extended under your feet is
terrible, lexical or not.

I also maintain that putting lexical bindings onto the global object is not
an option. It is incompatible with having a TDZ, unless one wants to
introduce TDZs for properties into the object model, which I doubt anybody
wants. Or unless one makes toplevel binding semantics completely different
(and insane), which I also hope nobody wants (though I'm not so sure).


The implementors seem to be rebelling but I'm not trying to stir up
> trouble. It would help if V8 did support let, etc. in sloppy mode. Then we
> might see open rebellion among two or more implementors.
>

AFAICS this issue is completely orthogonal to sloppy-vs-script, and there
are no new effects specific to sloppy mode. V8 already fully implements the
necessary semantics. It wasn't pretty, but there are uglier things in ES6.

The main thing holding back sloppy let in V8 right now is the parsing
nonsense and extra look-ahead required, which turns out to be a major pain
for us (and FWIW, slows down the V8 parser by a couple of percent with
little hope for recovery :( ).

/Andreas
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Re: Existential Operator / Null Propagation Operator

[Andreas Rossberg]

On 19 August 2015 at 16:21, Tingan Ho  wrote:

> Strange why do they need an operator for that? Probably to make it less
> error prone with access nil errors. But that could be fixed with static
> code analysis.
>

OT but: The whole point of optional values (as opposed to
null/nil/undefined inhabiting everything) is to make the boundaries of
optionality explicit, thereby avoiding Hoare's billion dollar mistake.

That said, "convenient" operators like ! already destroy half the benefit.
Plenty of experience from other languages like ML or Haskell shows that
they are almost always used incorrectly (read: over-optimistically). If a
language has to have such an operator, it should at least be very explicit
and as inconvenient as bearable.

/Andreas


On Wed, Aug 19, 2015 at 10:09 PM, Kevin Smith  wrote:
>
>>
>> In TypeScript `?` means optional. But throw if the value is nil is the
>>> same same as non-nullable?
>>>
>>
>> In Swift, the postfix "!" operator unwraps an optional value, throwing if
>> nil.
>>
>> See
>> https://developer.apple.com/library/ios/documentation/Swift/Conceptual/Swift_Programming_Language/OptionalChaining.html
>>
>>
>
>
> --
> Sincerely,
>
> Tingan Ho
> @tingan87 
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Extensible destructuring proposal

[Andreas Rossberg]

On 5 August 2015 at 09:27, Isiah Meadows  wrote:

> Damnit...forgot to fix the subject.
>
> On Wed, Aug 5, 2015 at 3:20 AM, Isiah Meadows  wrote:
>
>> Wait...this got me thinking... The proposal itself doesn't bring along a
>> lot of merits, but it seems like it could be a great stepping stone to a
>> limited pattern matching syntax. This would probably be a little more
>> justifiable IMHO than merely a custom destructuring syntax. Maybe something
>> like this:
>>
>
I intentionally did not bring up pattern matching. That indeed is what
views are usually wanted for. But then you need to be much more careful in
designing a mechanism that avoids re-transforming the scrutinee for every
tested case! Because that would be very costly. For that reason, I fear
that the feature as proposed would interact badly with any future pattern
matching mechanism, in the sense that it would encourage very costly usage
that cannot be optimised.

/Andreas



>
>> ```js
>> Type[Symbol.pattern] = (obj) => {
>>   return [obj.a, obj.b];
>> }
>>
>> const Other = {
>>   [Symbol.pattern]: obj => obj,
>> }
>>
>> class None {
>>   static [Symbol.pattern](obj) {
>> return obj
>>   }
>> }
>>
>> // Pattern matching, signaled by `in` here
>> switch (object) in {
>>   case Type([a, b]): return a + b
>>   case Other({a, b}): return a * b
>>   case None: return undefined // Special case, no identifier initialized
>> }
>>
>> // Extensible destructuring, easy to implement with the pattern
>> // matching
>> let Type([a, b]) = object
>> let Other({a, b}) = object
>> ```
>>
>> In the destructuring phase for both, I was thinking about the following
>> semantics to assert the type, based on `typeof` and the prototype. This
>> will help engines in optimizing this as well as some type safety for all of
>> us.
>>
>> ```js
>> function _checkProto(object, Type) {
>>   // Note: Type[Symbol.pattern] must be callable
>>   if (typeof Type[Symbol.pattern] !== 'function') throw new TypeError()
>>   if (typeof Type === 'function') {
>> if (type === Array) {
>>   return Array.isArray(object)
>> } else {
>>   return object instanceof Type
>> }
>>   } else {
>> return Object.prototype.isPrototypeOf.call(Type, object)
>>   }
>> }
>>
>> function isInstance(object, Type) {
>>   switch (typeof object) {
>> case 'object': return obj != null && _checkProto(object, Type)
>> case 'function': return Type === Function
>> case 'boolean': return Type === Boolean
>> case 'number': return Type === Number
>> case 'string': return Type === String
>> case 'symbol': return Type === Symbol
>> case 'undefined': return false
>>   }
>> }
>> ```
>>
>> Finally, get the result and do a basic variable pattern assignment, LHS
>> being the operand, and RHS calling `Type[Symbol.pattern]`.
>>
>> The `switch` statement example would (roughly) desugar to the following:
>>
>> ```js
>> switch (true) {
>>   case isInstance(object, Type):
>> let [a, b] = Type[Symbol.pattern](object)
>> return a + b
>>
>>   case isInstance(object, Other):
>> let {a, b} = Other[Symbol.pattern](object)
>> return a * b
>>
>>   case isInstance(object, None):
>> return undefined
>> }
>> ```
>>
>> The destructuring examples would (roughly) desugar to this:
>>
>> ```js
>> if (!isInstance(object, Type)) throw new TypeError()
>> let [a, b] = Type[Symbol.pattern](object)
>> if (!isInstance(object, Other)) throw new TypeError()
>> let {a, b} = Other[Symbol.pattern](object)
>> ```
>>
>> The type assertions will help engines in optimizing this, and it'll also
>> make this safer. It also just makes sense for pattern matching.
>>
>> As a side effect, you can get the value without destructuring (i.e. the
>> literal result of `Symbol.pattern`) via this:
>>
>> ```js
>> let Map(m) = someMap
>> let m = Map[Symbol.pattern](someMap)
>> ```
>>
>> I, myself, came up with a Scala-inspired case class concept
>> <https://gist.github.com/impinball/add0b0645ce74214f5aa> based on this,
>> and used it to make try-catch handling a little more Promise-like, which I
>> know quite a few TypeScript users would eat up in a hurry
>> <https://github.com/Microsoft/TypeScri

Re: Extensible destructuring proposal

[Andreas Rossberg]

On 31 July 2015 at 20:09, Samuel Hapák  wrote:

> So, do you still have objections against this proposal? Could we summarize
> them?
>
> @Andreas, do you still think that there is category error involved?
>

If you want to overload existing object pattern syntax, then yes,
definitely. I strongly disagree with that. It breaks regularity and
substitutability (you cannot pass a map to where a generic object is
expected).

As for a more Scala-like variant with distinguished syntax, I'm fine with
that semantically. But I still don't buy the specific motivation with maps.
Can you give a practical example where you'd want to create a map
(immutable or not) for something that is just a record of statically known
shape? And explain _why_ you need to do that? Surely it can't be
immutability, since objects can be frozen, too.

To be clear, I wouldn't reject such a feature outright. In fact, in a
language with abstract data types, "views", as they are sometimes called in
literature, can be valuable. But they are also notorious for a high
complexity cost vs minor convenience they typically provide. In particular,
it is no longer to write

  let {a: x, b: y} = unMap(map)

as you can today, then it would be to move the transformation to the
pattern:

  let Map({a: x, b: y}) = map

So I encourage you to come up with more convincing examples in the
JavaScript context. Short of that, I'd argue that the complexity is not
justified, at least for the time being.

/Andreas
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: await on synchronous functions

[Andreas Rossberg]

On 17 July 2015 at 23:39, Mark S. Miller  wrote:

> On Fri, Jul 17, 2015 at 10:41 AM, Andrea Giammarchi <
> andrea.giammar...@gmail.com> wrote:
>
>> If I might, if there's one thing that has never particularly shone in JS,
>> that is consistency.
>>
>> I see only two possibilities here: 1) it throws with non Promises 2) it
>> "Promisify" anything that's not a Promise as if it was a
>> `Promise.resolve(1)` ... but since there's too much magic in the second
>> point, I'd rather stick with the first one.
>>
>
> Definitely #2. Had #1 been proposed, async/await never would have achieved
> consensus.
>

Wait, what?? Oh no, please don't bake that sloppy craze deeper into the
language! Implicit conversions are Not Good.

/Andreas
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Extensible destructuring proposal

[Andreas Rossberg]

I think the example actually reveals a deeper issue with the motivation:
the desire to destructure maps like here is rooted in a category error.
Destructuring is designed to apply to objects from the program domain,
while maps are typically meant to encode data from the problem domain.

Or, in other words: destructuring is only useful when you know the keys at
programming time (i.e., statically). But if that is the case, there is
rarely a good reason to use a map.

/Andreas


On 21 July 2015 at 18:12, Domenic Denicola  wrote:

>  Well,  the spec says they are ordered, so I'm not sure where you're
> getting that from.
>
>
>  *From:* Bergi 
> *Sent:* Jul 21, 2015 8:53 AM
> *To:* Domenic Denicola; es-discuss
> *Subject:* Re: Extensible destructuring proposal
>
>  Domenic Denicola schrieb:
> > For maps you can just do
> >
> > ```js
> > const [[k1, v1], [k2, v2], ...rest] = map.entries();
> > ```
>
> The problem with this is that you would need to know the order of the
> keys in the map. Your code does only extract the "first" and "second"
> key-value pairs, allowing us to get the key values of them, but this
> syntax does not allow us to extract the value for a given key from
> somewhere in the map.
> Predictability is all fine, but I still consider maps to be inherently
> unordered.
>
>   Bergi
>
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Extensible destructuring proposal

[Andreas Rossberg]

On 21 July 2015 at 08:14, Samuel Hapák  wrote:

> I have written proposal to allow extend standard behavior of object
> destructuring:
>
> https://github.com/vacuumlabs/es-proposals/blob/master/extensible-destructuring.md
>
> Main idea is, that currently object destructuring is useless for people
> who use Map or Immutable.Map (https://facebook.github.io/immutable-js/)
> as their main data structure.
>
> This would allow authors of libraries to create map like structures that
> would support destructuring. It extends the language in a similar way
> iterator does.
>
> The main idea is, that if object defines `Symbol.get` method, it gets used
> to access properties of object instead of `[]` when destructuring.
>
> What do you think?
>

People reading code will (rightfully) expect destructuring to be syntactic
sugar for property access. I don't think it's worth breaking that
equivalence. If you want user-defined patterns then they should be
syntactically distinct from existing forms.

Also, destructuring patterns are meant to match, and be the logical inverse
of, literal syntax. Consequently, from my perspective at least, extensible
destructuring would require first introducing extensible literal syntax in
a symmetric manner. I think it would be unnecessarily surprising if for
random patterns they didn't match up (worse, if you cannot even tell the
meaning syntactically, but it depends on whatever object you happen to get).

/Andreas
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Generalize do-expressions to statements in general?

[Andreas Rossberg]

On 16 July 2015 at 17:29, Mark S. Miller  wrote:

> When simply generating simple JS code from something else, this
> restriction is a perpetual but minor annoyance.
>

Indeed, one motivation for do-expressions is better support for compilers
targeting JS. And for some of those, not being able to mix statements and
expressions, not having try inside expressions, and not having support for
nested bindings, can be very tough, because it prevents compositional
translation.


By itself, I would agree that this annoyance is not important enough to add
> a new feature. However, if rather than "adding a feature", we can explain
> the change as "removing a restriction", then JS would get both simpler and
> more powerful at the same time. Ideally, the test would be whether, when
> explaining the less restrictive JS to a new programmer not familiar with
> statement languages, this change results in one less thing to explain
> rather than one more.
>

I doubt that will work, because there still will be plenty of artefacts and
irregularities of a statement language that they will have to understand.
Pretending it's an expression language will rather cause more confusion
than less, because it isn't (for one, you can't get rid of the 'return'
statement).

/Andreas
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Generalize do-expressions to statements in general?

[Andreas Rossberg]

On 16 July 2015 at 15:21, Bob Myers  wrote:

> With all "do" respect, none of this syntax tinkering makes any sense to me.
>
> I've been programming JS for 15 years and never noticed I needed a try
> block that returns a value.
>
> Long ago I programmed in a language called AED that had valued blockl,
> which I was quite fond of, but never felt the need for that in JS for
> whatever reason.
>

I've been programming in C++ for 25 years, and didn't have much need for a
try expression or nested binding either.

I've also been programming in functional languages for 20 years, and need
them on a regular basis.

It all depends on how high-level your programming style is. Also, Sapir
Whorf applies as usual.

/Andreas
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Generalize do-expressions to statements in general?

[Andreas Rossberg]

On 14 July 2015 at 16:48, Mark S. Miller  wrote:

> On Tue, Jul 14, 2015 at 2:31 AM, Andreas Rossberg 
> wrote:
>
>> I don't see why you need parens at all, see my previous post. But I
>> wouldn't make the do-less forms the base syntax,; rather, only short-hands
>> for the general thing. In particular, because the ability to have an actual
>> block inside an expression is one primary motivation for having
>> do-expressions in the first place.
>>
>
> Ah. Take a look at my full proposal. The bizarre observation is that
> extending the syntax of parens to contain approx a block-body, and
> extending its meaning to creating a block-like scope for evaluating that
> block-body, in addition to returning a value. In that case, we simply don't
> need the "do" expression at all. Don't propose something unnecessarily
> complex just because you expect that something simpler would be too
> controversial. If it actually is too controversial, that's another matter.
>

I would very much dislike introducing a second syntax for blocks, though --
which is essentially what you are suggesting. Especially when curly braces
provide a much better visual clue for the extent of a scope than innocent
plain parens do. It's the natural expectation for a C-like language, too.

In the design of any modern language the whole notion of block of course is
totally obsolete. But JavaScript has its C heritage, and I doubt bolting on
something alien would make it a prettier language.

...Ah, it's 2015, and we still have to come up with ways to overcome the
>> archaic statement/expression distinction from the stone ages. :)
>>
>
> Between Gedanken, Smalltalk, and Actors, almost everything we do in oo
> dynamic language design was already conceived right by the early '70s.
> Retrofitting without breaking things takes much longer than invention ;)
>

Well, statements vs expressions was already found unnecessary before OO, in
the early 60s -- consider Algol 68. (Let alone Lisp, which is late 50s.)

/Andreas


On 14 July 2015 at 01:33, Mark S. Miller  wrote:
>>
>>> Interesting. Got me thinking. Here's an alternate proposal I'll call "do
>>> expressions without the 'do'."
>>>
>>> At <
>>> https://people.mozilla.org/~jorendorff/es6-draft.html#sec-expression-statement>
>>> we have the syntax of the expression statement. Ignoring sloppy "let"
>>> nonsense, this says that an expression statement cannot begin with "{",
>>> "function", or "class".
>>>
>>> At <
>>> https://people.mozilla.org/~jorendorff/es6-draft.html#sec-ecmascript-language-statements-and-declarations>
>>> are the legal ES6 statements. Note that most of these begin with a keyword
>>> that cannot possibly be legal at the beginning of an expression. Therefore,
>>> adding all these initial-statement-keywords to the list of things that
>>> cannot begin an expression statement would break nothing. They already
>>> cannot begin an expression statement.
>>>
>>> With the expression statement prohibition in place, now we can allow all
>>> these forms to be expressions. As with "{", "function", or "class", if you
>>> want to state such an expression in expression-statement position, surround
>>> it with parens.
>>>
>>> Because all these new forms will look bizarre and confusing, at least at
>>> first, let's say these always need surrounding parens to be expressions. I
>>> think that would help minimize confusion.
>>>
>>> If we do this, the oddest duck is "{", since it begins an object literal
>>> expression. This proposal gives us no straightforward way to express an
>>> block expression. "function" and "class" are less odd, since their existing
>>> expression forms mean what you almost might expect by this new rule -- even
>>> though they are initial-declaration-keywords rather than
>>> initial-statement-keywords.
>>>
>>> The remaining initial-declaration-keywords are "let" and "const". We
>>> already made "let" insane regarding these issues in sloppy mode, so I'm
>>> going to ignore that. But let's consider "const" and strict "let". These
>>> already cannot appear at the beginning of an expression, so it would not
>>> break anything to add them to the prohibition list for the beginning of
>>> expression statements.
>>>
>>> No current expression can add any binding to the s

Re: for statement with index and value

[Andreas Rossberg]

On 14 July 2015 at 15:41, Jonathan Bond-Caron 
wrote:

> On Tue Jul 14 09:27 AM, Domenic Denicola wrote:
> > From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of
> > Matthew
> > Robb
> >
> > > Why not use the new meta syntax?
> >
> > If I thought this was a real problem that
> > needed solving,
>
> Disagree
>
> "As early as the mid-1980’s, it was observed that programming
> language research and funding emphasized technical aspects of the
> domain and neglected psychological aspects:"
>
> " The human and computer parts of programming languages have developed in
> radical asymmetry"
>
> http://repository.cmu.edu/cgi/viewcontent.cgi?article=1805&context=isr
>
> Bias of Engineering problems > Psychology
>

You might want to catch up on the recent discussion we just had here:

https://mail.mozilla.org/pipermail/es-discuss/2015-June/043307.html

Complexity is very much a "psychological" aspect. And random special cases,
syntactic additions, and irregularities eat into the complexity budget
quickly.

/Andreas
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Generalize do-expressions to statements in general?

[Andreas Rossberg]

On 14 July 2015 at 15:04, Matthew Robb  wrote:

> The only gripes I have with do expressions is the inability to specify the
> value produced in an obvious and uniform way,
>

Well, the completion value is fairly uniform. You mean an analogue to a
return in a function body?


> also are do expressions capable of being labelled?
>

No, but they can of course contain a labelled statement, which is
equivalently expressive.

/Andreas


On Tue, Jul 14, 2015 at 3:31 AM, Andreas Rossberg 
> wrote:
>
>> I don't see why you need parens at all, see my previous post. But I
>> wouldn't make the do-less forms the base syntax,; rather, only short-hands
>> for the general thing. In particular, because the ability to have an actual
>> block inside an expression is one primary motivation for having
>> do-expressions in the first place.
>>
>> ...Ah, it's 2015, and we still have to come up with ways to overcome the
>> archaic statement/expression distinction from the stone ages. :)
>>
>> /Andreas
>>
>>
>> On 14 July 2015 at 01:33, Mark S. Miller  wrote:
>>
>>> Interesting. Got me thinking. Here's an alternate proposal I'll call "do
>>> expressions without the 'do'."
>>>
>>> At <
>>> https://people.mozilla.org/~jorendorff/es6-draft.html#sec-expression-statement>
>>> we have the syntax of the expression statement. Ignoring sloppy "let"
>>> nonsense, this says that an expression statement cannot begin with "{",
>>> "function", or "class".
>>>
>>> At <
>>> https://people.mozilla.org/~jorendorff/es6-draft.html#sec-ecmascript-language-statements-and-declarations>
>>> are the legal ES6 statements. Note that most of these begin with a keyword
>>> that cannot possibly be legal at the beginning of an expression. Therefore,
>>> adding all these initial-statement-keywords to the list of things that
>>> cannot begin an expression statement would break nothing. They already
>>> cannot begin an expression statement.
>>>
>>> With the expression statement prohibition in place, now we can allow all
>>> these forms to be expressions. As with "{", "function", or "class", if you
>>> want to state such an expression in expression-statement position, surround
>>> it with parens.
>>>
>>> Because all these new forms will look bizarre and confusing, at least at
>>> first, let's say these always need surrounding parens to be expressions. I
>>> think that would help minimize confusion.
>>>
>>> If we do this, the oddest duck is "{", since it begins an object literal
>>> expression. This proposal gives us no straightforward way to express an
>>> block expression. "function" and "class" are less odd, since their existing
>>> expression forms mean what you almost might expect by this new rule -- even
>>> though they are initial-declaration-keywords rather than
>>> initial-statement-keywords.
>>>
>>> The remaining initial-declaration-keywords are "let" and "const". We
>>> already made "let" insane regarding these issues in sloppy mode, so I'm
>>> going to ignore that. But let's consider "const" and strict "let". These
>>> already cannot appear at the beginning of an expression, so it would not
>>> break anything to add them to the prohibition list for the beginning of
>>> expression statements.
>>>
>>> No current expression can add any binding to the scope in which the
>>> expression appears. Let's examine the consequences of having parens --
>>> rather than containing a "{"-block to create a nested scope with a value
>>> (which would conflict with object literals), instead simply define a
>>> block-like nested scope with a value. This would allow declarations and
>>> statements within the parens, much like the current "do" proposal. It would
>>> even be consistent enough with the existing semantics of paren-surrounded
>>> function and class expressions: Someone who sees these as a function or
>>> class declaration within its own nested scope, whose value was the value
>>> being declared, would rarely be surprised by the subtle difference between
>>> that story and the current semantics.
>>>
>>> Having parens accept a list of declarations and statements rather than
>>> just an expressions seems like a radical change that must brea

Re: Generalize do-expressions to statements in general?

[Andreas Rossberg]

I don't see why you need parens at all, see my previous post. But I
wouldn't make the do-less forms the base syntax,; rather, only short-hands
for the general thing. In particular, because the ability to have an actual
block inside an expression is one primary motivation for having
do-expressions in the first place.

...Ah, it's 2015, and we still have to come up with ways to overcome the
archaic statement/expression distinction from the stone ages. :)

/Andreas


On 14 July 2015 at 01:33, Mark S. Miller  wrote:

> Interesting. Got me thinking. Here's an alternate proposal I'll call "do
> expressions without the 'do'."
>
> At <
> https://people.mozilla.org/~jorendorff/es6-draft.html#sec-expression-statement>
> we have the syntax of the expression statement. Ignoring sloppy "let"
> nonsense, this says that an expression statement cannot begin with "{",
> "function", or "class".
>
> At <
> https://people.mozilla.org/~jorendorff/es6-draft.html#sec-ecmascript-language-statements-and-declarations>
> are the legal ES6 statements. Note that most of these begin with a keyword
> that cannot possibly be legal at the beginning of an expression. Therefore,
> adding all these initial-statement-keywords to the list of things that
> cannot begin an expression statement would break nothing. They already
> cannot begin an expression statement.
>
> With the expression statement prohibition in place, now we can allow all
> these forms to be expressions. As with "{", "function", or "class", if you
> want to state such an expression in expression-statement position, surround
> it with parens.
>
> Because all these new forms will look bizarre and confusing, at least at
> first, let's say these always need surrounding parens to be expressions. I
> think that would help minimize confusion.
>
> If we do this, the oddest duck is "{", since it begins an object literal
> expression. This proposal gives us no straightforward way to express an
> block expression. "function" and "class" are less odd, since their existing
> expression forms mean what you almost might expect by this new rule -- even
> though they are initial-declaration-keywords rather than
> initial-statement-keywords.
>
> The remaining initial-declaration-keywords are "let" and "const". We
> already made "let" insane regarding these issues in sloppy mode, so I'm
> going to ignore that. But let's consider "const" and strict "let". These
> already cannot appear at the beginning of an expression, so it would not
> break anything to add them to the prohibition list for the beginning of
> expression statements.
>
> No current expression can add any binding to the scope in which the
> expression appears. Let's examine the consequences of having parens --
> rather than containing a "{"-block to create a nested scope with a value
> (which would conflict with object literals), instead simply define a
> block-like nested scope with a value. This would allow declarations and
> statements within the parens, much like the current "do" proposal. It would
> even be consistent enough with the existing semantics of paren-surrounded
> function and class expressions: Someone who sees these as a function or
> class declaration within its own nested scope, whose value was the value
> being declared, would rarely be surprised by the subtle difference between
> that story and the current semantics.
>
> Having parens accept a list of declarations and statements rather than
> just an expressions seems like a radical change that must break something,
> but I can't find a problem. Am I missing something?
>
> Examples inline:
>
>
>
> On Mon, Jul 13, 2015 at 5:47 PM, Isiah Meadows 
> wrote:
>
>> I was reading a recent thread
>>  where
>> do-expressions simplified a common try-catch use case, and I was wondering
>> if `do` could be simplified to an expression? It would allow for this to be
>> solved very easily, but also add a lot more flexibility in this proposal,
>> as well as avoiding some ugly nested braces.
>>
>> I know it would cause an ambiguity with `do-while` loops, but that could
>> be resolved with a single token lookahead of "if the next token is the
>> keyword `while`, then the block body is the body of a do-while loop, else
>> it is the body of the block statement in a `do` expression".
>>
>> As for the EBNF, do-expressions could be parsed with a goal symbol of
>> either `+While` or `-While`, with do-while statements spec-wise effectively
>> being treated as do-expressions without an init part run repetitively, but
>> mandated to be statements.
>>
>> ```js
>> // Do expression
>> let foo = do {
>>   foo(0)
>> };
>>
>
> let foo = (foo(0));
>
> This seems as broken as the original. In both cases, unless I'm missing
> something, this is a TDZ violation when the right side evaluates foo.
> Mistake?
>
>
>>
>> let tried = do try {
>>   foo(0)
>> } catch (e) {
>>   throw e
>> };
>>
>
> let tried = (try { foo(0) } catch (e) {

Re: Generalize do-expressions to statements in general?

[Andreas Rossberg]

All you are proposing is to allow the braces to be dropped from a
do-expression, right? That's an obvious tweak, although I'm not sure if it
really improves readability. (Other than that, do-expressions are already
intended to work as you describe, using the completion value of the
statement list. That's their whole point, after all.)

I had something else in mind. Once we have do expressions, we can introduce
syntactic sugar that effectively makes any statement syntax into legal
expressions. E.g.:

  throw expr  ~>  do { throw expr; }
  try expr catch (pat) expr  ~>  do { try { expr; } catch (pat) { expr; } }
  if (expr) expr else expr  ~>  do { if (expr) expr; else expr; }
  etc

At least for those statements for which it makes sense. To avoid ambiguity,
all you need to do is extend the existing restriction that none of the
initial keywords may start an expression statement.

But I intend to propose that separately from (or as an optional part of)
the do-expressions proposal, since it might be more controversial.

/Andreas


On 14 July 2015 at 00:47, Isiah Meadows  wrote:

> I was reading a recent thread
>  where
> do-expressions simplified a common try-catch use case, and I was wondering
> if `do` could be simplified to an expression? It would allow for this to be
> solved very easily, but also add a lot more flexibility in this proposal,
> as well as avoiding some ugly nested braces.
>
> I know it would cause an ambiguity with `do-while` loops, but that could
> be resolved with a single token lookahead of "if the next token is the
> keyword `while`, then the block body is the body of a do-while loop, else
> it is the body of the block statement in a `do` expression".
>
> As for the EBNF, do-expressions could be parsed with a goal symbol of
> either `+While` or `-While`, with do-while statements spec-wise effectively
> being treated as do-expressions without an init part run repetitively, but
> mandated to be statements.
>
> ```js
> // Do expression
> let foo = do {
>   foo(0)
> };
>
> let tried = do try {
>   foo(0)
> } catch (e) {
>   throw e
> };
>
> // Do-while statement
> let i = 0;
> do {
>   foo(i)
> } while (i++ < 10);
>
> // Combined:
> let i = 0;
> let foo9 = do do {
>   foo(i) // can have side effects, foo9 = foo(9)
> } while (i++ < 10);
> ```
>
> Another example of where this could come in handy: simplifying
> asynchronous code.
>
> ```js
> function readConfig() {
>   fs.readFileAsync('config.json', 'utf8')
> .then(JSON.parse)
> .then(contents => do if (contents.unexpectedProperty) {
>   throw new Error('Bad property') // rejects the promise
> } else {
>   doSomething(contents)
> })
> .catch(err => process.domain.emit('err', error))
> }
>
> // With only block statement
> function readConfig() {
>   fs.readFileAsync('config.json', 'utf8')
> .then(JSON.parse)
> .then(contents => do {
>   if (contents.unexpectedProperty) {
> throw new Error('Bad property') // rejects the promise
>   } else {
> doSomething(contents)
>   }
> })
> .catch(err => process.domain.emit('err', error))
> }
>
> // Without do-expressions
> function readConfig() {
>   fs.readFileAsync('config.json', 'utf8')
> .then(JSON.parse)
> .then(contents => {
>   if (contents.unexpectedProperty) {
> throw new Error('Bad property') // rejects the promise
>   } else {
> doSomething(contents)
>   }
> })
> .catch(err => process.domain.emit('err', error))
> }
> ```
>
> As you can see, the more general version does simplify things a little.
>
> Also, if-statements look better than long ternaries IMHO, and are less
> repetitive than their counterpart, repeated assignment (us lazy typists...):
>
> ```js
> let foo = do if (someCondition) {
>   value
> } else if (someOtherCondition) {
>   value + 1
> } else if (someEdgeCase) {
>   addressEdgeCase(value)
> } else {
>   value
> }
> ```
>
> --
> Isiah Meadows
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Allow `try…catch` blocks to return a value.

[Andreas Rossberg]

Do-expressions will solve this:

 let stuff = do { try {
   f()
 } catch (e) { 0 } }

The inflation of braces is somewhat ugly there, and we might want to allow
dropping some of them.

/Andreas


On 12 July 2015 at 10:26, Gary Guo  wrote:

> This is not possible as it contracts with existing semantics. Wrap it with
> a function instead.
>
> --
> From: jbuca...@me.com
> Subject: Allow `try…catch` blocks to return a value.
> Date: Sun, 12 Jul 2015 06:53:52 +0900
> To: es-discuss@mozilla.org
>
>
> Allow `try…catch` blocks to return a value.
>
> Sometimes I wrap a `try…catch` in a function and return a value based in
> whether there was an error or not.
>
> It would be useful if you could use `return` inside a `try…catch` block to
> accomplish the same.
>
>
> ```js
>  let stuff = try {
>return ...
>  } catch (e) { return … ? … : ... }
> ```
> ___ es-discuss mailing list
> es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Will any new features be tied to constructors?

[Andreas Rossberg]

On 1 July 2015 at 17:12, Domenic Denicola  wrote:

> Similarly, for several V8 built-ins, private state is not done via the
> allocator at all, but instead via "private symbols" that act quite similar
> to data properties. They can be added or removed at any time. In short,
> they're much more part of initialization than of allocation.
>

For the record, the ability to do this is rather an incidental consequence
of private symbols. We don't remove private state anywhere, nor did I
intend it to be used that way. There is one case where we add a private
field dynamically (attaching a stack trace to a thrown object), but that is
a half-broken hack anyway.

I'd love to have a proper allocation-time notion of private state, like
Allen & Kevin suggest. You still have weak maps for more dynamic relations.

/Andreas
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Cross language discussion

[Andreas Rossberg]

On 1 July 2015 at 14:37, Benjamin Gruenbaum  wrote:

> So, this is something that has been bothering me for a while now.
>
> The TC, and the mailing list is full of some really smart people. However,
> smart people can overlook things too and smart people can spend months in a
> debate that other people already thought about.
>
> Other languages have open processes too, other languages have mailing
> lists and working groups and much of the same discussions we do.
>
> -
>
> I think it would be really awesome if a small subgroup of the TC could do
> a monthly or bi-monthly chat (hangouts, skype, in person, whatever) with
> working groups from other languages.
>
> I have talked to several PHP-Internals people and they are generally in
> favour. Knowing some of these people they have a ton to contribute - if we
> could save just a single debate or understand a domain better it'd be worth
> it IMO.
>
> What do you guys think?
>

Quite a few members of TC39 are already deeply involved in various other
language communities, although I don't know about PHP in particular. That
has often proved helpful. In general, anybody on a language committee ought
to have a certain degree of knowledge and interest in a broader variety of
languages. OTOH, I believe that individual cross involvement is far more
fertile than unfocussed group meetings.

/Andreas
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: May 2015 Meeting Notes

[Andreas Rossberg]

On 30 June 2015 at 16:26, Jonathan Bond-Caron 
wrote:

> On Tue Jun 30 09:55 AM, Andreas Rossberg wrote:
> >   typeof ColorType1 // "Color:s1" // where s1...sN is a generated
> increment/key for a new user symbol
> >   typeof ColorType2 // "Color:s2"
> >   typeof ColorType3 // "Other:s3"
> >   typeof ColorType4 // "s4"
> >
> > A seemingly predictable name is a rather bad idea, because it would be
> very brittle, e.g., depend on other libraries loaded, or even loading
> order. It's better to have clearly non-deterministic
> > (e.g. gensym) than something that pretends to be deterministic but isn't
> in practice.
> >
> > In fact, it might be best if typeof returned the symbol itself. At least
> that cleanly matches the generative nature of the type definition. If you
> want it to work cross-realm, you have to broker
> > the symbol as usual.
> >
>
> Can you explain how 'gensym' would be different? Google tells me:
> https://clojuredocs.org/clojure.core/gensym
>
> https://github.com/clojure/clojure/blob/clojure-1.5.1/src/jvm/clojure/lang/RT.java#L468


Gensym usually is understood to produce a unique value that has a low
likelihood (or even none, like actual ES symbols) of clashing with
user-provided values. Clojure's implementation seems kind of weak there. :)

/Andreas
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: May 2015 Meeting Notes

[Andreas Rossberg]

On 30 June 2015 at 15:39, Jonathan Bond-Caron 
wrote:

> On Fri Jun 26 05:23 PM, Brian Terlson wrote:
> > https://github.com/tc39/tc39-notes/blob/master/es6/2015-05/may-29.md
>
> Yay to Value types
> and +1 for the per-realm thinking
>
> For typeof, this would seem intuitive:
>
> var ColorType1 = ValueType(Symbol("Color"), {...});
> var ColorType2 = ValueType(Symbol("Color"), {...});
> var ColorType3 = ValueType(Symbol("Other"), {...});
> var ColorType4 = ValueType(Symbol(), {...});
>
> typeof ColorType1 // "Color:s1" // where s1...sN is a generated
> increment/key for a new user symbol
> typeof ColorType2 // "Color:s2"
> typeof ColorType3 // "Other:s3"
> typeof ColorType4 // "s4"
>

A seemingly predictable name is a rather bad idea, because it would be very
brittle, e.g., depend on other libraries loaded, or even loading order.
It's better to have clearly non-deterministic (e.g. gensym) than something
that pretends to be deterministic but isn't in practice.

In fact, it might be best if typeof returned the symbol itself. At least
that cleanly matches the generative nature of the type definition. If you
want it to work cross-realm, you have to broker the symbol as usual.

/Andreas

// Global symbols use their keys prefixed by a 'g'
> var ColorType5 = ValueType(Symbol.for("Color"), {...});
> typeof ColorType5 // "gColor"
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: function.sent beta equivalence?

[Andreas Rossberg]

On 24 June 2015 at 22:56, Jason Orendorff  wrote:

> Quick question about function.sent:
>
> As of ES6, there's this parallel between functions and generators:
>
> // how to wrap a function
> // f2 is equivalent to f, if f doesn't use `this`.
> function f(...) { ... }
> function f2(...args) { return f(...args); }
>
> // how to wrap a generator
> // g2 is equivalent to g, if g doesn't use `this`.
> function* g(...) { ... }
> function* g2(...args) { return yield* g(...args); }
>
> That is, λx.f(x) = f, a sort of beta-equivalence rule,


Nitpick: this equivalence is eta, not beta. Unfortunately, I don't have
anything more profound to add.

But it's a good question. Maybe it's an indication that we should not add
function.sent?

/Andreas



> and for
> generators, you just need to add `yield*` to get an analogous rule. My
> understanding is that this is one reason we have `yield*`. (Writing a
> wrapping function/generator that also covers `this` is left as an easy
> exercise.)
>
> Given function.sent, is there still a way to "wrap" a generator?
>
> -j
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Move es-discuss to discuss.webplatform.org?

[Andreas Rossberg]

On 19 June 2015 at 23:04, Axel Rauschmayer  wrote:

> http://discourse.specifiction.org/t/upcoming-migration/805
>
> Would it make sense to move es-discuss to that upcoming site? I’m not
> particularly fond of mailing lists and much prefer forums, especially
> discourse-based ones.
>

Another -1 from me, sorry. Other than being new & shiny, forums introduce
more problems than they fix (like, account/login inflation, broken
threading, no offline reading or half-assed mail gateways, etc).

We had this discussion before. I'm still wondering what problem moving to a
forum would actually solve.

/Andreas
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: revive let blocks

[Andreas Rossberg]

On 26 June 2015 at 04:08, Kevin Smith  wrote:

> I think do expressions are "go" for ES7 but they need re-championing,
>> and implementation. I'll stir the pot.
>>
>
> I think Andreas was interested at some point?
>

Yes, I'm planning to prepare a proper spec for the September meeting. I'm
also hoping we get a prototype impl in V8 some time later this year,
although I'd rather not promise anything.

/Andreas
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: When macros will get in, will the core get slimmed in favour of macro-definitions?

[Andreas Rossberg]

I doubt this will be possible in a backwards compatible manner. With ES6,
we missed the opportunity to take more of a desugaring approach for new
features. As a consequence, there now is a fair amount of micro variation
between seemingly related features that is only describable in terms of
lower-level spec language.

/Andreas


On 22 June 2015 at 06:23, Brendan Eich  wrote:

> Sure, we'd want that. And sweet.js can handle a lot (it handled classes,
> destructuring, and other ES6 features before they were implemented in
> popular engines). This may take a while. Best way to ensure this outcome:
> more people learning, using, and helping improve sweet.js.
>
> /be
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: The Tragedy of the Common Lisp, or, Why Large Languages Explode (was: revive let blocks)

[Andreas Rossberg]

On 19 June 2015 at 10:06, Alexander Jones  wrote:

> If people are unable to internalize the whole language, then surely we
> need a way to remove cruft and idiosyncracies in it, lest the language
> stagnate beyond repair.
>
> Removing var, typeof, exotic objects, function declarations, IsNaN, ==,
> enumerable properties, are just a few examples of things we should not be
> frightened to talk about.
>
> While I don't personally see a need for the proposed let syntax, I think
> that concerns about the language growing uncontrollably should be directed
> at its apparent lack of deprecation strategy, rather than shutting down
> discussion of new ideas that might help us write better programs.
>

While I agree that the impossibility of deprecating features is a problem
(without a solution in JS), it's also fair to say that deprecation doesn't
really work or help. Take C++ as the obvious example. They do deprecate
occasionally, with difficulties. Yet the language had already blown
complexity out of any sane proportion 25 years ago. Let alone today. Not a
chance that there is a single person who _even remotely_ understands the
full language, and there probably hasn't been one for 3 decades at least.

Deprecation doesn't solve the problem because new cruft typically gets
added orders of magnitude faster than old cruft can ever be removed. That
is true for almost all production languages. Because it's so much easier to
add stuff.

Thus, the only way to keep a language small (if at all) is being extra
careful about adding features. Just about any terrible feature can be
justified by "use cases", but that's insufficient reason to add it.
Especially "convenience" features are a slippery slope. (I could make a
list of ES6 additions that already violate this principle.)

The art in language design isn't what to add, but what to leave out.

/Andreas




> On Thursday, June 18, 2015, Allen Wirfs-Brock 
> wrote:
>
>>
>> On Jun 18, 2015, at 12:18 PM, Andreas Rossberg wrote:
>>
>> On 18 June 2015 at 19:26, Benjamin Gruenbaum 
>> wrote:
>>
>>> This is a mailing list comprised of people who typically have a much
>>> better understanding of the language and its corners than most (even
>>> professional) developers have (and dare I say, are interested in or care
>>> about having). With ES6 the language already got a *lot* bigger and I'd
>>> argue that it's now harder to learn the whole. The tradeoffs were
>>> worthwhile but it's definitely an issue.
>>>
>>
>> I dare say that at this point Allen probably is the only person in the
>> world who actually fully knows and understands the complete language. I
>> won't hesitate to admit that I don't. ;)
>>
>>
>> And I occasionally have to go and look up details.
>>
>> Allen
>>
>>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Re: The Tragedy of the Common Lisp, or, Why Large Languages Explode (was: revive let blocks)

[Andreas Rossberg]

On 18 June 2015 at 19:26, Benjamin Gruenbaum  wrote:

> This is a mailing list comprised of people who typically have a much
> better understanding of the language and its corners than most (even
> professional) developers have (and dare I say, are interested in or care
> about having). With ES6 the language already got a *lot* bigger and I'd
> argue that it's now harder to learn the whole. The tradeoffs were
> worthwhile but it's definitely an issue.
>

I dare say that at this point Allen probably is the only person in the
world who actually fully knows and understands the complete language. I
won't hesitate to admit that I don't. ;)

/Andreas
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Existential Operator / Null Propagation Operator

[Andreas Rossberg]

On 2 June 2015 at 18:57, Brendan Eich  wrote:

> Sander Deryckere wrote:
>
>> 2015-06-02 17:49 GMT+02:00 Brendan Eich > bren...@mozilla.org>>:
>>
>>
>> Sander Deryckere wrote:
>>
>> For the prefix operator, it's unclear to me how you would do
>> the following: Say you know `obj` is non-null, you want to
>> test if it has a key `k1`, but if `k1` exists, you know it
>> will also have a key `k2` a level deeper. With the suffix
>> operator, this would be `obj[k1]?[k2]`, but with the prefix
>> operator, it could be `obj?[k1][k2]`
>>
>>
>> You circled back to the incompatible syntax, `?[`, but the prefix
>> idea would have `?obj[k1][k2]`. The `?` goes in front at the start
>> of an operand, and is thus unambiguous with respect to the ternary
>> operator.
>>
>>
>> The question is not about the existence of `obj`, but if `obj` has a key
>> `k1`. AFAICS, `?obj[k1][k2]` would test the existence of `obj`, which I
>> don't need in this example. To test the existence of a key inside `obj`, a
>> prefix operator should come somewhere before the key.
>>
>
> You might hope for that, but as we both noted, `?[` is not going to fly.
> Don't break the (minified) Web.
>
> The prefix idea generalizes:
>
> ?obj[key]
> obj[?key]
> obj[key1][?key2]
>

Hm, what's the meaning of

a[?b[c]]

?

/Andreas
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: is an iterator allowed to reuse the same "state" object?

[Andreas Rossberg]

On 29 April 2015 at 18:37, Brendan Eich  wrote:

> Andreas Rossberg wrote:
>
>> On 29 April 2015 at 02:21, John Lenz > concavel...@gmail.com>> wrote:
>>
>> I missed it, thanks.I know things will improve in time but I'm
>> just coming from a discussion with folks complaining about the
>> performance of generators and GC overhead in real code with Chrome
>> and Firefox relative to simple hand written loops.
>>
>>
>> Note that there is a huge difference between optimising iterators (in
>> particular, for-of), and optimising generators. I expect that VMs will
>> start getting better on the former relatively soon, for iterators that are
>> not generators. Making generators fast is a much more complicated problem.
>>
>
> But in either case, escape analysis and object allocation elimination can
> avoid the flood of eden objects John cited, right?
>

Yes, together with inlining.

I'm inferring your comment about generator optimization hardship has to do
> with a function that yields -- whose CFG has multiple entry points and
> whose activation record must live in the heap.


Yes, the biggest challenge perhaps is not even generator CFGs per se, but
getting inlining to work with them, which is necessary to take advantage of
escape analysis.

/Andreas
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: is an iterator allowed to reuse the same "state" object?

[Andreas Rossberg]

On 29 April 2015 at 02:21, John Lenz  wrote:

> I missed it, thanks.I know things will improve in time but I'm just
> coming from a discussion with folks complaining about the performance of
> generators and GC overhead in real code with Chrome and Firefox relative to
> simple hand written loops.
>

Note that there is a huge difference between optimising iterators (in
particular, for-of), and optimising generators. I expect that VMs will
start getting better on the former relatively soon, for iterators that are
not generators. Making generators fast is a much more complicated problem.

/Andreas


On Tue, Apr 28, 2015 at 4:28 PM, Allen Wirfs-Brock 
> wrote:
>
>>
>> On Apr 28, 2015, at 4:21 PM, John Lenz wrote:
>>
>> You would hope that the engines might be able to create these objects on
>> the stack but I don't think anyone does that yet and the result is a flood
>> of eden objects.
>>
>> I would like to know I'm wrong about this.
>>
>> did you see
>> https://esdiscuss.org/topic/performance-of-iterator-next-as-specified#content-15
>>
>>
>> A really good optimizing jit should be able to inline the 'next' call,
>> recognize that the IterationResult object doesn't escape (it knows this for
>> for-of loops) and not do an allocation at all.
>>
>> Allen
>>
>>
>>
>> On Apr 27, 2015 4:59 PM, "Allen Wirfs-Brock" 
>> wrote:
>>
>>>
>>> On Apr 27, 2015, at 3:29 PM, Tab Atkins Jr. wrote:
>>>
>>> On Mon, Apr 27, 2015 at 3:11 PM, John Lenz 
>>> wrote:
>>>
>>> By which I mean the object that returns the current value and "done"
>>> state?
>>>
>>>
>>> IIRC, it's not supposed to.  The built-in iterators will return fresh
>>> objects each time, so there's no mutation hazard.  Userland iterators
>>> can of course violate this, but at their peril.
>>>
>>>
>>> Well, that's not exactly what the ES2015 spec. says.  The specification
>>> of the Iterator interface (
>>> http://people.mozilla.org/~jorendorff/es6-draft.html#sec-iterator-interface 
>>> )
>>> does not require that the `next` method return a fresh object each time it
>>> it called.  So a userland iterator would not be violating anything by
>>> reusing a result object.
>>>
>>> However,  the specifications for all ES2015  built-in iterators require
>>> that they return fresh objects.
>>>
>>> None of the built-in consumers of the Iterator interface (for-of,
>>> Array.from, etc.) retain references to IteratorResult objects after testing
>>> for `done` and accessing the `value`, so semantically they don't care
>>> whether the ResultObject is reused. However, such reuse might preclude some
>>> otherwise plausible engine level optimizations.
>>>
>>> Allen
>>>
>>>
>>>
>>
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Non-binding destructuring assignment

[Andreas Rossberg]

I agree that we should have wildcard patterns. I also think that array
elisions are a non-solution, because you need a magnifier to read or count
them, and they square oddly with optional commas in the end.

/Andreas

On 29 April 2015 at 13:47, Elie Rotenberg  wrote:

> Wow, thanks. I feel dumb for asking :D
>
> On Wed, Apr 29, 2015 at 1:43 PM, Sebastian McKenzie 
> wrote:
>
>> The binding identifiers are optional. You can do what you want already
>> with:
>>
>> const lastOfThree = ([,, third]) => {
>>   return third;
>> }
>>
>>
>>
>>
>> On Wed, Apr 29, 2015 at 12:40 PM, Elie Rotenberg 
>> wrote:
>>
>>> Using array destructuring assignment and constraining linting rules, I
>>> often find myself having to chose names for bindings I don't intent on
>>> using. I usually end up using a conventional ignore name, such as _ignore,
>>> which I "void" to shut up the linter without adding exceptions. Besides the
>>> linting problem (which can be solved by refining the linting rules), it's
>>> still a conceptually useless binding.
>>>
>>> Here's a contrived example:
>>>
>>> const lastOfThree = ([first, second, third])  => third;
>>>
>>> Which I usually end up rewriting:
>>>
>>> const lastOfThree = ([_ignore1, _ignore2, third]) => {
>>>   void _ignore1;
>>>   void _ignore2;
>>>   return third;
>>> }
>>>
>>> This problem doesn't exist when using objects, since only the fields
>>> specified on the LHS are bound.
>>>
>>> I realize the bigger topic behind non-binding match is refutable pattern
>>> matching, as per
>>> http://wiki.ecmascript.org/doku.php?id=strawman:pattern_matching, but
>>> being able to dismiss a matched (or unmatched) value from a destructuring
>>> assignment seems a very often desirable feature when programming in a
>>> functional style (eg. working with lists represented as 2-element arrays).
>>> Most functional-style languages have a non-binding matching feature.
>>>
>>> This topic has been discussed in the following topics:
>>> - https://esdiscuss.org/topic/conditional-catch
>>> - https://esdiscuss.org/notes/2014-07-30
>>> - https://esdiscuss.org/topic/conditional-catch-clause
>>>
>>> Does anyone else feel the need for a specific means of dismissing a
>>> binding from a destructuring assignment? Is pattern matching still on
>>> discussion?
>>>
>>> Regards,
>>>
>>
>>
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Putting `global` reference in specs

[Andreas Rossberg]

On 17 April 2015 at 17:27, Mark S. Miller  wrote:

> (1,eval)('"use strict"; this')
>

Is the 'use strict' relevant here? Seems overkill.

/Andreas



>
> On Fri, Apr 17, 2015 at 8:23 AM, Andrea Giammarchi <
> andrea.giammar...@gmail.com> wrote:
>
>> there's actually no way, officially, to reference what ES2015 call *the
>> global object*, just pointless fragmentation between engines.
>>
>>
>>
>> On Fri, Apr 17, 2015 at 4:19 PM, Anne van Kesteren 
>> wrote:
>>
>>> On Fri, Apr 17, 2015 at 5:12 PM, Andrea Giammarchi
>>>  wrote:
>>> > So I'd say we should not have `self` (if stays on global and Worker I
>>> don't
>>> > actually care) and add a `global` that nobody needs explanation to
>>> > understand what it is in JavaScript
>>>
>>> Indeed, three ways to reference the global object is not nearly enough.
>>>
>>>
>>> --
>>> https://annevankesteren.nl/
>>>
>>
>>
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>>
>
>
> --
> Cheers,
> --MarkM
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: do while scope

[Andreas Rossberg]

On 17 April 2015 at 17:18, Glen Huang  wrote:

> Not sure about others, but i assume the condition part and statement part
> in a control construct live in the same scope.
>
> That's why you can do `for (let a = 1; a < 2; a++) a;`. And `if (let a =
> 1) a;` maybe in es7?
>
> Why that's not the case for "do while"? Is my mental model wrong?
>

Yes. :)

for (let x ...) scopes over the body naturally. In your example, you expect
to scope an inner declaration (one even inside a block) to scope to the
outside. That is something else entirely, and makes no sense to me.

/Andreas


> > On Apr 17, 2015, at 11:10 PM, Caitlin Potter 
> wrote:
> >
> > Is there a language where lexically scoped variables declared in a block
> are accessible outside of that block? Java, C, C#, rust, Python, etc, will
> not let you do this. I’m not sure this is a gotcha for most software
> developers
> >
> >> On Apr 17, 2015, at 10:57 AM, Glen Huang  wrote:
> >>
> >> ```js
> >> do {
> >> let a = 1;
> >> } while (a);
> >> ```
> >> is "a" undefined in the while condition? This seems like a gotcha.
> >>
> >>
> >> ___
> >> es-discuss mailing list
> >> es-discuss@mozilla.org
> >> https://mail.mozilla.org/listinfo/es-discuss
> >
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Should "const" be favored over "let"?

[Andreas Rossberg]

On 17 April 2015 at 14:17, Mathias Bynens  wrote:

> On Fri, Apr 17, 2015 at 7:53 AM, Glen Huang  wrote:
> > I've completely replaced "var" with "let" in my es 2015 code, but I
> noticed most variables I introduced never change.
>
> Note that `const` has nothing to do with the value of a variable
> changing or not. It can still change:
>
> const foo = {};
> foo.bar = 42; // does not throw
>
> `const` indicates the *binding* is constant, i.e. there will be no
> reassignments etc.
>

I have to nitpick on this. In usual nomenclature of programming language
semantics the "value" in question is the _reference_ to the object (for
types with reference semantics), and that does not change. That the object
itself actually can be mutable is a separate property.

The idea that const somehow applies transitively is a specific idiosyncrasy
of low-level languages like C and friends, that make flattening and copying
of mutable objects an implicit part of their semantics. It is not the norm,
and actually rather contorted semantically.

/Andreas


> In my post-ES6 code, I use `const` by default, falling back to `let`
> if I explicitly need rebinding. `var` is for legacy code.
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: forward-incompatible Function.prototype.toString requirement

[Andreas Rossberg]

On 16 April 2015 at 14:34, Frankie Bagnardi  wrote:

> The part that sticks out to me is... toString on functions currently
> throws a syntax error when eval'd for non-named functions.  Tested in
> chrome:
>
> var f = function(){ return 1 };eval(f.toString()); // SyntaxError
> // becausefunction(){ return 1 }; // SyntaxError
> // but, force an expression: eval("(" + f.toString() + ")") // essentially 
> clones f
>
> ​
> This... is confusing in my opinion.
>

Yeah, the spec says:

"The string representation must have the syntax of a FunctionDeclaration
FunctionExpression, GeneratorDeclaration, GeneratorExpression,
ClassDeclaration, ClassExpression, ArrowFunction, MethodDefinition, or
GeneratorMethod depending upon the actual characteristics of the object."

which is weird. First, it doesn't really make sense, because whether
something originates from a declaration vs expression isn't a
"characteristic of the object". Second, making it return different
syntactic classes in different cases is not particularly useful for your
case.

But then again, using the result of f.toString as input to eval is A REAL
BAD IDEA anyway; toString should only be used for diagnostics, not
programmatically, because that is meaningless in general. So I personally
don't mind the friction.

/Andreas



>
>
> On Thu, Apr 16, 2015 at 2:56 AM, Andreas Rossberg 
> wrote:
>
>> On 16 April 2015 at 11:34, Michael Ficarra 
>> wrote:
>>
>>> ES2015 section 19.2.3.5 (Function.prototype.toString) places four
>>> restrictions on the output of Function.prototype.toString, one of which is
>>>
>>> If the implementation cannot produce a source code string that meets
>>>> these criteria then it must return a string for which *eval* will
>>>> throw a *SyntaxError* exception.
>>>>
>>>
>>> What is a SyntaxError today may not be a SyntaxError tomorrow. How can
>>> an implementation return a string that will satisfy this requirement in the
>>> future when the language has added new syntax? Does the committee have a
>>> SyntaxError recommendation that can be added as a non-normative note to
>>> that section?
>>>
>>
>> In the (probably unlikely) case that the language changed that way, and
>> an affected implementation adopted that change, then it would simply have
>> to change its toString implementation accordingly at that point. I don't
>> see a problem there.
>>
>> /Andreas
>>
>>
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: forward-incompatible Function.prototype.toString requirement

[Andreas Rossberg]

On 16 April 2015 at 11:34, Michael Ficarra 
wrote:

> ES2015 section 19.2.3.5 (Function.prototype.toString) places four
> restrictions on the output of Function.prototype.toString, one of which is
>
> If the implementation cannot produce a source code string that meets these
>> criteria then it must return a string for which *eval* will throw a
>> *SyntaxError* exception.
>>
>
> What is a SyntaxError today may not be a SyntaxError tomorrow. How can an
> implementation return a string that will satisfy this requirement in the
> future when the language has added new syntax? Does the committee have a
> SyntaxError recommendation that can be added as a non-normative note to
> that section?
>

In the (probably unlikely) case that the language changed that way, and an
affected implementation adopted that change, then it would simply have to
change its toString implementation accordingly at that point. I don't see a
problem there.

/Andreas
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Could we make %ArrayPrototype%'s [[DefineOwnProperty]] throw or no-op for numeric keys?

[Andreas Rossberg]

As long as we have mutable __proto__ in the language that is not going to
help. And even then, you'd have to restrict the whole prototype chain,
including Object.prototype.

AFAICT, the only working solution is to change the behaviour of [[Get]] on
arrays, such that they do not consider inherited numeric properties -- like
typed arrays, or what we propose for strong mode arrays.

/Andreas


On 16 April 2015 at 05:23, Domenic Denicola  wrote:

> Just an idle thought:
>
> Many of the spec-compliance bugs in engines' array implementations over
> the last couple years have had to do with handling what happens when you
> e.g. install getters or setters on %ArrayPrototype%. I've been told that
> handling this case adds lots of complexity to the implementations and their
> optimizations.
>
> Would it be worthwhile to explore making this impossible? Since
> %ArrayPrototype% is an exotic object anyway, we could give it a custom
> [[DefineOwnProperty]] that behaves similarly to that of array exotic
> objects, but disallows defining numeric keys. I guess this comes down to a
> few questions:
>
> - Would this actually give gains for implementers? My information here is
> secondhand and inferred.
> - Would the implementation complexity introduced by this change (separate
> exotic object types for arrays vs. %ArrayPrototype%) be worth the gains
> elsewhere, or is it just trading one weirdness for another?
> - Is this feasibly web-compatible? (i.e. worth trying?)
>
> Curious what implementers think.
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Number.prototype not being an instance breaks the web, too

[Andreas Rossberg]

V8 just rolled a change into Canary yesterday that implements the new ES6
semantics for Number.prototype (and Boolean.prototype) being ordinary
objects. Unfortunately, that seems to break the web. In particular
http://jsfiddle.net/#run fails to load now.

What I see happening on that page is a TypeError "Number.prototype.valueOf
is not generic" being thrown in this function (probably part of moo tools):

Number.prototype.$family = function(){
return isFinite(this) ? 'number' : 'null';
}.hide();

after being invoked on Number.prototype.

AFAICS, that leaves only one option: backing out of this spec change.

(See https://code.google.com/p/chromium/issues/detail?id=476437 for the
bug.)

/Andreas
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Class double-bind

[Andreas Rossberg]

On 5 March 2015 at 04:57, Brendan Eich  wrote:

> Allen Wirfs-Brock wrote:
>
>> This is novel weirdness.
>>>
>>
>> In C++/Java/C# etc. you don't see it because the corresponding
>> declarations create immutable bindings. I agree that it would have been
>> nice of we could have done that.
>>
>
> Why could we not have?
>
> I asked this up-thread. What was the rationale for let not const binding
> via class declarations? I honestly do not remember us considering const.
> Did we just "default" into let because of the historical (var) default
> binding form being mutable? If so, is it really too late?
>

I seem to remember a (brief) discussion about this, where the main argument
for mutable was that it was "natural" for JS. Allen probably remembers more
of the details.

It would be totally awesome if we could still correct this.

/Andreas


>
> Cc'ing Arv in case he can check via Traceur telemetry whether anyone
> counts on let-not-const from class.
>
> /be
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Class double-bind

[Andreas Rossberg]

For the record, I strongly dislike the function behaviour. Turning a
function expression into a declaration silently changes the meaning of
internal recursive references, in ways that many people find very
surprising. That is an unnecessary pitfall.

Your argument essentially is that you want to be able to do some AOP-style
hacking on (otherwise internal) class bindings. But as Allen pointed out,
that isn't reliable anyway, nor would it work for classes that do not
happen to be defined using class declaration syntax. So I think it is a
fairly weak argument. It is even preferable that the language does not
encourage such brittle patterns.

In summary, I'm glad that we did not adopt this behaviour for classes.

(On the other hand, I do think that it probably was a serious mistakes to
make class bindings mutable.)

/Andreas



On 4 March 2015 at 13:23, Jason Orendorff  wrote:

> I guess we are just going to disagree here. Double bindings with
> mutability still seem clearly bad. I can't make sense of the rationale
> that classes can cope with every external binding being mutable except
> for, somehow, their own name, and we're doing users a favor by
> "protecting" them from "tampering" for just this one binding in this
> one place.
>
> -j
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Object.assign and inherited properties

[Andreas Rossberg]

On 27 February 2015 at 16:16, Andri Möll  wrote:

> The fragile base class problem is one.
>
>
> That’s a problem of the caller, not the callee, the user of Object.assign.
> If I decide to use inheritance, that’s my risk.
>

You would like it to be that way, but that's not how it plays out in
practice. Once dependencies have been created, you often can't afford to
break them, no matter how much a problem is their fault.

/Andreas
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Object.assign and inherited properties

[Andreas Rossberg]

On 27 February 2015 at 15:22, Andri Möll  wrote:

> noone? JSLint doesn't even let you write a for/in loop if you don't have
> `obj.hasOwnProperty(key)` in it, and usually nobody wants inherited
> properties (included methods from old classes/ahem prototypes) reassigned
> everywhere.
>
>
> Huh? Old prototypes? Those prototypes have their properties set as
> non-enumerable since how long now? You yourself said one shouldn’t use
> Object.assign for objects with behavior in the inheritance chain. And I
> agree. It’s pretty much only useful for data objects (a.k.a plain). Those
> have no methods in the inheritance chain one needs to ignore.
>
> Again, I ask, *what is the problem to which ignoring inherited properties
> is the solution to?*
>

The fragile base class problem is one.

/Andreas
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: short-circuiting Array.prototype.reduce

[Andreas Rossberg]

On 23 February 2015 at 16:22, Mark S. Miller  wrote:

> We still an an option open to us, that would merely compatibly remove a
> restriction from the language rather than add a feature: Allow labels to
> remain visible across function boundaries, or at least across arrow
> function boundaries. Then one could break-to-label to a label of a
> lexically enclosing function.
>
> This has repeatedly died in committee before because it does raise another
> case for implementors: Once the execution context of that label has
> completed, an attempt to break to that label must instead throw an error.
> I've never understood why this extra case was a show stopper.
>

I opposed it (and still firmly do) not just because this has considerable
implementation complexity (each call could then have an arbitrary and
unknown number of exit points, not just two, and I don't even want to
imagine what that would do to our control graph) -- that is just a
consequence of the real problem, which is that this is an unstructured form
of non-local control transfer, a half-way, half-broken form of
continuations. If you want continuations, add real continuations.


On Sun, Feb 22, 2015 at 11:36 PM, Dmitry Soshnikov <
> dmitry.soshni...@gmail.com> wrote:
>
>> The technical reason for this I guess, is that JS doesn't have TCP
>> blocks, that would allow you to stop iteration, and exit the `reduce`
>> context right from the callback context. With TCP it would be a `return`
>> statement, which in JS we have to solve throwing a special "marker"
>> exception, which should be caught and analyzed.
>>
>
I don't see the relation to the OP's problem. A break would be a very poor
device for exiting a reduce, since it doesn't allow you to pass a result
(you'd have to funnel that through assigning some outer variable). Also, I
don't see why you can't do the same with a throw today.

What Lee really wants is a partial reduce. I think this could be provided
easily without magic symbols by using the encoding of an Either type, like
e.g. iterators already do (though it's used here in the inverse direction).
For example, you could imagine the following signature:

  reducePartial(f: (acc: A, val: B, key: number) => {value: A, done:
boolean}, init: A): A

/Andreas




>
>> From the practical perspective, yeah, it would be good to see real
>> examples of how useful the feature is. Of course if we take the reason:
>> "exit from an hight-order iteration as soon as possible in a convenient
>> way", that could sound reasonable/practical. Although, to have concrete
>> examples would be good.
>>
>> However, I'd say, JS betters needs some sort of TCP blocks, which would
>> solve other similar cases (and which I'm pretty sure were discussed several
>> times couple of years ago). E.g. in Ruby that example would be much easier,
>> and that `@@reduced` would be just simple intuitive `return`.
>>
>> Dmitry
>>
>>
>>
>>> The only inkling of why this might be useful is an unsourced assertion
>>> that it's done in Clojure, for unknown reasons. The example code isn't very
>>> compelling either; something more real-world would be good there.
>>>  --
>>> From: Lee Byron 
>>> Sent: ‎2015-‎02-‎23 00:58
>>> To: es-discuss@mozilla.org
>>> Subject: short-circuiting Array.prototype.reduce
>>>
>>>  Hey all,
>>>
>>>  I’d like to propose an addition to ES7 to add @@reduced as a way to
>>> short-circuit from Array.prototype.reduce.
>>>
>>>  I’ve written up a polyfill and explanation here:
>>>
>>>  https://github.com/leebyron/ecma-reduced
>>>
>>>  I would love your feedback on this.
>>>
>>>  Lee
>>>
>>> ___
>>> es-discuss mailing list
>>> es-discuss@mozilla.org
>>> https://mail.mozilla.org/listinfo/es-discuss
>>>
>>>
>>
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>>
>
>
> --
> Cheers,
> --MarkM
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: How would we copy... Anything?

[Andreas Rossberg]

On 23 February 2015 at 10:37, David Bruant  wrote:

> Le 23/02/2015 10:10, Michał Wadas a écrit :
>
>> Cloning objects is long requested feature.
>> "clone object javascript" yields 1 480 000 results in Google.
>>
> I'd like to share this as an answer
> http://facebook.github.io/immutable-js/#the-case-for-immutability
> "If an object is immutable, it can be "copied" simply by making another
> reference to it instead of copying the entire object. Because a reference
> is much smaller than the object itself, this results in memory savings and
> a potential boost in execution speed for programs which rely on copies
> (such as an undo-stack)."
>
> ```js
> var map1 = Immutable.Map({a:1, b:2, c:3});
> var clone = map1;
> ```
>

To be clear, that is only true in general as long as immutable objects also
don't have identity. With identity (i.e., reference equality), the
difference between an alias and an actual copy is still observable.
JavaScript is plagued by all objects having identity, a well-known problem
preventing various optimisations in compilers.

In other words, the ES spec would have to make an explicit and conscious
decisions to say that "cloning" an immutable object is not actually cloning
it. A compiler or runtime system usually cannot apply that decision itself
(except for primitives, which have structural equality).

Despite people *saying* all over the Internet they want cloning, maybe they
> want immutability?


Yeah, I tend to agree with that sentiment.

/Andreas


My proposition is to create a new well known Symbol - Symbol.clone and
>> corresponding method on Object - Object.clone.
>>
>> Default behavior for an object is to throw on clone try.
>> Object.prototype[Symbol.clone] = () => { throw TypeError; }
>> Users are encorauged to define their own Symbol.clone logic.
>>
>> Primitives are cloned easily.
>> Number.prototype[Symbol.clone] = String.prototype[Symbol.clone] =
>> Boolean.prototype[Symbol.clone] = function() {return this.valueOf();}
>>
> Primitives are immutable, no need to clone them.
> If you're referring to "primitive objects", it might be better to forget
> about this weird corner of the language than polish it.
>
> Back to something you wrote above:
>
>> Users are encorauged to define their own Symbol.clone logic.
>>
> Perhaps this cloning protocol can be purely implemented in userland as a
> library and doesn't need support from the language. That's one of the
> reasons symbols have been introduced after all.
>
> David
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Performance of iterator .next() as specified

[Andreas Rossberg]

On 16 February 2015 at 15:41, Andrea Giammarchi  wrote:

> Common pattern is to poll.next() a yield until its `done` property is
> `true` so that a value can be used.
>
> This is I believe the common case that will create thousands of objects to
> be quickly trashed as garbage ... so I was wondering if those are all needed
>

Er, I don't think this is the common use case at all. You iterate over
something to process values, otherwise there isn't much point in using
iterators in the first place.

/Andreas



> On Mon, Feb 16, 2015 at 2:38 PM, Andrea Giammarchi <
> andrea.giammar...@gmail.com> wrote:
>
>> then frozen `{done: false}` without even the `value` property ... Would
>> this work or speed-up anything at all?
>>
>> On Mon, Feb 16, 2015 at 2:32 PM, Andreas Rossberg 
>> wrote:
>>
>>> On 16 February 2015 at 15:21, Andrea Giammarchi <
>>> andrea.giammar...@gmail.com> wrote:
>>>
>>>> > Shared mutable result objects
>>>>
>>>> FWIW to me that could be even be a singleton frozen `{done: false,
>>>> value: null}` constant during iteration and a new object only once done.
>>>>
>>>> Would this work or speed-up anything at all?
>>>>
>>>
>>> Frozen value null? I don't understand. You'd get the actual values
>>> from... where?
>>>
>>> /Andreas
>>>
>>>
>>> On Mon, Feb 16, 2015 at 2:04 PM, Andreas Rossberg 
>>>> wrote:
>>>>
>>>>> On 15 February 2015 at 12:07, Katelyn Gadd  wrote:
>>>>>
>>>>>> I'm certainly in favor of VMs improving to handle that, and adding
>>>>>> pressure for it is good. However, optimizing a TypedArray temporary
>>>>>> arg to .set() is a much simpler problem than doing the escape analysis
>>>>>> necessary to be certain a .next() result doesn't escape from a calling
>>>>>> scope and isn't used after a later next() call. Applying pressure will
>>>>>> be a good way to make sure VM authors do the work necessary for this
>>>>>> to happen, but if iterators are unacceptably slow in shipping
>>>>>> implementations for a year+ I think the odds are good that most
>>>>>> shipping software will avoid using them, at which point VM authors
>>>>>> will have no reason to optimize for primitives nobody uses. =[
>>>>>>
>>>>>
>>>>> Engines are still ramping up on ES6 features, and most probably
>>>>> haven't been able to put much resources into optimisations yet (ES6 is
>>>>> large!). You can't compare it to old features that have been tuned for a
>>>>> decade and expect equal performance. This situation is unfortunate but
>>>>> unavoidable.
>>>>>
>>>>> Either way, it doesn't justify cutting corners in the semantics in a
>>>>> naive and premature attempt to optimise (which might even harm more
>>>>> highl-level optimisations on the long run). Shared mutable result objects
>>>>> would be a horrible API with footgun potential, especially when you start
>>>>> to build stream abstractions on top. FWIW, this has been discussed at
>>>>> length at some of the meetings.
>>>>>
>>>>> The fixed layout of the iterator object would allow the GC to allocate
>>>>>> it cheaply and in the case of values (like ints) it wouldn't need to
>>>>>> trace it either - so that helps a lot. But I don't know how realistic
>>>>>> those optimizations are in practice.
>>>>>>
>>>>>
>>>>> Not sure what you mean here. Unfortunately, result objects are still
>>>>> mutable and extensible, so anything can happen.
>>>>>
>>>>> /Andreas
>>>>>
>>>>>
>>>>> On 15 February 2015 at 02:36, Andrea Giammarchi
>>>>>>  wrote:
>>>>>> > +1 and I've raised same concerns 2 years ago [1]
>>>>>> >
>>>>>> > IIRC the outcome was that VM should be good enough to handle
>>>>>> objects with
>>>>>> > very short lifecycle, I'm still convinced (behind tests) that
>>>>>> generators are
>>>>>> > overkill for IoT devices (low clock and way lower RAM).
>>>>>> >
>>>>>> > Having always same object per iter

Re: Performance of iterator .next() as specified

[Andreas Rossberg]

On 16 February 2015 at 15:21, Andrea Giammarchi  wrote:

> > Shared mutable result objects
>
> FWIW to me that could be even be a singleton frozen `{done: false, value:
> null}` constant during iteration and a new object only once done.
>
> Would this work or speed-up anything at all?
>

Frozen value null? I don't understand. You'd get the actual values from...
where?

/Andreas


On Mon, Feb 16, 2015 at 2:04 PM, Andreas Rossberg 
> wrote:
>
>> On 15 February 2015 at 12:07, Katelyn Gadd  wrote:
>>
>>> I'm certainly in favor of VMs improving to handle that, and adding
>>> pressure for it is good. However, optimizing a TypedArray temporary
>>> arg to .set() is a much simpler problem than doing the escape analysis
>>> necessary to be certain a .next() result doesn't escape from a calling
>>> scope and isn't used after a later next() call. Applying pressure will
>>> be a good way to make sure VM authors do the work necessary for this
>>> to happen, but if iterators are unacceptably slow in shipping
>>> implementations for a year+ I think the odds are good that most
>>> shipping software will avoid using them, at which point VM authors
>>> will have no reason to optimize for primitives nobody uses. =[
>>>
>>
>> Engines are still ramping up on ES6 features, and most probably haven't
>> been able to put much resources into optimisations yet (ES6 is large!). You
>> can't compare it to old features that have been tuned for a decade and
>> expect equal performance. This situation is unfortunate but unavoidable.
>>
>> Either way, it doesn't justify cutting corners in the semantics in a
>> naive and premature attempt to optimise (which might even harm more
>> highl-level optimisations on the long run). Shared mutable result objects
>> would be a horrible API with footgun potential, especially when you start
>> to build stream abstractions on top. FWIW, this has been discussed at
>> length at some of the meetings.
>>
>> The fixed layout of the iterator object would allow the GC to allocate
>>> it cheaply and in the case of values (like ints) it wouldn't need to
>>> trace it either - so that helps a lot. But I don't know how realistic
>>> those optimizations are in practice.
>>>
>>
>> Not sure what you mean here. Unfortunately, result objects are still
>> mutable and extensible, so anything can happen.
>>
>> /Andreas
>>
>>
>> On 15 February 2015 at 02:36, Andrea Giammarchi
>>>  wrote:
>>> > +1 and I've raised same concerns 2 years ago [1]
>>> >
>>> > IIRC the outcome was that VM should be good enough to handle objects
>>> with
>>> > very short lifecycle, I'm still convinced (behind tests) that
>>> generators are
>>> > overkill for IoT devices (low clock and way lower RAM).
>>> >
>>> > Having always same object per iteration makes sense to me at least
>>> until
>>> > it's done so that could be just a struct-like `{done: false, value:
>>> null}`
>>> > object and GC will be happier than ever.
>>> >
>>> > Regards
>>> >
>>> >
>>> > [1]
>>> >
>>> http://webreflection.blogspot.co.uk/2013/06/on-harmony-javascript-generators.html
>>> >
>>> > On Sun, Feb 15, 2015 at 10:06 AM, Katelyn Gadd 
>>> wrote:
>>> >>
>>> >> As specified, iterator .next() seems to be required to return a new
>>> >> object instance for each iteration.
>>> >>
>>> >> In my testing (and in my theory, as an absolute) this is a real
>>> >> performance defect in the spec and it will make iterators inferior to
>>> >> all other forms of sequence iteration, to the extent that they may end
>>> >> up being used very rarely, and developers will be biased away from Map
>>> >> and Set as a result.
>>> >>
>>> >> The issue here is that the new object requirement means that every
>>> >> iteration produces GC pressure. I think that past APIs with this
>>> >> problem (for example TypedArray.set) have proven that 'a sufficiently
>>> >> smart VM can optimize this' is not representative of real VMs or real
>>> >> use cases.
>>> >>
>>> >> In the specific case of .next(), the method returning a new object on
>>> >> every iteration does not produce any actual improvement to us

Re: Performance of iterator .next() as specified

[Andreas Rossberg]

On 15 February 2015 at 12:07, Katelyn Gadd  wrote:

> I'm certainly in favor of VMs improving to handle that, and adding
> pressure for it is good. However, optimizing a TypedArray temporary
> arg to .set() is a much simpler problem than doing the escape analysis
> necessary to be certain a .next() result doesn't escape from a calling
> scope and isn't used after a later next() call. Applying pressure will
> be a good way to make sure VM authors do the work necessary for this
> to happen, but if iterators are unacceptably slow in shipping
> implementations for a year+ I think the odds are good that most
> shipping software will avoid using them, at which point VM authors
> will have no reason to optimize for primitives nobody uses. =[
>

Engines are still ramping up on ES6 features, and most probably haven't
been able to put much resources into optimisations yet (ES6 is large!). You
can't compare it to old features that have been tuned for a decade and
expect equal performance. This situation is unfortunate but unavoidable.

Either way, it doesn't justify cutting corners in the semantics in a naive
and premature attempt to optimise (which might even harm more highl-level
optimisations on the long run). Shared mutable result objects would be a
horrible API with footgun potential, especially when you start to build
stream abstractions on top. FWIW, this has been discussed at length at some
of the meetings.

The fixed layout of the iterator object would allow the GC to allocate
> it cheaply and in the case of values (like ints) it wouldn't need to
> trace it either - so that helps a lot. But I don't know how realistic
> those optimizations are in practice.
>

Not sure what you mean here. Unfortunately, result objects are still
mutable and extensible, so anything can happen.

/Andreas


On 15 February 2015 at 02:36, Andrea Giammarchi
>  wrote:
> > +1 and I've raised same concerns 2 years ago [1]
> >
> > IIRC the outcome was that VM should be good enough to handle objects with
> > very short lifecycle, I'm still convinced (behind tests) that generators
> are
> > overkill for IoT devices (low clock and way lower RAM).
> >
> > Having always same object per iteration makes sense to me at least until
> > it's done so that could be just a struct-like `{done: false, value:
> null}`
> > object and GC will be happier than ever.
> >
> > Regards
> >
> >
> > [1]
> >
> http://webreflection.blogspot.co.uk/2013/06/on-harmony-javascript-generators.html
> >
> > On Sun, Feb 15, 2015 at 10:06 AM, Katelyn Gadd  wrote:
> >>
> >> As specified, iterator .next() seems to be required to return a new
> >> object instance for each iteration.
> >>
> >> In my testing (and in my theory, as an absolute) this is a real
> >> performance defect in the spec and it will make iterators inferior to
> >> all other forms of sequence iteration, to the extent that they may end
> >> up being used very rarely, and developers will be biased away from Map
> >> and Set as a result.
> >>
> >> The issue here is that the new object requirement means that every
> >> iteration produces GC pressure. I think that past APIs with this
> >> problem (for example TypedArray.set) have proven that 'a sufficiently
> >> smart VM can optimize this' is not representative of real VMs or real
> >> use cases.
> >>
> >> In the specific case of .next(), the method returning a new object on
> >> every iteration does not produce any actual improvement to usability:
> >> There is no realistic use case that requires saving multiple next()
> >> results from the same sequence, as the sequence itself represents (at
> >> least in most cases) a container or generated value sequence that is
> >> fully reproducible on demand.
> >>
> >> I think allowing (or requiring) implementations to return the same
> >> object instance from every .next() call, or perhaps as a usability
> >> compromise, reusing a pair of objects on a round-robin basis (so that
> >> you can keep around the current and prior result) would be a very good
> >> decision here.
> >>
> >> In my testing Map and Set are outperformed by a trivial Object or
> >> Array based data structure in every case, *despite the fact* that
> >> using an Object as a Map requires the use of Object.keys() to be able
> >> to sequentially iterate elements. The cost of iterator.next() in v8
> >> and spidermonkey is currently extremely profound and profiling shows
> >> all the time is being spent in object creation and GC. (To be fair,
> >> self-hosting of iterations might improve on this some.)
> >>
> >> Oddly enough, I consider the ES iterator spec to be a big improvement
> >> over C#'s IEnumerable, in terms of usability/API. But this is an area
> >> where it is intrinsically worse performance-wise than IEnumerable and
> >> that's unfortunate.
> >>
> >> -kg
> >> ___
> >> es-discuss mailing list
> >> es-discuss@mozilla.org
> >> https://mail.mozilla.org/listinfo/es-discuss
> >
> >
> __

Re: Forged well-known symbols

[Andreas Rossberg]

On 6 February 2015 at 10:19, Jordan Harband  wrote:

> Should a JS engine retain a reference to the original value of well-known
> symbols (like Symbol.iterator), or should steps that use
> well-known-Symbol-valued properties (like for..of iteration) always do a
> dynamic lookup on that value?
>

The language never looks up any intrinsics dynamically. Given JavaScript's
unreliable library semantics, that would break left and right.


> http://jsfiddle.net/hzzo10dm/2/ is a proof of concept that demonstrates
> in Chrome 40 that by replacing Symbol.iterator with another symbol, I can
> create some weird behavior.
>
> What is specified to happen to built-in and custom iterables if I do
> `Symbol.iterator = Symbol()`?
>

This is not having the effect you think it does:

d8> var s = Symbol.iterator
undefined
d8> Symbol.iterator = Symbol("bla")
Symbol(bla)
d8> s === Symbol.iterator
true

It's just sloppy mode semantics not complaining. What you _can_ do,
however, is:

d8> Symbol = {iterator: Symbol("bla")}
{iterator: Symbol(bla)}
d8> s === Symbol.iterator
false

But that's just general JavaScript craziness. Fortunately, it still does
not change the actual iterator symbol.

/Andreas
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Maximum String length

[Andreas Rossberg]

On 28 January 2015 at 13:14, Claude Pache  wrote:

> To me, "finite" is just to be taken in the common mathematical sense of
> the term; in particular you could have theoretically a string of length
> 10^1. But yes, it would be reasonable to restrict oneself to strings of
> length at most 2^52, so that `string.length` could always return an exact
> answer.
>

To me it would be reasonable to restrict oneself to much shorter strings,
since no existing machine has the memory to represent a string of length
2^52, nor will any in the foreseeable future. ;)

VMs can always run into out-of-memory conditions. In general, there is no
way to predict those. Even strings with less then the hard-coded length
limit might cause you to go OOM. So providing reflection on a constant like
that might do little but giving a false sense of safety.

/Andreas
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Setting this to null instead of throwing ReferenceError in a derived class' constructor

[Andreas Rossberg]

On 20 January 2015 at 23:25, Brendan Eich  wrote:

> Ryosuke Niwa wrote:
>
>> Having said that, TDZ was introduced to give "let", "const", and alike a
>> sensible behavior as I understand it.  Since "this" was never defined by
>> "let" or "const", it seems a little arbitrary and inconsistent to make
>> "this" TDZ only inside a derived class's constructor.
>>
>
> It's not arbitrary as in a fair coin toss -- it's intentionally biased to
> catch errors. Using null or undefined would find fewer errors.
>
> I'm wondering whether other implementors feel the same pain. I mailed a
> few V8 folks asking them, maybe they'll weigh in.


Like with other occurrences of temporal dead zones, for the vast majority
of cases you should typically be able to tell statically (and easily) that
you don't need runtime checks.

But Dmitry is the one currently updating the implementation in V8, so he
might know more concretely.

/Andreas
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: @@toStringTag spoofing for null and undefined

[Andreas Rossberg]

On 21 January 2015 at 01:28, Mark S. Miller  wrote:

> * Pages are created by people who don't really understand the code they
> are modifying, nor the semantics of the language it is written in. They
> simply keep fiddling with it until it no longer seems to be broken, and
> then ship it. I used to have more mixed feelings about this until I
> realized that it is *precisely* how I use LaTeX.
>

On a tangent, but I find this analogy questionable. LaTeX programs are
normally supposed to have exactly one possible, fixed output, so you can
trivially do "exhaustive testing". (Unless you are writing a package, but
then you're hopefully beyond fiddling.) Not so with dynamic web pages.

/Andreas
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: @@toStringTag spoofing for null and undefined

[Andreas Rossberg]

On 20 January 2015 at 20:26, Mark S. Miller  wrote:

> On Tue, Jan 20, 2015 at 10:05 AM, Brendan Eich 
> wrote:
>
>> Domenic Denicola wrote:
>>
>>> Nominal-typing bad!
>>>
>>
>> That "X-typing bad!" line is not helpful. (What is this, a sports/beer
>> commercial?)
>>
>> Even structural typing fans such as Mark Miller have noted in their
>> research results the benefits of nominal types for certain use-cases.
>> Sometimes you need to know your implementation. This is the exception to
>> the rule, but it's not always and everywhere "bad!".
>
>
> Yes, but I would put it more positively. Nominal and Structural typing are
> about different things. Neither subsume the other. Nominal types are often
> misunderstood to be about the string-name of types or some equally
> non-generative notion of type, so I prefer to use the brand terminology.
> The classic Types are Not Sets <
> http://dl.acm.org/citation.cfm?doid=512927.512938>, IIRC, uses the term
> "trademarking" instead with the same meaning. If anyone has a link to the
> actual pdf, please post.
>

Indeed. In practice, all proper type systems combine both structural and
nominal elements. Both are needed. Many mainstream languages being overly
structurally challenged notwithstanding.

/Andreas
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: A new ES6 draft is available

[Andreas Rossberg]

On 17 January 2015 at 19:14, Allen Wirfs-Brock 
wrote:

> On Jan 17, 2015, at 9:53 AM, Domenic Denicola wrote:
> > On Jan 17, 2015, at 12:31, Allen Wirfs-Brock 
> wrote:
> >>
> >> If the enclosing function is invoked as a call expression the value of
> `new.target` is null
> >
> > Just curious, why null instead of undefined?
>
> null is used to indicate no [[Prototype]], so it seem to me to be a better
> match for this situation.
>

Wouldn't the fact that null is a quasi-legal prototype strongly speak for
using undefined here? Otherwise, it seems you couldn't distinguish Call
invocations from Construct invocations with a prototype that has actually
been set to null (which I suppose is legal?).

(In terms of proper option/maybe types, this is yet another case of a None
vs Some(None) distinction.)

/Andreas
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Figuring out the behavior of WindowProxy in the face of non-configurable properties

[Andreas Rossberg]

On 5 December 2014 at 02:19, Mark Miller  wrote:
> On Thu, Dec 4, 2014 at 4:49 PM, Boris Zbarsky  wrote:
>> On 12/4/14, 4:45 PM, Mark Miller wrote:
>>>
>>> On Thu, Dec 4, 2014 at 4:32 PM, Boris Zbarsky  wrote:

 Sure, for a scope chain.  Testcase at

 https://web.mit.edu/bzbarsky/www/testcases/windowproxy/use-old-window-1.html
>>>
>>>
>>> That page demands a client certificate. Is that intentional?
>>
>>
>> Er, sorry.
>> http://web.mit.edu/bzbarsky/www/testcases/windowproxy/use-old-window-1.html
>> should work for everyone.
>>
>> -Boris
>
> Here's an unexpected weirdness, probably not deeply related. Change
> your first helper page to
>
> 
> var someName = "OLD WINDOW";
> var evil = eval;
> function f() {
>   return someName;
> }
> function g() {
>   return (1,evil)("3");
> }
> 
>
> On FF and Safari, I get 3 as expected. On Chrome, I get on my console:
>
> Uncaught EvalError: The "this" value passed to eval must be the
> global object from which eval originated
>
> Especially weird, because this code doesn't pass any this to the
> renamed eval. I don't know what this means.

This seems to be an attempt to kill off dead window contexts as early
as possible, in order to avoid memory leaks. Toon might be able to say
more.

/Andreas
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Removal of WeakMap/WeakSet clear

[Andreas Rossberg]

On 4 December 2014 at 13:58, David Bruant  wrote:
> Le 04/12/2014 09:55, Andreas Rossberg a écrit :
>>
>> On 4 December 2014 at 00:54, David Bruant  wrote:
>>>
>>> The way I see it, data structures are a tool to efficiently query data.
>>> They
>>> don't *have* to be arbitrarily mutable anytime for this purpose.
>>> It's a point of view problem, but in my opinion, mutability is the
>>> problem,
>>> not sharing the same object. Being able to create and share structured
>>> data
>>> should not have to mean it can be modified by anyone anytime. Hence
>>> Object.freeze, hence the recent popularity of React.js.
>>
>> I agree, but that is all irrelevant regarding the question of weak
>> maps, because you cannot freeze their content.
>
> The heart of the problem is mutability and .clear is a mutability
> capability, so it's relevant. WeakMap are effectively frozen for some
> bindings if you don't have the keys.

No, they are not. Everybody can enter additional keys, for example. In
the security or abstraction related examples I'm aware of, allowing
that would actually be more disastrous than doing a clear.

>> So my question stands: What would be a plausible scenario where
>> handing a weak map to an untrusted third party is not utterly crazy to
>> start with?
>
> Sometimes you call functions you don't have written and pass arguments to
> them. WeakMaps are new, but APIs will have functions with WeakMaps as
> arguments. I don't see what's crazy. It'd be nice if I don't have to review
> all NPM packages I use to make sure they dont use .clear when I pass a
> weakmap.

Sure, I should have added "security-related" to the above sentence.

> If you don't want to pass the WeakMap directly, you have to create a new
> object "just in case" (cloning or wrapping) which carries its own obvious
> efficiency. Security then comes at the cost of performance while both could
> have been achieved if the same safe-by-default weakmap can be shared.
>
>> In particular, when can giving them the ability to clear
>> be harmful, while the ability to add random entries, or attempt to
>> remove entries at guess, is not?
>
> I don't have an answer to this case, now.
> That said, I'm uncomfortable with the idea of seeing a decision being made
> that affects the language of the web until its end based on the inability of
> a few person to find a scenario that is deemed plausible by few other
> persons within a limited timeframe. It's almost calling for an "I told you
> so" one day.
> I would return the question: can you demonstrate there are no such scenario?
>
> We know ambiant authority is a bad thing, examples are endless in JS.
> The ability to modify global variable has been the source of bugs and
> vulnerabilities.
> JSON.parse implementations were modified by browsers because they used
> malicious versions of Array as a constructor which led to data leakage.
> WeakMap.prototype.clear is ambiant authority. Admittedly, its effects are
> less broad and its malicious usage is certainly more subtle.

Sure, but WeakMap.prototype.set is no different in that regard. When
you hand out a sensitive weak map you've already lost, with or without
clear. This really seems like a phantom discussion to me (and I'm
saying that although I do care a lot about abstraction and security!).

/Andreas
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss