Re: Existential Operator / Null Propagation Operator

2017-01-03 Thread Igor Baklan
For me ``.?.`` looks more strict. With variations: ``a.?.b.?.c``, ``a.?(args)``, ``a.?[key]``. Since I would rather look on it like on something similar to [C# extension method](https://msdn.microsoft.com/en-us//library/bb383977.aspx) (or [Scala implicit method](

Re: Re: Existential Operator / Null Propagation Operator

2016-10-13 Thread Kagami Rosylight
>From a technical point of view, using ![ instead of ?.[ may work only if you >forbid a line terminator before the ! I tried this on [TS Playground](http://www.typescriptlang.org/play/#src=var%20a%20%3D%20%7B%7D%3B%0D%0A%0D%0Aa!%5B3%5D%3B%0D%0Aa%0D%0A!%5B3%5D%3B) and it interestingly changes

Re: Existential Operator / Null Propagation Operator

2016-10-13 Thread Isiah Meadows
On Thu, Oct 13, 2016, 12:07 Claude Pache wrote: Le 13 oct. 2016 à 17:14, Kagami Rosylight a écrit : >IIRC the proposed syntax for computed properties was x?.[y], Yes you’re right, sorry :/ IMO it still seems the syntax problem is the main

Re: Existential Operator / Null Propagation Operator

2016-10-13 Thread Claude Pache
> Le 13 oct. 2016 à 19:20, Bob Myers a écrit : > > Why is this needed? Why are people trying to get the property of an object > which is null? Why is the object null in the first place? This is not about trying to get something from null, but about taking different paths

Re: Existential Operator / Null Propagation Operator

2016-10-13 Thread Mark Volkmann
I think the point is that people would like to write something like this: if (person?.address?.zipcode) instead of this: if (person && person.address && person.address.zipcode) That appeals to me. On Thu, Oct 13, 2016 at 12:20 PM, Bob Myers wrote: > Why is this needed? Why are

Re: Re: Existential Operator / Null Propagation Operator

2016-10-13 Thread Kagami Rosylight
>Why is this needed? Why are people trying to get the property of an object >which is null? I will appreciate null propagation when a function receives an “option bag” ```js function someFunction(options) { if(options?.foo) { doSomething(); }; } someFunction(); someFunction({ foo: true

Re: Existential Operator / Null Propagation Operator

2016-10-13 Thread Bob Myers
Why is this needed? Why are people trying to get the property of an object which is null? Why is the object null in the first place? This can probably be considered poor program design. It's sort of like trying to dereference a null pointer. In addition, parameter defaults and defaults in

Re: Existential Operator / Null Propagation Operator

2016-10-13 Thread Claude Pache
> Le 13 oct. 2016 à 17:32, Isiah Meadows a écrit : > > It may be a good idea to create a pull request for it if it isn't listed yet > I've already tried some time ago: https://github.com/tc39/ecma262/pull/340 —Claude___

Re: Existential Operator / Null Propagation Operator

2016-10-13 Thread Claude Pache
> Le 13 oct. 2016 à 17:14, Kagami Rosylight a écrit : > > > >IIRC the proposed syntax for computed properties was x?.[y], > > Yes you’re right, sorry :/ > > IMO it still seems the syntax problem is the main reason why this proposal > has stalled. If not, what is

Re: Re: Existential Operator / Null Propagation Operator

2016-10-13 Thread Isiah Meadows
It may be a good idea to create a pull request for it if it isn't listed yet (search "null propagation JavaScript"). I know there's a proposal written out (I've seen it), I just don't recall the exact URL offhand nor if there's a champion or not, but I thought it did. It could be one of those

Re: Re: Existential Operator / Null Propagation Operator

2016-10-13 Thread Kagami Rosylight
>IIRC the proposed syntax for computed properties was x?.[y], Yes you’re right, sorry :/ IMO it still seems the syntax problem is the main reason why this proposal has stalled. If not, what is the problem here? I’m curious why this proposal is not even listed in stage 0 proposal list.

Re: Re: Existential Operator / Null Propagation Operator

2016-10-13 Thread Isiah Meadows
IIRC the proposed syntax for computed properties was `x?.[y]`, to avoid the ambiguity. On Thu, Oct 13, 2016, 10:24 Kagami Rosylight wrote: > > > >The token ?. works fine > > > > I think more than half of this thread is about syntactic ambiguity, > regardless of whether

Re: Re: Existential Operator / Null Propagation Operator

2016-10-13 Thread Kagami Rosylight
>The token ?. works fine I think more than half of this thread is about syntactic ambiguity, regardless of whether the ambiguity is real or not. For example, from [an earlier post of this thread](https://esdiscuss.org/topic/existential-operator-null-propagation-operator#content-44): >But

Re: Existential Operator / Null Propagation Operator

2016-10-13 Thread Claude Pache
> Le 13 oct. 2016 à 14:37, Kagami Rosylight a écrit : > > > Or `!.`, which unfortunately is now being used by TypeScript? What is exactly the issue you're trying to solve? The token `?.` works fine (technically with a simple lookahead for excluding digit after it).

Re: Re: Existential Operator / Null Propagation Operator

2016-10-13 Thread Isiah Meadows
TypeScript can change if it has to, and it's done so before (ES modules are a good example of this). They try their best to be a strict superset of ECMAScript, and this even goes as far as making type errors early warnings, not early errors, by default (the latter would technically be a violation

Re: Re: Existential Operator / Null Propagation Operator

2016-10-13 Thread Kagami Rosylight
Or `!.`, which unfortunately is now being used by TypeScript? ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

Re: Re: Existential Operator / Null Propagation Operator

2016-09-30 Thread Kagami Rosylight
Is the only problem here is the parser problem with `obj.prop?.2:.1`? Then how about `??. ` instead of `?.`? >Once upon a time, there was a fascinating proposal on this subject: Why are you posting twice? :/ ___ es-discuss mailing list

Re: Existential Operator / Null Propagation Operator

2016-09-16 Thread Michał Wadas
Would break the web. On Fri, Sep 16, 2016 at 1:55 AM, Ron Waldon wrote: > Once upon a time, there was a fascinating proposal on this subject: > - https://github.com/sebmarkbage/ecmascript-undefined-propagation > > Rather than introduce new syntax, Sebastian's proposal was

Re: Existential Operator / Null Propagation Operator

2016-09-15 Thread Oriol Bugzilla
I disagree with silently ignoring property access on null/undefined. > Early errors are nice Yes, exactly. Errors should fail early and loudly. That's why the strictness of strict mode is useful. > It's no weirder that `123.foo` not throwing. No, it's entirely different, because numbers

Re: Existential Operator / Null Propagation Operator

2016-09-15 Thread Ron Waldon
Once upon a time, there was a fascinating proposal on this subject: - https://github.com/sebmarkbage/ecmascript-undefined-propagation Rather than introduce new syntax, Sebastian's proposal was to automatically propagate `undefined` values: if we're about to throw a

Re: Existential Operator / Null Propagation Operator

2016-05-24 Thread Brendan Eich
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,

Re: Existential Operator / Null Propagation Operator

2016-05-21 Thread Isiah Meadows
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

Re: Existential Operator / Null Propagation Operator

2016-05-19 Thread Kevin Smith
> > 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

Re: Existential Operator / Null Propagation Operator

2016-05-19 Thread Isiah Meadows
I will note that JavaScript does already require n-token lookahead worst case to disambiguate arrow functions from sequence expressions. ```js foo((a, {b}) => b) foo((a, {b}) <= b) ``` Also, that proposal is not syntactically ambiguous, since numbers are not allowed to start an identifier. On

Re: Existential Operator / Null Propagation Operator

2016-05-19 Thread Claude Pache
> Le 19 mai 2016 à 18:46, John Lenz a écrit : > > It is a parser problem: > > obj.prop?.2:.1 > > You need arbitrary look ahead to disambiguate ?. from ?: solve the problem. No, you just need a one-character lookahead checking for a digit. The response of the original

Re: Re: Existential Operator / Null Propagation Operator

2016-05-19 Thread John Lenz
It is a parser problem: obj.prop?.2:.1 You need arbitrary look ahead to disambiguate ?. from ?: solve the problem. On Tue, May 10, 2016 at 10:32 AM, wrote: > Why isn't it possible to use the obj.property?.sub syntax in combination > with lookahead as suggested by Brendan Eich

Re: Re: Existential Operator / Null Propagation Operator

2016-05-10 Thread mads . k
Why isn't it possible to use the obj.property?.sub syntax in combination with lookahead as suggested by Brendan Eich 4 years ago? http://wiki.ecmascript.org/doku.php?id=strawman:existential_operator ___ es-discuss mailing list es-discuss@mozilla.org

Re: Existential Operator / Null Propagation Operator

2015-10-30 Thread Claude Pache
> Le 30 oct. 2015 à 11:11, Isiah Meadows a écrit : > > It's visually ambiguous. I'd rather not read `1..toString()` and `foo..bar` > in the same file. Not with greatly differing meanings. > No, `(1.).toString()` and `(1)..toString()` have strictly the same observable

Object Propagation Operator (was Re: Existential Operator / Null Propagation Operator)

2015-10-30 Thread Isiah Meadows
It's visually ambiguous, though. I really don't want to be reading `foo..bar()` and `1..toString()` in the same file. They look the same, but mean two completely different things. In a language that has this feature, I almost never use it, anyways, unless I'm interacting with the DOM. And even

Re: Object Propagation Operator (was Re: Existential Operator / Null Propagation Operator)

2015-10-30 Thread Isiah Meadows
Ignore that last email...misremembered the context. On Fri, Oct 30, 2015, 06:06 Isiah Meadows wrote: > It's visually ambiguous, though. I really don't want to be reading > `foo..bar()` and `1..toString()` in the same file. They look the same, but > mean two completely

Re: Existential Operator / Null Propagation Operator

2015-10-30 Thread Isiah Meadows
Observable effect doesn't mean same process. Granted, the case with a number literal is very obscure, anyways, so I'm not that worried about it. On Fri, Oct 30, 2015, 06:20 Claude Pache wrote: > Le 30 oct. 2015 à 11:11, Isiah Meadows a écrit : >

Re: Existential Operator / Null Propagation Operator

2015-10-30 Thread Isiah Meadows
It's visually ambiguous. I'd rather not read `1..toString()` and `foo..bar` in the same file. Not with greatly differing meanings. On Thu, Oct 29, 2015, 19:29 Claude Pache wrote: > > > > Le 30 oct. 2015 à 00:07, Waldemar Horwat a écrit : > > > >> On

Re: Re: Existential Operator / Null Propagation Operator

2015-10-29 Thread Laurentiu Macovei
This would be amazing operator!! var error = a.b.c.d; //this would fail with error if a, b or c are null or undefined. var current = a && a.b && a.b.c && a.b.c.d; // the current messy way to handle this var typeScript = a?.b?.c?.d; // The typescript way of handling the above mess with no errors

Re: Re: Existential Operator / Null Propagation Operator

2015-10-29 Thread Maël Nison
As a side note, this feature has recently been added to Ruby (issue ). They use the "foo.?bar" syntax instead of "foo?.bar" because of a grammar conflict (ruby identifiers may end with an interrogation mark). Is there something wrong with the "foo?.bar"

Re: Re: Existential Operator / Null Propagation Operator

2015-10-29 Thread Angel Java Lopez
Proposal for variable keys: a.["b"].["c"].["d"] On Thu, Oct 29, 2015 at 3:32 PM, Eli Perelman wrote: > 2 dots may be problematic when parsing numbers (yeah, I know it's probably > not common, but it's still valid): > > 3..toString() > > Eli Perelman > > On Thu, Oct 29,

Re: Re: Existential Operator / Null Propagation Operator

2015-10-29 Thread Laurentiu Macovei
`foo?.bar` and `foo?['bar']` syntax would work too. However the using both current `?` `:` operator and `?.` might be very confusing on the same line. e.g. using `?.` and `?['prop']` ```js var a = { x: { y: 1 } }; var b = condition ? a?.x.?y : a?.y?.z; var c = condition ? a?['x']?['y'] :

Re: Re: Existential Operator / Null Propagation Operator

2015-10-29 Thread Sander Deryckere
2015-10-29 19:22 GMT+01:00 Laurentiu Macovei : > This would be amazing operator!! > > var error = a.b.c.d; //this would fail with error if a, b or c are null or > undefined. > var current = a && a.b && a.b.c && a.b.c.d; // the current messy way to > handle this > var

Re: Re: Existential Operator / Null Propagation Operator

2015-10-29 Thread Eli Perelman
2 dots may be problematic when parsing numbers (yeah, I know it's probably not common, but it's still valid): 3..toString() Eli Perelman On Thu, Oct 29, 2015 at 1:29 PM, Sander Deryckere wrote: > > > 2015-10-29 19:22 GMT+01:00 Laurentiu Macovei : > >>

Re: Re: Existential Operator / Null Propagation Operator

2015-10-29 Thread Laurentiu Macovei
Yes! I have updated my answer using markdown and also posted on the original issue of TypeScript. https://github.com/Microsoft/TypeScript/issues/16 Is there a better place to propose it for `ES6`/`ES7` ? This would be amazing operator!! Especially for `ES6`/`ES7`/`TypeScript` ```js var error =

Re: Existential Operator / Null Propagation Operator

2015-10-29 Thread Waldemar Horwat
On 10/29/2015 12:19, Laurentiu Macovei wrote: `foo?.bar` and `foo?['bar']` syntax would work too. No. It would break existing code: x = foo?.3:.5; x = foo?[a]:[b]; On the other hand, turning .. into a token should be fine. Waldemar

Re: Re: Existential Operator / Null Propagation Operator (Laurentiu Macovei)

2015-10-29 Thread Laurentiu Macovei
Ron, Javascript only works by `assumptions`, that the developer made at the time the code was written than at runtime they will be the same (and not changing by newly ESX). So, it does NOT make sense to change the code that currently works (expecting to throw error) so that would silently return

Re: Existential Operator / Null Propagation Operator (Laurentiu Macovei)

2015-10-29 Thread Steve Fink
discuss@mozilla.org> list" <es-discuss@mozilla.org <mailto:es-discuss@mozilla.org>> Date: Thu, 29 Oct 2015 19:52:37 +0100 Subject: Re: Re: Existential Operator / Null Propagation Operator Yes! I have updated my answer using markdown and also posted on the original i

Re: Existential Operator / Null Propagation Operator

2015-10-29 Thread Claude Pache
> Le 29 oct. 2015 à 19:32, Eli Perelman a écrit : > > 2 dots may be problematic when parsing numbers (yeah, I know it's probably > not common, but it's still valid): > > 3..toString() > > Eli Perelman Treating `..` as one token would be a breaking change, but I don't

Re: Existential Operator / Null Propagation Operator

2015-10-29 Thread Isiah Meadows
1. `foo?.3:.5` should be unambiguously `foo ? 0.3 : 0.5`, because `3` is a number, not an identifier. `foo?.3` in any other context should be a syntax error. It's also inconsistent with array access otherwise. 2. I wouldn't have a problem with `object?.[prop]`, since that's only one character

Re: Existential Operator / Null Propagation Operator

2015-10-29 Thread Waldemar Horwat
On 10/29/2015 14:20, Claude Pache wrote: Le 29 oct. 2015 à 19:32, Eli Perelman a écrit : 2 dots may be problematic when parsing numbers (yeah, I know it's probably not common, but it's still valid): 3..toString() Eli Perelman Treating `..` as one token would be a

Re: Existential Operator / Null Propagation Operator

2015-10-29 Thread Claude Pache
>> Le 29 oct. 2015 à 21:04, Waldemar Horwat a écrit : >> >> On 10/29/2015 12:19, Laurentiu Macovei wrote: >> `foo?.bar` and `foo?['bar']` syntax would work too. > > No. It would break existing code: > > x = foo?.3:.5; That could be resolved by a simple lookahead, I

Re: Re: Existential Operator / Null Propagation Operator (Laurentiu Macovei)

2015-10-29 Thread Isiah Meadows
il.com> > To: Sander Deryckere <sander...@gmail.com> > Cc: "es-discuss@ <es-discuss@mozilla.org>mozilla.org > <es-discuss@mozilla.org> list" <es-discuss@mozilla.org> > Date: Thu, 29 Oct 2015 19:52:37 +0100 > Subject: Re: Re: Existential Operator / N

Re: Existential Operator / Null Propagation Operator

2015-10-29 Thread Claude Pache
> Le 30 oct. 2015 à 00:07, Waldemar Horwat a écrit : > >> On 10/29/2015 14:20, Claude Pache wrote: > >> In some cases – as in `3..toStrign()` –, `undefined` will be produced where >> an error was thrown. > > > No, this would continue to throw an error. Oops, you're

Re: Existential Operator / Null Propagation Operator

2015-10-29 Thread Ron Waldon
When replying, please edit your Subject line so it is more specific than "Re: Contents of es-discuss digest..." Today's Topics: 1. Re: Re: Existential Operator / Null Propagation Operator (Laurentiu Macovei) (Isiah Meadows) 2. Re: Existential Operator / Null Propagat

Re: Re: Existential Operator / Null Propagation Operator

2015-08-20 Thread 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

Re: Re: Existential Operator / Null Propagation Operator

2015-08-19 Thread Kevin Smith
What about `a!?.b` since semantically the symbol `!` has a meaning of non-nullable in JSDoc[1]. ! in this context typically means non-optional, or throw if the value is nill. See Swift for example. Or just `a!.b`? Same thing. Kevin ___

Re: Re: Existential Operator / Null Propagation Operator

2015-08-19 Thread Kevin Smith
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

Re: Re: Existential Operator / Null Propagation Operator

2015-08-19 Thread Tingan Ho
In TypeScript `?` means optional. But throw if the value is nil is the same same as non-nullable? On Wed, Aug 19, 2015 at 9:24 PM, Kevin Smith zenpars...@gmail.com wrote: What about `a!?.b` since semantically the symbol `!` has a meaning of non-nullable in JSDoc[1]. ! in this context

Re: Re: Existential Operator / Null Propagation Operator

2015-08-19 Thread Tingan Ho
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. 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

Re: Re: Existential Operator / Null Propagation Operator

2015-08-19 Thread Tingan Ho
One thing to keep in mind is that with prefix operator `?a.b` will also let people move back and forth with their caret. Since most people type the identifier first and then the operator. So they type `a` first and the move the caret in front of `a` and type `?` and then move the caret back to the

Re: Re: Existential Operator / Null Propagation Operator

2015-08-19 Thread Isiah Meadows
-1 for the `!` idea. It feels redundant to me, since if you try calling an undefined value, it'll throw errors at you. It doesn't seem to insure anything extra beyond current behavior. On Wed, Aug 19, 2015, 02:27 Tingan Ho tinga...@gmail.com wrote: One thing to keep in mind is that with prefix

Re: Re: Existential Operator / Null Propagation Operator

2015-08-19 Thread Tingan Ho
I don't see the redundancy? In my proposal the original proposed symbol `?` is switched with `!`. So it shouldn't throw any error? On Wed, Aug 19, 2015 at 4:42 PM, Isiah Meadows isiahmead...@gmail.com wrote: -1 for the `!` idea. It feels redundant to me, since if you try calling an undefined

Re: Existential Operator / Null Propagation Operator

2015-06-03 Thread Sander Deryckere
@Sam Ruby: I think we should indeed go for an extra character. In the proposals that result in `?[` and similar, it may be possible to define correctly in the spec, but it would indeed be non-obvious for humans to interprete, and potentially make the parser slower. I proposed `??` as a unique

Re: Existential Operator / Null Propagation Operator

2015-06-02 Thread Sam Ruby
On Tue, Jun 2, 2015 at 1:31 PM, Sander Deryckere sander...@gmail.com wrote: 2015-06-02 18:57 GMT+02:00 Brendan Eich bren...@mozilla.org: You might hope for that, but as we both noted, `?[` is not going to fly. Don't break the (minified) Web. Which is why my proposal was about `??`. I

Re: Existential Operator / Null Propagation Operator

2015-06-02 Thread Brendan Eich
Sam Ruby wrote: I think that the problem here isn't that it is ambiguous, it is that it isn't obvious. Fair point! Something that might be more obvious but requires an additional character: `orders.?[client.key].price`. That's not bad. The whole proposal may founder, though, on grawlix

Re: Existential Operator / Null Propagation Operator

2015-06-02 Thread Brendan Eich
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

Re: Existential Operator / Null Propagation Operator

2015-06-02 Thread Sander Deryckere
2015-06-02 17:49 GMT+02:00 Brendan Eich bren...@mozilla.org: Sander Deryckere wrote: For the prefix operator, it's unclear to me how you would do the following: Say you know `obj` is non-null, you want to test if it has a key `k1`, but if `k1` exists, you know it will also have a key `k2` a

Re: Existential Operator / Null Propagation Operator

2015-06-02 Thread Brendan Eich
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

Re: Existential Operator / Null Propagation Operator

2015-06-02 Thread 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

Re: Existential Operator / Null Propagation Operator

2015-06-02 Thread Sander Deryckere
2015-06-02 18:57 GMT+02:00 Brendan Eich bren...@mozilla.org: You might hope for that, but as we both noted, `?[` is not going to fly. Don't break the (minified) Web. Which is why my proposal was about `??`. I believe there's currently no valid way to use a double question mark in JS, so even

Re: Existential Operator / Null Propagation Operator

2015-04-24 Thread Kevin Smith
I think it's a good idea to attempt to express these ideas using existing syntax and see what that might look like. So, for a bit of fun, I wrote this: https://gist.github.com/zenparsing/9ff3036b6eb15fa436e4 Basically, there's a Maybe function which returns a proxy over a target, and returns

Re: Existential Operator / Null Propagation Operator

2015-04-08 Thread Nick Krempel
On 7 April 2015 at 18:33, Christoph Pojer christoph.po...@gmail.com wrote: it doesn't have to be a bug. It asserts that if a is not null/undefined, it must have a property b. This can be enforced through static typing. Under option 1, that's not what it does. Since it's equivalent to

Re: Existential Operator / Null Propagation Operator

2015-04-08 Thread Claude Pache
Le 7 avr. 2015 à 21:09, Herby Vojčík he...@mailbox.sk a écrit : Kevin Smith wrote: Plus, it can be used for normalizing null/undefined to undefined: var normalizedFoo = ?foo; Seems sort of nice that it is separated and there are no special operations for ?., ?(, ?[. I

Re: Existential Operator / Null Propagation Operator

2015-04-08 Thread Nick Krempel
The prefix `?` for an absorbing Nil value sounds good. The semantics of `delete` may need clarifying; what should the following construct do? `delete ?a.b.c` Most intuitive would be to not raise an error and return true if either the `b` or `c` properties are missing, whether or not in strict

Re: Existential Operator / Null Propagation Operator

2015-04-07 Thread Nick Krempel
On 7 April 2015 at 18:03, Nick Krempel ndkrem...@google.com wrote: On 6 April 2015 at 20:01, Jordan Harband ljh...@gmail.com wrote: If I want the short circuit in option 1, I'd do `a?.b?.c` to indicate that, whereas in option 2 if I don't want the short circuit, I'm forced to use separate

Re: Existential Operator / Null Propagation Operator

2015-04-07 Thread Nick Krempel
On 6 April 2015 at 20:01, Jordan Harband ljh...@gmail.com wrote: If I want the short circuit in option 1, I'd do `a?.b?.c` to indicate that, whereas in option 2 if I don't want the short circuit, I'm forced to use separate variables. Worth noting that an option 1 `a?.b?.c` differs from an

Re: Existential Operator / Null Propagation Operator

2015-04-07 Thread Nick Krempel
On 6 April 2015 at 19:33, Christoph Pojer christoph.po...@gmail.com wrote: `a?.b` = `(a == null ? void 0 : a.b)` `a?.b.c` = `(a == null ? void 0 : a.b.c)` Would it not be more generally useful if it returned a rather than void 0 in the appropriate case, that is: `a?.b` = `(a == null ? a :

Re: Existential Operator / Null Propagation Operator

2015-04-07 Thread Herby Vojčík
Kevin Smith wrote: We should perhaps review this old thread: https://esdiscuss.org/topic/fail-fast-object-destructuring-don-t-add-more-slop-to-sloppy-mode for another possible way to avoid non-compositionality. (Look for the suggestion about Nil. It's basically an exotic falsey object

Re: Existential Operator / Null Propagation Operator

2015-04-07 Thread Christoph Pojer
it doesn't have to be a bug. It asserts that if a is not null/undefined, it must have a property b. This can be enforced through static typing. On Tue, Apr 7, 2015 at 10:07 AM, Nick Krempel ndkrem...@google.com wrote: On 7 April 2015 at 18:03, Nick Krempel ndkrem...@google.com wrote: On 6

Re: Existential Operator / Null Propagation Operator

2015-04-07 Thread Brendan Eich
Christoph Pojer wrote: it doesn't have to be a bug. It asserts that if a is not null/undefined, it must have a property b. This can be enforced through static typing. What do you mean? JS does not have static typing. Even if it got it via SoundScript, the new mode would be an opt-in. The

Re: Existential Operator / Null Propagation Operator

2015-04-07 Thread Herby Vojčík
Christoph Pojer wrote: it doesn't have to be a bug. It asserts that if a is not null/undefined, it must have a property b. This can be enforced Oh, that is completely different semantics. IMNSHO, it goes against DWIM. through static typing. On Tue, Apr 7, 2015 at 10:07 AM, Nick

Re: Existential Operator / Null Propagation Operator

2015-04-07 Thread Herby Vojčík
Kevin Smith wrote: Plus, it can be used for normalizing null/undefined to undefined: var normalizedFoo = ?foo; Seems sort of nice that it is separated and there are no special operations for ?., ?(, ?[. I agree, that is nice. But how does Nil get transformed into undefined?

Re: Existential Operator / Null Propagation Operator

2015-04-07 Thread Kevin Smith
Plus, it can be used for normalizing null/undefined to undefined: var normalizedFoo = ?foo; Seems sort of nice that it is separated and there are no special operations for ?., ?(, ?[. I agree, that is nice. But how does Nil get transformed into undefined?

Re: Existential Operator / Null Propagation Operator

2015-04-07 Thread Nathan White
Am I crazy to think that Nil could allow the Existential Operator to be used in assignments as well? var a = undefined; a?.b?.c?.d = 1; console.log(a); // {b: {c: {d: 1}}} Too powerful / abusive? Day dreaming, use U+02D9 (DOT ABOVE) as the operator. a˙b˙c.d On Tue, Apr 7, 2015 at 1:09 PM,

Re: Existential Operator / Null Propagation Operator

2015-04-07 Thread Brendan Eich
Nathan White wrote: Am I crazy to think that Nil could allow the Existential Operator to be used in assignments as well? var a = undefined; a?.b?.c?.d = 1; console.log(a); // {b: {c: {d: 1}}} Too powerful / abusive? Too error-prone. E4X (ECMA-357) and languages such as Borland's

Re: Re: Existential Operator / Null Propagation Operator

2015-04-07 Thread Caitlin Potter
On Mon, Apr 6, 2015 at 5:42 PM, Brendan Eich brendan at mozilla.org https://mail.mozilla.org/listinfo/es-discuss wrote: * Did you keep backward compatibility? `x?.1:y` must continue to work. * ​This is why I suggested a leading operator (`?a.?b()`) because it seems like it would have the

Re: Existential Operator / Null Propagation Operator

2015-04-07 Thread Brendan Eich
Caitlin Potter wrote: 6, 2015 at 5:42 PM, Brendan Eichbrendan at mozilla.org https://mail.mozilla.org/listinfo/es-discuss wrote: / Did you keep backward compatibility? `x?.1:y` must continue to work. / ​This is why I suggested a leading operator (`?a.?b()`) because it seems like it would

Re: Existential Operator / Null Propagation Operator

2015-04-07 Thread Brendan Eich
Brendan Eich wrote: Caitlin Potter wrote: 6, 2015 at 5:42 PM, Brendan Eichbrendan at mozilla.org https://mail.mozilla.org/listinfo/es-discuss wrote: / Did you keep backward compatibility? `x?.1:y` must continue to work. / ​This is why I suggested a leading operator (`?a.?b()`) because

Re: Existential Operator / Null Propagation Operator

2015-04-07 Thread joe
That's a good point. Are lexical non-DFA grammars allowed? It would be trivial to solve that with a regular expression lookahead. Although I suppose at that point you might as well call it a cover grammar. Joe On Mon, Apr 6, 2015 at 2:42 PM, Brendan Eich bren...@mozilla.org wrote: joe

RE: Existential Operator / Null Propagation Operator

2015-04-07 Thread Ron Buckton
Brendan Eich wrote: Brendan Eich wrote: Caitlin Potter wrote: 6, 2015 at 5:42 PM, Brendan Eichbrendan at mozilla.org https://mail.mozilla.org/listinfo/es-discuss wrote: / Did you keep backward compatibility? `x?.1:y` must continue to work. / ​This is why I suggested a

Re: Existential Operator / Null Propagation Operator

2015-04-07 Thread Brendan Eich
Ron Buckton wrote: The reduce/reduce conflict recognizing a left sentential form '[' E ']' vs. M '?' '[' E ']' shows the fatal ambiguity. /be There is also ambiguity due to ASI vs. a ConditionalExpression: ``` obj ? [ expr ] :label ``` Ron Colon goes after label :-P. But the

Re: Existential Operator / Null Propagation Operator

2015-04-07 Thread Brendan Eich
joe wrote: That's a good point. Are lexical non-DFA grammars allowed? It would be trivial to solve that with a regular expression lookahead. Although I suppose at that point you might as well call it a cover grammar. We must avoid being too clever -- it complicates implementations and

RE: Existential Operator / Null Propagation Operator

2015-04-07 Thread Ron Buckton
@mozilla.orgmailto:es-discuss@mozilla.org Subject: Re: Existential Operator / Null Propagation Operator Ron Buckton wrote: The reduce/reduce conflict recognizing a left sentential form '[' E ']' vs. M '?' '[' E ']' shows the fatal ambiguity. /be There is also ambiguity due to ASI vs

Re: Existential Operator / Null Propagation Operator

2015-04-07 Thread joe
Okay. I've updated my transpiler to demonstrate how (and why) this could work at the VM level (I do think VM devs will have to add new opcodes for this), and I've appended an example transformation to this email. Why is this so complicationed? The answer is that when you start nesting ?.

Re: Existential Operator / Null Propagation Operator

2015-04-07 Thread Sebastian McKenzie
No, you’d just memoise it to a variable:   a?.d().f?.b to:   var _temp, _temp2;   (a != undefined ? (temp = a.d() != undefined ? (_temp2 = _temp.f != undefined ? _temp2.b : undefined) : undefined))); You’re going to need to memoise all member expressions anyway as they might be

Re: Existential Operator / Null Propagation Operator

2015-04-07 Thread joe
That looks workable. Does anyone have any more comments on '.?' versus '?.' ? Joe On Tue, Apr 7, 2015 at 7:34 PM, Sebastian McKenzie seb...@gmail.com wrote: No, you’d just memoise it to a variable: a?.d().f?.b to: var _temp, _temp2; (a != undefined ? (temp = a.d() != undefined ?

Re: Existential Operator / Null Propagation Operator

2015-04-06 Thread Kevin Smith
If we can come to an agreement on the existential operator for member expressions, we would also be setting a precedent for other features of the same family. For example, existential call expressions: `fn?()` which would conditionally invoke `fn`. In the meeting notes you linked to,

Re: Existential Operator / Null Propagation Operator

2015-04-06 Thread Jordan Harband
Wouldn't option 1 provide the transitivity you're discussing? If `a?.b.c` calls `(void 0).c` then `(a?.b).c` and `a?.b.c` would be identical, and both throw a TypeError. From my reading, it seems like option 2 is the one that does not provide transitivity, and tbh would surprise me greatly in the

Re: Existential Operator / Null Propagation Operator

2015-04-06 Thread joe
I hacked together something similar myself. IIRC, this particular transformation has issues with nested operators (e.g. a.b?.c.d?.e.f?.h). Of course that's an implementation detail, but the problem (if I'm remembering it right) is that people couldn't figure out what the implementation

Re: Existential Operator / Null Propagation Operator

2015-04-06 Thread joe
By the way, I don't remember having grammar issues (I use a LALR compiler-compiler). Looking at my code, it looked like I handled it in the tokenizer stage; I added a COND_DOT token: COND_DOT : \?\. COND_DOT then became simply another binary operator in the Expression production. However, this

Re: Existential Operator / Null Propagation Operator

2015-04-06 Thread Herby Vojčík
Christoph Pojer wrote: Tim Yung and I have hacked on a reference implementation for the Existential Operator using esprima-fb and jstransform: a?.b Example: `a?.b` = `(a == null ? void 0 : a.b)` `a?.b.c` = `(a == null ? void 0 : a.b.c)` This must also make sure that `a` only gets

Re: Existential Operator / Null Propagation Operator

2015-04-06 Thread Brendan Eich
joe wrote: By the way, I don't remember having grammar issues (I use a LALR compiler-compiler). Looking at my code, it looked like I handled it in the tokenizer stage; I added a COND_DOT token: COND_DOT : \?\. Did you keep backward compatibility? `x?.1:y` must continue to work. /be

Re: Existential Operator / Null Propagation Operator

2015-04-06 Thread Brendan Eich
Yeah, and it would line up with cover grammar needed for refutable-by-default patterns. /be Matthew Robb wrote: On Mon, Apr 6, 2015 at 5:42 PM, Brendan Eich bren...@mozilla.org mailto:bren...@mozilla.org wrote: Did you keep backward compatibility? `x?.1:y` must continue to work.

Re: Existential Operator / Null Propagation Operator

2015-04-06 Thread Brendan Eich
Implement it; user-test it; auto-check the grammar for ambiguity and other problems. /be Christoph Pojer wrote: So I take it most would prefer this as a prefix operator. What would be the next steps involved to iterate on this idea? On Mon, Apr 6, 2015 at 3:35 PM, Brendan

RE: Existential Operator / Null Propagation Operator

2015-04-06 Thread Ron Buckton
, April 6, 2015 3:35 PM To: Matthew Robb Cc: es-discuss Subject: Re: Existential Operator / Null Propagation Operator Yeah, and it would line up with cover grammar needed for refutable-by-default patterns. /be Matthew Robb wrote: On Mon, Apr 6, 2015 at 5:42 PM, Brendan Eich bren...@mozilla.org

  1   2   >