JavaScript Pattern Matching Proposal

Post by _delirium » Wed, Apr 25, 2018, 4:17 PM UTC

stiGGG wrote: post #69

lmm wrote: post #38

Earlier quoted context omitted.

> It's been "trendy" since the 70's. It's been possible since the '70s but I've seen a lot more talking about it in the last 5-10 years.

Yeah, this applies to all that old Lisp features.

Post by Prefinem » Wed, Apr 25, 2018, 4:20 PM UTC

codedokode wrote: post #53

Zyst wrote: post #43

Earlier quoted context omitted.

In fairness I think that would look a bit more like this: const getDate = (date) => { switch (date) { case 1: return 'mon' case 2: return 'tues' default: return 'wed' } } let date = getDate(1) Which is, of course, still less terse. What I normally use when I have cases like this is an object-as-a-map. IE: const dates = { 1: 'mon', 2: 'tues' } let day = dates[3] || 'wed';

By the way, I don't think it is a good idea to write a function as a constant. Please compare this function getDate(date) { .. } to this: const getDate = (date) => { ... } The first version is more readable. We instantly see that it is a function and in a second case it looks like a constant at first. Also without the equal and arrow sign it looks simpler.

    new Promise(function (resolve, reject) {
        methodOne(data, function (error, response) {
            if (erorr) {
                reject(error);
            } else {
                resolve(response);
            }
        })
    })

    new Promise((resolve, reject) => methodOne(data, (error, response) => error ? reject(error) : resolve(response)));

Post by jerf » Wed, Apr 25, 2018, 4:23 PM UTC

tannhaeuser wrote: post #71

jerf wrote: post #54

Earlier quoted context omitted.

Erlang was built from the ground-up with pattern matching in mind, so it works. Instead objects are jammed into the pattern matching system, and where the two disagreed, pattern matching won. (Indeed, Erlang doesn't really even have objects, just some object-like convention.) In a language that started with an object model that has grown a lot of features, trying to jam pattern matching into it after the fact grows a…

I believe Erlang inherited its pattern matching from Prolog term unification since Erlang was prototyped as a DSL using Prolog's op built-in predicate (plus other Prolog parsing DSLs such as definite clause grammars). [1]: http://www.swi-prolog.org/pldoc/man?predicate=op%2f3

Post by ThurmaUman » Wed, Apr 25, 2018, 4:24 PM UTC

codedokode wrote: post #55

metalrain wrote: post #47

Earlier quoted context omitted.

I think match cases should be functions, since you have built those anyway. So instead of match (x) { expr... } you would have something like match(x, [ fn... ]) or match(x) { name: fn, name2: fn2 } where fn is like (objectToMatch) => { expr }

It could look like this: var x = match (response) { case { status:200 }: true; case { status: 404 }: false; case Number: 0; case SomeClass: 1; default: -1; };

    var x = (switch(true){
        case response === { status: 200 }:
            return true;
        case response === { status: 404 }:
            return false;
        case response === Number:
            return 0;
        case response === SomeClass: 
            return 1;
        default:
            return -1;
    });

Post by SilasX » Wed, Apr 25, 2018, 4:32 PM UTC