g77 future / proposed extension

g77 future / proposed extension

[Grant Petty]

CC: GNU/GCC project

Dear Craig,

I am a latecomer to the g77 scene and just went looking on the web for
info on the status of g77.  I did not know (before now) that its future
development was in doubt. While I completely understand the dilemma faced
by people involved in the support and improvement of g77, the reason I
went looking in the first place, and why I am writing you now, is to
suggest a new opportunity and rationale for g77 development that may have
been previously overlooked.  I know you have taken yourself off the g77
project, so please forward this message to someone else if appropriate,
and thanks for your past efforts!

I am an academic scientist who has long perceived a GLARING deficiency in
"standard" computer languages with respect to scientific computing.  In
contrast to system programming and consumer application programming,
scientific programming (e.g., data analysis, modeling, etc.) almost
invariably involves quantities with physical dimensions (length, force,
temperature, mass, etc.) rather than mere numbers. The universal
deficiency I perceive lies in (1) the assumption that numerical values in
mathematical expressions are physically dimensionless (unitless)
quantities, and (2) the requirement that the programmer bear the burden of
hand-coding unit conversions and of verifying dimension and unit
consistency in all calculations and in the passing of arguments between
functions.  To give a simple example, a calling program might use
millimeters to describe the diameter of a raindrop, whereas a called
subroutine obtained from another source might expect meters or cm.  And
far more complex examples exist.

It has been my experience that the most tedious part of scientific
programming, and one of the aspects most prone to error, is item 2, above.
Surprisingly, it has also been my experience that virtually no one in the
scientific community has ever stopped to consider whether this is a
desirable or necessary state of affairs!

I concluded that some surprisingly simple and (to my mind) technically
straightforward extensions to a language like Fortran could accommodate
physical units in a very natural and intuitive way, eliminate an important
source of errors and paving the way to a more robust style of scientific
programming.

Clearly, other languages could benefit from this as well, and some (such
as C++) might even be able to accommodate my ideas without actually
extending the language itself.  But I single out Fortran because it
remains the language of choice for most scientific programmers today and
because there is a huge body of legacy code "out there" that could be
modified in relatively simple ways to take advantage of the proposed
extensions.

The logical place, in my opinion, to implement and demonstrate a Fortran
extension of potentially great importance to scientists and engineers
would would be in an established community compiler like g77.  A
successful demonstration of the ideas I'm describing would, just maybe,
put g77 on the leading edge of a long-overdue overhaul of scientific
computing.

The essence of the proposed changes is simple:

1) Define a small number of new data types in addition to the standard
ones of REAL, INTEGER, and CHARACTER.  An example would be something I
call PREAL, which would be identical to REAL except for a few additional
bits for storing physical dimensions. 

2) Extend the standard mathematical operators and functions (and possibly
I/O functions) to do the correct thing with the new data types and to do
some simple run-time error checking.

Conceptually, at least, I think I have the details pretty much worked out
(see http://meso.eas.purdue.edu/~gpetty/fortran_proposal.txt ). But I am
not a compiler person, nor even a professional programmer, and could not
possibly hope to implement the proposed extensions in a working compiler.  
My question is therefore simple: is the GNU/gcc/g77 project the right
place to turn for help in demonstrating the concept?  If not, can you
suggest alternative avenues?

If I can show that people who know how to modify fortran compilers are
interested in participating, I would be willing to take the lead in
approaching the National Science Foundation for a modest amount of
funding.

	thanks for your time, and best regards,

	Grant Petty



Grant W. Petty                  |Assoc. Prof.,  Atmospheric Science
Earth & Atmospheric Sciences    |Voice:  (765)-494-2544
Purdue University, 1397 CIVL    |Fax:    (765)-496-1210
West Lafayette, IN 47907-1397   |Email: gpetty@purdue.edu

Re: g77 future / proposed extension

[Jamie Lokier]

Grant Petty wrote:
> Clearly, other languages could benefit from this as well, and some (such
> as C++) might even be able to accommodate my ideas without actually
> extending the language itself.

Yes, it has been done in C++.  I implemented that sort of thing twice in
C++.  It's very nice to use.

As a bonus, you can mess around with the representations for different
units, using the fastest and most compact integer representation when
you know your program doesn't need to deal with distances more
accurately than 1mm for example.

And you can do wraparound units, like `Angle' and `Direction'.

Vector units like `Distance', `Velocity', `Position'.

Relative and absolute units like `Time_Delay' and `Timestamp'.

By having a set of units like that, you can easily see the dimensional
correctness of your code.  And you clearly see the places where the code
is working in unusual numerical ranges, becuase it uses weird units there.

To finish, you can do all that while keeping the underlying units
abstract.  That's why I was able to optimise by using integer
representations for some things (this was in a video game): I could
select the units, and all the code using these abstract units, which was
quite a lot, just carried on working.

have a nice day,
-- Jamie

Re: g77 future / proposed extension

[Toon Moene]

Jamie Lokier wrote:

> Grant Petty wrote:

> > Clearly, other languages could benefit from this as well, and some (such
> > as C++) might even be able to accommodate my ideas without actually
> > extending the language itself.

> Yes, it has been done in C++.  I implemented that sort of thing twice in
> C++.  It's very nice to use.

> As a bonus, you can mess around with the representations for different
> units, using the fastest and most compact integer representation when
> you know your program doesn't need to deal with distances more
> accurately than 1mm for example.

In fact, I wouldn't be surprised if that wasn't already possible today
with Fortran 90/95.  Unfortunately, I never thought about this problem
so it might be useful to ask this question on comp.lang.fortran ...

Extending g77 for this purpose certainly seems the wrong approach to me,
though.

Cheers,

-- 
Toon Moene (toon@moene.indiv.nluug.nl)
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
Phone: +31 346 214290; Fax: +31 346 214286
GNU Fortran: http://gcc.gnu.org/onlinedocs/g77_news.html

Re: g77 future / proposed extension

[Grant Petty]

On Wed, 2 Feb 2000, Toon Moene wrote:

> Jamie Lokier wrote:
> 
> > Grant Petty wrote:
> 
> > > Clearly, other languages could benefit from this as well, and some (such
> > > as C++) might even be able to accommodate my ideas without actually
> > > extending the language itself.
> 
> > Yes, it has been done in C++.  I implemented that sort of thing twice in
> > C++.  It's very nice to use.
> 
> > As a bonus, you can mess around with the representations for different
> > units, using the fastest and most compact integer representation when
> > you know your program doesn't need to deal with distances more
> > accurately than 1mm for example.

Jamie - 

Thanks for your earlier response.  What you describe is very interesting,
and I would love to see a simple example program in C++ if one is
available. 

Unfortunatly, even if C++ is perfectly suited to this problem without any
need to extend that language, I'm quite certain that most scientists
working on physical problems around the world are not going to begin
migrating to C++ any time soon, no matter how great the incentive (there
are certain important disincentives as well).  Therefore I still perceive
an urgent need to address this problem transparently (from the scientific
programmer's perspective) in Fortran.

> 
> In fact, I wouldn't be surprised if that wasn't already possible today
> with Fortran 90/95.  Unfortunately, I never thought about this problem
> so it might be useful to ask this question on comp.lang.fortran ...

Toon -

Thanks for your reply.  Although I have not used Fortran 90 much, it is my
impression that it does not contain any provisions for operator
overloading, which I believe to a be fairly important prerequisite.  If
I'm wrong about this, I would certainly be happy to learn this. 
I will post a question to c.l.f. and see if anyone knows of a way to do
what I described.

> 
> Extending g77 for this purpose certainly seems the wrong approach to me,
> though.

You may be correct, but I wonder if you would be willing to state, in one
or two sentences, why you believe this, since I am not sure I understand.
Is it because of an official policy of keeping g77 consistent with
'standard' Fortran?  If so, then I need to identify people who are
familiar with the inner workings of g77 but are not constrained by that
policy.

In any case, if a genuine language extension is needed (as opposed to the
mere addition of a layer of preprocessor macros), it seems to me (a
non-expert) that the only way to achieve this is by writing a compiler
that implements that extension.  That being the case, the choice seems to
be between a commercial (proprietary) compiler or an open-source community
compiler, the only example of which that I know of is g77.  I would much
prefer the latter approach, if available.

	thanks again for your time,

	regards,


Grant W. Petty                  |Assoc. Prof.,  Atmospheric Science
Earth & Atmospheric Sciences    |Voice:  (765)-494-2544
Purdue University, 1397 CIVL    |Fax:    (765)-496-1210
West Lafayette, IN 47907-1397   |Email: gpetty@purdue.edu

Re: g77 future / proposed extension

[Jamie Lokier]

Grant Petty wrote:
> Unfortunatly, even if C++ is perfectly suited to this problem without any
> need to extend that language, I'm quite certain that most scientists
> working on physical problems around the world are not going to begin
> migrating to C++ any time soon, no matter how great the incentive (there
> are certain important disincentives as well).  Therefore I still perceive
> an urgent need to address this problem transparently (from the scientific
> programmer's perspective) in Fortran.

I would hardly call it urgent.  If they're willing to use some ancient
language full of arcane quirks, I'm sure they can handle writing
equations out normally like they have successfully for decades.

What makes you think there are scientists who are unwilling to give up
their cherished Fortran 77 (77 for goodness sake, not 90 or 95), but
will quite happily embrace a new-fangled typed number system?

> You may be correct, but I wonder if you would be willing to state, in one
> or two sentences, why you believe this, since I am not sure I understand.
> Is it because of an official policy of keeping g77 consistent with
> 'standard' Fortran?  If so, then I need to identify people who are
> familiar with the inner workings of g77 but are not constrained by that
> policy.

Of course.  What would be the point of calling it "g77" if it's not
Fortran 77?  As opposed, for example, to g90 or g95.

have a nice day,
-- Jamie

Re: g77 future / proposed extension

[Toon Moene]

Grant Petty wrote:

> Toon -

> Thanks for your reply.  Although I have not used Fortran 90 much, it is my
> impression that it does not contain any provisions for operator
> overloading, which I believe to a be fairly important prerequisite.  If
> I'm wrong about this, I would certainly be happy to learn this.
> I will post a question to c.l.f. and see if anyone knows of a way to do
> what I described.

Operator overloading is supported in Fortran since 1991 - the Fortran 90
Standard.

Because I never used it, it's better to await the answers you get from
the comp.lang.fortran crowd - there are quite a few people who know how
to tackle your approach ...

Hope this helps,

-- 
Toon Moene (toon@moene.indiv.nluug.nl)
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
Phone: +31 346 214290; Fax: +31 346 214286
GNU Fortran: http://gcc.gnu.org/onlinedocs/g77_news.html

Re: g77 future / proposed extension

[Ross Smith]

From: "Grant Petty" <gpetty@precip.eas.purdue.edu>
>
> > Jamie Lokier wrote:
> >
> > > Grant Petty wrote:
> >
> > > > Clearly, other languages could benefit from this as well, and
some (such
> > > > as C++) might even be able to accommodate my ideas without
actually
> > > > extending the language itself.
> >
> > > Yes, it has been done in C++.  I implemented that sort of thing
twice in
> > > C++.  It's very nice to use.
>
> Thanks for your earlier response.  What you describe is very
interesting,
> and I would love to see a simple example program in C++ if one is
> available.

I've written a simple implementation of the idea; you can grab it from
ftp://animal.ihug.co.nz/pub/measure.tgz . There are any number of
features that could be added to it (notably, the ability to write mixed
expressions involving quantities based on different scalar types), but
it illustrates the concept.

Ross Smith <ross.s@ihug.co.nz> The Internet Group, Auckland, New Zealand
========================================================================
    "Be careful about using the following code -- I've only proven
    that it works, I haven't tested it."           -- Donald Knuth

Re: g77 future / proposed extension

[N8TM]

>I wonder if you would be willing to state, in one
> or two sentences, why you believe this, since I am not >sure I understand.
> Is it because of an official policy of keeping g77 >consistent with
> 'standard' Fortran? 

If current standard Fortran (f95) appears to address this better than g77 now does, I would vote for incorporation of the necessary features of f95 rather than taking g77 in an independent direction, which would decrease rather than increase its relevance to people wishing to write portable code.

Tim
tprince@computer.org