Re: gm2 rejecting a constant statement as variable

[Gaius Mulley]

Alice Osako <alicetrillianosako@gmail.com> writes:

> I am currently intending to work with M2PP (https://github.com/m2sf/m2pp), 
> and for this purpose I have been writing a Makefile to compile all of the
> components and build the preprocessor. I have run the configuration script 
> (using the settings for ISO, GNU, POSIX, 32/64) and started preparing the make
> targets for the individual sub-modules.
>
> However, I have come across a surprising problem: several constant 
> initializations are being flagged as involving one or more variables. I have 
> confirmed
> that the assignments in question are, in fact, constant, but the compiler is 
> saying that they aren't.
>
> For example, the constant declaration:
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>   BitsInUse =
>     ORD(AddressableBits > MaxBits) * MaxBits +
>     ORD(AddressableBits <= MaxBits) * AddressableBits;
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> Gives the following error:
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> src/imp/Hash.mod:34:13: error: In implementation module ‘Hash’: in 
> assignment, cannot assign a variable to a constant ‘BitsInUse’
>    34 |   BitsInUse =
>       |             ^
> src/imp/Hash.mod:34:3: error: designator ‘BitsInUse’ is declared as a CONST
>    34 |   BitsInUse =
>       |   ^~~~~~~~~
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> I have confirmed that both AddressableBits and MaxBits are constants, and the 
> application of +, *, and ORD() on constants clearly should be recognized as
> constants as well. Indeed, immediately following this initialization is the 
> constant declaration
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>   TTP16  = ORD(AddressableBits>16) * 65535 + 1;
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> compiles without complaint.

Hi,

> (I am assuming that ORD(FALSE) should return zero, and ORD(TRUE)
> should return one,

correct

> which it clearly is the intended use in this code - in effect, a
> pocket ternary expression that only works with numeric values.)
>

I think this is a compiler error

> I noted that the error message does not specify the supposed variable
> in question, which would make it harder to debug even if there were a
> variable in the assignment.

indeed, I've fixed this locally:

$ gm2 constbool2.mod 
constbool2.mod:8:36: error: In program module ‘constbool2’: the procedure 
function ‘ORD’ is being called from within a constant expression and therefore 
the parameter must be a constant, seen expression
    8 |    BitsInUse = ORD(AddressableBits > MaxBits) * MaxBits + 
ORD(AddressableBits <= MaxBits) * AddressableBits;
      |                    ~~~~~~~~~~~~~~~~^~~~~~~~~

but I've seen this fix needs to be applied to most of the standard
procedure functions.  Once this is done and passes the regression tests
I'll push the git changes

> Am I missing something? I am not inclined to assume that this is a
> compiler fault, but if it isn't, I am not certain why it would see a
> variable in these assignments.

and then move on to the original bug, which is occurring due to the
comparison operator.  The result of the comparison is currently stored
in a variable - which needs to be fixed!

Many thanks for the bug reports - will fix,

regards,
Gaius