Re: Questions about behavior observed in gm2

[Jack Perry]

Hi, and thanks to Gaius, Eric, and Benjamin for the responses!

> currently gm2 defaults to pim settings and does not enable runtime checking.

Wow, I didn't realize there was that big a difference between pim and iso.

> > InOut.WriteInt(Part1, 0); (* needs to be Part1() *)

> Interesting - and thanks for the bug report - I'll investigate the above
> two issues

Sure. I don't know what the language standard is, but as to the other John's question: from my point of view, the bug is not that one has to write Part1() with parentheses, but that omitting the parentheses was not a compiler bug. Instead, it did a silent c-style cast, without even raising a warning. My impression was that this is at least a type mismatch: `Part1` is a function, not an integer, so if you want the function's address, you should be explicit about that. But again, I've been away from Modula-2 for a loooong time, so my interpration of that may be very wrong in the M2 context.

> The gm2 libraries consist of the DynamicStrings module which (if
> you choose to use the DynamicStrings.String data type) has the Slice
> procedure function which behaves in much the same way as Python

Aha, thanks; I will look into that. Dynamic strings would certainly prove useful as I chug through AoC.

If I may, I'd like to ask about another thing I observed the other day. I have a variant record

ParsedDigit = RECORD
CASE Valid: BOOLEAN OF
TRUE:
Value: CARDINAL;
ELSE
END;
END;

Suppose I want to initialize it, e.g.,

CONST PD1 = ParsedDigit { False } ;
PD2 = ParsedDigit { True, 3 };

FWIW this is not the particular one I was having trouble with; but the compiler refused to accept it. It kept saying I had an unknown field. Is this a known issue?

Jack Perry
--
I'd rather be unhappy than have a false, lying sort of happiness. -- Brave New World