|Complex Constants in Fortran firstname.lastname@example.org (1993-01-02)|
|Re: Complex Constants in Fortran email@example.com (1993-01-04)|
|Re: Complex Constants in Fortran firstname.lastname@example.org (1993-01-04)|
|From:||email@example.com (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|
firstname.lastname@example.org (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
and now comes the part I'm curious about. Should the scanner return
or should the scanner return
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
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 email@example.com
[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
Search the comp.compilers archives again.