Yasuki Arasaki writes:
 > The situation can be fixed (in decades time) by enabling somehow
 > the configuration of default real type. Google shows that this
 > point has been brought up several times before, but was not persued
 > further because it was just too much bother.

At one time, it was actually on J3's approved list as a feature to be
added.  It got dropped because of its difficulty; it isn't easy.

I'd love the feature, as would many other people.  Oh, and yes, Peter,
64-bit reals are almost universally needed in my applications, enough
so that I just standardly use 64-bit reals unless I have specific
reason to do otherwise.  While this isn't universal, I'm confident
that it is pretty common.

Reals aren't the only issue, though.  In some ways, reals are simpler
to handle than integers.  Even scientific codes tend to involve many,
many integers, probably more than reals though I haven't bothered to
take actual statistics.  Heck, for every array, you probably have one
or more integers involved in declaring its bounds for a start.  (I'm
counting an array as a single case; if you count each array element
separately, then reals likely dominate by a lot because there are
often large arrays of reals).  If you had to put a kind number on
every integer, it would probably make most codes more inscrutable than
if you had to put a kind number on every real.

Many large scientific codes do exceed the limits of 32-bit integers,
so yes, it is a significant issue.

Unfortunately, default integer worms its way into many places,
including a lot of the interface with the run-time library.  That
can make it pretty difficult to cleanly support user-specified
default integers.  Not impossible - please note that I don't claim
that; yes I know it can be done; but it is a bunch of work.

Compatibility with existing codes is, of course a major issue that
isn't likely to go away anytime soon.  Others in the thread have
mentioned this, but I have a feeling that some are underestimating
it.  No, I don't think it will be acceptable to try to "quarrantine"
the existing codes; if you think that will work, I think you are
underestimating the problem.

Another big problem area is compatibility between different files
compiled with different options in the same application.  This is
a problem today with the various -double/-r8/-whatever switches.
A user compiles his/her code with the switch, but then finds a
need to call a library not compiled with the same switch.  At best,
the interface becomes awkward.

Anyway, to summarize, while I think this a feature that would be
very useful, I also realize that it is a complicated one.  What
killed it last time, after it was already approved for the standard,
was that the people proposing and working on it underestimated
its difficulty.  I don't have any magic answers for the problem;
if I had a magic answer then it wouldn't be dificult.  I just have
the caution not to underestimate it: been there; done that; failed
to get the feature in as a result.

--
Richard Maine                |  Good judgment comes from experience;
[log in to unmask]       |  experience comes from bad judgment.
                             |        -- Mark Twain