Using constants not allowed in DATAs

[baltasarq]

Hi!
Another bug or at least improvement, sorry!
When I create constants, such as:
const DCMD_EOD                            as ubyte = 100
const DCMD_LINE                           as ubyte = 101
const DCMD_CIRCLE                         as ubyte = 102
const DCMD_FILL                           as ubyte = 103
const DCMD_UDG                            as ubyte = 104

And then try to use them like so (initializer expression):
sub draw_presentation()
    dim pic_data(11) as ubyte => { _
        DCMD_Circle, 50, 180, 10,  _
        DCMD_Fill, 50, 180,        _
        DCMD_Circle, 100, 160, 25, _
        DCMD_EOD }
   
    draw_pic( pic_data )
end sub

Or maybe like so (DATAs):
LocPics:
    ' Loc 0 - Limbo
    data DCMD_Line, 0, 180, 250, 100, _
        DCMD_Line, 250, 180, 0, 100, _
        DCMD_EOD

    ' Loc 1 - Landing
    data DCMD_Circle, 50, 180, 10,  _
        DCMD_Fill, 50, 180,        _
        DCMD_Circle, 100, 160, 25,  _
        DCMD_EOD

I receive the following errors:
For the use of constants inside DATAs:
locs.bas:64: warning: [W100] Using default implicit type 'float' for 'DCMD_Line'
locs.bas:69: warning: [W100] Using default implicit type 'float' for 'DCMD_Circle'
locs.bas:70: warning: [W100] Using default implicit type 'float' for 'DCMD_Fill'

This doesn't make any sense, since they are defined as constants of type ubyte.
For the use of these constants inside the constant initializer for an array:
reveni.bas:14: error: Initializer expression is not constant.
reveni.bas:19: warning: [W100] Using default implicit type 'float' for 'pic_data'
reveni.bas:19: error: Invalid argument 'pic_data'

Again, this doesn't make any sense, since they are constants but the initializer expression is erroneously detected as non-constant.
Could this be solved?
Thanks,

[boriel]

Ok. I will have a look at this.

[baltasarq]

Ok. I will have a look at this.

Thanks!!

[boriel]

You can track the progress here https://github.com/boriel-basic/zxbasic/issues/967
(I recommend to use the issue form, since it's more agile).

[boriel]

This is not a bug, but expected behaviour: the constant was declared all in UPPERCASE, but then when used it's not.
Boriel BASIC by default is case-sensitive, meaning that, like in other languages like C, case matters. If you want to compile this program as is, you can use the command line parameter --ignore-case. :-)

When you use an undeclared variable, in Sinclair BASIC you will get the error "Variable not found". But in other BASIC flavours (like Boriel BASIC) an undeclared variable is automatically created the first time it's used with default value of 0. The type will be automatically guessed (usually Float for maximum compatibility) and a warning will be issued. If you don´t want this behaviour you can compile with the flags --explicit and --strict.

--explicit requires all variables and functions to be declared before being used.

Code:

PRINT a: REM Error if compiled with --explicit

Code:

REM you can use #pragma to override command line flags. This one enforces explicit
#pragma explicit=true

DIM a: REM declares variable a with default (float) type
PRINT a

--strict is even more strict: requires the variable to be declared and typed

Code:

DIM a: REM will issue an error

Code:

DIM a As Ubyte
PRINT a

Note: if using --strict you don´t need --explicit, because to type a variable / function you need to declare it first. That said, if you use BOTH, the errors messages will be clearer.

[baltasarq]

I can't believe it. I'm so stupid. Sorry to make you waste your  time.
I'll activate strict and explicit.
Thank you,

[baltasarq]

As an outcome to use "strict" and "explicit" as compilation options, now the compiler complains about the sinclair basic function new being not declared.

Code:

sub do_cmd_end()
    ' more things...
    new
end sub

Output:

Code:

cmd.bas:164: error: Undeclared function "new"

It compiles it I replace the new function call with a randomize( usr( 0 ) ) call.
Should I include something for new?

[boriel]

This is unrelated to --strict and --explicit. The statement new is not implemented.
If you need it you can implement it yourself either as a macro

Code:

#define new randomize usr 0

or as a sub.
Simply, I didn't find it useful for a compiled program. Also, new preserves the RAMTOP (it deletes only the memory zone below the CLEAR limit). For a compiled program, like the ones generated with this compiler, the executable should always go above the RAMTOP and set it as low as possible (the region below the RAMTOP will be used for the stack and might overwrite the BASIC region if it grows too much.

[baltasarq]

I see... thanks.