Parsing bug in blitzmx compiler

Hey ppl.
I found a small bug in the code parser of the blitzmax compiler.
It concerns arrays.

This occurs in blitzmax 1.30 (svn threading build)

SuperStrict
Framework brl.basic
Local arr:String[] = ["abc" . "def"];

'//     notice the dot here ^ should be a comma.

Print(arr[0]); '// prints 'def' instead of 'abc'.
Print(arr[1]); '// should be 'def', but throws 'out of bounds' error

First off, this compiles without an error, eventhough the dot is there instead of a comma.
Secondly, it causes the parser to completely ignore the first array entry.

Maybe the parser reads the '.' like '0.5' (you can write .5) and it considers the first parameter as 0 (or void for string)?
Confirm the error in Bmax 130 SVN 171

This must happen because strings are objects. I think it is more of an unintended side effect than a bug.

Framework brl.basic

Print
Print "abc".length
Print "abc"."def"

No, it is definitely a bug. This throws a compile error:

Print ("Hello")."World"

Whereas this compiles:

Local i:Int
Print i."Hello World!"

A parser error, like Jim T wrote above.

I would say it is definitely a bug, maybe. The docs give the syntax for Print as

Function Print( str$="" )

In your second example a string has been built from integer i. This object has a "Hello World!" field, whatever that means.

The first example won't compile, but

Print ( ("Hello")."goodbye" )

is okay. I guess this says something about the precedence of the dot operator.

Bug or not it is certainly peculiar.

Hi,

Well, it's kind of a 'feature'...

The way Max works, consts exist in all scopes - ie: you can use them anywhere.

So stuff like obj."string" means the const "string" was found in obj's scope!

This is 'right', but obviously a little icky. Will have a look into this soonish.