Re: Existential operator (was: ||= is much needed?)

On Thu, Jun 21, 2012 at 5:55 PM, Aymeric Vitte wrote: > > According to my previous posts I am quite convinced it has an interest, I > remain perplex regarding the use of ?( , then, I am really curious to see > CS's uses, could you please highlight some projects ? > Certainly. Here's a brief sampl

Re: Existential operator (was: ||= is much needed?)

I guess the grep work is not easy to do, but I have tried (manually) to find ?. or ?( in coffee script projects, trying to seek into projects of main contributors. Maybe not lucky or not really aware of the most popular projects, but I did not find any up to now. According to my previous pos

Re: Existential operator (was: ||= is much needed?)

Brendan Eich wrote: Herby Vojčík wrote: That I cannot envision... but Null Pattern object that produces itself for all operations ([[Get]], [[Call]], ...) should not be problematic. You might be surprised (I am) by how seemingly innocent things can become problematic. Just on aesthetic grou

Re: Existential operator (was: ||= is much needed?)

Herby Vojčík wrote: That I cannot envision... but Null Pattern object that produces itself for all operations ([[Get]], [[Call]], ...) should not be problematic. You might be surprised (I am) by how seemingly innocent things can become problematic. Just on aesthetic grounds, I bet TC39ers w

Re: Existential operator (was: ||= is much needed?)

Brendan Eich wrote: Herby Vojčík wrote: Adn that is precisely what I proposed under name [[NullPatternObject]]. So all of (1), (3), (4) and (5) are void. Apologies, I missed that and saw only someone (perhaps it was Domenic) write ({}) as the default value, which is not the same. Such a Ni

Re: Existential operator (was: ||= is much needed?)

Herby Vojčík wrote: Adn that is precisely what I proposed under name [[NullPatternObject]]. So all of (1), (3), (4) and (5) are void. Apologies, I missed that and saw only someone (perhaps it was Domenic) write ({}) as the default value, which is not the same. Such a Nil proxy still cannot

Re: Existential operator (was: ||= is much needed?)

Brendan Eich wrote: Replying to both Herby and Domenic here. Domenic Denicola wrote: On Jun 21, 2012, at 3:22, "Herby Vojčík" wrote: Brendan Eich wrote: Herby Vojčík wrote: I feel there is objection to introduce magical [[NullPatternObject]] into language, but all of CS-style soft-accesse

Re: Existential operator (was: ||= is much needed?)

John Tamplin wrote: On Thu, Jun 21, 2012 at 11:23 AM, Brendan Eich > wrote: John Tamplin wrote: So do you have to do it by treating the ?. operator as a standalone? Not sure what you mean here -- "standalone ?" (with an English-langauge ?

Re: Existential operator (was: ||= is much needed?)

On Thu, Jun 21, 2012 at 11:23 AM, Brendan Eich wrote: > John Tamplin wrote: > >> So do you have to do it by treating the ?. operator as a standalone? >> > Not sure what you mean here -- "standalone ?" (with an English-langauge ? > implied after in your sentence? ;-)? > > Or something else that am

Re: Existential operator (was: ||= is much needed?)

Brendan Eich wrote: Thus foo?.bar.baz.quux is really (((foo?.bar).baz).quux). So (as many have noted) parenthesization does not call GetValue in ECMA-262: 11.1.6 The Grouping Operator The production PrimaryExpression : ( Expression ) is evaluated as follows: 1. Return the result of evaluatin

Re: Existential operator (was: ||= is much needed?)

John Tamplin wrote: So do you have to do it by treating the ?. operator as a standalone? Not sure what you mean here -- "standalone ?" (with an English-langauge ? implied after in your sentence? ;-)? Or something else that amounts to a concealed Reference or Nil-value-proxy expression? Just

Re: Existential operator (was: ||= is much needed?)

So do you have to do it by treating the ?. operator as a standalone? Instead, could you do the "indefinte soak" part during parsing, treating the rest of the expression differently after having seen a ?. operator? -- John A. Tamplin Software Engineer (GWT), Google ___

Re: Existential operator (was: ||= is much needed?)

Replying to both Herby and Domenic here. Domenic Denicola wrote: On Jun 21, 2012, at 3:22, "Herby Vojčík" wrote: Brendan Eich wrote: Herby Vojčík wrote: I feel there is objection to introduce magical [[NullPatternObject]] into language, but all of CS-style soft-accesses could be solved very

Re: Existential operator (was: ||= is much needed?)

On Jun 21, 2012, at 3:22, "Herby Vojčík" wrote: > > > Brendan Eich wrote: >> Herby Vojčík wrote: >>> I feel there is objection to introduce magical [[NullPatternObject]] >>> into language, but all of CS-style soft-accesses could be solved very >>> cleanly and consistently. >> >> No, because (a

Re: Existential operator (was: ||= is much needed?)

Brendan Eich wrote: Herby Vojčík wrote: I feel there is objection to introduce magical [[NullPatternObject]] into language, but all of CS-style soft-accesses could be solved very cleanly and consistently. No, because (a) the overhead of a new object is too high; (b) with any Spec / impl ov

Re: Existential operator (was: ||= is much needed?)

Brendan Eich wrote: Herby Vojčík wrote: I feel there is objection to introduce magical [[NullPatternObject]] into language, but all of CS-style soft-accesses could be solved very cleanly and consistently. No, because (a) the overhead of a new object is too high; (b) with any kind of suffix-?

Re: Existential operator (was: ||= is much needed?)

As requested, running those rough greps again on the top ten most popular CoffeeScript repos on Github yields: 188 uses of object?.property 32 uses of object?[key] 50 uses of function?(args) 46 uses of variable ?= value ... and the other ones are a bit tricker to grep for. There are at least a

Re: Existential operator (was: ||= is much needed?)

Herby Vojčík wrote: I feel there is objection to introduce magical [[NullPatternObject]] into language, but all of CS-style soft-accesses could be solved very cleanly and consistently. No, because (a) the overhead of a new object is too high; (b) with any kind of suffix-? or suffix-.? as you

Re: Existential operator (was: ||= is much needed?)

Brendan Eich wrote: Herby Vojčík wrote: Let's allow foo.? to denote "soft foo", so you get: foo.?.bar // foo == null ? undefined : foo.bar foo.?(bar) // foo == null ? undefined : foo(bar) foo.?[bar] // foo == null ? undefined : foo[bar] ?. works as well for these and the main (by use-freque

Re: Existential operator (was: ||= is much needed?)

Because it's rare to have a maybe-method called on a maybe-object, Yes it's probably rare as I previously mentioned too, thinking about it I still can not find a single example of use, then maybe CS users can highlight this Existence looks more important than callable, the CS's way like a?.

Re: Existential operator (was: ||= is much needed?)

Herby Vojčík wrote: Let's allow foo.? to denote "soft foo", so you get: foo.?.bar// foo == null ? undefined : foo.bar foo.?(bar)// foo == null ? undefined : foo(bar) foo.?[bar]// foo == null ? undefined : foo[bar] ?. works as well for these and the main (by use-frequency, so far) f

Re: Existential operator (was: ||= is much needed?)

Brendan Eich wrote: Allen Wirfs-Brock wrote: yes, that's what I was proposing. I think calls need to be part of the overall discussion for this feature area. Jeremy is kindly grepping more codebases, but just from CoffeeScript (self-hosted) source itself, ?. is 42, ?[ is 7, and ?( is 3 -- so

Re: Existential operator (was: ||= is much needed?)

Brendan Eich wrote: This is infelicitous compared to putting ? first because it separates the ? from the maybe-nully left operand too much, and looks ugly (to Spanish readers it looks even more wrong). It's also a loss to deviate from CS, but we can't do ?( so we're half (or 1/14th by the Cof

Re: Existential operator (was: ||= is much needed?)

On Wed, Jun 20, 2012 at 12:47 PM, Allen Wirfs-Brock wrote: > yes, but in a static Java-like language such as for you example above, the > existence of person implies the existence of the getName method. The JS > equivalent would likely be something like: > Is it really rare to write JS code that

Re: Existential operator (was: ||= is much needed?)

Allen Wirfs-Brock wrote: yes, that's what I was proposing. I think calls need to be part of the overall discussion for this feature area. Jeremy is kindly grepping more codebases, but just from CoffeeScript (self-hosted) source itself, ?. is 42, ?[ is 7, and ?( is 3 -- so 12:2:1. Supports d

Re: Existential operator (was: ||= is much needed?)

Brendan Eich wrote: Let's look at what CoffeeScript requires to avoid this exception: $ cat /tmp/z.coffee person = {} person?.getName?() $ ./bin/coffee -p /tmp/z.coffee (function() { var person; person = {}; if (person != null) { if (typeof person.getName === "function") { per

Re: Existential operator (was: ||= is much needed?)

On Jun 20, 2012, at 10:45 AM, Brendan Eich wrote: > Allen Wirfs-Brock wrote: >> I was hypothesizing that Brendan's semantics would seldom be the programer's >> intent for person?.getName() . If an exception was acceptable, why wouldn't >> you just say: > > Because it's rare to have a maybe-met

Re: Existential operator (was: ||= is much needed?)

Allen Wirfs-Brock wrote: I was hypothesizing that Brendan's semantics would seldom be the programer's intent for person?.getName() . If an exception was acceptable, why wouldn't you just say: Because it's rare to have a maybe-method called on a maybe-object, based on CoffeeScript experience a

Re: Existential operator (was: ||= is much needed?)

On Jun 20, 2012, at 7:18 AM, John Tamplin wrote: > On Tue, Jun 19, 2012 at 1:34 PM, Jeremy Ashkenas wrote: > Allen asks about when you would want to write `foo?.bar()` > > ... the only use case I can think of is when `foo` may or may not be defined, > and you know that if it *is* defined, it's

Re: Existential operator (was: ||= is much needed?)

On Tue, Jun 19, 2012 at 1:34 PM, Jeremy Ashkenas wrote: > Allen asks about when you would want to write `foo?.bar()` > > ... the only use case I can think of is when `foo` may or may not be > defined, and you know that if it *is* defined, it's going to have a `bar` > method on it, and if it *is* d

Re: Existential operator (was: ||= is much needed?)

Complement for my last sentence : if you are using ?. it means that you don't know if the thing does exist, then you are probably waiting for it to exist (asynchronous environments for example), then once you get it, it is very unlikely that you call it right away, I would like to see some exam

Re: Existential operator (was: ||= is much needed?)

Indeed I did not spec this in http://wiki.ecmascript.org/doku.php?id=strawman:existential_operator#semantics -- one step at a time. Also I'm not sure how the indefinite soak will fly with others on TC39. Allen, I agree if we do make a soak and don't spec it as CoffeeScript realizes it (by tra

Re: Existential operator (was: ||= is much needed?)

Allen Wirfs-Brock wrote: On Jun 19, 2012, at 10:50 AM, Brendan Eich wrote: Another problem with your alternative: either it breaks a refactoring equivalence. Let<==> be equivalence for a program fragment, and be inequivalence. Then we have in JS today extended with do expressions (and gens

Re: Existential operator (was: ||= is much needed?)

Coffeescript seems to have some radical behavior (a.b?.c.d.e.f) a bit similar to what I suggested (which ok can not be in js) But the discussion here still does not say how much a.b?() or a.b?.call(xxx) is used in coffeescript Personnaly I was thinking that ?. should more allow to check exist

Re: Existential operator (was: ||= is much needed?)

On Jun 19, 2012, at 2:15 PM, Jeremy Ashkenas wrote: > On Tue, Jun 19, 2012 at 4:35 PM, Allen Wirfs-Brock > wrote: > > ... > > Ha ha, loose equality strikes again! It's actually guarding for both null and > undefined. It's the only place that CoffeeScript purposefully uses the > in-all-other

Re: Existential operator (was: ||= is much needed?)

On Tue, Jun 19, 2012 at 4:35 PM, Allen Wirfs-Brock wrote: > > Ah, interesting...so this is actually close to what I was advocating for > this particular case. However, if I now understand correctly you are > saying that > fun?.call() > produces undefined if fun is null/undefined but will thr

Re: Existential operator (was: ||= is much needed?)

On Jun 19, 2012, at 12:37 PM, Jeremy Ashkenas wrote: > On Tue, Jun 19, 2012 at 3:33 PM, Allen Wirfs-Brock > wrote: > > > foo.bar?(args) <==> foo.bar?.call(foo, args) > > fun?(args) <==> fun?.call(undefined, args) > > How are these equivalent? Won't fun?.call evaluate to undefined if fun

Re: Existential operator (was: ||= is much needed?)

On Tue, Jun 19, 2012 at 3:33 PM, Allen Wirfs-Brock wrote: > > > foo.bar?(args) <==> foo.bar?.call(foo, args) > > fun?(args) <==> fun?.call(undefined, args) > > How are these equivalent? Won't fun?.call evaluate to undefined if fun is > undefined and undefined(undefined,args) will throw... > >

Re: Existential operator (was: ||= is much needed?)

Is it possible to do something like foo.bar?:(foo, args) Basically a ternary that allows an empty component, and can tell the future (whether the other result is callable) ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/list

Re: Existential operator (was: ||= is much needed?)

On Jun 19, 2012, at 12:26 PM, Brendan Eich wrote: > Brendan Eich wrote: >> Worse, instead of leaking an observable ConditionalReference (whew!), you've >> opted to break the equivalence between foo.bar() and %tmp = foo.bar; >> %tmp.call(foo) for the case where . is replaced by ?. -- in this cas

Re: Existential operator (was: ||= is much needed?)

Brendan Eich wrote: Worse, instead of leaking an observable ConditionalReference (whew!), you've opted to break the equivalence between foo.bar() and %tmp = foo.bar; %tmp.call(foo) for the case where . is replaced by ?. -- in this case your proposal does not throw while the expansion does. Th

Re: Existential operator (was: ||= is much needed?)

On Jun 19, 2012, at 10:50 AM, Brendan Eich wrote: > Another problem with your alternative: either it breaks a refactoring > equivalence. > > Let <==> be equivalence for a program fragment, and be inequivalence. > Then we have in JS today extended with do expressions (and gensym via $tmp): >

Re: Existential operator (was: ||= is much needed?)

Allen Wirfs-Brock wrote: I don't agree, probably because I'm look at ?. as an operator that evaluates to a special kind of Reference. That your alternative off-by-one in its basis case is bad enough -- it creates two error suppression points from one syntactic extension-point, it will hide

Re: Existential operator (was: ||= is much needed?)

Jeremy Ashkenas wrote: On Tue, Jun 19, 2012 at 2:59 PM, Brendan Eich > wrote: Herby Vojčík wrote: Will you include options.success?.[index] then, too? I wasn't planning on it. CoffeeScript does not have any such thing (spelling it ?[ would be ha

Re: Existential operator (was: ||= is much needed?)

On Jun 19, 2012, at 10:31 AM, Brendan Eich wrote: > Brendan Eich wrote: >> Allen Wirfs-Brock wrote: >>> I still stand by my alternative semantics as being a way to address the >>> more important use case without have ?() >> No, the basis cases differ and that is a bug in your alternative. >> >>

Re: Existential operator (was: ||= is much needed?)

On Tue, Jun 19, 2012 at 2:59 PM, Brendan Eich wrote: > Herby Vojčík wrote: > >> Will you include options.success?.[index] then, too? >> > > I wasn't planning on it. CoffeeScript does not have any such thing > (spelling it ?[ would be hard in CS too, due to array literals). Could add > it in the f

Re: Existential operator (was: ||= is much needed?)

Herby Vojčík wrote: Will you include options.success?.[index] then, too? I wasn't planning on it. CoffeeScript does not have any such thing (spelling it ?[ would be hard in CS too, due to array literals). Could add it in the future, trying not to overdo the strawman at this point. YAGNI and

Re: Existential operator (was: ||= is much needed?)

That's possible but it is a bit ugly, isn't it? Also, as dherman observed, ?. and variations are different from defaulting, in one point of view. That is, avoiding dereferencing a value that does not coerce to object is the purpose of ?. but not necessarily of ??= (or || as used for defaulting

Re: Existential operator (was: ||= is much needed?)

Brendan Eich wrote: Jeremy Ashkenas wrote: Everywhere else in the language, `?` means existence (not null or undefined) -- but when used to call a function, the check ensures that the value is callable as well. In a DWIM sense, this makes sense, because the only things you'd ever want to try

RE: Existential operator (was: ||= is much needed?)

012 14:08 To: Jeremy Ashkenas Cc: es-discuss Subject: Re: Existential operator (was: ||= is much needed?) Jeremy Ashkenas wrote: > > Everywhere else in the language, `?` means existence (not null or > undefined) -- but when used to call a function, the check ensures that > the value is c

Re: Existential operator (was: ||= is much needed?)

Jeremy Ashkenas wrote: Everywhere else in the language, `?` means existence (not null or undefined) -- but when used to call a function, the check ensures that the value is callable as well. In a DWIM sense, this makes sense, because the only things you'd ever want to try to call in JavaScrip

Re: Existential operator (was: ||= is much needed?)

Brendan Eich wrote: Another problem with your alternative: either it breaks a refactoring equivalence. ... or it leaks maybe-Reference type values into the language. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listi

Re: Existential operator (was: ||= is much needed?)

Another problem with your alternative: either it breaks a refactoring equivalence. Let <==> be equivalence for a program fragment, and be inequivalence. Then we have in JS today extended with do expressions (and gensym via $tmp): foo.bar() <==> do {let $tmp = foo.bar; $tmp.call(foo)} Now

Re: Existential operator (was: ||= is much needed?)

Sorry -- an old inbox filter caused me to miss this... There were a couple of questions asked in the thread, but I think it might be helpful to summarize the overall rationale first. The existential operator in CoffeeScript (?) is intended to make it easier to ask questions about whether values e

Re: Existential operator (was: ||= is much needed?)

Brendan Eich wrote: Allen Wirfs-Brock wrote: I still stand by my alternative semantics as being a way to address the more important use case without have ?() No, the basis cases differ and that is a bug in your alternative. foo?.bar means take bar from foo or undefined if foo == null. foo?.ba

Re: Existential operator (was: ||= is much needed?)

Allen Wirfs-Brock wrote: I still stand by my alternative semantics as being a way to address the more important use case without have ?() No, the basis cases differ and that is a bug in your alternative. foo?.bar means take bar from foo or undefined if foo == null. foo?.bar() means take bar f

Re: Existential operator (was: ||= is much needed?)

David Bruant wrote: What about a more generic operator that would be able to silently absorb any error? let greedy = obj.hints?.greedy; would become: let greedy = silent obj.hints.greedy; Ignoring exact syntax, I don't think we want more general throwing suppression. The goal with

Re: Existential operator (was: ||= is much needed?)

On Jun 19, 2012, at 2:30 AM, David Bruant wrote: > What about a more generic operator that would be able to silently absorb any > error? > >let greedy = obj.hints?.greedy; > > would become: > >let greedy = silent obj.hints.greedy; A hazard with this approach is that it could silence

Re: Existential operator (was: ||= is much needed?)

Allen Wirfs-Brock wrote: On Jun 19, 2012, at 12:44 AM, Brendan Eich wrote: Allen Wirfs-Brock wrote: "This proposal augments the default operator by adding syntax to avoid accessing a missing property, specifically |?.| for

Re: Existential operator (was: ||= is much needed?)

On Jun 19, 2012, at 12:44 AM, Brendan Eich wrote: > Allen Wirfs-Brock wrote: >> "This proposal augments the default operator >> by adding >> syntax to avoid accessing a missing property, specifically |?.| for getting >> and set

Re: Existential operator (was: ||= is much needed?)

As there is no keyword as 'or' so far, does something like *x = x.value or 5 *sound better? On Tue, Jun 19, 2012 at 3:00 PM, David Bruant wrote: > What about a more generic operator that would be able to silently absorb > any error? > >let greedy = obj.hints?.greedy; > > would become: > >

Re: Existential operator (was: ||= is much needed?)

What about a more generic operator that would be able to silently absorb any error? let greedy = obj.hints?.greedy; would become: let greedy = silent obj.hints.greedy; The semantic would be exactly the same. The syntax is up to debate. Specifically, it would be nice to be able to sil

Re: Existential operator (was: ||= is much needed?)

Allen Wirfs-Brock wrote: "This proposal augments the default operator by adding syntax to avoid accessing a missing property, specifically |?.| for getting and setting a property from a reference base that might be |undefined|

Re: Existential operator (was: ||= is much needed?)

"This proposal augments the default operator by adding syntax to avoid accessing a missing property, specifically ?. for getting and setting a property from a reference base that might be undefined or null:" [1] The specified semantics of proposal actually does more than "avoid accessing a mis

Re: Existential operator (was: ||= is much needed?)

OK, ?. is enough and good Le 18/06/2012 16:48, Brendan Eich a écrit : Aymeric Vitte wrote: Why not, instead of adding "?" operator ? You mean ?. here, I assume. The answer is because what you propose is an incompatible change to ECMA-262 (all editions) and JS back to its birth, which lets p

Re: Existential operator (was: ||= is much needed?)

Aymeric Vitte wrote: Why not, instead of adding "?" operator ? You mean ?. here, I assume. The answer is because what you propose is an incompatible change to ECMA-262 (all editions) and JS back to its birth, which lets programs that throw currently continue to run, with possibly disastrous

Re: Existential operator (was: ||= is much needed?)

This is related to what I was trying to figure out in the "more fun with undefined" thread, maybe it is wrong or have too many impact but I was about to suggest : 8.9.1 GetValue (V) ... 5. If IsUnresolvableReference(V), return undefined 11.2.1 Property Accessors Runtime Semantics: Evaluation .