[Oberon] SystemV- Heap + Module Space

[John R. Strohm]

Richard Hable said:
On 03.01.19 23:49, Skulski, Wojciech wrote:
>> Tomas:
>>> MODULE_LOAD_FAILURE
>>> This looks like `C' #define constant!
>>
>> Intentionally. Sometimes I am under an impression that the C community
>> has worked out some reasonable solutions. Do not say that in this
>> mailing list.
>
> Preprocessor definitions of constants are certainly no reasonable
> solution! See, you shouldn't have said it! :)
>
> I once had to maintain a large C program with lots of define statements
> like
>
>  #define XY_MASK 0x123
>
> arbitrarily distributed among various header files. Within the C source
> files there would be some bit operations using these “constants”. It was
> hell finding out what these operations would actually do at runtime. I
> had to grep through a large number of source files—which sometimes even
> lead to different definitions with the same name.

This usually indicates poor modularization at the source code file level.
This is all too common among "professional" C (and C++) programmers.

> And, of course, these definitions also did not add any additional
> flexibility, because they were used to process some binary file formats
> which could not be changed without breaking compatibility.

Flexibility is not the only object of the exercise.  Understandability is
also important.  In the case of arbitrary binary file formats, helping the
maintenance programmer understand the format will help him when he
has to chase an obscure bug in something that has to read or write that
binary format.

There is an argument frequently made that programs should
be written first to be understandable to the next person who must maintain
them, and second to be compiled to efficient code.  (As a DSP guy, who has
done real-time video image processing, where EVERY CLOCK COUNTS, I won't go
all the way down that road.  On the gripping hand, I find that it is USUALLY
the case that code that is written to be understandable is code that the
compiler has an easy time with.

> Now, in Oberon we have real constant definitions. Nevertheless, one has
> to navigate to the definition section to find out what will actually
> happen at runtime. In case of imported constants this requires first
> checking the import section to find the (possibly renamed) name of the
> referenced module and then analyzing the definition or source file of
> the imported module.

This is arguably a language shortcoming.  The complete symbol name should be
RIGHT THERE, in the code, including the module and class names, so that the
programmer can know immediately where to look.  Not incidentally, this also
allows an industrial-strength programming text editor to do the same thing.

> I thought I read this kind of advice somewhere in Oberon textbooks. And
> then I looked at the Oberon System code. Oh, my.
>
> But another priniciple of Oberon is to make it as simple as possible.
> Adding an additional indirection makes it less simple…

Given a choice between

   IF random_variable AND 16

and

   IF UART_status_register_copy AND UARTIO.TX_BUFFER_EMPTY

I'll go with the latter, every time.  I argue that it is FAR simpler, 
because
it tells me what is going on.  (Yes, there are other choices possible.)

> IMO, defining a constant usually only makes sense for values which are
> expected to have to be changed in the future, and if there are several
> references to it.

Here we disagree.

Even if the constant is only used ONCE, making something like

const TX_BUFFER_EMPTY = 16;

in the UARTIO module, and then using it the one time, tells me a lot more
than the basic raw magic number.

--John R. Strohm


---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus