Skip to content
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

Proposal: better negation syntax #12

Open
yrashk opened this issue Feb 2, 2012 · 6 comments
Open

Proposal: better negation syntax #12

yrashk opened this issue Feb 2, 2012 · 6 comments

Comments

@yrashk
Copy link
Contributor

yrashk commented Feb 2, 2012

So, right now the syntax is really awkwardly hard:

-neg_rule({determine_engine_state, [{'working-state', engine, '__IGNORE_UNDERSCORE__'},
                                    {repair, '__IGNORE_UNDERSCORE__'}]}).
%% ...
determine_engine_state(Engine, {start, _})
  when not {rule, [{'working-state', engine, _}, {repair, _}]} ->

I was just thinking, and basing on my experience writing Exportie (https://github.com/spawngrid/exportie) I am pretty sure we can pack this above example to:

determine_engine_state(Engine,{start,_},not([{'working-state', engine, _}, {repair, _}]) ->
...

I am not sure I can use not there, but if I can't, we can't settle with another keyword, such as negative or unless

If you agree with this proposal I will implement this and send a pull request. Please let me know.

@ericbmerritt
Copy link
Member

This seems reasonable to me. and its more inline with the direction I am thinking of going with the API rewrite. The only possible concern I have is making sure the negative is visible. however, I suspect its ok.

@yrashk
Copy link
Contributor Author

yrashk commented Feb 3, 2012

Alright. I will implement this additional rewrite then.

@yrashk
Copy link
Contributor Author

yrashk commented Feb 29, 2012

I am no longer sure this is a good idea. I mean, overall, it does seem to be interesting, but it will obscure rule's actual arity

@yrashk
Copy link
Contributor Author

yrashk commented Feb 29, 2012

I guess what confuses me in the existing syntax is this {rule, []}

What we can do (at least) is to get rid of the list, and if somebody wants to match multiple not-rules, they should do when not {rule, A} andalso not {rule, B} kind of thing.

Also, since we're controlling the parse transformation in question, may be we can make this look this way: not rule(A)? I am pretty sure I can do that with applications on forms level. I do the same thing to function arguments in exportie.

@ericbmerritt
Copy link
Member

I am ok with that I suspect.

@yrashk
Copy link
Contributor Author

yrashk commented Mar 1, 2012

good, will try playing with this whenever I'll get around that.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants