Off the cuff ;-)

DRL accepts Unicode letters for identifier, and any character in string literals.
Normally, this would make a language fully unicodable, but DRL has a few
nooks and crannies where the syntax isn't fully specified by the language.
For instance, after all the temporal operators, you may write '[' <text> ']',
and the parser will, no: should: accept anything as long as brackets contained
in <text> are properly balanced.

DSL shouldn't be a problem, since parsing it is a relatively simple pattern matching
operation (with some frills).

On 21 October 2010 21:55, Michael Anstis <michael.anstis@gmail.com> wrote:
Yes you are naughty ;-)

But it does lead me to question whether DRL and DSL can be unicode encoded (so DSL at least) can be localised language (U+007F is the end of Basic Latin/ASCII). Do you know the answer in your delvings?

On 21 October 2010 20:25, Wolfgang Laun <wolfgang.laun@gmail.com> wrote:
Well, yes, I'm naughty. I've implemented a  parameterized evaluator, using Unicode codepoint U+2282 as a parameter.

But the DRL parser refuses to accept this (as part of square_chunk_data):
  Line 60:59 no viable alternative at input ''
which indicates that the character isn't recognized at all.

I think this happens because, outside of strings, codepoints beyond U+007F aren't accepted anywhere except
those explicitly specified as IdentifierStart and IdentifierPart. Perhaps square_chunk_data after an operator
identifier could be made to behave more like a string.

Admittedly, this is esoteric, but it sure does look dazzling ;-)

Cheers
-W


_______________________________________________
rules-dev mailing list
rules-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev



_______________________________________________
rules-dev mailing list
rules-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev