Re: This mailing list needs a FAQ page.

[Pranay Prakash]

https://esdiscuss.org

On Sat, May 12, 2018, 9:55 AM Alex Vincent  wrote:

> I hate to say it, but I keep seeing the same dozen ideas surfaced over and
> over again here.  We really should capture them in a HTML page with link
> targets.  I'd like to see a format of:
>
> Q: I have this idea or I want this in the language...
> A: Hyperlink to a TC39 spec, a library or an explanation why it's a bad
> idea.
>
> It'd be nice to add it to the message headers, right above those
> unsubscribe links that nobody bothers to search for.
>
> Any volunteers?
>
> Alex
> --
> "The first step in confirming there is a bug in someone else's work is
> confirming there are no bugs in your own."
> -- Alexander J. Vincent, June 30, 2001
> ___
> 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: Suggested Enhancement to ecmascript

[Pranay Prakash]

I agree, Promises easily allow you to do this. Even if you wanted to 'wait'
on an event, you can either.

1. Use EventEmitter and simply have an 'on' handler
2. Create a promise and pass the resolve function to whatever js doing the
work, and `await` on the promise itself

You can also wrap an event emitter callback with a promise, oe use
something like RxJS for Observables. So many possibilities.

On Fri, May 11, 2018, 4:56 PM Michał Wadas  wrote:

> What's wrong with async functions and
> await Promise.all([a, b, c])
> ?
>
> On Fri, May 11, 2018 at 11:14 PM, Matthew Tedder <
> matthew.ted...@hyperconversal.com> wrote:
>
>>
>> wait for ( condition );
>>
>> Stop executing statements until the condition evaluates to true.  To
>> implement this, freeze the instance of the function in, add a hook to each
>> variable in the condition so that when its value is written to, the
>> condition is re-evaluated.
>>
>> This will greatly increase the clarity and reduce coding needed for
>> operations with many asynchronous calls and any with callbacks using arrow
>> functions..  E.g.,
>>
>> let a = false;
>> let b = 5;
>> let c = 'oranges';
>> doSomethenWhenever( () => { a = true; }
>> doAnotherThingWhenever( () => { b = 16; }
>> DoYetAnotherThing( () => { c = 'apples'; }
>> wait for ( a && b > 10 && c !== 'oranges' );
>> console.log('Conditions are met!');
>>
>>
>> --
>> Matthew C. Tedder
>> HyperConversal, Inc.
>> Desk: 352-381-7142 / Cell: 509-432-5520
>>
>> ___
>> 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: Iterator Functions

[Pranay Prakash]

A buddy of mine has actually been working on implementing
array producers/consumers as a library, and I think that's a good solution.
i.e. iterators are a nice native addition that can power functionality like
this in userland, and library authors can create libraries to make it
easier to use in userland.

A quick google search shows me that there are existing libraries that do
this (https://fitzgen.github.io/wu.js/) and what my friend is working on
implements a `collect` method which sounds like the `start` method you
mentioned.

Shameless plug: In the meanwhile, I've been working on a library too that,
amongst other things, gives you lazy evaluated list transformations. I'll
be talking about it at https://zeit.co/day :)

Cheers,
Pranay

On Mon, 16 Apr 2018 at 15:42 Sebastian Malton  wrote:

> With the ability to create iterators and convert other objects to them.
> Would it not make sense for them to implement most of the array style
> functions. These would execute lazily and only start once a call to `start`
> happens. (A new function as well).
>
> Sebastian Malton
> ___
> 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: Proposal: Optional Static Typing (Part 3)

[Pranay Prakash]

I'm still yet to read the entire proposal, but with a quick skim, it seems
to me like this is essentially what Typescript or Flow offers you: i.e. an
opt-in type system?

I'm wondering if you have any good reasons to want there to be a
standardised static type annotation syntax within ECMAScript instead of a
"Bring Your Own Type Checker" system.
If you do have some thoughts on this, you might also want to include that
as a preface on your Github's README.You have a "Rationale" bit that seems
to ignore the existence of these existing systems.

Waiting to hear more thoughts on this :)

On Thu, 11 Jan 2018 at 11:56 Brandon Andrews 
wrote:

> It's been a year and a half since my last post and I've made a number of
> small changes and corrections over 2.5 years. The proposal is still on my
> github at:
>
>
> https://github.com/sirisian/ecmascript-types
>
> I've talked to a lot of people about it, but I haven't gotten much
> criticism or suggested improvements. I'm a bit in over my head in trying to
> flesh out all the details or all the nuanced syntax changes that a
> championed proposal would be expected to do. That said I've been making
> more changes lately to try to find edge cases and potential problems.
>
>
> I've been jotting down issues here:
> https://github.com/sirisian/ecmascript-types/issues I closed a number of
> them recently as I made changes.
>
> If anyone has any comments on what I should expand, look into more, or
> change I'm open to discussing them here or on github.
>
> One issue in particular is this:
> https://github.com/sirisian/ecmascript-types/issues/15 It covers whether
> I should introduce a new assignment operator to my proposal. Maybe there's
> another way to look at it or a different solution. I need fresh eyes on the
> whole proposal really to get a list of new issues to tackle this year.
>
> I'm also not against having one or multiple people champion it and working
> on it without me. (I haven't been able to dedicate time to read the
> ECMAScript spec and really understanding the grammar fully so having
> someone qualified to take over would help the proposal a lot).
>
>
> Thanks for reading the proposal for anyone that has the time.
> ___
> 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: Ideas on a testing focussed code transform

[Pranay Prakash]

Yup, that applies perfectly to what I'm describing Dante (and is some great
reading) :)



On Mon, 18 Dec 2017 at 13:38 dante federici 
wrote:

> To add to this --- a Monad is a useful concept for separating the
> description of execution versus actually running the execution:
> https://www.wikiwand.com/en/Monad_(functional_programming)
> ___
> 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: Ideas on a testing focussed code transform

[Pranay Prakash]

Oh, I'll check out those links. However, the key part of my idea is to NOT
change the way write application code.

So, when I described the second version of the codebase (the one with
yields), that's not how I want you, the developer, to write code. I simply
propose a static code transform that convert the code you originally wrote
(first example) to the pure version with yield calls.

The trick here is, the original version of the code will be used when you
test your program, but the transformed code is what gets used solely when
you're testing (meaning your tests have to account for the code being
transformed, but I can image a good library to abstract some of those
details away)

I'll have to read up more about the dependency injection links you sent
before I can comment further on that comparison between this idea and
dependency injection

On Sat, 16 Dec 2017, 11:07 Isiah Meadows, <isiahmead...@gmail.com> wrote:

> You're still changing code as evidenced by your original email.
>
> - With dependency injection, you're changing the call sites (name ->
> method call) and argument count or state size (to hold the injection).
> - With your idea, you're changing the call sites (name+args to `yield`)
> and return value (value -> `yield` result).
>
> To give you an idea what I mean by dependency injection, take a look at
> this:
>
> - `util` uses here:
> https://github.com/isiahmeadows/thallium/blob/master/lib/cli/run.js
> - `state.util` uses here:
> https://github.com/isiahmeadows/thallium/blob/master/lib/cli/loader.js
> - Main `state.util` definition:
> https://github.com/isiahmeadows/thallium/blob/master/lib/cli/util.js
> - Testing `state.util` definition (`Mock` class):
> https://github.com/isiahmeadows/thallium/blob/master/test-util/cli/cli.js
>
> I mean small functional dependency injection, not the boilerplatey
> Java-style one. Mine is a bit more complex, because I also am passing
> shared state with it (like parsed args and config), but it's just an extra
> object property on that state, as defined in the `State` constructor in
> `lib/cli/run.js`.
>
> On Sat, Dec 16, 2017, 11:51 Pranay Prakash <pranay...@gmail.com> wrote:
>
>> I don't understand what you mean by "record actions done by iterables".
>> Could you please expand on that :)
>>
>> My main reason for being weary of dependency injection is that I don't
>> want to change how I write application code just to make it more testable.
>> That's a pretty well shared concern about dependency injection whereby it
>> affects the entire structure of your codebase, or adds additional arguments
>> to simple functions for the sole purpose of testing it.
>>
>> With the method I'm proposing, you wouldn't have to change how you code
>> at all, and I think that's really nice
>>
>> On Sat, 16 Dec 2017, 10:32 Isiah Meadows, <isiahmead...@gmail.com> wrote:
>>
>>> I think what you're looking for is dependency injection, which is simply
>>> the functions you care about passed as an argument rather than sent from
>>> `yield`. In your case, the injections would be recording what method is
>>> called when and with what, but that's what I typically do. As an added
>>> bonus, I don't need to rely on how the functions are structured - I can
>>> even record actions done from iterables. (That's one area yours won't work.)
>>>
>>> The only catch is that you can't asynchronously block, but that's far
>>> more rare in practice (automated testing doesn't need it, and you can set
>>> breakpoints when debugging, removing the need to asynchronously hook into
>>> it).
>>>
>>> On Sat, Dec 16, 2017, 00:19 Pranay Prakash <pranay...@gmail.com> wrote:
>>>
>>>> Hmm, I suppose the stack traces drawback doesn't matter as long you're
>>>> only using this within the context of testing. The emphasis here is that
>>>> the actual application code that you run in production is what you wrote
>>>> (the imperative function calls), but when you 'require' the function into
>>>> your testing code, it gets transformed into this pure generator function
>>>> that's easier to test.
>>>>
>>>> I don't see how the state/future of async functions affects this. In
>>>> fact, in my example, I use an async function to try and show that this
>>>> transform can even work for async functions (and will convert them to a
>>>> synchronous generator function rather easily)
>>>>
>>>> On Fri, 15 Dec 2017 at 23:14 Isiah Meadows <isiahmead...@gmail.com>
>>>> wrote:
>>>>
>>>>> You're describin

Re: Ideas on a testing focussed code transform

[Pranay Prakash]

I don't understand what you mean by "record actions done by iterables".
Could you please expand on that :)

My main reason for being weary of dependency injection is that I don't want
to change how I write application code just to make it more testable.
That's a pretty well shared concern about dependency injection whereby it
affects the entire structure of your codebase, or adds additional arguments
to simple functions for the sole purpose of testing it.

With the method I'm proposing, you wouldn't have to change how you code at
all, and I think that's really nice

On Sat, 16 Dec 2017, 10:32 Isiah Meadows, <isiahmead...@gmail.com> wrote:

> I think what you're looking for is dependency injection, which is simply
> the functions you care about passed as an argument rather than sent from
> `yield`. In your case, the injections would be recording what method is
> called when and with what, but that's what I typically do. As an added
> bonus, I don't need to rely on how the functions are structured - I can
> even record actions done from iterables. (That's one area yours won't work.)
>
> The only catch is that you can't asynchronously block, but that's far more
> rare in practice (automated testing doesn't need it, and you can set
> breakpoints when debugging, removing the need to asynchronously hook into
> it).
>
> On Sat, Dec 16, 2017, 00:19 Pranay Prakash <pranay...@gmail.com> wrote:
>
>> Hmm, I suppose the stack traces drawback doesn't matter as long you're
>> only using this within the context of testing. The emphasis here is that
>> the actual application code that you run in production is what you wrote
>> (the imperative function calls), but when you 'require' the function into
>> your testing code, it gets transformed into this pure generator function
>> that's easier to test.
>>
>> I don't see how the state/future of async functions affects this. In
>> fact, in my example, I use an async function to try and show that this
>> transform can even work for async functions (and will convert them to a
>> synchronous generator function rather easily)
>>
>> On Fri, 15 Dec 2017 at 23:14 Isiah Meadows <isiahmead...@gmail.com>
>> wrote:
>>
>>> You're describing a variant of the interpreter pattern. I've used
>>> similar in task scheduling contexts, and the key drawback is you no longer
>>> have useful stack traces.
>>>
>>> I haven't done any formal research on the approach, though. I will
>>> caution you that async functions are already widely used enough
>>> (particularly in Node) they're unlikely to go anywhere beyond something
>>> drastic.
>>>
>>> On Sat, Dec 16, 2017, 00:07 Pranay Prakash <pranay...@gmail.com> wrote:
>>>
>>>> Hey all,
>>>>
>>>> I was just reading the docs for `redux-saga` where I encountered a nice
>>>> design pattern for a saga which is (correct me if I'm wrong) a
>>>> regular javascript generator function that yields the intent to call a
>>>> function (instead of actually calling a function) until it goes through all
>>>> the steps. If that doesn't make sense, consider this simple function:
>>>>
>>>> ```
>>>> async function findFriends() {
>>>>   const myId = getMyID();
>>>>   const myUser = await fetchUser(myId);
>>>>   return myUser.friends;
>>>> }
>>>> ```
>>>>
>>>> instead of actually making the function calls needed, we can instead
>>>> have a function that does something like this:
>>>>
>>>>
>>>> ```
>>>> function* findFriends() {
>>>>   const myId = yield { fn: getMyID };
>>>>   const myUser = yield { fn: fetchUser, args: [myId] };
>>>>   return myUser.friends;
>>>> }
>>>> ```
>>>>
>>>> This is a pure generator function that doesn't actually do anything,
>>>> but has all the necessary information to recreate the original function[1]
>>>> (or have a library "trampoline" through the function and make all the
>>>> necessary calls for you)
>>>>
>>>> A HUGE plus of the second version of the function is that it's *easily*
>>>> testable (unlike the first one). Pure functions are easier to test. Testing
>>>> this is simply a matter of calling `.next()`, getting the "intent", making
>>>> sure the right intent was yielded (good enough for unit testing) and
>>>> calling `.next()` again with the "mock" value, you want to return and
>>>> 

Re: Ideas on a testing focussed code transform

[Pranay Prakash]

Hmm, I suppose the stack traces drawback doesn't matter as long you're only
using this within the context of testing. The emphasis here is that the
actual application code that you run in production is what you wrote (the
imperative function calls), but when you 'require' the function into your
testing code, it gets transformed into this pure generator function that's
easier to test.

I don't see how the state/future of async functions affects this. In fact,
in my example, I use an async function to try and show that this transform
can even work for async functions (and will convert them to a synchronous
generator function rather easily)

On Fri, 15 Dec 2017 at 23:14 Isiah Meadows <isiahmead...@gmail.com> wrote:

> You're describing a variant of the interpreter pattern. I've used similar
> in task scheduling contexts, and the key drawback is you no longer have
> useful stack traces.
>
> I haven't done any formal research on the approach, though. I will caution
> you that async functions are already widely used enough (particularly in
> Node) they're unlikely to go anywhere beyond something drastic.
>
> On Sat, Dec 16, 2017, 00:07 Pranay Prakash <pranay...@gmail.com> wrote:
>
>> Hey all,
>>
>> I was just reading the docs for `redux-saga` where I encountered a nice
>> design pattern for a saga which is (correct me if I'm wrong) a
>> regular javascript generator function that yields the intent to call a
>> function (instead of actually calling a function) until it goes through all
>> the steps. If that doesn't make sense, consider this simple function:
>>
>> ```
>> async function findFriends() {
>>   const myId = getMyID();
>>   const myUser = await fetchUser(myId);
>>   return myUser.friends;
>> }
>> ```
>>
>> instead of actually making the function calls needed, we can instead have
>> a function that does something like this:
>>
>>
>> ```
>> function* findFriends() {
>>   const myId = yield { fn: getMyID };
>>   const myUser = yield { fn: fetchUser, args: [myId] };
>>   return myUser.friends;
>> }
>> ```
>>
>> This is a pure generator function that doesn't actually do anything, but
>> has all the necessary information to recreate the original function[1] (or
>> have a library "trampoline" through the function and make all the necessary
>> calls for you)
>>
>> A HUGE plus of the second version of the function is that it's *easily*
>> testable (unlike the first one). Pure functions are easier to test. Testing
>> this is simply a matter of calling `.next()`, getting the "intent", making
>> sure the right intent was yielded (good enough for unit testing) and
>> calling `.next()` again with the "mock" value, you want to return and
>> continue to test.
>>
>> An observation to make here is that you can transform the original
>> version of this code (easy, normal code to write) to the latter (easy code
>> to test). So, what about having some sort of babel transform perhaps that
>> can convert the first to the second but only in the context of unit tests.
>> You write code the normal way as you would for your application and don't
>> worry about test suite implementation details (mocking/dependency
>> injection/etc.), and when you want to test, simply import your function
>> (which gets converted to a generator) and step through it to test different
>> scenarios.
>>
>> I personally think this is a super clean way to do testing since
>> the tests never interfere with how you actually write the code AND you
>> don't have to explicitly mock.
>>
>> Does anyone have thoughts on this / prior research (or knows about an
>> existing implementation of this)?
>>
>> Cheers,
>> Pranay
>>
> ___
>> 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

Ideas on a testing focussed code transform

[Pranay Prakash]

Hey all,

I was just reading the docs for `redux-saga` where I encountered a nice
design pattern for a saga which is (correct me if I'm wrong) a
regular javascript generator function that yields the intent to call a
function (instead of actually calling a function) until it goes through all
the steps. If that doesn't make sense, consider this simple function:

```
async function findFriends() {
  const myId = getMyID();
  const myUser = await fetchUser(myId);
  return myUser.friends;
}
```

instead of actually making the function calls needed, we can instead have a
function that does something like this:


```
function* findFriends() {
  const myId = yield { fn: getMyID };
  const myUser = yield { fn: fetchUser, args: [myId] };
  return myUser.friends;
}
```

This is a pure generator function that doesn't actually do anything, but
has all the necessary information to recreate the original function[1] (or
have a library "trampoline" through the function and make all the necessary
calls for you)

A HUGE plus of the second version of the function is that it's *easily*
testable (unlike the first one). Pure functions are easier to test. Testing
this is simply a matter of calling `.next()`, getting the "intent", making
sure the right intent was yielded (good enough for unit testing) and
calling `.next()` again with the "mock" value, you want to return and
continue to test.

An observation to make here is that you can transform the original version
of this code (easy, normal code to write) to the latter (easy code to
test). So, what about having some sort of babel transform perhaps that can
convert the first to the second but only in the context of unit tests. You
write code the normal way as you would for your application and don't worry
about test suite implementation details (mocking/dependency
injection/etc.), and when you want to test, simply import your function
(which gets converted to a generator) and step through it to test different
scenarios.

I personally think this is a super clean way to do testing since the tests
never interfere with how you actually write the code AND you don't have to
explicitly mock.

Does anyone have thoughts on this / prior research (or knows about an
existing implementation of this)?

Cheers,
Pranay
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: New Promise Syntax Proposal

[Pranay Prakash]

Lot of good ideas mentioned in this thread, and I think in general, the
async/await pattern helps to make code like this more terse.

Rather than inventing new syntax like:

```
promise promiseFunction(resolve, reject, …args) {  // call to reject() or
resolve()
}
…

the existing way of implementing this is:

```
async function promiseFunction(…args) {  // return something (to resolve) or
throw an error (to reject)
}
…
We already have the latter, and it is cleaner IMO
Cheers,Pranay  





On Mon, Nov 6, 2017 1:05 PM, Augusto Moura augusto.borg...@gmail.com  wrote:
Using arrow functions it doesn't seems so verbose
```js
function requestInput(question) {  return new Promise(function(resolve) {   
interface.question(question, function(input) {      resolve(input);    })  })}
```can be written as:
```js
const requestInput = question => new Promise((resolve) => {
interface.question(question, resolve); // You can wrap resolve in a `unary`
helper if more than 1 argument is problematic
});
```

I don't see a problem with verbosity-- 
Augusto Moura___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Array.prototype.do proposal

[Pranay Prakash]

I found the existence of a function like this in RxJS quite useful and I
wish JavaScript had it too. What do you think?

https://github.com/pranaygp/proposal-array-prototype-do

Cheers,
Pranay
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss