inconsistent Sindarin syntax

[fbach]

The attached Sindarin file 'foo1.sin' crashes due to the two-sided invariant mass cut (compare with working example 'foo2.sin'), although the same syntax works for cutting on any eta interval

[Juergen Reuter]

Such a statement also fails

   and all (130 GeV)^2 > M2 [e2,E2]

but should be permitted in principle. So this is either a flaw in the ifile_append structure, or there is a bogus in the recursive subroutine eval_node_compile_compared_expr. WK has to look into this, unfortunately. I suppose it's a quick one, which should get fixed pretty soon.

[kilian]

I suppose it's a quick one, which should get fixed pretty soon.

Couldn't be more wrong than that ...

First of all, there is an ugly but simple workaround:

   and all + (50 GeV)^2 < M2 < (130 GeV)^2 [e2,E2]

does work. This needs some explanation:

When I constructed the language, I insisted that the parser could determine the type of every legal expression (numeric, logical or string). Furthermore, the parser has no lookahead, so it determines the type of an expression by looking at the first token. This is the reason for the ? and $ prefixes for logical/string variables.

In the present case, once the parser finds the opening bracket, it assumes that the expression in brackets is logical, which is wrong. Stated differently, only one of

?foo = (0) < 1
?foo = (0 < 1)

can possibly work, but not both. The present choice is that the second line works, but not the first line.

So, this is a fundamental design flaw in the compiler. There are two generic solutions, which would also remove the need for prefixes: (1) Introduce lookahead for the parser [which has other implications], or (2) separate parsing and type checking.

I'd opt for the second solution, and I already did some exploratory work in that direction. However, this is a considerable task given the current pace of development --

I have to admit that comparisons can't be compiled if the l.h.s. starts with a bracket, and this is a WONTFIX right now.