Function Overloading or Pattern Matching of functions in Ecma

Cyril Auburtin cyril.auburtin at gmail.com
Tue Oct 23 08:57:32 UTC 2018


I suggested it in
https://github.com/tc39/proposal-pattern-matching/issues/48, I think zkat
extended the proposal since with
https://github.com/tc39/proposal-pattern-matching/blob/latest/TO_INFINITY_AND_BEYOND.md

On Mon, Oct 22, 2018 at 10:35 PM Isiah Meadows <isiahmeadows at gmail.com>
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 <matthewwrobb at gmail.com> 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 <isiahmeadows at gmail.com>
>> 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
>>> contact at isiahmeadows.com
>>> www.isiahmeadows.com
>>>
>>> On Mon, Oct 22, 2018 at 3:08 AM bishwendu kundu <bishwenduk029 at gmail.com>
>>> 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 <kaizhu256 at gmail.com> 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
>>> >> kaizhu256 at gmail.com
>>> >>
>>> >>
>>> >>
>>> >> On 17 Oct 2018, at 12:23 PM, bishwendu kundu <bishwenduk029 at gmail.com>
>>> 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
>>> >> es-discuss at mozilla.org
>>> >> https://mail.mozilla.org/listinfo/es-discuss
>>> >>
>>> >>
>>> > _______________________________________________
>>> > es-discuss mailing list
>>> > es-discuss at mozilla.org
>>> > https://mail.mozilla.org/listinfo/es-discuss
>>> _______________________________________________
>>> es-discuss mailing list
>>> es-discuss at mozilla.org
>>> https://mail.mozilla.org/listinfo/es-discuss
>>>
>> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20181023/3fef8066/attachment-0001.html>


More information about the es-discuss mailing list