home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / arch / 10783 < prev    next >
Encoding:
Internet Message Format  |  1992-11-16  |  2.7 KB
  1. Xref: sparky comp.arch:10783 comp.lang.misc:3714
  2. Path: sparky!uunet!spool.mu.edu!snorkelwacker.mit.edu!ai-lab!life.ai.mit.edu!tmb
  3. From: tmb@arolla.idiap.ch (Thomas M. Breuel)
  4. Newsgroups: comp.arch,comp.lang.misc
  5. Subject: Re: how to advocate new software/hardware features (Re: Hardware Support for Numeric Algorithms)
  6. Date: 16 Nov 92 14:01:38
  7. Organization: IDIAP (Institut Dalle Molle d'Intelligence Artificielle
  8.     Perceptive)
  9. Lines: 44
  10. Message-ID: <TMB.92Nov16140138@arolla.idiap.ch>
  11. References: <Bxr8vG.IpI@mentor.cc.purdue.edu> <1e775rINNslq@network.ucsd.edu>
  12. Reply-To: tmb@idiap.ch
  13. NNTP-Posting-Host: arolla.idiap.ch
  14. In-reply-to: mbk@lyapunov.ucsd.edu's message of 16 Nov 1992 04:13:47 GMT
  15.  
  16. In article <1e775rINNslq@network.ucsd.edu> mbk@lyapunov.ucsd.edu (Matt Kennel) writes:
  17.  
  18.      Prof. Rubin wants to use a syntax which cannot be parsed with the
  19.    "standard" tools of compiler contruction kits.  Think of 
  20.    the old standbys "lex 'n' yacc"---he essentially wants something in
  21.    which the "tables" themselves could somehow be altered using langauge
  22.    statements.  Maybe the world doesn't revolve around statically generated
  23.    context-free unambiguous grammars.
  24.  
  25.    Too many computer scientists think that "syntax is trivial" or "syntax
  26.    is uninteresting", which it may be to the inside of a compiler, but isn't
  27.    to ordinary users.
  28.  
  29. Far from it. In fact, a lot of research in computer science is
  30. directed at coming up with ways of letting people specify syntax and
  31. syntactic transformations as conveniently as possible. Reality is that
  32. this is a hard problem. That's why there are only compromises
  33. available.
  34.  
  35. The available compromises are the following:
  36.  
  37.  * Programming languages themselves nowadays only let you specify very
  38.    limited syntactic extensions, because such extensions are difficult
  39.    to scope properly (mind you, the computer and the parser have no
  40.    problem with this, it is the humans that can't deal with it).  This
  41.    isn't the result of some kind of "language fascism", but of market
  42.    forces: languages that have allowed more general syntactic
  43.    extensions simply never caught on, presumably because such
  44.    extensions were causing more hassle than they were worth.
  45.  
  46.  * Some programming languages use limited syntax but allow very
  47.    general transformations (e.g., Lisp macros).
  48.  
  49.  * There are a number of general-purpose tools for writing systems
  50.    that perform syntactic transformations (yacc, TXL, Prolog, ...).
  51.    Such systems let you express just about any syntax you might want
  52.    to, but because they are so powerful, they are more difficult to
  53.    use.
  54.  
  55. Now, there is certainly room for improvement, so if you don't like
  56. what you are getting right now, maybe you can come up with something
  57. better.
  58.  
  59.                     Thomas.
  60.