Erik,
You're not think 5th dimensionally here;
Currently without fixing this bug a use has the expression statement of;
var a = ((a + b) - (c + d)) * e;
They use the compiler, it checks out fine, FalconJx is currently
rendering to JavaScript that will get executed;
var a = a + b - c + d * e;
See a problem here?
I have tested a fix that produces;
var a:* = ((a + b) - (c + d)) * e;
I have to fix all sub emitters that override emitBinaryOperator().
Fortunately it looks like we didn't add a lot of test code that relies
on operator precedence so the test code to change looks not that
difficult to update.
Mike
Quoting Erik de Bruin <e...@ixsoftware.nl>:
Agreed (on the 'simple' fix).
A thought: isn't doing this in Jx not somewhat over the top? I mean,
if you are going to 'calculate' the parenthesis somehow, you might be
fixing the user's code - after all, the user can put them in however
he likes... Isn't there a way for the parenthesis to be (and this is
probably going to sound silly, but I'm not so deep into this stuff
that I know the actual jargon) part of the AST, so we can just 'visit'
and 'emit' them?
EdB
On Wed, Mar 6, 2013 at 4:37 PM, Michael Schmalle
<apa...@teotigraphix.com> wrote:
Don't worry about this one.
When I fix this, I'm just going to have to get every test working again
before I commit. I have time since this is a breaking bug that will render
complex binary expressions useless as it stands.
What I plan on doing is the most simple fix. Since I know that the tree is
correct, I will probably implement this in the before and after strategy to
wrap any binary expression that is an operator in ( ). This might cause some
extra parenthesis that "might" not be needed but for now I see this as the
safest and most accurate way to proceed.
Mike
Quoting Erik de Bruin <e...@ixsoftware.nl>:
Mike,
Sure, no problem. I'm not planning any work on Jx the next couple of
days, so if you figure something in that time, go ahead and implement.
Also, if you need help fixing tests, I don't mind, so feel free to
ask.
EdB
On Wed, Mar 6, 2013 at 4:22 PM, Michael Schmalle
<apa...@teotigraphix.com> wrote:
Erik,
Now that I'm getting back into the core framework again I am wishing that
I
would have taken care of a bug that I knew about.
There is a serious problem that has to be fixed. Since we don't save
tokens
from the parser, a Binary AST tree knows nothing about it's order of
operations when output using the visitor framework.
The fortunate thing here is that when the ASParser assembles these nodes,
they are assembled based on operator precedence.
The unfortunate thing is, when I go to fix this its more than likely
going
to affect a huge amount of tests.
My plan is to create tests based on my other project so I stay out of the
main framework for now. When I figure out something that works I will let
you know because we should again be on the same revision so there aren't
hard merge issues.
Mike
--
Michael Schmalle - Teoti Graphix, LLC
http://www.teotigraphix.com
http://blog.teotigraphix.com
--
Ix Multimedia Software
Jan Luykenstraat 27
3521 VB Utrecht
T. 06-51952295
I. www.ixsoftware.nl
--
Michael Schmalle - Teoti Graphix, LLC
http://www.teotigraphix.com
http://blog.teotigraphix.com
--
Ix Multimedia Software
Jan Luykenstraat 27
3521 VB Utrecht
T. 06-51952295
I. www.ixsoftware.nl
--
Michael Schmalle - Teoti Graphix, LLC
http://www.teotigraphix.com
http://blog.teotigraphix.com
