Re: [Gm2] REAL precision

[SiTex Graphics]

Thanks Gaius for taking this request under consideration and for the
clear description of possible alternatives.

First I want to clarify that for us compatibility with other compilers
is not an issue of "legacy" code in the sense of old code that is
still in use but no longer under development.  We're not making a
one-time port of code to GM2.  We want to use GM2 on a code base that
is under active development using multiple compilers.  GM2 must work
with code that is compatible with other compilers, and we must be able
to automate any changes needed to compile the code with GM2.

My take on the options:

(ii):  we could live with this, especially if the default behavior
were REAL=float, LONGREAL=double.  Against this option:  yet another
configuration option to remember to change if the default is not
what's desired.

(iii):  Yet another switch to have to remember.  What happens if I
forget the switch when compiling one module in a project?  Will the
project still link?  Run?  How will I know what's gone wrong?

(v)a:  Yet more libraries added to the distribution.  Not clear if
anyone is using the extended precision libs.

(v)b:  Requires users to modify their code to obtain same results as
other compilers.

(v)c:  What happens if a user forgets to make the necessary changes to
one module in a project?

(v)d:  REAL=SHORTREAL:  Redefining basic system types just seems like
a bad idea in general and prone to generate all kinds of trouble if
say a user forgets to import the magic definition in a module.

(v)e:  In my experience GM2 does not yet handle equivalent types
consistently at least with respect to system types.  E.g., I've tried
using

TYPE
 INT32 = INTEGER32;

and run into more problems than if I simply search/replace INT32 with
INTEGER32.  That experience makes me wonder how well GM2 will handle
REAL=SHORTREAL...

(v) is the least desirable option in my opinion.  I'd rather live with
(i) than (v).

I vote strongly in favor of (iv).  LONGLONGREAL might be hard on the
eyes, but it's analogous to the approach taken by the developers of
C/C++ compilers when adding extended precision.  They did not change
the the "float" type to double-precision so a "double" could be
extended precision because that would break a huge base of existing
code.  They sensibly added a new type for the new functionality.

-Scott