Re: ECMA-262: ElementList : ... AssignmentExpression? Wtf?
Expression is .comma expression so can't be used without fatal ambiguity: is [a,,b] [(a,b)] or [(a), (b)]? It's the latter by using AssignmentExpression. If it were PrimaryExpression, ever expression using a binary operator would need to be parenthesized. Is the "Dragon Book" still in print? Recommended. /be On Sun, Oct 29, 2017 at 5:49 AM Uncloud Group wrote: > The first example was meant to be [ a, b ]. Sorry. > ___ > 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
On Wed, Jul 26, 2017 at 11:59 AM Michał Wadas wrote: > I know that's hard to remove features from the web. That's why I propose > *clear > and well defined *route to clean up language. > Instead of asserting in bold, why not answer the questions I posed in reply to your clear but incomplete proposal? Suppose TC39 said "with" was going away in 2027. Who among content owners, developers they hire sporadically, or browser users visiting their sites would do anything, and why would they do it? If a browser in 2027 ships without "with" support ahead of other major browsers, what happens to its support costs and market share? > Browsers already "broke" the web many times. Java Applets are dead. > ActiveX is dead (though some government websites still require it). Flash > will be dead in few years. And some sites stopped working because of this. > You are citing proprietary plugins. The Web of which JS is a part is defined by open standards from Ecma, WHATWG, W3C, IETF. We survived plugins dying (and good riddance, in general; credit to Flash for filling gaps and still doing things the standard Web cannot do well -- this is to the shame of the Web, no argument). Ok, so proprietary or not, plugins died and that has costs. But they are borne by sites who dropped those plugins, one by one. They are not imposed (at least not till Brave, or now with the plan to kill Flash by 2020 among Adobe and the big four browsers) from the client side. Again, the browser-market game theory does not work. Please respond to this clear and well-defined point :-P. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: FW: Removal of language features
Languages have warts, not just JS. No cleanup is perfect, and more warts come over time. If your point is merely about a "language you hate" but must perforce use on the Web, I think you should be happy right now. The solution is not to hate JS. It's not going to change incompatibly. Rather, you can use linters, "transpilers", compilers, voluntary unchecked subsets -- all possible today. If you then object to having to use a tool or a subsetting discipline, I'm not sure what to say. The `with` statement is not forcing you to use it. Avoid it! If you are concerned with the "painting into the corner" problem for engine implementors, the big ones are all in the room here and they can cope. If you are concerned about JS pedagogy or marketing, the solution already practiced is to subset. Just as when teaching English or another evolved, irregularity-ridden living language. /be On Wed, Jul 26, 2017 at 3:06 PM Florian Bösch wrote: > On Wed, Jul 26, 2017 at 11:41 PM, Brendan Eich > wrote: >> >> Those languages forked and some modernized (I remember Fortran 77). Those >> are all quite a bit older than JS. I would also suggest they are for the >> most part stunning successes. We've learned a lot from them. >> > > Yes, but we'll also want people to *want* to use a language. Not just use > it because eons ago something has been written in them and now there is no > way out. JS has to keep pace or it will end up like those languages, some > relic from the past that nobody uses if they can possibly avoid it. I don't > think the mission brief of JS can be "The best language you hate using but > can't avoid using anyway." > ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: FW: Removal of language features
On Wed, Jul 26, 2017 at 12:14 PM Florian Bösch wrote:
> On Wed, Jul 26, 2017 at 9:00 PM, T.J. Crowder <
> tj.crow...@farsightsoftware.com> wrote:
>>
>> keeping it alive and healthy beyond its browser-limited existence.
>>
>
> Many languages (including Python and Perl) concluded that at some point
> things have to be "cleaned up".
>
You have not addressed my points about the difficulty of removing things on
the Web. Citing Perl and Python implies you want opt-in versioning, which I
had proposed for ES4 back in the day. before I wised up ;-). A couple of
points:
1. Perl 5 vs. 6 and Python 2 vs. 3 are not great precedents. I think they
are counterexamples even given the ability with Unix command line tools to
be installed and used on single systems or in cloud settings without the
huge coordination problem posed by the Web. Perl and Python have forked,
and split their communities between versions. The Python rift may heal, but
these forks have real and high costs. I know, we use Python at Brave in our
build system.
2. Opt-in versioning on the Web is an anti-pattern, as discussed at length
on es-discuss. The better way, dubbed 1JS, is to let old forms fall into
disuse while carefully extending the language with new syntax and semantics
that compose well with the existing surface language, using a kernel
semantics approach. This is still TC39's settled conviction as best foot
forward.
The track record of languages that never cleaned up isn't... great. You
> could consider things like RPG, Cobol, Fortran, etc. "alive" because
> they're still used. But in any other sense of the word they aren't.
>
Those languages forked and some modernized (I remember Fortran 77). Those
are all quite a bit older than JS. I would also suggest they are for the
most part stunning successes. We've learned a lot from them.
But the point of order here is whether JS can even be forked as Perl and
Python have been. Another point to discuss is what you mean by "isn't...
great." Aesthetics aside, keeping compatibility maximizes utility. There is
risk of "painting into a corner", making conflicts in the kernel semantics
or surface language over time, or just making a kitchen sink language.
These are not _malum in se_ but costs to be traded off for benefits.
If the aesthetic or Platonic ideal approach prevails, almost any successful
language is not "alive" because it is messy. But that's false: C is still
alive, C++ is quite alive, etc. I suggest being precise about costs vs.
benefits and avoiding vague or counterfactual metaphorical judgments
("isn't... great", not "alive").
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: FW: Removal of language features
1. There's no evidence (I'm sitting in a TC39 meeting) other than grumping from a few that we are near the point of JS painted into a corner by backward compatibility. 2. WebAssembly is happening. Dynamic language support will take a while. Together these suggest JS evolution will continue. It shall continue. /be On Wed, Jul 26, 2017 at 11:37 AM Florian Bösch wrote: > On Tue, Jul 25, 2017 at 11:50 PM, Brendan Eich > wrote: >> >> Core language changes are different in kind from sync touch events. It's >> very hard to plan to remove anything on a practical schedule or >> order-of-work basis. Engine maintainers likely still hate more modes, and >> users should too. New syntax as its own opt-in still wins, although this >> obligates TC39 to work on future-proofing, e.g., : after declarator name in >> declaration for type annotation syntax. >> > > There's a point at which you cannot add anything new meaningful because of > the broken things. And you can't remove the broken things because you're > committed to eternal backwards compatibility. And you can't add modes > because nobody likes them. That's just planned obsolescence. This means JS > is not a living language, or won't be much longer in any case. It's > probably best if whatever you run on the web ships its own interpreter that > runs on whatever flavor runtime (JS, asm.js or Web Assembly) is available. > ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Re: FW: Removal of language features
Strict mode also made runtime-incompatible changes, e.g. arguments[i] not aliasing i'th formal parameter, which required two-way testing while strict mode adoption was nascent or partial (which of course many devs skipped). On Wed, Jul 26, 2017 at 9:53 AM Andreas Rossberg wrote: > 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. > Agreed (static analysis approximates runtime, so the ability to do it is of course not binary -- many trade-offs). >From my memory of the meetings and online discussions, strict mode was not meant to make static analysis significantly easier. More important was enabling Caja (now SES) to "use strict" and do less work, static and at runtime. Implementation and legacy loopholes continue to confound such efforts :-). /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Re: FW: Removal of language features
One thing that may not be obvious: On Wed, Jul 26, 2017 at 8:52 AM Brendan Eich wrote: > I created JS in 1995. In 1996 I made a few incompatible changes to JS and > got away with it, but not in 1997. ES3 was done in 1999 based on de-facto > work in Netscape and IE that converged (mostly; a few edge cases) around > the same time, but even by 1998 the only way to coordinate was via the > ECMA-262 standards work, not just ES1 but the discussions about future work > we were having in 1997. > Netscape had effective monopoly control of JS in 1995 and into 1996, but was losing it by 1997 with IE4 coming out. No browser has it now, although Chrome has the most market power. Even monopolies cannot repeal price law -- they can only force deadweight losses on customers up to a limit where the customer does without, or else substitutes by going outside the monopoly system. With JS, there was risk at the limit of users going without JS. There was risk too, small at first but growing to large, of users substituting IE and even using VBScript instead of JS. Fortunately ;-), JS was first and good-enough, and standardized enough, to head off the VBScript substitution. So I couldn't just change JS any way I wanted based on market power. Nor can Chrome now, or in a future where it got closer to IE's top (2004?) share of 95% (per wikipedia). /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Re: FW: Removal of language features
On Wed, Jul 26, 2017 at 4:44 AM Michał Wadas wrote: > Simple idea: > >- Add new Annex to language. >- Define operation EmitDeprecationWarning(code) - implementations MAY >show deprecation warning in implementation dependent way (it can depend on >runtime flag, dev tools, not minified code, etc.); otherwise operation >EmitDeprecationWarning is noop > > Who sees the warnings? Publishers hire contractors to build (re-build) site in year N, in year N+M when contractors are long gone, users visit site and get unseen warnings in their unopened devtools. What upper bound can be put on M? > >- Define when implementations SHOULD emit deprecations warnings - like >using with statement, non-standard Reg-Exp properties, compile method, >assign to arguments, getYear etc. > > Who sees the warnings? Not the contractors, they are long gone by year N+1. > >- Language features can be removed after 10 (15?) years > > So M=10 might work (who knows?) but it's so long a time frame that no one will act on the remote threat of breakage. And yet at Y=N+M, there will be sites (not just web.archive.org) using the old feature, I would bet real money. We know this because from looking back at when the Web was smaller and easier to coordinate. Your model seems to assume a small-world-network coordination system. That's not the Web. I created JS in 1995. In 1996 I made a few incompatible changes to JS and got away with it, but not in 1997. ES3 was done in 1999 based on de-facto work in Netscape and IE that converged (mostly; a few edge cases) around the same time, but even by 1998 the only way to coordinate was via the ECMA-262 standards work, not just ES1 but the discussions about future work we were having in 1997. This kind of TC39 coordination helps for sure, don't get me wrong. But it does not solve the publisher/contractor division of labor leaving M effectively unbounded. For a language like Java or C# used server side, where the retrograde sites can stick to old tool/runtime versions as long as vendors support them, M can be a "Goldilocks" interval, not too big, not too small. The threat of vendors obsoleting old versions pushes most customers to upgrade in time, and the customers of size can push back and keep support going an extra year or three if need be. But that's not the Web. On the web, you don't just have the publishers and contractors, you have browser users also not coordinated except possibly by loose rules about supported browsers (banks try this and still get it wrong). Most sites do not want to turn away users based on detailed user agent version checks. Suppose TC39 said "with" was going away in 2027. Who among content owners, developers they hire sporadically, or browser users visiting their sites would do anything, and why would they do it? If a browser in 2027 ships without "with" support ahead of other major browsers, what happens to its support costs and market share? I hope this helps. It's very hard to remove things on the Web. That's the nature of the beast. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Re: FW: Removal of language features
Hi Andreas, is this the best link to the Strong Mode post-mortem? https://groups.google.com/d/msg/strengthen-js/ojj3TDxbHpQ/5ENNAiUzEgAJ /be On Wed, Jul 26, 2017 at 2:56 AM Andreas Rossberg wrote: > As for the reoccurring assumption that deprecation would help simplifying > JavaScript implementations: no, not to a relevant degree. 80+% of the > complexity in a JS VM comes from the plethora of (sometimes ridiculous) > edge cases in the core semantics of JavaScript, its object model, implicit > conversions, etc., and the desire to make all that fast in the common case > without breaking correctness of the million special cases. None of that can > be deprecated without creating a completely new language. > > And clearly, modes or versions only make things worse in that regard. > Strict mode already is a pig when it comes to implementation complexity (in > retrospect, it does not carry its weight IMHO). ES6 made it worse. Our > experiments with strong mode a while ago increased complexity even further, > so much that the urge to rip it out again overtook very quickly. I for one > am eternally healed of modes. > ___ > es-discuss mailing list > es-discuss@mozilla.org > https://mail.mozilla.org/listinfo/es-discuss > ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: FW: Removal of language features
This thread makes me want to unsubscribe from es-discuss. I think I recreated the list. :-( Please read https://esdiscuss.org/topic/no-more-modes and https://esdiscuss.org/topic/use-es6-any-plans-for-such-a-mode#content-2. "Don't break the web" is not some vague high-minded notion of TC39's. It's a consequence of hard-to-change browser-market game theory. No browser wants to risk (however small the risk) breaking what might be more of the web than one thinks at first. It's very hard to find out what "the web" is and prove absence of breakage (paywalls, firewalls, archives, intranets, etc.). There's very little gain and potentially much pain, which could mean support calls and market share loss. This is not just a browser market failure. Developers don't want their code broken, until they stop using something and then ask for it to be removed. That is not globally coordinated so it won't fly, as browser market share depends in part on developer testing and use of browsers. Ecosystem effects mitigate against breaking the web in deep ways, _in general_. Yet ECMA-262 has broken compatibility in a few edge cases. And browser competition led to some dead limbs and underspecified pain-points (e.g., global object prototype chain). And Google people seem to be leading the Web Intervention Community Group, which wants to break the web a bit (rather than block 3rd party ad/tracking scripts :-P). So perhaps we can break some DOM APIs such as sync touch events, without also breaking gmail :-). The jury is still out in my view, but Chrome has enough market power to push and assume more risk than other browsers. Core language changes are different in kind from sync touch events. It's very hard to plan to remove anything on a practical schedule or order-of-work basis. Engine maintainers likely still hate more modes, and users should too. New syntax as its own opt-in still wins, although this obligates TC39 to work on future-proofing, e.g., : after declarator name in declaration for type annotation syntax. So based on 22+ years doing JS, I believe anything like opt-in versioning for ES4, a la Python3 or Perl6, is a non-starter. Period, end of story. Ok, I'm not unsubscribing -- but I hope more people read and search https://esdiscuss.org/ and engage with history instead of coming as if to a blank slate. Santayana's dictum applies. /be On Tue, Jul 25, 2017 at 2:10 PM Alexander Craggs wrote: > I think version interoperability is a must in a world of Webpack & > Browserify. > > On 25/07/2017 21:12:58, doodad-js Admin wrote: > >- How are you going to deal with scenarios that don't have extensions, >e.g. REPL or inline JS. > > > > For inline, that’ll be: > > > > ... > > > > For REPL, I don’t know... I didn’t think about this one :-) It should be > based of the content of the page. And I don’t know if we should allow to > mix different versions together. That’s things we’ll have to clarify. > > > >- Are extensions going to be released often, or is this going to be a >one time thing? > > > > Just at another new major revision of JS, which should not happen before a > long time. > > > >- would it make more sense to start on js7 instead of js2 > > > > No, because ES6, ES7, ... are still JS 1. > > > > > > *From:* Alexander Craggs [mailto:alexan...@debenclipper.com] > *Sent:* Tuesday, July 25, 2017 3:54 PM > *To:* doodad-js Admin ; es-discuss@mozilla.org > *Subject:* Re: FW: Removal of language features > > > > I'm sorry, I missed that suggestion. > > > > That definitely sounds significantly better than a new MIME type. > Although two thoughts I have are: > > > > - How are you going to deal with scenarios that don't have extensions, > e.g. REPL or inline JS. > > > > - Are extensions going to be released often, or is this going to be a one > time thing? For example, would we increment the version number with the > current JS version (js6, js7 etc) and if so, would it make more sense to > start on js7 instead of js2? > > ___ > 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: Existential Operator / Null Propagation Operator
You need to be very careful hacking around in an ad-hoc parser. It's easy to diverge from the formal (and verified) grammar by accident. Ambiguous grammars with ad-hoc disambiguation rules codified only by your parser's source code are bad business. Voice of experience here. /be On Sat, May 21, 2016 at 3:57 PM Isiah Meadows wrote: > I'm aware it's specified as a cover grammar, which is the easiest way I'm > aware of to do it in a traditional declarative grammar. If you're writing a > parser, though, you'll probably be using a mixture of lookahead and > speculative parsing, or something to that effect, in practice, since it's > faster. > > On Thu, May 19, 2016, 16:38 Kevin Smith wrote: > >> I will note that JavaScript does already require n-token lookahead worst >>> case to disambiguate arrow functions from sequence expressions. >>> >> The syntax is actually specified in terms of cover grammars, not >> arbitrary lookahead. >> >> ___ > 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: monadic extension to do-notation
We'll get it on the next TC39 meeting's agenda.
/be
On Mon, Feb 22, 2016 at 5:28 PM Alan Johnson wrote:
> If this is done, please go with `async do { … await … }`. May as well
> reuse existing syntax as much as possible. As mentioned, `<-` is
> problematic both from the standpoint of conflict with existing operators
> and incomplete analogy with Haskell. If the result should be Promise-ified,
> best to indicate this explicitly with `async`.
>
> I do think that having a syntax for async expressions is very useful.
> IIFEs already feels like a hack around the lack of expression-orientedness
> of control flow structures in JS, and async-IIFEs just compound the issue
> of syntactic noise for straightforward operations.
> ___
> 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: monadic extension to do-notation
And draft ES6 tried for monadic, but compatibility with Promises libraries
(more than "convenience") prevailed.
/be
On Sun, Feb 7, 2016 at 11:35 AM Raphael Mu wrote:
> In theory it's possible, but Promise.resolve automatically joins Promises
> for the sake of ergonomics.
>
> On Sun, Feb 7, 2016 at 1:15 PM Jordan Harband wrote:
>
>> How is Promise an instance of Monad, if you can't ever have a Promise of
>> a Promise?
>>
>> On Sun, Feb 7, 2016 at 9:59 AM, Raphael Mu
>> wrote:
>>
>>> The `a < -b` issue could be solved by using a different operator, like
>>> `>>
>>> On Sun, Feb 7, 2016 at 12:35 PM Kevin Smith
>>> wrote:
>>>
Why not just use await within `async do`?
On 12:19PM, Sun, Feb 7, 2016 Rick Waldron
wrote:
> What does this do?
>
>
> let finalPromise = do {
> let a;
> a <- b;
> }
>
>
> Currently, that's an expression that means "a less than negated b"
>
> Rick
>
> On Sun, Feb 7, 2016 at 12:07 PM Raphael Mu
> wrote:
>
>> The ES Promise is an instance of Monad, a property that implies a
>> much more concise and expressive syntax for using Promise, by exploiting
>> its monadic properties. I've seen a lot of people complain about Promises
>> having too clumsy a syntax, and likewise for async/await.
>>
>> We now have the do-notation proposal (
>> http://wiki.ecmascript.org/doku.php?id=strawman:do_expressions), and
>> monadic assignment would fit well into the syntax.
>>
>> The extension would allow use of `<-` within a do-expression for
>> binding Promise values to variables, and the computation would behave
>> most
>> similarly to the Either monad in Haskell (in the following code, if
>> promiseA or promiseB reject, the result of the entire expression would
>> be a
>> rejected Promise).
>>
>> (monadic extension)
>> ```javascript
>> let finalPromise = do {
>> let a <- promiseA;
>> let b <- promiseB;
>> let c = f(a, b);
>> g(a, b, c)
>> }
>> ```
>>
>> (desugared to async/await)
>> ```javascript
>> let finalPromise = (async () => {
>> let a = await promiseA;
>> let b = await promiseB;
>> let c = f(a, b);
>> return g(a, b, c);
>> })();
>> ```
>>
>> (desugared to ES6)
>> ```javascript
>> let finalPromise = promiseA.then(a =>
>> promiseB.then(b => {
>> let c = f(a, b);
>> return g(a, b, c);
>> })
>> );
>> ```
>>
>> The do-notation would apply Promise.resolve to the last expression
>> (like async and Promise#then), effectively returning another Promise. The
>> current proposal doesn't specify this behavior, but there are two ways
>> about this collision:
>>
>> 1. use an explicit version of do-notation, e.g. `async do { ... }` or
>> `do* { ... }`
>> 2. revise the do-notation proposal to always apply Promise.resolve to
>> the last expression
>>
>> Both choices give us a new Promise literal for free: `do* { x }` (1)
>> or `do { x }` (2) would be functionally equivalent to
>> `Promise.resolve(x)`.
>>
>> The idea was briefly mentioned several years ago, but didn't attract
>> much attention (
>> https://mail.mozilla.org/pipermail/es-discuss/2012-March/021624.html
>> ).
>>
>> This is an earlier draft of this proposal:
>> https://github.com/edge/es-monadic
>> ___
>> 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
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: monadic extension to do-notation
+1 to experience report from nodent, and +many to futures or eventual
values. We've discussed before in terms of value types, value proxies,
"become". See, e.g.
https://twitter.com/brendaneich/status/585858406742786048
Also: Monadic for sure. Too late for promises. Sometimes you end up taking
two steps.
/be
On Sun, Feb 7, 2016 at 10:19 AM Mat At Bread wrote:
> The conflation of assignment and awaiting is a bad idea. It leads to lots
> of unnecessary temporary variables and makes anything but the simplest
> expression involving more than one await/promise very ugly - akin to the
> original syntax you're trying to avoid with inner variable declarations and
> <- operations.
>
> A very similar syntax was used by nodent until v1 when it was replaced
> with async and await.
>
> I'd be much more interested in a VM extension that performed auto
> boxing/unboxing on Promises, achieving a similar result without the need
> for additional syntactic constructions
>
> > --
> > monadic extension to do-notation
> > From: Raphael Mu
> > Date: 7 Feb, 17:07
> > To: es-discuss@mozilla.org
>
>
> >
> > The ES Promise is an instance of Monad, a property that implies a much
> more
> > concise and expressive syntax for using Promise, by exploiting its
> monadic
> > properties. I've seen a lot of people complain about Promises having too
> > clumsy a syntax, and likewise for async/await.
> >
> > We now have the do-notation proposal (
> > http://wiki.ecmascript.org/doku.php?id=strawman:do_expressions), and
> > monadic assignment would fit well into the syntax.
> >
> > The extension would allow use of `<-` within a do-expression for binding
> > Promise values to variables, and the computation would behave most
> > similarly to the Either monad in Haskell (in the following code, if
> > promiseA or promiseB reject, the result of the entire expression would
> be a
> > rejected Promise).
> >
> > (monadic extension)
> > ```javascript
> > let finalPromise = do {
> > let a <- promiseA;
> > let b <- promiseB;
> > let c = f(a, b);
> > g(a, b, c)
> > }
> > ```
> >
> > (desugared to async/await)
> > ```javascript
> > let finalPromise = (async () => {
> > let a = await promiseA;
> > let b = await promiseB;
> > let c = f(a, b);
> > return g(a, b, c);
> > })();
> > ```
> >
> > (desugared to ES6)
> > ```javascript
> > let finalPromise = promiseA.then(a =>
> > promiseB.then(b => {
> > let c = f(a, b);
> > return g(a, b, c);
> > })
> > );
> > ```
> >
> > The do-notation would apply Promise.resolve to the last expression (like
> > async and Promise#then), effectively returning another Promise. The
> current
> > proposal doesn't specify this behavior, but there are two ways about this
> > collision:
> >
> > 1. use an explicit version of do-notation, e.g. `async do { ... }` or
> `do*
> > { ... }`
> > 2. revise the do-notation proposal to always apply Promise.resolve to the
> > last expression
> >
> > Both choices give us a new Promise literal for free: `do* { x }` (1) or
> `do
> > { x }` (2) would be functionally equivalent to `Promise.resolve(x)`.
> >
> > The idea was briefly mentioned several years ago, but didn't attract much
> > attention (
> > https://mail.mozilla.org/pipermail/es-discuss/2012-March/021624.html).
> >
> > This is an earlier draft of this proposal:
> > https://github.com/edge/es-monadic
> >
> >
> >
>
> > --
> > Re: monadic extension to do-notation
> > From: Rick Waldron
> > Date: 7 Feb, 17:19
> > To: Raphael Mu , es-discuss@mozilla.org
>
>
> >
> > What does this do?
> >
> >
> > let finalPromise = do {
> > let a;
> > a <- b;
> > }
> >
> >
> > Currently, that's an expression that means "a less than negated b"
> >
> > Rick
> >
> > On Sun, Feb 7, 2016 at 12:07 PM Raphael Mu
> wrote:
> >
> >> The ES Promise is an instance of Monad, a property that implies a much
> >> more concise and expressive syntax for using Promise, by exploiting its
> >> monadic properties. I've seen a lot of people complain about Promises
> >> having too clumsy a syntax, and likewise for async/await.
> >>
> >> We now have the do-notation proposal (
> >> http://wiki.ecmascript.org/doku.php?id=strawman:do_expressions), and
> >> monadic assignment would fit well into the syntax.
> >>
> >> The extension would allow use of `<-` within a do-expression for binding
> >> Promise values to variables, and the computation would behave most
> >> similarly to the Either monad in Haskell (in the following code, if
> >> promiseA or promiseB reject, the result of the entire expression would
> be a
> >> rejected Promise).
> >>
> >> (monadic extension)
> >> ```javascript
> >> let finalPromise = do {
> >> let a <- promiseA;
> >> let b <- promiseB;
> >> let c = f(a, b);
> >> g(a, b, c)
> >> }
> >> ```
> >>
> >> (desugared to async/await)
> >> ```javascript
> >> let finalPromise = (async () => {
> >> let a = await promiseA;
> >> let b = await promiseB;
> >> let c = f(a, b);
> >>
Re: Paren-free heads strawman
Did you read the proposal?
http://wiki.ecmascript.org/doku.php?id=strawman:paren_free
Yes, it means if you start a condition with '(' you are obligated to use
paren-full not paren-free style. :-P
/be
On Mon, Feb 1, 2016 at 10:20 AM Andreas Rossberg
wrote:
> 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
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
Re: Paren-free heads strawman
Braces required, see the old strawman. /be On Mon, Feb 1, 2016 at 9:18 AM Andreas Rossberg wrote: > 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 > ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Class member encapsulation
C++ has static inheritance and typing. this->A::x is 1 after B's
constructor delegates to A's constructor, and this->B::x (a different
field) is 2 once that field has been set in B::B.
JS has (not yet, anyway) no field declarations, no namespacing akin to A::x
and B::x, and so only one this.x to mutate among the super and subclass
when constructing a new instance of b.
JS ain't C++, no one has ever accused it of that (or me of "making it into
C++", lol).
/be
On Sun, Jan 3, 2016 at 3:08 PM monolithed wrote:
> C++:
>
> ```c++
> #include
>
> class A {
> public:
> A () {
> this->x = 1;
> }
>
> int call () {
> return this->x;
> }
>
> int x;
> };
>
> class B : public A {
> public:
> B() : A () {
> this->x = 2;
> }
>
> int x;
> };
>
>
> int main () {
> B b;
>
> std::cout << b.call(); // 1
> return 0;
> }
> ```
>
> JavaScript:
>
> ```js
> class A {
>constructor () {
> this.x = 1;
>}
>
>call () {
> return this.x;
>}
> }
>
>
> class B extends A {
>constructor () {
> super();
> this.x = 2;
>}
> }
>
>
> let b = new B();
>
> b.call(); // 2
> ```
>
>
> ~~Why we have different behavior?!~~
> I know that ECMAScript classes are syntactical sugar, but this behavior is
> unexpected for many people...
> ___
> 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: HTML-like comment behavior inconsistent
Apologies for formatting problems -- I blame the Google Inbox web app. One typo fix, hope it's obvious already: On Sat, Jan 2, 2016 at 2:28 PM Brendan Eich wrote: > Thanks, Claude. > > It may be tempting to assume the standard specified something dumb, or due > to "legacy" mysteries. Not so. HTML5 fully specifies
Re: HTML-like comment behavior inconsistent
Thanks, Claude. It may be tempting to assume the standard specified something dumb, or due to "legacy" mysteries. Not so. HTML5 fully specifies , which I created in 1995 at Netscape. I had no time for the src= attribute, and even if I had (I implemented that in 1996 for Netscape 3), but basis case was code directly in the HTML page, as I noted on twitter: https://twitter.com/BrendanEich/status/683344089308200960. kdex, think about how < is interpreted within an inline