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 <[email protected]> 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 <[email protected]> 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 <[email protected]> >> 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 >>> [email protected] >>> www.isiahmeadows.com >>> >>> On Mon, Oct 22, 2018 at 3:08 AM bishwendu kundu <[email protected]> >>> 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 <[email protected]> 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 >>> >> [email protected] >>> >> >>> >> >>> >> >>> >> On 17 Oct 2018, at 12:23 PM, bishwendu kundu <[email protected]> >>> 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 >>> >> [email protected] >>> >> https://mail.mozilla.org/listinfo/es-discuss >>> >> >>> >> >>> > _______________________________________________ >>> > es-discuss mailing list >>> > [email protected] >>> > https://mail.mozilla.org/listinfo/es-discuss >>> _______________________________________________ >>> es-discuss mailing list >>> [email protected] >>> https://mail.mozilla.org/listinfo/es-discuss >>> >> _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
