Re: Complex Constants in Fortran

uesu03@giac1.oscs.montana.edu (Lou Glassy) writes:


      [how to scan this:]
            X = FU ( 1.0, 3.4 ) ! has to be a function call, but
! the scanner doesn't know that...


      I'd guess the scanner would return a stream of tokens like


            X IDENTIFIER
            = ASSIGNMENT_OPERATOR
            FU IDENTIFIER


      and now comes the part I'm curious about. Should the scanner return


            ( LEFT_PAREN
            1.0 REAL_CONSTANT
            , COMMA
            3.4 REAL_CONSTANT
            ) RIGHT_PAREN


            or should the scanner return


            (1.0,3.4) COMPLEX_CONSTANT


            ???


The former. It's easier.


      If I go the first route, then a COMPLEX_CONSTANT must be resolved (or
      'constructed') by the parser -- which is no great disaster. Conceptually,
      though, it seems that constants of any type should be resolvable by the
      scanner. Is there not enough contextual information available to the
      scanner to do this?


Well, ultimately there is always enough contextual info available, it's
just that you probably don't want to make the scanner sophisticated (and
complex) enough to maintain the necessary info and to look ahead far
enough to do the job properly. For example, you probably don't want to
have to look ahead real far to determine whether the 1.8E4 in
"FORMAT(1.8E4,..." represents a constant (nor do you necessarily want to
simply require that array indexes must be integers when supporting popular
extensions). If you constant-ize the 1.8E4 always, then the parsing code
for FORMAT must expect all sorts of strange things to come along. (That's
true anyway, come to think of it, especially in Fortran-90's free form.
:-) The danger is that your parser won't accept a perfectly legit
construct because it happens to look like a constant to the scanner, and
that possibility didn't occur to you when writing the parser.


Remember, what _conceptually_ makes sense to a compiler writer today is
not necessarily going to help in writing a Fortran or Cobol compiler,
since the languages were designed way back when.


  [In INfort I constructed complex constants in the parser because it was
  easier to do that way, and while I was at it I allowed (exp,exp) as a general
  complex expression constructor. It wouldn't have been very hard to do in
  the scanner; there are so many lexical hacks in parsing Fortran already that
  telling whether a complex constant is allowed is easy. In the case above,
  the scanner had better return the list of primitive tokens unless you want to
  add a lot of extra glop to the parser to take complex constants apart in the
  places where they turn out to be pairs of procedure arguments. -John]


Precisely. But something about (general-exp,general-exp) being shorthand
for CMPLX(general-exp,general-exp) bugs me -- I seem to remember thinking
about doing this and deciding against it for some good reason, but can't
remember what that good reason is. Perhaps some new Fortran-90 syntax
makes it ambiguous? Yet my own code seems to potentially support it by
simply removing some conditionals. Did this feature turn out to be
useful?


Actually, maybe my concern is just that it's much harder to visually grok
"(R*3.4,S/4.5)" than "CMPLX(R*3.4,S/4.5)" as a complex expression.
--
James Craig Burley, Software Craftsperson burley@gnu.ai.mit.edu
[I never had any trouble with (exp,exp) though that was a long time before
F90 came along. Nobody used it since 99% of all code run through INfort was
ported from other systems. -John]
--

Return to the comp.compilers page.
Search the comp.compilers archives again.