[Oberon] Negative integer literals in Oberon

[Arnim Littek]

This theme and others that are particularly amenable to right-first-time software are at the core of Ada.  The effort up front is higher, but there's a body of evidence that suggests this up front effort is not wasted.  Adding it to Oberon-X would certainly defeat the purpose of a small language.  

Whether teaching the precepts of right-first-time software is suitable for teenagers is one question, but teenagers as a rule have no comprehension of the risks of leaky software.

Arnim

On Sat, 2 May 2020 21:40:52 +0200
Jan de Kruyf <jan.de.kruyf at gmail.com> wrote:

> >So to put the cat amongst the pigeons again :-)...
> 
> Yes very well said.😇 And all the birds are long ago in the highest tree
> they could find.
> And the cat sits licking itself in the sun: "It didn't happen anyway!"
> 
> So do I understand then that, to solve the multiple type size issue (which
> is basically a hardware issue)
> you propose sub-ranges (which are an aid to software development)??
> 
> I would not like to teach that to a 14 year old, Dave. My oldest son did
> very well with the Wirth and Reiser book
> at the time. It taught him reading and clear thinking. But this would have
> been a bridge too far
> because the primary concepts are fudged
> 
> 
> On Sat, May 2, 2020 at 6:06 PM <dave at brownsmeet.com> wrote:
> 
> > While I agree on Oberon 2007+, this is not sufficient for original
> > Oberon2 systems with SHORTINTs and (signed) BYTES. It's not an issue on
> > Oberon2007+ because of the freer integer type compatibility rules.
> >
> > e.g. myshort := 0FFFFH
> >
> > doesn't work on multi-size oberon2 compilers because 65535 is bigger
> > than MAX(SHORTINT) which is 32767.
> >
> > And using MOD to restrict the size doesn't work on such compilers
> > because the size of the result of an arithmetic operation such as MOD
> > that has a INTEGER parameters is INTEGER. There is no special case
> > handling for MOD: the compiler doesn't look at the right hand argument,
> > see if it is a constant, and work out how many bits that constant would
> > require.
> >
> > (It could, but I don't know of any that do, and it's not covered in the
> > language report, or in system specific documents that I have seen.)
> >
> > The more we discuss this the more I'm convinced that the compiler needs
> > to be more sophisticated: rather than hex constants being rapidly
> > treated as signed integers, they need a distinct intermediate
> > representation that can be taken through the expression evaluation
> > handling to the point where we can make a valid decision on whether they
> > are an acceptable size.
> >
> > But - this is quite a lot of special case code for compilers that
> > support multiple sizes of integer.
> >
> > And actually it is the support of multiple sizes of integer that is the
> > real can of worms here, hex literal issues are just one issue.
> >
> > So to put the cat amongst the pigeons again :-), I have seen no better
> > solution to multiple integer sizes than Wirth and Knudsen's original
> > Pascal 6000 compiler (circa 1975) and its support for integer subranges.
> >
> > The BYTE/SHORTINT/INTEGER/LONGINT approach is for me the worst solution,
> > it has neither the simplicity of a single INTEGER size, nor does it
> > avoid the complexities of subranges, while at the same time introducing
> > more special cases and limitations.
> >
> > Hey ho -- Dave.
> >
> >
> > On 2020-05-02 16:12, Joerg wrote:
> > > Dave
> > >
> > > For smaller values than the size of your CPU register it‘s not needed,
> > > as you always can enfoce what you want by using normal INTEGER
> > > arithmetic.
> > >
> > > b := FFH;
> > > word16 := 0CAFEH;
> > >
> > > or to be absolutely sure (although not needed)
> > >
> > > b := FFH MOD 100H;
> > > word16 := 0CAFEH MOD 10000H;
> > >
> > > All those literals are legal INTEGERs on a 32 CPU.
> > >
> > > But you can‘t use the same for values completely filling yor register
> > > that are no valid INTEGERs anymore.
> > >
> > > i := 0CAFEBABEH;
> > > is not going to work, as CAFEBABE needs more than 31 bit to be
> > > represented as positive INTEGER.
> > >
> > > br
> > > Jörg
> > --
> > Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
> > https://lists.inf.ethz.ch/mailman/listinfo/oberon
> >


-- 
Arnim Littek <arnim at actrix.gen.nz>