-
Notifications
You must be signed in to change notification settings - Fork 17
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Pattern matching support #3
Comments
Gleb, I like the idea of generalizing Erlson syntax to support pattern-matching. I was thinking about ways to achieve it, but couldn't find a simple enough general-purpose solution. Even for the case you are suggesting, it is more complicated than that. For instance, as a fist step, you need to assign expression Also, suppose there's no element More importantly, by transforming Even if we don't consider function clauses, there are guard expressions and other pattern matching constructs (e.g. It is likely that all these things can be figured out and I don't mean to discourage you from doing this. It would be an interesting project, but it requires more time than I personally would be able to spend on it. |
Would you consider at least allowing pattern matching like the following? (Just a quick access to many variables in the dictionary) #{a=A, b=B, c=C} = Dict, I can send a patch if you wish. |
Sure! It looks like a useful feature. Just open a pull request and I'll merge it. |
Alright I will. However, considering how peculiar the project is, could you give me some pointers as to what I need to modify in order to add this? Is there changes to be made to the lexer/parser or should I be fine just matching and replacing in the parse transform? Thanks. |
Implementing it as a parse transform should be fairly straightforward. This is the clause in expr({match,LINE,P,E_0}, S) ->
{match,LINE,?pattern(P),?expr(E_0)}; I would't bother adding an in-place parse transform to |
I was wondering if it is possible to implement the simple pattern matching cases like:
introducing some artificial variables at compile time:
This would be much more complicated if we want to implement pattern matching for function clauses and more complex cases. But even such implementation would be a small step forward.
Anton, what's your opinion on this?
The text was updated successfully, but these errors were encountered: