{"action":"created","issue":{"url":"https://api.github.com/repos/tc39/proposal-pattern-matching/issues/117","repository_url":"https://api.github.com/repos/tc39/proposal-pattern-matching","labels_url":"https://api.github.com/repos/tc39/proposal-pattern-matching/issues/117/labels{/name}","comments_url":"https://api.github.com/repos/tc39/proposal-pattern-matching/issues/117/comments","events_url":"https://api.github.com/repos/tc39/proposal-pattern-matching/issues/117/events","html_url":"https://github.com/tc39/proposal-pattern-matching/issues/117","id":334298861,"node_id":"MDU6SXNzdWUzMzQyOTg4NjE=","number":117,"title":"Pattern matching NewExpression/CallExpression","user":{"login":"littledan","id":189835,"node_id":"MDQ6VXNlcjE4OTgzNQ==","avatar_url":"https://avatars3.githubusercontent.com/u/189835?v=4","gravatar_id":"","url":"https://api.github.com/users/littledan","html_url":"https://github.com/littledan","followers_url":"https://api.github.com/users/littledan/followers","following_url":"https://api.github.com/users/littledan/following{/other_user}","gists_url":"https://api.github.com/users/littledan/gists{/gist_id}","starred_url":"https://api.github.com/users/littledan/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/littledan/subscriptions","organizations_url":"https://api.github.com/users/littledan/orgs","repos_url":"https://api.github.com/users/littledan/repos","events_url":"https://api.github.com/users/littledan/events{/privacy}","received_events_url":"https://api.github.com/users/littledan/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":2,"created_at":"2018-06-21T00:54:44Z","updated_at":"2018-06-23T00:34:45Z","closed_at":null,"author_association":"MEMBER","body":"In the May 2018 TC39 meeting, @zkat presented the possibility of having pattern matching on NewExpressions. I think this is a great idea, but I didn't see anything in this repository for it. I wanted to suggest some concrete syntax and semantics\r\n\r\n### Syntax and semantics\r\n\r\nSyntax of new things that can be put as the thing which comes after `when`:\r\n```\r\nCallExpression[?Yield, ?Await] Arguments[?Yield, ?Await]\r\nnew MemberExpression[?Yield, ?Await] Arguments[?Yield, ?Await]\r\nnew MemberExpression[?Yield, ?Await]\r\n```\r\n\r\nWhen matching against any of the three constructs, the expression (either `CallExpression` or `MemberExpression`) is evaluated, and a Symbol-named method is called, with the object being patched passed in as the argument. For the `new` constructs, let's call that method `Symbol.invertConstruct`; for calls, let's call this `Symbol.invertCall`. The method is expected to return either `null` (indicating a failed match) or an iterator. If it returns non-null, that value is treated as an iterator and is matched against the argument list of the construct/call, with the same algorithm as pattern matching on Array literals.\r\n\r\n### Example\r\n\r\nLet's do Lisp! Stack space and useful variable names be damned.\r\n\r\n```js\r\nconst map = (fn, list) => case (list) {\r\n  when cons(car, cdr) -> cons(fn(car), map(fn, cdr))\r\n  when nil() -> nil()\r\n};\r\n```\r\n\r\n(Note, the above depends on the ability to use the above example depends on the ability to use `case` expressions, as proposed in #116.)\r\n\r\nThere's a million ways this could be implemented, but here's an especially poorly designed one:\r\n\r\n```js\r\nfunction nil() { return null; }\r\nnil[Symbol.invertCall] = arg => arg === null ? [] : null;\r\n\r\nfunction cons(car, cdr) { return {car, cdr}; }\r\ncons[Symbol.invertCall] = arg =>\r\n    typeof arg === 'object'\r\n    && Object.getOwnPropertyNames(arg).toString() === \"car,cdr\" ? \r\n    [arg.car, arg.cdr] : null;\r\n```\r\n\r\n### Possible future extensions\r\n\r\n- The above proposal doesn't really handle constructor functions which are overloaded between different argument types. Sometimes, what's textually present as the arguments could give a hint here. In a follow-on proposal, the hint could be passed as the second argument to the `invert` function.\r\n- Although this proposal is somewhat similar to variable pinning and collection literals in use cases, it still composes well with them (they don't really interact).\r\n\r\nShameless, irrelevant plug: see [my related work](http://micsymposium.org/mics_2009_proceedings/mics2009_submission_72.pdf) in Factor."},"comment":{"url":"https://api.github.com/repos/tc39/proposal-pattern-matching/issues/comments/399616177","html_url":"https://github.com/tc39/proposal-pattern-matching/issues/117#issuecomment-399616177","issue_url":"https://api.github.com/repos/tc39/proposal-pattern-matching/issues/117","id":399616177,"node_id":"MDEyOklzc3VlQ29tbWVudDM5OTYxNjE3Nw==","user":{"login":"littledan","id":189835,"node_id":"MDQ6VXNlcjE4OTgzNQ==","avatar_url":"https://avatars3.githubusercontent.com/u/189835?v=4","gravatar_id":"","url":"https://api.github.com/users/littledan","html_url":"https://github.com/littledan","followers_url":"https://api.github.com/users/littledan/followers","following_url":"https://api.github.com/users/littledan/following{/other_user}","gists_url":"https://api.github.com/users/littledan/gists{/gist_id}","starred_url":"https://api.github.com/users/littledan/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/littledan/subscriptions","organizations_url":"https://api.github.com/users/littledan/orgs","repos_url":"https://api.github.com/users/littledan/repos","events_url":"https://api.github.com/users/littledan/events{/privacy}","received_events_url":"https://api.github.com/users/littledan/received_events","type":"User","site_admin":false},"created_at":"2018-06-23T00:34:45Z","updated_at":"2018-06-23T00:34:45Z","author_association":"MEMBER","body":"@luftzig Maybe that would make sense with the pinning feature? The proposal alone adds something further--datatype-specific pattern matching logic, not just a way to pattern match on property accesses."}}
{"actor":{"display_login":"littledan"}}