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 <m...@heyimmark.com> 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 <kaizhu...@gmail.com> wrote:
>
>> On Jul 27, 2017, at 5:43 PM, Andreas Rossberg <rossb...@google.com>
>> 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 <m...@heyimmark.com> 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 <rossb...@google.com>
> wrote:
>
>> On 27 July 2017 at 11:00, Mark <m...@heyimmark.com> 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 <mikesam...@gmail.com> wrote:

> On Wed, Jul 26, 2017 at 5:55 AM, Andreas Rossberg <rossb...@google.com>
> 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 <brendan.e...@gmail.com> 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 <rossb...@google.com>
> 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 <wildfict...@gmail.com> 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 <rossb...@google.com>
> wrote:
>
>> On 21 June 2017 at 18:40, Bradley Meck <bradley.m...@gmail.com> 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 <e...@qfox.nl> 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 <rossb...@google.com>
> wrote:
> > On 24 May 2017 at 08:57, Gareth Heyes <gareth.he...@portswigger.net>
> 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: 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 <j...@trusktr.io> 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 <rossb...@google.com>
> 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 <j...@trusktr.io> 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 <bzbar...@mit.edu> 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

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 <concavel...@gmail.com> 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 <rossb...@google.com>
> wrote:
>
>>
>>
>> On 19 February 2016 at 10:29, Andreas Rossberg <rossb...@google.com>
>> wrote:
>>
>>> On 19 February 2016 at 06:29, John Lenz <concavel...@gmail.com> 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 <rossb...@google.com> wrote:

> On 19 February 2016 at 06:29, John Lenz <concavel...@gmail.com> 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 18:20, Jonathan Bond-Caron
<jbo...@gdesolutions.com> 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 19:25, Jordan Harband <ljh...@gmail.com> 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
> <jbo...@gdesolutions.com> 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 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 03:50, Brendan Eich <bren...@mozilla.org> wrote:

> Andreas Rossberg wrote:
>
>> On 3 September 2015 at 01:58, Brendan Eich <bren...@mozilla.org > 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 20:57, Brendan Eich <bren...@mozilla.org> wrote:

> Andreas Rossberg wrote:
>
>> On 3 September 2015 at 03:50, Brendan Eich <bren...@mozilla.org > 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 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 tinga...@gmail.com 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 zenpars...@gmail.com 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 https://twitter.com/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 impinb...@gmail.com wrote:

 Damnit...forgot to fix the subject.

 On Wed, Aug 5, 2015 at 3:20 AM, Isiah Meadows impinb...@gmail.com 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/TypeScript/issues/186 (particularly the
 sum type implementation). I also created a little toy Option/Maybe
 implementation https://gist.github.com/impinball/4833dc420b60ad0aca73
 using pattern matching to ease `null`/`undefined` handling.

 And also, check out my gist
 https://gist.github.com/impinball/62ac17d8fa9a20b4d73d for a proposed
 `Symbol.pattern` prolyfill for the primitive types. That would allow for
 things like this:

 ```js
 switch (list) in {
   case Array([a, b, c]): return doSomething(a, b, c)
   case Map({a, b, c}): return doSomethingElse(a, b, c)
   default: return addressBadType(list)
 }
 ```

  -- Forwarded message --
  From: Andreas Rossberg rossb...@google.com
  To: Samuel Hapák samuel.ha...@vacuumapps.com
  Cc: es-discuss es-discuss@mozilla.org
  Date: Tue, 4 Aug 2015 14:26:45 +0200
  Subject: Re: Extensible destructuring proposal
  On 31 July 2015 at 20:09, Samuel Hapák samuel.ha...@vacuumapps.com
 wrote:
 
  So, do you still have objections against this proposal? Could we

Re: Extensible destructuring proposal

[Andreas Rossberg]

On 31 July 2015 at 20:09, Samuel Hapák samuel.ha...@vacuumapps.com 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 erig...@google.com 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 d...@domenic.me wrote:

  Well,  the spec says they are ordered, so I'm not sure where you're
 getting that from.


  *From:* Bergi a.d.be...@web.de
 *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 samuel.ha...@vacuumapps.com 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 erig...@google.com 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 r...@gol.com 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]

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 impinb...@gmail.com wrote:

 I was reading a recent thread
 https://esdiscuss.org/topic/allow-try-catch-blocks-to-return-a-value 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: 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 erig...@google.com 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 impinb...@gmail.com
 wrote:

 I was reading a recent thread
 https://esdiscuss.org/topic/allow-try-catch-blocks-to-return-a-value 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) { throw e });




 // Do-while statement
 let i = 0;
 do {
   foo(i)
 } while (i++  10);

 // Combined:
 let i = 0;
 let foo9 = do do {
   

Re: for statement with index and value

[Andreas Rossberg]

On 14 July 2015 at 15:41, Jonathan Bond-Caron jbo...@gdesolutions.com
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=1805context=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 matthewwr...@gmail.com 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 rossb...@google.com
 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 erig...@google.com 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 impinb...@gmail.com
 wrote:

 I was reading a recent thread
 https://esdiscuss.org/topic/allow-try-catch-blocks-to-return-a-value 
 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

Re: Generalize do-expressions to statements in general?

[Andreas Rossberg]

On 14 July 2015 at 16:48, Mark S. Miller erig...@google.com wrote:

 On Tue, Jul 14, 2015 at 2:31 AM, Andreas Rossberg rossb...@google.com
 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 erig...@google.com 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

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 nbdd0...@hotmail.com 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 d...@domenic.me 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 benjami...@gmail.com 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 15:39, Jonathan Bond-Caron jbo...@gdesolutions.com
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: May 2015 Meeting Notes

[Andreas Rossberg]

On 30 June 2015 at 16:26, Jonathan Bond-Caron jbo...@gdesolutions.com
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: revive let blocks

[Andreas Rossberg]

On 26 June 2015 at 04:08, Kevin Smith zenpars...@gmail.com 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 bren...@secure.meer.net 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: Move es-discuss to discuss.webplatform.org?

[Andreas Rossberg]

On 19 June 2015 at 23:04, Axel Rauschmayer a...@rauschma.de 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: function.sent beta equivalence?

[Andreas Rossberg]

On 24 June 2015 at 22:56, Jason Orendorff jason.orendo...@gmail.com 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: 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 a...@weej.com 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 al...@wirfs-brock.com
 wrote:


 On Jun 18, 2015, at 12:18 PM, Andreas Rossberg wrote:

 On 18 June 2015 at 19:26, Benjamin Gruenbaum benjami...@gmail.com
 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 benjami...@gmail.com 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 bren...@mozilla.org wrote:

 Sander Deryckere wrote:

 2015-06-02 17:49 GMT+02:00 Brendan Eich bren...@mozilla.org mailto:
 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: 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 e...@rotenberg.io wrote:

 Wow, thanks. I feel dumb for asking :D

 On Wed, Apr 29, 2015 at 1:43 PM, Sebastian McKenzie seb...@gmail.com
 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 e...@rotenberg.io
 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: is an iterator allowed to reuse the same state object?

[Andreas Rossberg]

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.

/Andreas


On Tue, Apr 28, 2015 at 4:28 PM, Allen Wirfs-Brock al...@wirfs-brock.com
 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 al...@wirfs-brock.com
 wrote:


 On Apr 27, 2015, at 3:29 PM, Tab Atkins Jr. wrote:

 On Mon, Apr 27, 2015 at 3:11 PM, John Lenz concavel...@gmail.com
 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: is an iterator allowed to reuse the same state object?

[Andreas Rossberg]

On 29 April 2015 at 18:37, Brendan Eich bren...@mozilla.org wrote:

 Andreas Rossberg wrote:

 On 29 April 2015 at 02:21, John Lenz concavel...@gmail.com mailto:
 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: Should const be favored over let?

[Andreas Rossberg]

On 17 April 2015 at 14:17, Mathias Bynens mathi...@opera.com wrote:

 On Fri, Apr 17, 2015 at 7:53 AM, Glen Huang curvedm...@gmail.com 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: do while scope

[Andreas Rossberg]

On 17 April 2015 at 17:18, Glen Huang curvedm...@gmail.com 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 caitpotte...@gmail.com
 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 curvedm...@gmail.com 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: Putting `global` reference in specs

[Andreas Rossberg]

On 17 April 2015 at 17:27, Mark S. Miller erig...@google.com 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 ann...@annevk.nl
 wrote:

 On Fri, Apr 17, 2015 at 5:12 PM, Andrea Giammarchi
 andrea.giammar...@gmail.com 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: forward-incompatible Function.prototype.toString requirement

[Andreas Rossberg]

On 16 April 2015 at 11:34, Michael Ficarra mfica...@shapesecurity.com
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 d...@domenic.me 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

Re: forward-incompatible Function.prototype.toString requirement

[Andreas Rossberg]

On 16 April 2015 at 14:34, Frankie Bagnardi f.bagna...@gmail.com 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 rossb...@google.com
 wrote:

 On 16 April 2015 at 11:34, Michael Ficarra mfica...@shapesecurity.com
 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

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 bren...@mozilla.org 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 jason.orendo...@gmail.com 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 15:22, Andri Möll an...@dot.ee 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: Object.assign and inherited properties

[Andreas Rossberg]

On 27 February 2015 at 16:16, Andri Möll an...@dot.ee 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: How would we copy... Anything?

[Andreas Rossberg]

On 23 February 2015 at 10:37, David Bruant bruan...@gmail.com 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: short-circuiting Array.prototype.reduce

[Andreas Rossberg]

On 23 February 2015 at 16:22, Mark S. Miller erig...@google.com 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:

  reducePartialA, B(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 leeby...@fb.com
 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: Performance of iterator .next() as specified

[Andreas Rossberg]

On 15 February 2015 at 12:07, Katelyn Gadd k...@luminance.org 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
 andrea.giammar...@gmail.com 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 k...@luminance.org 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
 
 
 ___
 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: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 rossb...@google.com
 wrote:

 On 15 February 2015 at 12:07, Katelyn Gadd k...@luminance.org 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
 andrea.giammar...@gmail.com 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 k...@luminance.org
 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

Re: Forged well-known symbols

[Andreas Rossberg]

On 6 February 2015 at 10:19, Jordan Harband ljh...@gmail.com 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 claude.pa...@gmail.com 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: @@toStringTag spoofing for null and undefined

[Andreas Rossberg]

On 21 January 2015 at 01:28, Mark S. Miller erig...@google.com 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 erig...@google.com wrote:

 On Tue, Jan 20, 2015 at 10:05 AM, Brendan Eich bren...@mozilla.org
 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: Setting this to null instead of throwing ReferenceError in a derived class' constructor

[Andreas Rossberg]

On 20 January 2015 at 23:25, Brendan Eich bren...@mozilla.org 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: Removal of WeakMap/WeakSet clear

[Andreas Rossberg]

On 4 December 2014 at 00:54, David Bruant bruan...@gmail.com 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.

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

/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 bruan...@gmail.com wrote:
 Le 04/12/2014 09:55, Andreas Rossberg a écrit :

 On 4 December 2014 at 00:54, David Bruant bruan...@gmail.com 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

Re: Removal of WeakMap/WeakSet clear

[Andreas Rossberg]

On 2 December 2014 at 19:15, Mark S. Miller erig...@google.com wrote:
 In both minor or major collection both m and v are immediately
 reclaimed, because neither is strongly reachable at that point

 which shows the asymmetry, and that v8 is effectively optimizing for
 the wrong side of that asymmetry. By adopting what Allen and I refer
 to as the transposed representation (as opposed to your transposed
 representation), you'd instead be able to say of the common scenario

 In both minor or major collection both k and v are immediately
 reclaimed, because neither is strongly reachable at that point

 which would be much more valuable than any other efficiency issue
 discussed in this thread.

What I'm saying is that this is a theoretical conclusion at which you
arrive only under various simplifying and idealistic assumptions (such
as life time being the only factor that matters). I maintain that
there is no evidence yet that this actually translates to better
overall performance in practice, and I have severe doubts that it
would. I don’t want to reiterate the concerns that I already raised in
an earlier thread, but the executive summary is:

Good performance absolutely wants an object layout that is stable and
compact. The transposed weak map implementation pretty much is an
antithesis to that. It hence induces a potential cost on all key
objects (and all their uses throughout a program) instead of just the
maps. That is a case of optimising for the wrong thing as well.

(Back to the actual topic of this thread, you still owe me a reply
regarding why .clear is bad for security. ;) )

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

Re: Scoping of non-strict direct evals in parameter expressions

[Andreas Rossberg]

On 3 December 2014 at 23:09, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
 See https://bugs.ecmascript.org/show_bug.cgi?id=3383

 The issue concerns things like this:

 don't use strict;
 var x=outer
 function f(a=eval( var x=1;  42),
  x=eval( console.log(can+(x!=1?'t:)+ see earlier
 eval binding}; 84)
  ) {
  console.log(x); // ? outer , 1, or  84?
 }
 f();

 In other words, for non-strict functions,  in what scope does should a
 direct eval that occurs in a parameter list expression context create its
 declarations.  Remember that formal parameters  have their own scope contour
 that is separate from the body scope (and the environment for the body scope
 doesn't even exist during parameter expression evaluation.  Also remember
 that legacy non-strict direct evals within functions create vars (and
 functions) in the variable scope of the function (which is the same as the
 body scope).

 I propose, that for scoping purposes, we treat such evals (parameter
 expression + non-strict + direct) as if they were strict evals. That means
 that all declarations created by the eval code are created in a new
 environment record that is discarded when the eval completes. Basically, it
 means that evals in parameter expression can't create bindings that are
 visible outside of the eval.

 Also, note that I'm not proposing that strict mode rules such as banning
 'with' be applied to the body of the eval.  I'm just talking about the
 declaration scoping rules.  This introduces a sort of micro-mode but the
 alternatives see less desirable.  They are 1) figure out a semantics of
 declarations injected into the function from parameter list evals; 2) force
 parameter list direct evals into full trict mode.  The first is hard,
 complex, and probably pointless; the second is still a sort of micro-mode,
 seems less aligned with the likely user intent, and I think will actually be
 harder to specify.

 Thoughts?

Sounds good to me. FWIW, I wouldn't consider this a micro-mode. It's
just scoping: every default expression simply executes in a new
(declaration) scope. You don't even need to change the rules for eval
itself, it can be specified completely independent of what the
expression is. If you model it that way, then it automatically extends
to future do-expression as well (which might also be abused to create
'var's in default expressions).

/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 1 December 2014 at 03:12, Mark S. Miller erig...@google.com wrote:
 On Sun, Nov 30, 2014 at 12:21 PM, Boris Zbarsky bzbar...@mit.edu wrote:
 Per spec ES6, it seems to me like attempting to define a non-configurable
 property on a WindowProxy should throw and getting a property descriptor for
 a non-configurable property that got defined on the Window (e.g. via var)
 should report it as configurable.

Can you clarify? Do you mean that it should report properties as
configurable, but still reject attempts to actually reconfigure them?
Also, how would you allow 'var' to even define non-configurable
properties? If you want DefineProperty to throw on any such attempt,
then 'var' semantics would somehow have to bypass the MOP.

 From prior similar experiences, the way to get this fixed quickly is
 to add test262 tests which fail on these violations. All browsers have
 been much quicker to fix breakage that shows up in test262 results
 than to mere bug reports.

Well, let's find a workable semantics first. :)

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