This repository has been archived by the owner. It is now read-only.

WIP Pattern Matching (Stage 0) #635

Closed
wants to merge 4 commits into
base: master
from

Conversation

Projects
None yet
5 participants
@krzkaczor

krzkaczor commented Jul 18, 2017

Work in progress. I am creating this PR so other people can see progress and contribute. Related issues: babel/proposals#6

I will align to all contributing guidelines in a very near future ;)

What's missing:

  • solve ambiguity between pattern matching and calling a match function (currently match is considered just another keyword which is obviously far from perfect)
  • ast nodes docs
  • some patterns ( ex. [...]) doesnt work
  • test cases for errors
  • align with contribution guidelines
@@ -31,7 +31,7 @@ export const reservedWords = {
// And the keywords
export const isKeyword = makePredicate(
"break case catch continue debugger default do else finally for function if return switch throw try var while with null true false instanceof typeof void delete new in this let const class extends export import yield super",
"break case catch continue debugger default do else finally for function if return switch throw try var while with null true false instanceof typeof void delete new in this let const class extends export import yield super match",

This comment has been minimized.

@hzoo

hzoo Jul 18, 2017

Member

We'll need to somehow fork this with the hasPlugin check as well right?

This comment has been minimized.

@xtuc

xtuc Jul 18, 2017

Member

You mean makePredicate([...] + this.hasPlugin('match') ? 'match' : '') ? Yes because match shoudln't be a keyword without the plugin.

This comment has been minimized.

@krzkaczor

krzkaczor Jul 18, 2017

@hzoo @xtuc I wonder if we should make match a keyword at all (or at least part of this array)?
If we do it then we need to tweak for all situations where match is currently being used as a valid identifier. Of course only when the plugin is enabled but when it is, it can break a lot of code out there.

What I imagined instead as a simplest implementation, is to tokenize it as a identifier and use lookup to determine if it should be a keyword in a given context (part of match expression or just a ex. function call match(something);).

This comment has been minimized.

@xtuc

xtuc Jul 18, 2017

Member

Yes, that makes sense. Or consider it as a keyword only in a certain context, but more ifs would be spread across the codebase I guess.

This comment has been minimized.

@krzkaczor
@hzoo

This comment has been minimized.

Member

hzoo commented Jul 18, 2017

We should start a discussion on the AST structure then (spec.md change)

@xtuc

This comment has been minimized.

Member

xtuc commented Jul 18, 2017

@hzoo what a about an AST repo with the Babel AST spec? We could PR and discuss there.

I want to avoid mixing AST and implementation discussions.

@xtuc xtuc referenced this pull request Jul 18, 2017

Open

Pattern Matching (Stage 0) #6

0 of 2 tasks complete
@hzoo

This comment has been minimized.

Member

hzoo commented Jul 18, 2017

I don't think we need an AST repo, babylon is already that repo at the very least 😛. Or just discuss in the proposal issue, I think it's fine, otherwise it would be an estree issue.

@alexeyraspopov

This comment has been minimized.

alexeyraspopov commented Oct 21, 2017

What’s the status of this PR? What’s left to be done? Any help needed?

@krzkaczor

This comment has been minimized.

krzkaczor commented Oct 21, 2017

@alexeyraspopov There is a small todo list in the ticket description. Unfortunately, I don't have time right now to continue work on this issue but I will come back to it in some time.

One of the first steps now should be re-aligning it with spec proposal - I am sure that it developed further.

Feel free to continue from where I left off ;)

@danez

This comment has been minimized.

Member

danez commented Nov 1, 2017

We moved babylon back into the monorepo at https://github.com/babel/babel/tree/master/packages/babylon.

Unfortunately pull requests cannot be migrated between repositories automatically. If this PR is still valid please reopen it there.
Thanks for your effort.

@danez danez closed this Nov 1, 2017

@hzoo hzoo referenced this pull request Nov 7, 2017

Closed

tc39-proposal-pattern-matching #6761

3 of 3 tasks complete
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.