From: burley@apple-gunkies.gnu.ai.mit.edu (Craig Burley)
Subject: Re: Complex Constants in Fortran
Reply-To: burley@apple-gunkies.gnu.ai.mit.edu (Craig Burley)
Organization: Free Software Foundation 545 Tech Square Cambridge, MA 02139
Date: Mon, 4 Jan 1993 19:21:08 GMT
Keywords: Fortran, parse, comment

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]
-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.