[Oberon] Negative integer literals in Oberon

[dave at brownsmeet.com]

I think there are a couple of conversations going on here, I'm trying to
get straight what's being discussed. 

Arthur's original question was about passing 90909090H as a literal to a
32 bit INTEGER parameter, he found that Oberon 2013 supported it and VOC
didn't. 

I chimed in because I had tried to support this in VOC but had not been
able to. My response was an attempt to explain why VOC could not support
it but I suspect I just confused the matter. 

VOC is an Oberon 2 compiler including support for SHORTINT, INTEGER and
LONGINT, and for size conversions SHORT() and LONG(), and applies type
compatibility rules as per the OBERON 2 language report. 

This is in contrast to the Oberon 2007/2013/2016 language which has a
single integer size. (While it also has BYTE, it does not have the size
compatibility rules of Oberon 2, nor does it have SHORT() and LONG().
This makes it a lot simpler.) 

I think I am seeing some level of consensus that having a single INTEGER
size has benefits. 

(Aside - I worked a lot with the original CDC 6000 Pascal which had a
single integer size of 60 bits. It worked vary well, I miss it. All
arithmetic was done on 60 bit values. Additionally Pascal supported
subrange types - these did not affect arithmetic, but they did
  1) support compile time range and run time value checking
  2) affect storage size - only when used in packed records.
) 

I think the answer to Arthur's original question depends on whether his
goal is a single integer size compiler, or whether there is an intent to
add support for e.g. Oberon 2's SHORTINT and LONGINT. 

The crux of the issue from my point of view is that supporting 90909090H
as a 32 bit integer parameter is easy for a compiler like Oberon 2013
that supports a single INTEGER size, and not easy, or not possible for a
compiler that supports OBERON 2's multiple integer sizes. (Component
Pascal has the H vs L suffix workaround for 64 bit and 32 bit integers,
but does not provide similar solutions for 16 or 8 bit integers.) 

-- Dave. 

On 2020-04-27 00:55, Chris Burrows wrote:

> It is useful that Blackbox reports those compilation errors; it is less forgiving than many Oberon compilers. By not making assumptions it forces the programmer to really think about what he is trying to achieve. 
> 
> As far as I know there are no specific literal constants defined in Component Pascal for BYTE or SHORTINT values. 
> 
> If I were you I would implement two completely separate compilers. One that implements 32-bit INTEGERs and another that implements 64-bit INTEGERs and avoid mixing the two. In that way you can still conform to the Oberon Language report and not have to introduce any extensions. If you are concerned that a programmer might want to write code using the 64-bit compiler and then try to run it on the 32-bit compiler that is a problem for the programmer not you. 
> 
> If the programmer is writing code that he wants to run on both systems then he should separate any parts that are sensitive to the size of INTEGER and include assertions in those parts such as: 
> 
> ASSERT(SYSTEM.SIZE(INTEGER) = 8) 
> 
> to prevent it from accidentally being compiled for, and run on, the wrong platform. 
> 
> Regards, 
> 
> Chris Burrows 
> 
> CFB Software 
> 
> https://www.astrobe.com 
> 
> /lists.inf.ethz.ch/mailman/listinfo/oberon [1]
 

Links:
------
[1] https://lists.inf.ethz.ch/mailman/listinfo/oberon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.inf.ethz.ch/pipermail/oberon/attachments/20200427/e2a92b20/attachment.html>