[Oberon] Type compatibility in Oberon

[Chris Burrows]

As has been suggested elsewhere, if you are concerned about running your program on several different 32-bit INTEGER systems then you might sleep better at night if you wrote:

 i := SYSTEM.VAL(INTEGER, 9502F900H)
 
Otherwise, what would you propose as a solution to your problem? 

If all you are asking for is a change to the Language Report what would be the *exact* words that you would use to "clarify the semantic" to avoid any form of ambiguity? Would you have any concern about what effect this change would have on the backward compatibility of existing code?

An alternative solution if you want to design your own new language would be to introduce an unsigned data type perhaps? Maybe called 'CARDINAL'? If so, I can't say I would be very enthusiastic about that idea. I did lot of Modula-2 programmimg in the 1980's and have quite a strong recollection of painful experiences resulting from programs that had mixtures of INTEGER and CARDINAL. 

What might be 'correct' from a pedantic, dogmatic viewpoint unfortunately is often not useful when dealing with grubby real world programming problems. These problems tend to be grey rather than the black and white kind that unimaginative programmers wish for. 

Tools which adopt a more lenient, pragmatic approach are needed to tackle fuzzy real world problems. 

What is crucially important is that a competent programmer has the capability to direct a compiler to do what he wants it to do based on his understanding of the language not what a compiler implementer thinks is best for him. If the language is too prescriptive or too dependent on specific physical hardware characteristics the compiler implementer is limited in what he can deliver. That was a major problem with Pascal. 

A competent programmer continually performs unit tests during his development activities. If he is unable to explain the results, he has the choice of asking for technical support from the compiler maintainer or devising a more predictable solution to his problem. The latter is usually the more expedient route to take. It is usually easier to change your own behaviour than attempt to change somebody else's. Fortunately, when developing software, there's always more than one way to skin a cat.

To conclude - at the risk of opening up another can of worms, (or waking sleeping dogs!) I would make the observation that the current question of when and how hexadecimal constants should be used pales into significance when compared with many other day-to-day issues a programmer typically has to face. Dealing with floating point arithmetic is one example that springs to mind.  

Regards,
Chris Burrows
CFB Software
https://www.astrobe.com

 

> -----Original Message-----
> From: Joerg [mailto:joerg.straube at iaeth.ch]
> Sent: Saturday, 2 May 2020 12:13 AM
> To: chris at cfbsoftware.com; ETH Oberon and related systems
> Subject: Re: [Oberon] Type compatibility in Oberon
> 
> If the system uses a 32bit CPU and the Oberon compiler spits an error on
>   i := 2500000000;
> saying �nbr too big� I accept it, as the Oberon report does not specify
> the size of an INTEGER;
> 
> But I find it strange that the very same compiler allows
>    i := 9502F900H;
> that is - according to my reading of the Oberon report - the same as the
> first statement.
> 
> Basically, the above compiler allows decimal literals from 0 to 2.147
> billion, but hex literals from 0 to 4.29 billion.
> 
> In my point of view, what the compiler does is what the programmer of low
> level modules expects from hex notation. It would help if the Oberon
> report would clarify the semantic.
> 
> Don�t misunderstand me: the hex notation is useful (especially for low
> level programming), and it would be cumbersome being forced by a strict
> compiler to use -6AFD0700H just to reach the same goal.
> 
> br
> J�rg
> 
> > Am 01.05.2020 um 15:41 schrieb Joerg <joerg.straube at iaeth.ch>:
> >