FreeBASIC Compiler

PRINT isn't a function call, and doesn't allow the expression list to be
surrounded by parentheses (e.g. PRINT( 1, 2; 3 ) doesn't work). So there
isn't an issue with ambiguity.

But now you're wandering into issues of operator precedence. The way
operators are parsed shouldn't depend on the type of the expressions.
*(a.b) is fine if a is a udt and .b is a pointer, but (*a).b is fine if a
is a ptr to a udt with a .b field. *a.b isn't going to magically choose
the right one.

Interestingly, "print (*a).value1" does not error. I suppose "print
*a.value1" should error, though? (and it does)

I think the problem is, when the parser sees that first open bracket '(',
how is it supposed to know whether it's the start of a container for a set
of parameters '(a, b, c)', or a component of an expression '(a) + b, c'?
It needs to decide that before trying to parse the expressions inside.

But it looks like I've gone wrong somewhere, because this all works:

sub foo( byval a as integer, byval b as integer ): end sub

foo (1, 2) '' comma inside a single, bracketed argument (doesn't make
sense)
foo( 1, 2 ) '' two arguments separated by a comma (makes sense)

foo (1), 2 '' two arguments, one in brackets
foo( 1 ) , 2 '' comma following single-argument sub call (doesn't make
sense)

(the whitespace doesn't make a difference, just serves to illustrate
possible interpretations; each proc-call is equivalent to the other one
it's paired with)

Frankly this amazes me. From my initial looks at the parser code I don't
see how that's possible. I suspect it might have something to do with the
complicated identifier-parsing code, which would explain why it doesn't
work in your case, but that's just a guess.

(Incidentally, QB didn't have this problem because it didn't allow "foo(
a, b )" or "CALL foo a, b", so there was never any ambiguity.)

Anyway, as you've seen, the current workaround is always to wrap all the
arguments in a set of parentheses. It's not QB-compatible, but it'll have
to do.