oh gosh, I've stopped at the title. I guess I'll just move on then ^_^ On Wed, Sep 20, 2017 at 11:14 AM, Isiah Meadows <[email protected]> wrote:
> This is starting to seem eerily familiar... (especially the idea of "let" > expressions) > > Take a look at this thread from a couple years ago, and you'll see what I > mean. > > https://esdiscuss.org/topic/the-tragedy-of-the-common- > lisp-or-why-large-languages-explode-was-revive-let-blocks > > On Wed, Sep 20, 2017, 05:08 Andrea Giammarchi <[email protected]> > wrote: > >> gotta admit an `if (let y = fn())` would be a very nice feature to have. >> Only the `for(...)` lets us declare block variables, the `let` expression >> would solve/simplify this case and many others. >> >> ```js >> const newFoo = (let x = getSomething()) ? >> (doSomethingFirst(), x.doSomething()) : >> doSomethingElse(); >> ``` >> >> On Wed, Sep 20, 2017 at 10:41 AM, Isiah Meadows <[email protected]> >> wrote: >> >>> I'll just note that the only two languages I know of with a feature like >>> this is Haskell with its `maybe fn orElse m`* function in `Data.Maybe` and >>> Scala's `Option[T].mapOrElse(fn, orElse)`. Here's what many other languages >>> do: >>> >>> Several languages use some form of `if let`, including Rust, Scala, and >>> Swift: >>> >>> ```swift >>> // In Swift >>> let newFoo >>> if let x = getSomething() { >>> doSomethingFirst() >>> newFoo = x.doSomething() >>> } else { >>> newFoo = doSomethingElse() >>> } >>> ``` >>> >>> Clojure offers the macro `(if-let)`, which does mostly the same thing >>> (Common Lisp has a similar macro): >>> >>> ```clj >>> ;; Top-level declaration >>> (def new-foo >>> (if-let x (get-something) >>> (do >>> (do-something-first) >>> (do-something x)) >>> :else (do-something-else))) >>> ``` >>> >>> OCaml uses pattern matching, and C/C++, most of its derivatives (like >>> Python), and Kotlin just do `if (x != NULL) ... else ...` or similar. >>> (Kotlin has flow-sensitive typing like TypeScript, which helps avoid >>> mistakes.) >>> >>> * I might have gotten the argument order wrong - I'm not a regular >>> Haskell user, and it's not commonly used. >>> >>> On Tue, Sep 19, 2017, 09:36 Michael Rosefield <[email protected]> >>> wrote: >>> >>>> We still have to explicitly create a variable (x), either in the do >>>> block or before that ternary, and the bracket-enclosed comma-separated >>>> expressions are... not to my taste. >>>> >>>> This was always about syntactic sugar and concision, as there are >>>> always other ways to go about it; as I commented in my reddit post, both >>>> operators can be done functionally: >>>> >>>> const $equivFn = (cond, ifTruthy, otherwise) => cond ? ifTruthy(cond) : >>>> otherwise(), >>>> foo = $equivFn(getSomething(), x => doSomething(x), () => >>>> doSomething()), >>>> equivFoo = getSomething() ?! x => doSomething(x) : doSomethingElse(); >>>> >>>> // normal ternary >>>> const $ternary = (cond, ifTruthy, otherwise) => cond ? ifTruthy() : >>>> otherwise(), >>>> foo = $ternary(checkSomething(), () => doSomething(), () => >>>> doSomething()), >>>> equivFoo = checkSomething() ? doSomething() : doSomethingElse(); >>>> >>>> >>>> ... but it's not elegant. >>>> >>>> And I appreciate ?! was a bad choice, but can easily be substituted by >>>> anything else. >>>> >>>> On Tue, 19 Sep 2017 at 14:06 Andrea Giammarchi < >>>> [email protected]> wrote: >>>> >>>>> I don't think `do` is "much longer" than your last example, however, >>>>> it can be shorter >>>>> >>>>> ```js >>>>> const newFoo = do { >>>>> let x = getSomething(); >>>>> x ? >>>>> (doSomethingFirst(), x.doSomething()) : >>>>> doSomethingElse(); >>>>> }; >>>>> >>>>> On Tue, Sep 19, 2017 at 3:00 PM, Sebastian Malton < >>>>> [email protected]> wrote: >>>>> >>>>>> I don't think that talking about the syntax is relevant now since it >>>>>> is not important when talking about the reasonability of a suggestion. >>>>>> Saying that the syntax could be `?|` >>>>>> >>>>>> The `do` is much longer than the example. >>>>>> >>>>>> I think that this a reasonable idea. >>>>>> >>>>>> *From:* [email protected] >>>>>> *Sent:* September 19, 2017 8:57 AM >>>>>> *To:* [email protected]; [email protected] >>>>>> *Subject:* Re: Proposal: result-forwarding ternary operator >>>>>> >>>>>> Few issues: >>>>>> >>>>>> 1. This is already technically valid code: `cond?!fn:orElse` is >>>>>> equivalent to `cond ? !fn : orElse` >>>>>> 2. Have you considered `do` expressions (stage 1 proposal)? They work >>>>>> a lot like IIFEs, but allow easy definition of computed constants. >>>>>> 3. Have you considered using in-condition assignment or just >>>>>> factoring out the computed condition into a separate variable? >>>>>> Sometimes, a >>>>>> little verbosity helps. >>>>>> >>>>>> Using `do` expressions, your second code sample would look like this: >>>>>> >>>>>> ```js >>>>>> const newFoo = do { >>>>>> let x = getSomething(); >>>>>> if (x) { >>>>>> doSomethingFirst(); >>>>>> x.doSomething(); >>>>>> } else { >>>>>> doSomethingElse(); >>>>>> } >>>>>> }; >>>>>> ``` >>>>>> >>>>>> On Tue, Sep 19, 2017, 08:33 Michael Rosefield <[email protected]> >>>>>> wrote: >>>>>> >>>>>>> (I've also put this on reddit >>>>>>> <https://www.reddit.com/r/javascript/comments/7129tn/proposal_resultforwarding_ternary_operator/>, >>>>>>> which I've copied this from. Hope the formatting doesn't go haywire...) >>>>>>> >>>>>>> First course of action for this proposal is, obviously, to >>>>>>> come up with a better name for it.... >>>>>>> >>>>>>> >>>>>>> Motivation >>>>>>> >>>>>>> As with the 'optional chaining' proposal for tc39 >>>>>>> <https://github.com/tc39/proposal-optional-chaining>, this operator >>>>>>> is a way to avoid excess and annoying code from safety-checking. >>>>>>> >>>>>>> The optional chaining proposal, above, follows a chain and >>>>>>> short-circuits it upon acting on a null object, returning a safe ' >>>>>>> *undefined*' result; it can be thought of as an extended '*if*' >>>>>>> sequence. It looks like this: >>>>>>> >>>>>>> // safeVal = result of someProp, or undefined if looking for props on >>>>>>> null obj >>>>>>> const safeVal = blah?.someMethod()?.someProp; >>>>>>> >>>>>>> This proposal provides for an '*else'* scenario, particularly in >>>>>>> situations where chaining isn't appropriate, by forwarding the result >>>>>>> of a >>>>>>> truthy conditional check to a single-parameter function. >>>>>>> >>>>>>> >>>>>>> Syntax >>>>>>> >>>>>>> *condition ?! fn : expr* >>>>>>> >>>>>>> Parameters >>>>>>> >>>>>>> - condition: any condition, *identical to use in standard >>>>>>> ternary* >>>>>>> - fn: function taking single parameter, which is the result of >>>>>>> evaluating *condition* >>>>>>> - expr: any expression, *identical to use in standard ternary* >>>>>>> >>>>>>> >>>>>>> Usage Example >>>>>>> >>>>>>> // temporary variable >>>>>>> const temp = getSomething(), >>>>>>> foo = temp ? doSomething(temp) : doSomethingElse(); >>>>>>> >>>>>>> // repeated code, possible side-effects >>>>>>> const foo2 = getSomething() ? doSomething(getSomething()) : >>>>>>> doSomethingElse(); >>>>>>> >>>>>>> // proposal, no chaining >>>>>>> const newFoo = getSomething() ?! x => doSomething(x) : >>>>>>> doSomethingElse(); >>>>>>> >>>>>>> // proposal, chaining >>>>>>> const newFoo = getSomething() ?! >>>>>>> x => { >>>>>>> doSomethingFirst(); >>>>>>> return x.doSomething(); >>>>>>> } : >>>>>>> doSomethingElse(); >>>>>>> >>>>>>> >>>>>>> Notes >>>>>>> >>>>>>> - >>>>>>> >>>>>>> The choice of '?!' is entirely arbitrary and not a core part of >>>>>>> the proposal. >>>>>>> - >>>>>>> >>>>>>> The result of the conditional check is not passed on to the >>>>>>> falsey path, because it seems pointless to do so. >>>>>>> >>>>>>> _______________________________________________ >>>>>>> es-discuss mailing list >>>>>>> [email protected] >>>>>>> https://mail.mozilla.org/listinfo/es-discuss >>>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> es-discuss mailing list >>>>>> [email protected] >>>>>> https://mail.mozilla.org/listinfo/es-discuss >>>>>> >>>>>> >>>>> _______________________________________________ >>>>> es-discuss mailing list >>>>> [email protected] >>>>> https://mail.mozilla.org/listinfo/es-discuss >>>>> >>>> _______________________________________________ >>>> es-discuss mailing list >>>> [email protected] >>>> https://mail.mozilla.org/listinfo/es-discuss >>>> >>> >>
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
