Re: Some modules from Modula-2

[acken@informatik.uni-kl.de]

Mike wrote:
>  I'll volunteer to implement the following ISO modules:
>  
>  	LowReal, LowLong  (already partially covered by Math, MathL)
>  	RealStr, LongStr  
>  	RealConv, LongConv
>  	RealMath, LongMath (are these modules really necessary given Math(L)?)
>  	ComplexMath, LongComplexMath
>  
>  I suggest that the RealMath & LongMath simply be stubs which call the
>  appropriate Math or MathL routines.
>  
I'd rather have it the other way round: change the name of Math to
RealMath and MathL to LongMath.  I prefer the M2 names because they
use a quite orthogonal naming scheme for *Str, *Conv, *Math, and Low*.
The module names Math/MathL can then be dropped altogether
resp. turned into OakMath and OakMathL which would be stubs that call
the *Math modules.

I don't see how you can conveniently implement the Complex modules
without a builtin COMPLEX type.  Take for example the function 
  PROCEDURE conj (z: COMPLEX): COMPLEX; 
This can only be declared when COMPLEX is a pointer type, which isn't
very nice.  And complex constants like "i = CMPLX (0.0, 1.0)" aren't
possible at all.

Some remarks on the RealConv/RealStr modules:  It is absolutely
paramount that the conversion from real to string and vice versa is
precise to the last bit.  This probably prevents using any floating
point functions (+, /, exp, etc) to construct a string or calculate a
number from a string.  To illustrate this requirement I'll give an
example from the very early days of o2c: 
  The first RealStr module of o2c relied on the real operators and
various math functions to build/break down strings.  The algorithms
where pure Oberon, and naturally they contained a number of real
constants.  o2c was used to compile the module, and o2c used the
module to read in the real constants in the module sources.  
  But the real number conversion wasn't precise.  Whenever the
compiler read a real const from RealStr, it translated it to its
value+-something.  This v+-s value went into the module's next object
file.  This in turn was used to build a new compiler whose conversion
functions lost even more precision.  The new compiler converted reals
into something like value+-(2*something) and the whole cycle started
anew.  
  At the end each compilation of RealStr.Mod build conversion
functions that where a factor of 10 of the mark, and the gap was
widening... 
  Therefore my urge to implement RealStr/Conv with the greatest
possible care and without the use of any real arithmetic (at least in
the critical parts).

-- mva