Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Tolga]

I  think the new changes in the expression mechanism broke some past code. This may be by design but I wanted to double-check since the resulting mechanism can get difficult to debug in some cases.

 MC allows parantheses without escape characters in calculated values as long as it could parse them. For example I can have tag value:

[bla] = bla bla bla (more bla)

The following expression used to work but now it gives syntax error:

[bla2] = IsEqual([bla], more bla,

Since we do not have direct control of inline functionality, it is weird that [bla] does not return syntax error, but [bla2] returns one. This makes tracking bugs difficult. I recommend that MC either does stronger syntax checking and returns syntax error for [bla] and enforces user to type bla bla bla /(more bla/) or allows bla bla bla (more bla) value but converts it to bla bla bla /(more bla/) internally. I think the latter is better since it is more backwards compatible and easier on novice users.

(I may not be able to followup thread, if you can't replicate please send private message, or email k o n i k @ stanford.edu)

[Matt]

This is clearly a bug.  Good find.

I think adding a syntax to say "parse this as an independent subexpression" by surrounding stuff with /{ }/ might be the best solution.

In your example (simplified just a little):
[bla] = bla bla bla (more bla)
[bla2] = IsEqual([bla], more bla)

Currently inlines to this, which doesn't work:
[bla2] = IsEqual(bla bla bla (more bla), more bla)

However, if we used /{ }/, it would become:
[bla2] = IsEqual(/{bla bla bla (more bla)}/, more bla)

I'm still trying to decide what characters to use.  /# #/ means string.  Maybe /$ $/ or /% %/ would be better, because {} are characters that might actually need escapement someday.

Anyway, this seems like a safe and easy change, so look for a fix in a coming build.

[MrC]

Is it not possible for the inliner to add the blackslash escape to the parens in [bla]'s value during inlining?  And does the tokenizer not remove these automatically for passing as function arguments (so IsEqual() compares against the correct string)?

[Matt]

In a coming build:
Fixed: Expression inlining could cause problems if the inlined expression used parenthesis or commas outside of a function context.
Changed: Expression engine allows putting a subexpression in /% %/ to force it to be tokenized independently (used internally for inlined expressions).

Is it not possible for the inliner to add the blackslash escape to the parens in [bla]'s value during inlining?

That's basically what we're doing with the new sytax.  

It's a little complicated to just escape only the right stuff in [bla] since doing that requires understanding whether a parenthesis, comma, etc. should be escaped or if it's part of a function, math expression, etc.  Currently the code only works in the opposite direction -- deciding if things should be unescaped.

But with the approach above, the tokenizer can just call itself recursively with a fresh context when it encounters a /% %/ block.  This means there's really no new code, which is good.

[Tolga]

This works for me. Thank you for fixing it faster than I was able to take another look at this thread.