Skip to content
This repository has been archived by the owner on Sep 20, 2021. It is now read-only.

Add native arithmetical expressions support #11

Open
Hywan opened this issue Mar 2, 2014 · 26 comments
Open

Add native arithmetical expressions support #11

Hywan opened this issue Mar 2, 2014 · 26 comments

Comments

@Hywan
Copy link
Member

Hywan commented Mar 2, 2014

A trivial merge of Hoa\Math in this library to get native arithmetical expressions support.

It will introduce a change (so a break) in the grammar. Array declarations will be [1, 2, 3] and no longer (1, 2, 3). The library has the RC state, so we can still introduce BC breaks. I particulary ask @stephpy, @shouze and @osaris to get their feedbacks :-).

Note: we should not add new features in the grammar in the future. If we want more power, we should focus on Hoathis\Lua which is a much better scripting language (imperative, procedural, functional etc.).

@stephpy
Copy link
Member

stephpy commented Mar 3, 2014

I don't understand, you want to merge ruler and math grammar to support thinkgs like (2 + user.nb_vote) > context.minimum_vote_to_win ?

@Hywan
Copy link
Member Author

Hywan commented Mar 3, 2014

“merge” is not really appropriated. I just would like to see the same features, i.e. native arithmetical expressions. And to reply to your question: yes :-).

@stephpy
Copy link
Member

stephpy commented Mar 3, 2014

Ok, that would be a good point. But is “Ruler“ a good name ? May be it would be appropriated to make something more global like symfony\ExpressionLanguage ?

@Hywan
Copy link
Member Author

Hywan commented Mar 3, 2014

No, as I said, if we need more features, we should focus on Lua which is a real scripting language (more powerful than Symfony\ExpressionLanguage). But are arithmetical operations a need in rules? That's the real question I think.

@shouze
Copy link
Contributor

shouze commented Mar 3, 2014

@Hywan I think that Ruler should stay a Rete rule algorithm like lib. I'm not very confortable with the fact you can assign a value to any variable in this lib. Should be immutable & read only system I think.

@Hywan
Copy link
Member Author

Hywan commented Mar 3, 2014

@shouze Oh sure, it will be immutable. I propose the support of arithmetical expression, not assignation. The example of @stephpy is right: user.nb_vote + 2 > context.minimum_vote_to_win / 2 for example.

(thanks for the link)

@shouze
Copy link
Contributor

shouze commented Mar 3, 2014

ok, so I'm fully ok with that 👍

@Hywan
Copy link
Member Author

Hywan commented Mar 3, 2014

Actually, it will not be so much difficult (I think). Arithmetical operators will be introduce in the grammar and treated as Hoa\Ruler\Model\Operator. Maybe we will need some tricks for the minus operator bu we will see. Anyone interesting for a PR?

@Hywan
Copy link
Member Author

Hywan commented Mar 3, 2014

But what about the BC break it will introduce?

@stephpy
Copy link
Member

stephpy commented Mar 3, 2014

Why (1,2,3) could not be supported ? The SQL like syntax of rule is interesting, if we can keep it, it would be better.

@stephpy
Copy link
Member

stephpy commented Mar 3, 2014

Oh, due to conflicts with arythmetic operations (x + y) etc...

If we can't support it, let's go for []

@Hywan
Copy link
Member Author

Hywan commented Mar 3, 2014

(7) is an array or just 7 ;-) ? This is ambiguous.

@stephpy
Copy link
Member

stephpy commented Mar 4, 2014

This is ambigous indeed, but (7) in SQL is an array with only 7 value :)

@Hywan
Copy link
Member Author

Hywan commented Mar 4, 2014

@stephpy Hmm interesting. So, since we postulate the ruler language is close to SQL, do we need to introduce this BC break? Also, (7) is very “uncommon” but this is language design error from my point of view :-p.

@stephpy
Copy link
Member

stephpy commented Mar 4, 2014

Imoi, It would be nice to keep SQL syntax, but the question is “Is it possible ?".

@Hywan
Copy link
Member Author

Hywan commented Mar 4, 2014

Normally, yes. I have to test, but the only ambiguous syntax is an unary list like (7) which will be considered as an array with one element instead of a “flat” integer. But if the user is aware of it, there is no problem.

@stephpy
Copy link
Member

stephpy commented Mar 4, 2014

the difficulty is to supports 1 + (7) in (8) which should return true.

@flip111
Copy link

flip111 commented Mar 4, 2014

In the same line what will happen when you do (2, 3) * (5, 6) matrix calculation?

@stephpy
Copy link
Member

stephpy commented Mar 4, 2014

@flip111 it's not valid, (2,3) is an array, it's like array(2, 3) * array(5,6)

@Hywan
Copy link
Member Author

Hywan commented Mar 4, 2014

@stephpy, you said:

the difficulty is to supports 1 + (7) in (8) which should return true.

No it should not. 1 + (7) is “integer plus array”, which is not valid (PHP will try to cast anyway). So either (i) we introduce the BC break (an array declaration is surrounded by [ and ]), or (ii) the (7) will only represent an array. We have to know if the solution (ii) is restrictive for the user or not.

@stephpy
Copy link
Member

stephpy commented May 2, 2016

Is it still relevant ?

@shouze
Copy link
Contributor

shouze commented May 2, 2016

@Hywan just in case of BC break array notation support, the best thing should be indeed to adopt something similar to matlab notation no? So yes [ and ], so php array(1, 2)or [1, 2] should be represented by [1 2] notation. Parenthesis are so much essential in operation groups that they can't be used also for array notation.

@Hywan
Copy link
Member Author

Hywan commented May 9, 2016

@shouze Arrays are represented by [ and ] since a long time. The comments above are outdated.

@stephpy This might be still relevant I guess but this is still hard to implement. This will duplicate code from Hoa\Math, except if we re-use the arithmetical visitor.
Are you willing to do it?

@shouze
Copy link
Contributor

shouze commented May 9, 2016

@Hywan Oops, yes indeed, sorry.

@jubianchi
Copy link
Member

Looking at the code and grammars, this seems pretty hard to implement. At least, it will require many code duplication:

  • part of the Arithmetic.pp grammar will have to be added here
  • some of the rules in Arithmetic.pp will have to change a bit: for example, Arithmetic.pp expects a number token and Ruler works with floats and integers
  • The visitor from Hoa\Math will also have to be duplicated
  • The visitor will also have to be adapted: for example, Math expects a #variable node but Ruler does not have such node defined in its grammar

I think this is not as easy as it seems.

@Hywan
Copy link
Member Author

Hywan commented Sep 12, 2016

Yup, it's a very hard problem.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Development

No branches or pull requests

5 participants