[Oberon] Assumed issue in the Lola-2 compiler

[Jörg]

Wojtek

It heavily depends on the use case. My Display.Mod display driver for the colored frame buffer is full of SETs. So yes, I’m puristic enough to use SETs if appropriate.

Whether you use internally INTEGERs or SETs depends on the operations you apply to your values: Addition, subtraction is more for INTEGERs, Bit tests and mask operation is more for SETs, although you can mask with MOD and DIV on INTEGERs as well...

As important as the operations are the input/output routines for those values.
As shown in LSV.WriteHex, this output routine takes a (signed) INTEGER but effectively writes it as (unsigned) hex value even for INTEGERS where the highest (sign) bit is set.

br
Jörg

> Am 14.04.2019 um 18:20 schrieb Skulski, Wojciech <skulski at pas.rochester.edu>:
> 
> Paul:
> 
> yes, I know the design assumptions. I know that mixing the signed and unsigned types can lead to a nightmare. An example is provided in VHDL where I can import both signed and unsigned libraries, and of more than one kind at the same time. I did this in the past and I learned it is better avoided.
> 
> So maybe I should revert my comment and rather say that SET should be used for unsigned bit manipulation, while INTEGER and LONGINT (now being the same) is for math. But this is not a realistic position, either, as shown by this discussion. We are all conditioned to know how many bits the INTEGER has. As soon as there is a legitimate need for a 32 bit entity, we will throw in an INTEGER rather than a SET. But in this case the intent was a bit field rather than algebra, so INTEGER should not have been used. 
> 
> Is anyone going to be such a purist and start using SETs? You will probably agree that in practice we will all opt for INTEGERs. So there is a disconnect between a preferred practice and the envisioned intent behind both types. LOLA is an example which is more directed towards bit manipulation than math. Therefore, SETs should have been used, but they were not. It is a hint that perhaps the language is too minimalist in this case.
> 
> Wojtek
> 
> @Wojtek, as you know, Oberon-07 is intentionally a minimalist language,
> in reaction, for example, to Modula-2, where Prof. Wirth rues that he
> was persuaded to add too many features, types etc..  So please give an
> example of where unsigned types are "necessary" and what that even
> means, so we can have a sensible discussion.  Thanks!
> 
> --
> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
> https://lists.inf.ethz.ch/mailman/listinfo/oberon