super return

classic Classic list List threaded Threaded
16 messages Options
Reply | Threaded
Open this post in threaded view
|

super return

Sebastian Malton
I have seen some people want to modify some of the array prototype functions, especially forEach, so that returning from them returns a value. 
However, I have also seems that this could break things since in some cases, again forEach, the return value in explicitly defined. 

Thus I propose the new syntax `super return` and any other positive number of supers. This syntax is currently not valid in any scenario and with the current meaning of super seems, to me at least, relativity easy to understand. 

The outcome of this basically means "return from current context up one level and then return from there".

A current method of doing this is by using try / catch but it is not ideal. Using the above method I believe that it would be able to be better optimized.


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: super return

Michael J. Ryan
Well, there's already .map(), .find() and .filter() for returning values from arrays


--
Michael J. Ryan - [hidden email] - http://tracker1.info

Please excuse grammar errors and typos, as this message was sent from my phone.

On Aug 28, 2017 12:30 PM, "Sebastian Malton" <[hidden email]> wrote:
I have seen some people want to modify some of the array prototype functions, especially forEach, so that returning from them returns a value. 
However, I have also seems that this could break things since in some cases, again forEach, the return value in explicitly defined. 

Thus I propose the new syntax `super return` and any other positive number of supers. This syntax is currently not valid in any scenario and with the current meaning of super seems, to me at least, relativity easy to understand. 

The outcome of this basically means "return from current context up one level and then return from there".

A current method of doing this is by using try / catch but it is not ideal. Using the above method I believe that it would be able to be better optimized.


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: super return

Sebastian Malton
That is for returning values of arrays (or slightly changed values). I am more talking about for errors and such

Example:

```js
function someThing(doWith) {
    return doWith.map(elem => {
        if (typeof elem !== "number") {
            super return "Not all are numbers" ;
        return elem * 2;
    });
}
```


Sent: August 28, 2017 3:43 PM
Subject: Re: super return

Well, there's already .map(), .find() and .filter() for returning values from arrays


--
Michael J. Ryan - [hidden email] - http://tracker1.info

Please excuse grammar errors and typos, as this message was sent from my phone.

On Aug 28, 2017 12:30 PM, "Sebastian Malton" <[hidden email]> wrote:
I have seen some people want to modify some of the array prototype functions, especially forEach, so that returning from them returns a value. 
However, I have also seems that this could break things since in some cases, again forEach, the return value in explicitly defined. 

Thus I propose the new syntax `super return` and any other positive number of supers. This syntax is currently not valid in any scenario and with the current meaning of super seems, to me at least, relativity easy to understand. 

The outcome of this basically means "return from current context up one level and then return from there".

A current method of doing this is by using try / catch but it is not ideal. Using the above method I believe that it would be able to be better optimized.


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: super return

Tab Atkins Jr.
In reply to this post by Sebastian Malton
On Mon, Aug 28, 2017 at 12:29 PM, Sebastian Malton
<[hidden email]> wrote:

> I have seen some people want to modify some of the array prototype
> functions, especially forEach, so that returning from them returns a value.
> However, I have also seems that this could break things since in some cases,
> again forEach, the return value in explicitly defined.
>
> Thus I propose the new syntax `super return` and any other positive number
> of supers. This syntax is currently not valid in any scenario and with the
> current meaning of super seems, to me at least, relativity easy to
> understand.
>
> The outcome of this basically means "return from current context up one
> level and then return from there".
>
> A current method of doing this is by using try / catch but it is not ideal.
> Using the above method I believe that it would be able to be better
> optimized.

This has been suggested in the past, by adding a fourth argument to
the callback signature passing an opaque "halt" value. Returning the
halt value would end execution of the looping function prematurely.
No reason to add new syntax for this, plus hooks for userland to take
advantage of it, when we can just use something that userland could
adopt *today*.

(As an added bonus, it would make the callback arguments be Element,
Index, Collection, Halt, finally spelling out Brendan's full last
name. ^_^)

~TJ
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: super return

Sebastian Malton
This could be done but I see a few problems with it:

1. Though it does make ending from some functions like forEach able to be done it does not all returning from other functions like map or sort
2. It does not directly allow the returning of values but this might be rectified by having it be a function that you call and when it calls it stops any further calls and then returns the first parameter past


  Original Message  
From: [hidden email]
Sent: August 28, 2017 4:17 PM
To: [hidden email]
Cc: [hidden email]
Subject: Re: super return

On Mon, Aug 28, 2017 at 12:29 PM, Sebastian Malton
<[hidden email]> wrote:

> I have seen some people want to modify some of the array prototype
> functions, especially forEach, so that returning from them returns a value.
> However, I have also seems that this could break things since in some cases,
> again forEach, the return value in explicitly defined.
>
> Thus I propose the new syntax `super return` and any other positive number
> of supers. This syntax is currently not valid in any scenario and with the
> current meaning of super seems, to me at least, relativity easy to
> understand.
>
> The outcome of this basically means "return from current context up one
> level and then return from there".
>
> A current method of doing this is by using try / catch but it is not ideal.
> Using the above method I believe that it would be able to be better
> optimized.

This has been suggested in the past, by adding a fourth argument to
the callback signature passing an opaque "halt" value. Returning the
halt value would end execution of the looping function prematurely.
No reason to add new syntax for this, plus hooks for userland to take
advantage of it, when we can just use something that userland could
adopt *today*.

(As an added bonus, it would make the callback arguments be Element,
Index, Collection, Halt, finally spelling out Brendan's full last
name. ^_^)

~TJ
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: super return

Michael J. Ryan
In reply to this post by Tab Atkins Jr.
if (arr.find(e => typeof e != 'number')) throw new Error('...');

return arr.map(e => {
  if (!...) throw new Error(...);
  return e * 2;
});

Odds are you need a conditional block, might as well be try catch.


--
Michael J. Ryan - [hidden email] - http://tracker1.info

Please excuse grammar errors and typos, as this message was sent from my phone.

On Aug 28, 2017 1:17 PM, "Tab Atkins Jr." <[hidden email]> wrote:
On Mon, Aug 28, 2017 at 12:29 PM, Sebastian Malton
<[hidden email]> wrote:
> I have seen some people want to modify some of the array prototype
> functions, especially forEach, so that returning from them returns a value.
> However, I have also seems that this could break things since in some cases,
> again forEach, the return value in explicitly defined.
>
> Thus I propose the new syntax `super return` and any other positive number
> of supers. This syntax is currently not valid in any scenario and with the
> current meaning of super seems, to me at least, relativity easy to
> understand.
>
> The outcome of this basically means "return from current context up one
> level and then return from there".
>
> A current method of doing this is by using try / catch but it is not ideal.
> Using the above method I believe that it would be able to be better
> optimized.

This has been suggested in the past, by adding a fourth argument to
the callback signature passing an opaque "halt" value. Returning the
halt value would end execution of the looping function prematurely.
No reason to add new syntax for this, plus hooks for userland to take
advantage of it, when we can just use something that userland could
adopt *today*.

(As an added bonus, it would make the callback arguments be Element,
Index, Collection, Halt, finally spelling out Brendan's full last
name. ^_^)

~TJ
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: super return

Tab Atkins Jr.
In reply to this post by Tab Atkins Jr.
On Mon, Aug 28, 2017 at 1:27 PM, Sebastian Malton <[hidden email]> wrote:
> This could be done but I see a few problems with it:
>
> 1. Though it does make ending from some functions like forEach able to be done it does not all returning from other functions like map or sort

map() and forEach() have exactly the same signatures for their
callbacks; you can definitely do the same thing in both of them.

You're right about sort(), but returning early from a sort() call
seems like a really small niche; I think it's the sort of thing you'll
only do in an error situation, in which case throwing is the correct
way to handle it.  (On the other hand, returning early from a
forEach() can be due to perfectly normal reasons, the same sorts of
things that cause you to `break` from a loop.)

> 2. It does not directly allow the returning of values but this might be rectified by having it be a function that you call and when it calls it stops any further calls and then returns the first parameter past

It's the outer function's responsibility to return appropriate values.
A map() call that didn't return an array would cause a lot of
problems; a forEach call that returned something meaningful would be
weird. In either case, it's a bad code smell to try and override what
the outer function is doing.  If you're stopping because of an error,
and so whatever the function is trying to do isn't relevant anymore,
you should throw an error instead.

~TJ
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: super return

Naveen Chawla

Returning early should be implemented via a new `takeWhile` call


On Tue, 29 Aug 2017 02:06 Tab Atkins Jr. <[hidden email]> wrote:
On Mon, Aug 28, 2017 at 1:27 PM, Sebastian Malton <[hidden email]> wrote:
> This could be done but I see a few problems with it:
>
> 1. Though it does make ending from some functions like forEach able to be done it does not all returning from other functions like map or sort

map() and forEach() have exactly the same signatures for their
callbacks; you can definitely do the same thing in both of them.

You're right about sort(), but returning early from a sort() call
seems like a really small niche; I think it's the sort of thing you'll
only do in an error situation, in which case throwing is the correct
way to handle it.  (On the other hand, returning early from a
forEach() can be due to perfectly normal reasons, the same sorts of
things that cause you to `break` from a loop.)

> 2. It does not directly allow the returning of values but this might be rectified by having it be a function that you call and when it calls it stops any further calls and then returns the first parameter past

It's the outer function's responsibility to return appropriate values.
A map() call that didn't return an array would cause a lot of
problems; a forEach call that returned something meaningful would be
weird. In either case, it's a bad code smell to try and override what
the outer function is doing.  If you're stopping because of an error,
and so whatever the function is trying to do isn't relevant anymore,
you should throw an error instead.

~TJ
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: super return

Andreas Rossberg-4
In reply to this post by Sebastian Malton
On 28 August 2017 at 21:29, Sebastian Malton <[hidden email]> wrote:
Thus I propose the new syntax `super return` and any other positive number of supers. This syntax is currently not valid in any scenario and with the current meaning of super seems, to me at least, relativity easy to understand. 

The outcome of this basically means "return from current context up one level and then return from there".

What if that context is no longer live? A function can outlive its creation scope. You could even try returning twice from the same function.

Allowing returns from outer functions has been discussed extensively in the ES6 phase (e.g. under the term "blocks"), but has been decided against in favour of arrow functions. One problem is that it introduces quite complex dynamic behaviour in general (it's halfway to introducing delimited continuations), and many new ways to fail.


A current method of doing this is by using try / catch but it is not ideal. Using the above method I believe that it would be able to be better optimized.

That's unlikely, since it is just as dynamic in the general case (and the less general cases can be optimised equally well for both).

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: super return

Sebastian Malton
If a function outlives its creation scope then this would do exactly what a normal return would do.

Sent: August 29, 2017 6:55 AM
Subject: Re: super return

On 28 August 2017 at 21:29, Sebastian Malton <[hidden email]> wrote:
Thus I propose the new syntax `super return` and any other positive number of supers. This syntax is currently not valid in any scenario and with the current meaning of super seems, to me at least, relativity easy to understand. 

The outcome of this basically means "return from current context up one level and then return from there".

What if that context is no longer live? A function can outlive its creation scope. You could even try returning twice from the same function.

Allowing returns from outer functions has been discussed extensively in the ES6 phase (e.g. under the term "blocks"), but has been decided against in favour of arrow functions. One problem is that it introduces quite complex dynamic behaviour in general (it's halfway to introducing delimited continuations), and many new ways to fail.


A current method of doing this is by using try / catch but it is not ideal. Using the above method I believe that it would be able to be better optimized.

That's unlikely, since it is just as dynamic in the general case (and the less general cases can be optimised equally well for both).

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: super return

Andreas Rossberg-4
In reply to this post by Andreas Rossberg-4
On 29 August 2017 at 14:30, Sebastian Malton <[hidden email]> wrote:
If a function outlives its creation scope then this would do exactly what a normal return would do.

That makes no sense, because that's a completely different continuation, usually expecting different, unrelated types of results. It needs to be an error at least. (In a language with proper continuations the outer continuation would be captured by the inner closure and invoking it later would reestablish the execution context to return to. But TC39 always agreed that we don't want full-blown continuations in JS.)


Sent: August 29, 2017 6:55 AM
Subject: Re: super return

On 28 August 2017 at 21:29, Sebastian Malton <[hidden email]> wrote:
Thus I propose the new syntax `super return` and any other positive number of supers. This syntax is currently not valid in any scenario and with the current meaning of super seems, to me at least, relativity easy to understand. 

The outcome of this basically means "return from current context up one level and then return from there".

What if that context is no longer live? A function can outlive its creation scope. You could even try returning twice from the same function.

Allowing returns from outer functions has been discussed extensively in the ES6 phase (e.g. under the term "blocks"), but has been decided against in favour of arrow functions. One problem is that it introduces quite complex dynamic behaviour in general (it's halfway to introducing delimited continuations), and many new ways to fail.


A current method of doing this is by using try / catch but it is not ideal. Using the above method I believe that it would be able to be better optimized.

That's unlikely, since it is just as dynamic in the general case (and the less general cases can be optimised equally well for both).


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: super return

Allen Wirfs-Brock
In reply to this post by Sebastian Malton

On Aug 28, 2017, at 12:29 PM, Sebastian Malton <[hidden email]> wrote:

The outcome of this basically means "return from current context up one level and then return from there”.

This would be a terrible violation of functional encapsulation.  How do you know that the (e.g.) forOf function isn’t internally using a encapsulated helper function that is making the actual call to the call back.  You simply have no way to predict where returning from the current context “up one” means.


A current method of doing this is by using try / catch but it is not ideal. Using the above method I believe that it would be able to be better optimized.

This technique provides a meaningful semantics because it allows the controlling outer function to define what early return means.



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: super return

Naveen Chawla
`takeWhile` would work as follows:

```
myArray.takeWhile(element=>true) //Simplest case. Iterates over all elements and returns a new array of them
```

It returns a new array with the consecutive elements from the start all of whose predicates returns truthy. Thusly it allows iteration with a custom exit condition, e.g.

```
myArray
    .takeWhile(
         element=>{
             let condition
             //calculate condition
             return condition
         }
    )
```

Prior art: Java 9, rxjs, lodash and possibly others

On Tue, 29 Aug 2017 at 21:27 Allen Wirfs-Brock <[hidden email]> wrote:
On Aug 28, 2017, at 12:29 PM, Sebastian Malton <[hidden email]> wrote:

The outcome of this basically means "return from current context up one level and then return from there”.

This would be a terrible violation of functional encapsulation.  How do you know that the (e.g.) forOf function isn’t internally using a encapsulated helper function that is making the actual call to the call back.  You simply have no way to predict where returning from the current context “up one” means.


A current method of doing this is by using try / catch but it is not ideal. Using the above method I believe that it would be able to be better optimized.

This technique provides a meaningful semantics because it allows the controlling outer function to define what early return means.


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: super return

Alexander Jones
In reply to this post by Allen Wirfs-Brock
Perhaps if the nested function is lexically inside such super function it can be fair game and actually quite powerful and liberating.

Unconstrained 'upleveling' is IIRC valid in such wonderful languages as Tcl. This unverified fact is presented without opinion :D

On Tue, 29 Aug 2017 at 16:57, Allen Wirfs-Brock <[hidden email]> wrote:
On Aug 28, 2017, at 12:29 PM, Sebastian Malton <[hidden email]> wrote:

The outcome of this basically means "return from current context up one level and then return from there”.

This would be a terrible violation of functional encapsulation.  How do you know that the (e.g.) forOf function isn’t internally using a encapsulated helper function that is making the actual call to the call back.  You simply have no way to predict where returning from the current context “up one” means.


A current method of doing this is by using try / catch but it is not ideal. Using the above method I believe that it would be able to be better optimized.

This technique provides a meaningful semantics because it allows the controlling outer function to define what early return means.


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: super return

Sebastian Malton
That makes sense, the use for this proposal is not for really for n - level forced retuning but for things like array functions or things like that

Sent: August 30, 2017 12:08 PM
Subject: Re: super return

Perhaps if the nested function is lexically inside such super function it can be fair game and actually quite powerful and liberating.

Unconstrained 'upleveling' is IIRC valid in such wonderful languages as Tcl. This unverified fact is presented without opinion :D

On Tue, 29 Aug 2017 at 16:57, Allen Wirfs-Brock <[hidden email]> wrote:
On Aug 28, 2017, at 12:29 PM, Sebastian Malton <[hidden email]> wrote:

The outcome of this basically means "return from current context up one level and then return from there”.

This would be a terrible violation of functional encapsulation.  How do you know that the (e.g.) forOf function isn’t internally using a encapsulated helper function that is making the actual call to the call back.  You simply have no way to predict where returning from the current context “up one” means.


A current method of doing this is by using try / catch but it is not ideal. Using the above method I believe that it would be able to be better optimized.

This technique provides a meaningful semantics because it allows the controlling outer function to define what early return means.


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: super return

Steve Fink
In reply to this post by Allen Wirfs-Brock
On 08/29/2017 08:56 AM, Allen Wirfs-Brock wrote:

On Aug 28, 2017, at 12:29 PM, Sebastian Malton <[hidden email]> wrote:

The outcome of this basically means "return from current context up one level and then return from there”.

This would be a terrible violation of functional encapsulation.  How do you know that the (e.g.) forOf function isn’t internally using a encapsulated helper function that is making the actual call to the call back.  You simply have no way to predict where returning from the current context “up one” means.

I agree. I think this would be much better as

```js
function someThing(doWith) {
    return doWith.map(elem => {
        typeCheckLabel:
        return elem * 2;
    });

    come from typeCheckLabel if (typeof elem !== "number");
    return "Not all are numbers" ;
}
```

:-)

(I agree with the encapsulation argument.)



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss