Function Overloading or Pattern Matching of functions in Ecma

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

Function Overloading or Pattern Matching of functions in Ecma

bishwendu kundu
Hello All,

I have been a great fan of the evolution of JavaScript in the recent past. The language is steadily closing the gap to ideal functional paradigm. One of the things that I have liked the most about languages like Erlang/Elixir/Haskell is their ability to define functions with same name and different airty. The decision of invoking the correct function-argument pattern is dependent on the invocation of the function. Implicit pattern matching in aforementioned languages helps avoid costly cognitive loads introduced by explicit if/else based pattern of logic flow branching.

The greatest power of the pattern matching which amazed me was, dropping the whole of looping construct, altogether. Elixir/Erlang have no LOOPS. Stack based recursive calls combined with JavaScript's closures suddenly strikes me as a very powerful programming model that not only increases readability of code but also promotes immutability of the data structures in use. The loops would continue to exist but more modern codes can be written leveraging the recursive model of JavaScript.

With de-structuring of arrays & objects already in place in JavaScript, pattern-matching of functions can fit right in perfectly, thereby taking JavaScript another step closer to ideal functional programming model.

Looking forward to your response.

Thanks & Regards,
Bishwendu.

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

Re: Function Overloading or Pattern Matching of functions in Ecma

kai zhu
hi Bishwendu, javascript is first-and-foremost a tool designed for web-product-development, a growing field that has eclipsed low-level general-purpose programming (where jobs are harder and harder to find) in the IT industry.

you need to give compelling reasons (for such significant language-change) why i, a web-developer would benefit from from having overloaded-functions in my (mostly expendable-code) web-projects, as opposed to creating confusion and maintennance-headaches, when i typically have to rewrite code multiple-times during the web-integration process.


On 17 Oct 2018, at 12:23 PM, bishwendu kundu <[hidden email]> wrote:

Hello All,

I have been a great fan of the evolution of JavaScript in the recent past. The language is steadily closing the gap to ideal functional paradigm. One of the things that I have liked the most about languages like Erlang/Elixir/Haskell is their ability to define functions with same name and different airty. The decision of invoking the correct function-argument pattern is dependent on the invocation of the function. Implicit pattern matching in aforementioned languages helps avoid costly cognitive loads introduced by explicit if/else based pattern of logic flow branching.

The greatest power of the pattern matching which amazed me was, dropping the whole of looping construct, altogether. Elixir/Erlang have no LOOPS. Stack based recursive calls combined with JavaScript's closures suddenly strikes me as a very powerful programming model that not only increases readability of code but also promotes immutability of the data structures in use. The loops would continue to exist but more modern codes can be written leveraging the recursive model of JavaScript.

With de-structuring of arrays & objects already in place in JavaScript, pattern-matching of functions can fit right in perfectly, thereby taking JavaScript another step closer to ideal functional programming model.

Looking forward to your response.

Thanks & Regards,
Bishwendu.
_______________________________________________
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: Function Overloading or Pattern Matching of functions in Ecma

Isiah Meadows-2
In reply to this post by bishwendu kundu
In general, you can do this via `arguments.length`, and if/once the pattern matching proposal [1] hits stage 4, you could do this to emulate it very closely:

```js
function foo(...args) {
    case (args) {
        when [] -> { /* zero args*/ },
        when [x] -> { /* one arg */ },
        // and so on...
    }
}
```

In general, that proposal would most interest you.


On Wed, Oct 17, 2018 at 01:24 bishwendu kundu <[hidden email]> wrote:
Hello All,

I have been a great fan of the evolution of JavaScript in the recent past. The language is steadily closing the gap to ideal functional paradigm. One of the things that I have liked the most about languages like Erlang/Elixir/Haskell is their ability to define functions with same name and different airty. The decision of invoking the correct function-argument pattern is dependent on the invocation of the function. Implicit pattern matching in aforementioned languages helps avoid costly cognitive loads introduced by explicit if/else based pattern of logic flow branching.

The greatest power of the pattern matching which amazed me was, dropping the whole of looping construct, altogether. Elixir/Erlang have no LOOPS. Stack based recursive calls combined with JavaScript's closures suddenly strikes me as a very powerful programming model that not only increases readability of code but also promotes immutability of the data structures in use. The loops would continue to exist but more modern codes can be written leveraging the recursive model of JavaScript.

With de-structuring of arrays & objects already in place in JavaScript, pattern-matching of functions can fit right in perfectly, thereby taking JavaScript another step closer to ideal functional programming model.

Looking forward to your response.

Thanks & Regards,
Bishwendu.
_______________________________________________
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: Function Overloading or Pattern Matching of functions in Ecma

bishwendu kundu
In reply to this post by kai zhu
Hi Kai Zhu,

I agree with you the new proposition should be of value to a web developer in daily work. If we observe the pattern it more closely resembles a more declarative form of solution implementation which is easy to code and understand. For example lets consider below piece of code:
```js
function sum_list(input, result){
    if(!input.length)
        return result;
    [head, ...input] = input;
    return sum_list(input, result + head);
}
```
Now the same code in the new proposal form

```js
function sum_list([head, ...tail], result){
    result = result + head;
    return sum_list(tail, result);
}

function sum_list([], result){
    return result;
}
```

This declarative model of coding also forces an immutable form of state management allowing for removing a family of bugs.

Thanks & Regards,
Bishwendu.

On Wed, Oct 17, 2018 at 12:57 PM kai zhu <[hidden email]> wrote:
hi Bishwendu, javascript is first-and-foremost a tool designed for web-product-development, a growing field that has eclipsed low-level general-purpose programming (where jobs are harder and harder to find) in the IT industry.

you need to give compelling reasons (for such significant language-change) why i, a web-developer would benefit from from having overloaded-functions in my (mostly expendable-code) web-projects, as opposed to creating confusion and maintennance-headaches, when i typically have to rewrite code multiple-times during the web-integration process.


On 17 Oct 2018, at 12:23 PM, bishwendu kundu <[hidden email]> wrote:

Hello All,

I have been a great fan of the evolution of JavaScript in the recent past. The language is steadily closing the gap to ideal functional paradigm. One of the things that I have liked the most about languages like Erlang/Elixir/Haskell is their ability to define functions with same name and different airty. The decision of invoking the correct function-argument pattern is dependent on the invocation of the function. Implicit pattern matching in aforementioned languages helps avoid costly cognitive loads introduced by explicit if/else based pattern of logic flow branching.

The greatest power of the pattern matching which amazed me was, dropping the whole of looping construct, altogether. Elixir/Erlang have no LOOPS. Stack based recursive calls combined with JavaScript's closures suddenly strikes me as a very powerful programming model that not only increases readability of code but also promotes immutability of the data structures in use. The loops would continue to exist but more modern codes can be written leveraging the recursive model of JavaScript.

With de-structuring of arrays & objects already in place in JavaScript, pattern-matching of functions can fit right in perfectly, thereby taking JavaScript another step closer to ideal functional programming model.

Looking forward to your response.

Thanks & Regards,
Bishwendu.
_______________________________________________
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: Function Overloading or Pattern Matching of functions in Ecma

Isiah Meadows-2
As mentioned previously, the pattern matching proposal does a lot to help here:

```js
function sum_list(input, result = 0) {
    case (input) {
        when [head, ...tail] -> return sum_list(input, result + head),
        when _ -> return result,
    };
}
```

-----

Isiah Meadows
[hidden email]
www.isiahmeadows.com

On Mon, Oct 22, 2018 at 3:08 AM bishwendu kundu <[hidden email]> wrote:

>
> Hi Kai Zhu,
>
> I agree with you the new proposition should be of value to a web developer in daily work. If we observe the pattern it more closely resembles a more declarative form of solution implementation which is easy to code and understand. For example lets consider below piece of code:
> ```js
> function sum_list(input, result){
>     if(!input.length)
>         return result;
>     [head, ...input] = input;
>     return sum_list(input, result + head);
> }
> ```
> Now the same code in the new proposal form
>
> ```js
> function sum_list([head, ...tail], result){
>     result = result + head;
>     return sum_list(tail, result);
> }
>
> function sum_list([], result){
>     return result;
> }
> ```
>
> This declarative model of coding also forces an immutable form of state management allowing for removing a family of bugs.
>
> Thanks & Regards,
> Bishwendu.
>
> On Wed, Oct 17, 2018 at 12:57 PM kai zhu <[hidden email]> wrote:
>>
>> hi Bishwendu, javascript is first-and-foremost a tool designed for web-product-development, a growing field that has eclipsed low-level general-purpose programming (where jobs are harder and harder to find) in the IT industry.
>>
>> you need to give compelling reasons (for such significant language-change) why i, a web-developer would benefit from from having overloaded-functions in my (mostly expendable-code) web-projects, as opposed to creating confusion and maintennance-headaches, when i typically have to rewrite code multiple-times during the web-integration process.
>>
>> kai zhu
>> [hidden email]
>>
>>
>>
>> On 17 Oct 2018, at 12:23 PM, bishwendu kundu <[hidden email]> wrote:
>>
>> Hello All,
>>
>> I have been a great fan of the evolution of JavaScript in the recent past. The language is steadily closing the gap to ideal functional paradigm. One of the things that I have liked the most about languages like Erlang/Elixir/Haskell is their ability to define functions with same name and different airty. The decision of invoking the correct function-argument pattern is dependent on the invocation of the function. Implicit pattern matching in aforementioned languages helps avoid costly cognitive loads introduced by explicit if/else based pattern of logic flow branching.
>>
>> The greatest power of the pattern matching which amazed me was, dropping the whole of looping construct, altogether. Elixir/Erlang have no LOOPS. Stack based recursive calls combined with JavaScript's closures suddenly strikes me as a very powerful programming model that not only increases readability of code but also promotes immutability of the data structures in use. The loops would continue to exist but more modern codes can be written leveraging the recursive model of JavaScript.
>>
>> With de-structuring of arrays & objects already in place in JavaScript, pattern-matching of functions can fit right in perfectly, thereby taking JavaScript another step closer to ideal functional programming model.
>>
>> Looking forward to your response.
>>
>> Thanks & Regards,
>> Bishwendu.
>> _______________________________________________
>> 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
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Function Overloading or Pattern Matching of functions in Ecma

Matthew Robb
Perhaps the following form could eventually make sense for pattern matching in function declarations:

```js
function sum_list(input, result = 0) case (input) {
    when [head, ...tail] -> {
        return sum_list(input, result + head);
    },

    when _ -> { return result; }
}
```  

- Matthew Robb


On Mon, Oct 22, 2018 at 8:48 AM Isiah Meadows <[hidden email]> wrote:
As mentioned previously, the pattern matching proposal does a lot to help here:

```js
function sum_list(input, result = 0) {
    case (input) {
        when [head, ...tail] -> return sum_list(input, result + head),
        when _ -> return result,
    };
}
```

-----

Isiah Meadows
[hidden email]
www.isiahmeadows.com

On Mon, Oct 22, 2018 at 3:08 AM bishwendu kundu <[hidden email]> wrote:
>
> Hi Kai Zhu,
>
> I agree with you the new proposition should be of value to a web developer in daily work. If we observe the pattern it more closely resembles a more declarative form of solution implementation which is easy to code and understand. For example lets consider below piece of code:
> ```js
> function sum_list(input, result){
>     if(!input.length)
>         return result;
>     [head, ...input] = input;
>     return sum_list(input, result + head);
> }
> ```
> Now the same code in the new proposal form
>
> ```js
> function sum_list([head, ...tail], result){
>     result = result + head;
>     return sum_list(tail, result);
> }
>
> function sum_list([], result){
>     return result;
> }
> ```
>
> This declarative model of coding also forces an immutable form of state management allowing for removing a family of bugs.
>
> Thanks & Regards,
> Bishwendu.
>
> On Wed, Oct 17, 2018 at 12:57 PM kai zhu <[hidden email]> wrote:
>>
>> hi Bishwendu, javascript is first-and-foremost a tool designed for web-product-development, a growing field that has eclipsed low-level general-purpose programming (where jobs are harder and harder to find) in the IT industry.
>>
>> you need to give compelling reasons (for such significant language-change) why i, a web-developer would benefit from from having overloaded-functions in my (mostly expendable-code) web-projects, as opposed to creating confusion and maintennance-headaches, when i typically have to rewrite code multiple-times during the web-integration process.
>>
>> kai zhu
>> [hidden email]
>>
>>
>>
>> On 17 Oct 2018, at 12:23 PM, bishwendu kundu <[hidden email]> wrote:
>>
>> Hello All,
>>
>> I have been a great fan of the evolution of JavaScript in the recent past. The language is steadily closing the gap to ideal functional paradigm. One of the things that I have liked the most about languages like Erlang/Elixir/Haskell is their ability to define functions with same name and different airty. The decision of invoking the correct function-argument pattern is dependent on the invocation of the function. Implicit pattern matching in aforementioned languages helps avoid costly cognitive loads introduced by explicit if/else based pattern of logic flow branching.
>>
>> The greatest power of the pattern matching which amazed me was, dropping the whole of looping construct, altogether. Elixir/Erlang have no LOOPS. Stack based recursive calls combined with JavaScript's closures suddenly strikes me as a very powerful programming model that not only increases readability of code but also promotes immutability of the data structures in use. The loops would continue to exist but more modern codes can be written leveraging the recursive model of JavaScript.
>>
>> With de-structuring of arrays & objects already in place in JavaScript, pattern-matching of functions can fit right in perfectly, thereby taking JavaScript another step closer to ideal functional programming model.
>>
>> Looking forward to your response.
>>
>> Thanks & Regards,
>> Bishwendu.
>> _______________________________________________
>> 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
_______________________________________________
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: Function Overloading or Pattern Matching of functions in Ecma

Isiah Meadows-2
You might want to check out the proposal's repo and make the suggestion there (it's been considered already IIRC, and I believe it was already noted in the repo as a possible future extension): https://github.com/tc39/proposal-pattern-matching
On Mon, Oct 22, 2018 at 15:38 Matthew Robb <[hidden email]> wrote:
Perhaps the following form could eventually make sense for pattern matching in function declarations:

```js
function sum_list(input, result = 0) case (input) {
    when [head, ...tail] -> {
        return sum_list(input, result + head);
    },

    when _ -> { return result; }
}
```  


- Matthew Robb


On Mon, Oct 22, 2018 at 8:48 AM Isiah Meadows <[hidden email]> wrote:
As mentioned previously, the pattern matching proposal does a lot to help here:

```js
function sum_list(input, result = 0) {
    case (input) {
        when [head, ...tail] -> return sum_list(input, result + head),
        when _ -> return result,
    };
}
```

-----

Isiah Meadows
[hidden email]
www.isiahmeadows.com

On Mon, Oct 22, 2018 at 3:08 AM bishwendu kundu <[hidden email]> wrote:
>
> Hi Kai Zhu,
>
> I agree with you the new proposition should be of value to a web developer in daily work. If we observe the pattern it more closely resembles a more declarative form of solution implementation which is easy to code and understand. For example lets consider below piece of code:
> ```js
> function sum_list(input, result){
>     if(!input.length)
>         return result;
>     [head, ...input] = input;
>     return sum_list(input, result + head);
> }
> ```
> Now the same code in the new proposal form
>
> ```js
> function sum_list([head, ...tail], result){
>     result = result + head;
>     return sum_list(tail, result);
> }
>
> function sum_list([], result){
>     return result;
> }
> ```
>
> This declarative model of coding also forces an immutable form of state management allowing for removing a family of bugs.
>
> Thanks & Regards,
> Bishwendu.
>
> On Wed, Oct 17, 2018 at 12:57 PM kai zhu <[hidden email]> wrote:
>>
>> hi Bishwendu, javascript is first-and-foremost a tool designed for web-product-development, a growing field that has eclipsed low-level general-purpose programming (where jobs are harder and harder to find) in the IT industry.
>>
>> you need to give compelling reasons (for such significant language-change) why i, a web-developer would benefit from from having overloaded-functions in my (mostly expendable-code) web-projects, as opposed to creating confusion and maintennance-headaches, when i typically have to rewrite code multiple-times during the web-integration process.
>>
>> kai zhu
>> [hidden email]
>>
>>
>>
>> On 17 Oct 2018, at 12:23 PM, bishwendu kundu <[hidden email]> wrote:
>>
>> Hello All,
>>
>> I have been a great fan of the evolution of JavaScript in the recent past. The language is steadily closing the gap to ideal functional paradigm. One of the things that I have liked the most about languages like Erlang/Elixir/Haskell is their ability to define functions with same name and different airty. The decision of invoking the correct function-argument pattern is dependent on the invocation of the function. Implicit pattern matching in aforementioned languages helps avoid costly cognitive loads introduced by explicit if/else based pattern of logic flow branching.
>>
>> The greatest power of the pattern matching which amazed me was, dropping the whole of looping construct, altogether. Elixir/Erlang have no LOOPS. Stack based recursive calls combined with JavaScript's closures suddenly strikes me as a very powerful programming model that not only increases readability of code but also promotes immutability of the data structures in use. The loops would continue to exist but more modern codes can be written leveraging the recursive model of JavaScript.
>>
>> With de-structuring of arrays & objects already in place in JavaScript, pattern-matching of functions can fit right in perfectly, thereby taking JavaScript another step closer to ideal functional programming model.
>>
>> Looking forward to your response.
>>
>> Thanks & Regards,
>> Bishwendu.
>> _______________________________________________
>> 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
_______________________________________________
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: Function Overloading or Pattern Matching of functions in Ecma

Cyril Auburtin

On Mon, Oct 22, 2018 at 10:35 PM Isiah Meadows <[hidden email]> wrote:
You might want to check out the proposal's repo and make the suggestion there (it's been considered already IIRC, and I believe it was already noted in the repo as a possible future extension): https://github.com/tc39/proposal-pattern-matching
On Mon, Oct 22, 2018 at 15:38 Matthew Robb <[hidden email]> wrote:
Perhaps the following form could eventually make sense for pattern matching in function declarations:

```js
function sum_list(input, result = 0) case (input) {
    when [head, ...tail] -> {
        return sum_list(input, result + head);
    },

    when _ -> { return result; }
}
```  


- Matthew Robb


On Mon, Oct 22, 2018 at 8:48 AM Isiah Meadows <[hidden email]> wrote:
As mentioned previously, the pattern matching proposal does a lot to help here:

```js
function sum_list(input, result = 0) {
    case (input) {
        when [head, ...tail] -> return sum_list(input, result + head),
        when _ -> return result,
    };
}
```

-----

Isiah Meadows
[hidden email]
www.isiahmeadows.com

On Mon, Oct 22, 2018 at 3:08 AM bishwendu kundu <[hidden email]> wrote:
>
> Hi Kai Zhu,
>
> I agree with you the new proposition should be of value to a web developer in daily work. If we observe the pattern it more closely resembles a more declarative form of solution implementation which is easy to code and understand. For example lets consider below piece of code:
> ```js
> function sum_list(input, result){
>     if(!input.length)
>         return result;
>     [head, ...input] = input;
>     return sum_list(input, result + head);
> }
> ```
> Now the same code in the new proposal form
>
> ```js
> function sum_list([head, ...tail], result){
>     result = result + head;
>     return sum_list(tail, result);
> }
>
> function sum_list([], result){
>     return result;
> }
> ```
>
> This declarative model of coding also forces an immutable form of state management allowing for removing a family of bugs.
>
> Thanks & Regards,
> Bishwendu.
>
> On Wed, Oct 17, 2018 at 12:57 PM kai zhu <[hidden email]> wrote:
>>
>> hi Bishwendu, javascript is first-and-foremost a tool designed for web-product-development, a growing field that has eclipsed low-level general-purpose programming (where jobs are harder and harder to find) in the IT industry.
>>
>> you need to give compelling reasons (for such significant language-change) why i, a web-developer would benefit from from having overloaded-functions in my (mostly expendable-code) web-projects, as opposed to creating confusion and maintennance-headaches, when i typically have to rewrite code multiple-times during the web-integration process.
>>
>> kai zhu
>> [hidden email]
>>
>>
>>
>> On 17 Oct 2018, at 12:23 PM, bishwendu kundu <[hidden email]> wrote:
>>
>> Hello All,
>>
>> I have been a great fan of the evolution of JavaScript in the recent past. The language is steadily closing the gap to ideal functional paradigm. One of the things that I have liked the most about languages like Erlang/Elixir/Haskell is their ability to define functions with same name and different airty. The decision of invoking the correct function-argument pattern is dependent on the invocation of the function. Implicit pattern matching in aforementioned languages helps avoid costly cognitive loads introduced by explicit if/else based pattern of logic flow branching.
>>
>> The greatest power of the pattern matching which amazed me was, dropping the whole of looping construct, altogether. Elixir/Erlang have no LOOPS. Stack based recursive calls combined with JavaScript's closures suddenly strikes me as a very powerful programming model that not only increases readability of code but also promotes immutability of the data structures in use. The loops would continue to exist but more modern codes can be written leveraging the recursive model of JavaScript.
>>
>> With de-structuring of arrays & objects already in place in JavaScript, pattern-matching of functions can fit right in perfectly, thereby taking JavaScript another step closer to ideal functional programming model.
>>
>> Looking forward to your response.
>>
>> Thanks & Regards,
>> Bishwendu.
>> _______________________________________________
>> 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
_______________________________________________
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

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