home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / edu / 1578 < prev    next >
Encoding:
Text File  |  1992-09-08  |  2.9 KB  |  70 lines
  1. Newsgroups: comp.edu
  2. Path: sparky!uunet!spool.mu.edu!caen!hellgate.utah.edu!lanl!cochiti.lanl.gov!jlg
  3. From: jlg@cochiti.lanl.gov (Jim Giles)
  4. Subject: Re: Re: Scientists as Programmers (was Re: Small Language Wanted)
  5. Message-ID: <1992Sep8.194256.26243@newshost.lanl.gov>
  6. Sender: news@newshost.lanl.gov
  7. Organization: Los Alamos National Laboratory
  8. References: <1992Sep3.112944.20996@dbsun.uucp> <Bu08uF.HBC@mentor.cc.purdue <KERS.92Sep4154056@cdollin.hpl.hp.com> <135691@lll-winken.LLNL.GOV>
  9. Distribution: na
  10. Date: Tue, 8 Sep 1992 19:42:56 GMT
  11. Lines: 57
  12.  
  13. In article <135691@lll-winken.LLNL.GOV>, blair@lll-crg.llnl.gov (Gary Blair) writes:
  14. |> [...]
  15. |> Wrong.  If your compiler uses ANY kind of table-driven parsing scheme, it is
  16. |> next to impossible to allow programmer-defined operators.  The parser must
  17. |> know what an operator looks like, and what precedence it has  with respect
  18. |> to all other operators.  This is usually predetermined, at
  19. |> compiler-generation time.  
  20.  
  21. This is an example of the overlap between syntax and semantics.  At the
  22. lexical level, the only issue is what constitutes an operator:
  23.  
  24.       op_char ::= @ | # | $ | % | ^ | & | `*' | - | `+' | `=' | / | \
  25.                 | < | > | `~' | ! | `|'
  26.  
  27.       operator ::= op_char+
  28.  
  29. That is, an operator is defined as one or more characters from the
  30. set defined as `op_char'.  Operators are delimited by anything not
  31. in the set.  There is no ambiguity at the lexical level about this
  32. definition of operators.  (Some characters quoted because they are
  33. part of the meta-syntax of the lexical scanner-generator).
  34.  
  35. Once identified, the operator is looked up in a symbol table to determine
  36. part of its semantic properties - like its precedence, associativity, etc..
  37. There is no reason why this symbol table need be generated statically
  38. as part of the *built-in* properties of the compiler.  Since *most*
  39. modern compilers use a split-level syntax (lexical being separate from
  40. the rest) and since most interpose a `screener' between the lexical
  41. level and the rest, most compilers could be enhanced in this way.
  42.  
  43. The grammar for expressions would be like Haskell's:
  44.  
  45.                  0
  46.       exp ::= exp
  47.  
  48.          i       i+1    (n,i)    i+1        i       i
  49.       exp ::= exp    [op      exp   ] | lexp  | rexp
  50.  
  51.           i         i      i+1    (l,i)   i+1 
  52.       lexp ::= (lexp  | exp   ) op     exp
  53.  
  54.           i       i+1  (r,i)     i      i+1
  55.       rexp ::= exp   op     (rexp  | exp   )
  56.  
  57. Where `n' means non-assocaitive, `l' means left associative, `r' means
  58. right associative, and these rules are actually repeated for each 
  59. precedence `i' that you allow.  Prefix and prostix rules can also 
  60. be added.
  61.  
  62. Having said this, I would personally caution users not to define too
  63. many operators.  There are very few for which a natural precedence
  64. and associativity (or even a natural notation) can be clearly identified.
  65. Overuse of user defined operators can lead to less legible code, not
  66. more legible.
  67.  
  68. -- 
  69. J. Giles
  70.