home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / compiler / 2079 next >
Encoding:
Text File  |  1993-01-04  |  4.2 KB  |  94 lines
  1. Newsgroups: comp.compilers
  2. Path: sparky!uunet!gatech!destroyer!gumby!yale!mintaka.lcs.mit.edu!spdcc!iecc!compilers-sender
  3. From: burley@apple-gunkies.gnu.ai.mit.edu (Craig Burley)
  4. Subject: Re: Complex Constants in Fortran
  5. Reply-To: burley@apple-gunkies.gnu.ai.mit.edu (Craig Burley)
  6. Organization: Free Software Foundation 545 Tech Square Cambridge, MA 02139
  7. Date: Mon, 4 Jan 1993 19:21:08 GMT
  8. Approved: compilers@iecc.cambridge.ma.us
  9. Message-ID: <93-01-006@comp.compilers>
  10. Keywords: Fortran, parse, comment
  11. References: <93-01-003@comp.compilers>
  12. Sender: compilers-sender@iecc.cambridge.ma.us
  13. Lines: 79
  14.  
  15. uesu03@giac1.oscs.montana.edu (Lou Glassy) writes:
  16.  
  17.    [how to scan this:]
  18.       X = FU ( 1.0, 3.4 )     ! has to be a function call, but
  19.                   ! the scanner doesn't know that...
  20.  
  21.    I'd guess the scanner would return a stream of tokens like
  22.  
  23.       X      IDENTIFIER
  24.       =      ASSIGNMENT_OPERATOR
  25.       FU     IDENTIFIER
  26.  
  27.    and now comes the part I'm curious about.  Should the scanner return
  28.  
  29.       (      LEFT_PAREN
  30.       1.0    REAL_CONSTANT
  31.       ,      COMMA
  32.       3.4    REAL_CONSTANT
  33.       )      RIGHT_PAREN
  34.  
  35.       or should the scanner return
  36.  
  37.       (1.0,3.4)   COMPLEX_CONSTANT
  38.  
  39.       ???
  40.  
  41. The former.  It's easier.
  42.  
  43.    If I go the first route, then a COMPLEX_CONSTANT must be resolved (or
  44.    'constructed') by the parser -- which is no great disaster.  Conceptually,
  45.    though, it seems that constants of any type should be resolvable by the
  46.    scanner.  Is there not enough contextual information available to the
  47.    scanner to do this?
  48.  
  49. Well, ultimately there is always enough contextual info available, it's
  50. just that you probably don't want to make the scanner sophisticated (and
  51. complex) enough to maintain the necessary info and to look ahead far
  52. enough to do the job properly.  For example, you probably don't want to
  53. have to look ahead real far to determine whether the 1.8E4 in
  54. "FORMAT(1.8E4,..." represents a constant (nor do you necessarily want to
  55. simply require that array indexes must be integers when supporting popular
  56. extensions).  If you constant-ize the 1.8E4 always, then the parsing code
  57. for FORMAT must expect all sorts of strange things to come along.  (That's
  58. true anyway, come to think of it, especially in Fortran-90's free form.
  59. :-) The danger is that your parser won't accept a perfectly legit
  60. construct because it happens to look like a constant to the scanner, and
  61. that possibility didn't occur to you when writing the parser.
  62.  
  63. Remember, what _conceptually_ makes sense to a compiler writer today is
  64. not necessarily going to help in writing a Fortran or Cobol compiler,
  65. since the languages were designed way back when.
  66.  
  67.  [In INfort I constructed complex constants in the parser because it was
  68.  easier to do that way, and while I was at it I allowed (exp,exp) as a general
  69.  complex expression constructor.  It wouldn't have been very hard to do in
  70.  the scanner; there are so many lexical hacks in parsing Fortran already that
  71.  telling whether a complex constant is allowed is easy.  In the case above,
  72.  the scanner had better return the list of primitive tokens unless you want to
  73.  add a lot of extra glop to the parser to take complex constants apart in the
  74.  places where they turn out to be pairs of procedure arguments. -John]
  75.  
  76. Precisely.  But something about (general-exp,general-exp) being shorthand
  77. for CMPLX(general-exp,general-exp) bugs me -- I seem to remember thinking
  78. about doing this and deciding against it for some good reason, but can't
  79. remember what that good reason is.  Perhaps some new Fortran-90 syntax
  80. makes it ambiguous?  Yet my own code seems to potentially support it by
  81. simply removing some conditionals.  Did this feature turn out to be
  82. useful?
  83.  
  84. Actually, maybe my concern is just that it's much harder to visually grok
  85. "(R*3.4,S/4.5)" than "CMPLX(R*3.4,S/4.5)" as a complex expression.
  86. --
  87. James Craig Burley, Software Craftsperson    burley@gnu.ai.mit.edu
  88. [I never had any trouble with (exp,exp) though that was a long time before
  89. F90 came along.  Nobody used it since 99% of all code run through INfort was
  90. ported from other systems. -John]
  91. -- 
  92. Send compilers articles to compilers@iecc.cambridge.ma.us or
  93. {ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
  94.