Re: Improved syntax for observable mapping and subscribing

[Isiah Meadows]

I've already looked into this kind of thing myself privately. I came
up with this last year [1], and I more recently came up with this [2]
(the second is much better IMHO). Both of those offer solutions to
this problem, and they do in fact offer ways for 1. iteration, and 2.
mapping/filtering/etc.

[1]: https://github.com/isiahmeadows/non-linear-proposal
[2]: https://github.com/isiahmeadows/lifted-pipeline-strawman
-

Isiah Meadows
m...@isiahmeadows.com

Looking for web consulting? Or a new website?
Send me an email and we can get started.
www.isiahmeadows.com


On Fri, Mar 23, 2018 at 11:06 AM, Thomas Grainger  wrote:
> You can convert an observable into an async iterator. You have to choose
> between discarding or buffering uniterated items
>
> On 23 Mar 2018 14:39, "Bob Myers"  wrote:
>>
>> Could someone jog my memory about proposals for better syntax for
>> observable mapping and subscribing, if any?
>>
>> I'm getting really tired of writing
>>
>> ```
>> foo$.pipe(map(bar => mapper(bar)))
>> ```
>>
>> I would much prefer to write something along the lines of
>>
>> ```
>> stream function fooMapper(foo$) {
>>   while async (const bar = foo$()) {
>> emit mapper(bar);
>>   }
>> }
>> ```
>>
>> Yes, I'm aware of all the potential issues here and this is just an
>> example, not an actual syntax proposal. I'm just wondering about any prior
>> art.
>>
>> Bob
>>
>>
>> ___
>> 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: Operator for Currying

[Isiah Meadows]

I do agree with much of your sentiment. I do have a few points inline, though:

-

Isiah Meadows
m...@isiahmeadows.com

Looking for web consulting? Or a new website?
Send me an email and we can get started.
www.isiahmeadows.com


On Thu, Mar 22, 2018 at 6:43 PM, Tab Atkins Jr.  wrote:
> While I love currying in many languages, I have some reservations
> about it being generally useful enough in JS to be worth adding syntax
> for.

Understandable, and my biggest reason for *not* is because it doesn't
mix well with function declarations.

>
> 1. Currying isn't friendly with variadic functions (that is, optional
> arguments) - you can't tell when the function has consumed "enough"
> arguments to finally resolve itself unless you predefine the arity.

The typical method of handling this *is* to predefine the arity
somehow, either via argument or checking `func.length`. In fact, most
of Ramda's variadic functions have their length set to something
useful (usually 1 or 2), and most other functional libraries do
similar.

> 2. Currying isn't friendly with JS's style of named arguments (passing
> an option bag) - no clue how to solve this even with workarounds?

OCaml has named arguments, both required and optional. They are really
the only way you can pass "optional" arguments in the usual sense, and
they don't support currying. You can still "partially apply" them by
using an anonymous function (OCaml doesn't have any way of partial
application).

>
> Partial application, whether via a dedicated syntax or as part of the
> smart-mix pipeline syntax, gives you *most* of the benefits of
> currying while solving these issues: 1, the partially-evaluated
> function will fully evaluate as soon as you call it, with whatever
> arguments you've given it (unless you explicitly partially-evaluate
> again); 2, with object-rest, you can spread a later options object
> into your partially-filled in options object, and then pass that to
> the underlying function.
>
> ```
> // variadic example with pipeline function
> const threeOrMore = +> Math.max(3, ...);
> // and you can partially-eval again to fill in more options without 
> "finishing":
> const moreLimitations = +> threeOrMore(newLimit, ...);`
>
> // option-bag example with arrow function
> const someOptions = (arg, moreOpts) => optUsingFunction(arg, 1, 2,
> {foo: bar, ...moreOpts});
> // or with pipeline function:
> const someOptions = +> optUsingFunction(#, 1, 2, {foo:bar, ...##});
> ```

I agree that for most cases, it's better to use partial application
instead of currying. To be quite honest, I feel automatic currying to
be an easy code maintenance footgun. Clojure has no native support for
it, OCaml idiomatically rarely uses it (short of the `|>` operator),
and even Haskell users try to limit it to high-context situations
where the currying just removes noise (they often call
point-free/tacit style "pointless").

>
> ~TJ
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Allow Object Destructoring when assigning

[Isiah Meadows]

Oops...I misinterpreted the original email. :-)

As for forcing reinterpretation, I stand by my suggestion in an earlier reply:

> It's not easy to parse for similar reasons async arrow functions are a
> bitch to parse, but it appears possible (it'd force a shift instead of
> a reduce, and it'd reinterpret the RHS unambiguously as a pattern)
> with a `[no LineTerminator here]` before the `=` token.

-

Isiah Meadows
m...@isiahmeadows.com

Looking for web consulting? Or a new website?
Send me an email and we can get started.
www.isiahmeadows.com


On Thu, Mar 22, 2018 at 5:49 PM, Claude Pache  wrote:
>
>
> Le 22 mars 2018 à 20:51, Sebastian Malton  a écrit :
>
> Currently object destructoring is only allowed during variable declaration,
> however it would be useful, and seems rather odd from a usage standpoint,
> that it cannot be done during assignment.
>
> Example:
> This is a allowed:
> ```
> const { a } = b;
> ```
>
> But this is not:
> ```
> let a;
>
> if (...) {
> { a } = b.c;
> }
> ```
>
> Sebastian Malton
>
>
> This is already allowed, but you have to use some artefact in order to force
> the parser not to interpret`{` as the beginning of a block:
>
> ```
> let a ;
> ({ a } = b);
> ```
>
> —Claude
>
>
> ___
> 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: Add "???" Unimplemented

[dante federici]

Simple example (ts):
```typescript
interface SearchFunc {
(source: string, subString: string): boolean;
}

// Later
let mySearch: SearchFunc;
mySearch = function(source: string, subString: string) {  ??? }
```

Simple example (js):
```js
class MyClass = {
  foo() { return "foo"; }
  bar() { return "bar"; }
}
class ExtendClass extends MyClass {
foo(){ ??? }
bar(){ return `extended bar`; }
}

// Elsewhere
myRunner = (classInstance) => `${classInstance.foo()} ::
${classInstance.bar()}`;

myRunner(myClassInstance);
myRunner(extendedClassInstance);
```

Decorations would be good for classes, but don't work for regular methods.

I'm not sold we need new syntax for this -- I just find myself reaching for
the `???` symbol. Especially in a typed language or in any instance that we
have a class and extended paradigm, or when you have a prescribed "object"
shape.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Improved syntax for observable mapping and subscribing

[Thomas Grainger]

You can convert an observable into an async iterator. You have to choose
between discarding or buffering uniterated items

On 23 Mar 2018 14:39, "Bob Myers"  wrote:

> Could someone jog my memory about proposals for better syntax for
> observable mapping and subscribing, if any?
>
> I'm getting really tired of writing
>
> ```
> foo$.pipe(map(bar => mapper(bar)))
> ```
>
> I would much prefer to write something along the lines of
>
> ```
> stream function fooMapper(foo$) {
>   while async (const bar = foo$()) {
> emit mapper(bar);
>   }
> }
> ```
>
> Yes, I'm aware of all the potential issues here and this is just an
> example, not an actual syntax proposal. I'm just wondering about any prior
> art.
>
> Bob
>
>
> ___
> 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

Improved syntax for observable mapping and subscribing

[Bob Myers]

Could someone jog my memory about proposals for better syntax for
observable mapping and subscribing, if any?

I'm getting really tired of writing

```
foo$.pipe(map(bar => mapper(bar)))
```

I would much prefer to write something along the lines of

```
stream function fooMapper(foo$) {
  while async (const bar = foo$()) {
emit mapper(bar);
  }
}
```

Yes, I'm aware of all the potential issues here and this is just an
example, not an actual syntax proposal. I'm just wondering about any prior
art.

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

Re: Proposal: if variable initialization

[Rodrigo]

@Naveen, I think it's best to avoid this road altogether and keep
initialization clean, even though assignment isn't.

The proposal is that given `for(;;)` hence `if(;)` instead of given
`x=y` hence `let x=y`.

But yes, `if( x = 5)` is already allowed, but it's confusing and hard to read.

Confusing on what is being compared on multiple statements: `if((const
x = 5, y = 10) > 0)`

Confusing when destructuring, on what's being compared: `if(let [x,y] = [1,2])`

Confusing when multiple statements: `if ((x = 10, y = 20) > 15)`

Looks like an error: `if( x = 5 )` versus `if( x == 5)`, did the
programmer forget the `=`?

And if you introduce nesting initializations everywhere outside the
`if`, that's basically an invitation for readability nightmare. `let`
and `const` anywhere introduce 2 conflicting best-practices:

- Rule 1: declare your variables that are used exclusively within `if`
blocks within the `if` parens

- Rule 2: don't declare variables within another statement (so that
people will refrain from doing `foo( let x=10 )`

Consider that, historically, other languages such as Perl allowed `if(
(my $x = 1) > 0)` and `foo( my $x = 100)` and became the ugly child of
power programming; whereas Golang, born much later, has limited
initializations to things such as `if( x:=1; x > 0)` and has kept
things quite minimalistic (and clear for the programmer).

```perl
# realworld example, hard to find variable declaration:

$redis->subscribe( 'queue', my $callback = sub {
...
});
```


On Fri, Mar 23, 2018 at 7:21 AM, Naveen Chawla  wrote:
> I'm still not seeing a compelling case for not allowing `const` / `let`
> declarations to be evaluated as expressions. Or I've missed it.
>
> As was noted,
>
> `if(x = 5)` is already allowed.
>
> Is `if(const x = 5)` really that much of a stretch?
>
> To answer a concern about a function call like `myFunction(const x = 7)`, of
> course the scope of `x` would be where it is declared. It can't be anywhere
> else (like inside myFunction or something).
>
> On Thu, 22 Mar 2018 at 22:53 Isiah Meadows  wrote:
>>
>> Probably true, more so than the `if (var ...)`/etc. (which can't be as
>> easily desugared). My `else` variant desugars more to something that
>> is also easily simulated, and it's a less common case:
>>
>> ```js
>> let foo = bar else return baz;
>>
>> // Desugared
>> let _tmp = bar;
>> if (tmp == null) return baz;
>> let foo = _tmp;
>> ```
>>
>> In this case, there's also the question of whether to require a
>> `return` in all code paths, which probably makes this a bit more
>> complicated than what would be worth for such a simple language
>> feature.
>> -
>>
>> Isiah Meadows
>> m...@isiahmeadows.com
>>
>> Looking for web consulting? Or a new website?
>> Send me an email and we can get started.
>> www.isiahmeadows.com
>>
>>
>> On Thu, Mar 22, 2018 at 12:23 PM, Michael Luder-Rosefield
>>  wrote:
>> > That strikes me as territory the 'do expression' proposal
>> > https://github.com/tc39/proposal-do-expressions is more fitted for:
>> >
>> > const x = do { if (c) expr; else { ... } };
>> >
>> > What I'd like for this proposal is something that works consistently and
>> > obviously for all blocks with a parenthesised element to them. When
>> > they're
>> > formally separated by semi-colons, as in `for (a;b;c)`, each of `a,b,c`
>> > acts
>> > as an expression. Why not allow any of those expressions to be replaced
>> > by a
>> > statement block that acts like a do expression, each of which's scope is
>> > nested under the previous one and are available to the following block?
>> >
>> > That didn't come out very clearly, so let's try with an example:
>> >
>> >   for ({
>> >   let x = 1, y = 2;
>> >   console.log("I'll be printed every loop!");
>> > }; {
>> >   let s = 'some string';
>> >   if (y%7 === 0) x === y;
>> >   else x < 1000;
>> > }; {
>> >   let s = 'some other string';
>> >   x+=1;
>> >   if (y%3 === 0) y += 2;
>> >   else y += 1;
>> > }) {
>> >   // whatever code here
>> >   // local scope hierarchy is
>> >   //   {
>> >   // x,
>> >   //y,
>> >   //__SCOPE__: {
>> >   //  s: 'some string',
>> >   //  __SCOPE__: {
>> >   //s: 'some other string'
>> >   //  }
>> >   //}
>> >   //  }
>> > }
>> >
>> > I'm just using some random logic in the blocks to illustrate the point:
>> > all
>> > the variables declared in the blocks are accessible in the for block,
>> > but
>> > the 'some string' `s` is masked by the 'some other string' `s` in the
>> > child
>> > scope. The termination condition in the second block can vary each loop,
>> > as
>> > can the iteration operation in the last block, and is simply the last
>> > value
>> > in the block as-per do expressions.
>> >
>> > On Thu, 22 Mar 2018 at 15:44 Mike Samuel  wrote:
>> >>
>> >> On Thu, Mar 22, 2018 at 3:50 AM, Isiah Meadows 
>> >> wrote:
>> >>>
>> >>>
>> >>> I do have one othe

Re: Proposal: if variable initialization

[kai zhu]

unlike all other popular c-derivatives, javascript is the only one that's *not* 
a blocking-code language by design.  maybe tc39 should do some outreach to 
educate the many language-designers and polyglots who only know blocking-code 
patterns of this simple fact.

as i've said before, adding these foreign, blocking-code design-patterns from 
java/c#/python/c++ can only get you so far with insignificant, low-level 
library-code, which is not what javascript is about.  javascript is about 
integrating non-blocking io and workflows, so that browser/webview UX’s don’t 
block-and-freeze and give the appearance a webapp has crashed.

but async/await will save us! …no it will not.  the hard-part of 
integration-level javascript is not writing non-blocking code, but debugging 
non-blocking code.  and debugging non-blocking generator-magic (and 
promise-magic), is generally more difficult than debugging magic-less 
recursive-callbacks.

there is currently an industry-glut of so-called “senior” 
javascript-developers, who only know how to write low-level library-code (and 
bikeshed them to death with let, const, destructuring, etc...), but are 
clueless on how to integrate whatever-it-is-they-wrote into a shippable 
web-product.  no, they usually need an “intermediate” frontend-developer to do 
that (who oftentimes didn’t have formal cs-training and wasn't brainwashed with 
all that blocking-code cr*p that hinders the "senior” developer from carrying 
out integration-work).

-kai

> On Mar 23, 2018, at 3:21 PM, Naveen Chawla  wrote:
> 
> I'm still not seeing a compelling case for not allowing `const` / `let` 
> declarations to be evaluated as expressions. Or I've missed it.
> 
> As was noted,
> 
> `if(x = 5)` is already allowed.
> 
> Is `if(const x = 5)` really that much of a stretch?
> 
> To answer a concern about a function call like `myFunction(const x = 7)`, of 
> course the scope of `x` would be where it is declared. It can't be anywhere 
> else (like inside myFunction or something).
> 
> On Thu, 22 Mar 2018 at 22:53 Isiah Meadows  > wrote:
> Probably true, more so than the `if (var ...)`/etc. (which can't be as
> easily desugared). My `else` variant desugars more to something that
> is also easily simulated, and it's a less common case:
> 
> ```js
> let foo = bar else return baz;
> 
> // Desugared
> let _tmp = bar;
> if (tmp == null) return baz;
> let foo = _tmp;
> ```
> 
> In this case, there's also the question of whether to require a
> `return` in all code paths, which probably makes this a bit more
> complicated than what would be worth for such a simple language
> feature.
> -
> 
> Isiah Meadows
> m...@isiahmeadows.com 
> 
> Looking for web consulting? Or a new website?
> Send me an email and we can get started.
> www.isiahmeadows.com 
> 
> 
> On Thu, Mar 22, 2018 at 12:23 PM, Michael Luder-Rosefield
> mailto:rosyatran...@gmail.com>> wrote:
> > That strikes me as territory the 'do expression' proposal
> > https://github.com/tc39/proposal-do-expressions 
> >  is more fitted for:
> >
> > const x = do { if (c) expr; else { ... } };
> >
> > What I'd like for this proposal is something that works consistently and
> > obviously for all blocks with a parenthesised element to them. When they're
> > formally separated by semi-colons, as in `for (a;b;c)`, each of `a,b,c` acts
> > as an expression. Why not allow any of those expressions to be replaced by a
> > statement block that acts like a do expression, each of which's scope is
> > nested under the previous one and are available to the following block?
> >
> > That didn't come out very clearly, so let's try with an example:
> >
> >   for ({
> >   let x = 1, y = 2;
> >   console.log("I'll be printed every loop!");
> > }; {
> >   let s = 'some string';
> >   if (y%7 === 0) x === y;
> >   else x < 1000;
> > }; {
> >   let s = 'some other string';
> >   x+=1;
> >   if (y%3 === 0) y += 2;
> >   else y += 1;
> > }) {
> >   // whatever code here
> >   // local scope hierarchy is
> >   //   {
> >   // x,
> >   //y,
> >   //__SCOPE__: {
> >   //  s: 'some string',
> >   //  __SCOPE__: {
> >   //s: 'some other string'
> >   //  }
> >   //}
> >   //  }
> > }
> >
> > I'm just using some random logic in the blocks to illustrate the point: all
> > the variables declared in the blocks are accessible in the for block, but
> > the 'some string' `s` is masked by the 'some other string' `s` in the child
> > scope. The termination condition in the second block can vary each loop, as
> > can the iteration operation in the last block, and is simply the last value
> > in the block as-per do expressions.
> >
> > On Thu, 22 Mar 2018 at 15:44 Mike Samuel  > > wrote:
> >>
> >> On