Xref: utzoo comp.lang.c:17716 comp.lang.fortran:1947
Path: utzoo!dptcdc!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!bloom-beacon!think!ames!haven!adm!cmcl2!lanl!jlg
From: jlg@lanl.gov (Jim Giles)
Newsgroups: comp.lang.c,comp.lang.fortran
Subject: Re: fortran to C converter
Message-ID: <12169@lanl.gov>
Date: 17 Apr 89 17:19:55 GMT
References: <1989Apr14.161147.28053@utzoo.uucp>
Organization: Los Alamos National Laboratory
Lines: 54

From article <1989Apr14.161147.28053@utzoo.uucp>, by henry@utzoo.uucp (Henry Spencer):
> In article <12000@lanl.gov> jlg@lanl.gov (Jim Giles) writes:
>>... In any case, the mechanism you describe (and any C++
>>mechanism) would require 7 different definitions for each operator:
>>COMPLEX*INT, COMPLEX*FLOAT, COMPLEX*DOUBLE, COMPLEX*COMPLEX, INT*COMPLEX,
>>FLOAT*COMPLEX, DOUBLE*COMPLEX.  Or did you think that an implementation
>>that _didn't_ support mixed mode operations was satisfactory?  ...
> 
> Um, it may not have come to your attention that C++ will do conversions

That's exactly what I DON'T want it to do.  Converting to complex
before the operation eliminates exactly the sort of optimization
that should ALLWAYS be done.  (And, yes, I know Stroustrup recommends
conversion here - he also implements COMPLEX as two DOUBLES (bad choice),
and he only implements mixed mode operators fo COMPLEX*DOUBLE combinations.)

> [...]                            If that is not satisfactory, i.e. if you
> really do want all those operations to be different, you will of course
> need to specify them all no matter what you do.

Not necessarily.  The syntax I would recommend would allow declaration of
ALL the mixed mode for a given operator in _one_ declaration:

      Class ordinary_number:: (integer, float)

      Commutative infix operator '*' is
         Inline complex function mixed_mult (complex::x, ordinary_number::y)
            mixed_mult.real = x.real * y
            mixed_mult.imag = x.imag
         end

This syntax is Fortran-like (what about it for Fortran++ :-).  Because
of the Class definition (which doesn't mean the same thing as a object
oriented language class), the function is generic for integers and floats
in its second argument.  It is declared explicitly to be INLINE.  And,
since the operator is declared to be commutative, the function is invoked
no matter which order the operands appear in the expression.  This stands
for four separate declarations in C++ (all of which have the same internal
definition - the two assignment statements).

> [...]
> Given in-header definitions of the operators, there is no reason why a
> C++ optimizing compiler can't do this.  Existing C++ compilers, by and
> large, are not heavy optimizers; the language is too young for that yet.
> They will come.

The optimization I had in mind is called constant folding.  It was first
applied in compilers in the late fifties.  The technology involved in
providing this optimization is therefore older than most C++ programmers
are.  If a compiler still doesn't have it, it is because some other
problem is involved.  In the case of the C++ environment I have access
to, the problem is that new operators are not inline.  Presumably those
C++ processors that do inlining also do this constant folding operation
(I hope!).