home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / arch / 10790 < prev    next >
Encoding:
Internet Message Format  |  1992-11-16  |  3.9 KB
  1. Xref: sparky comp.arch:10790 comp.lang.misc:3716
  2. Newsgroups: comp.arch,comp.lang.misc
  3. Path: sparky!uunet!haven.umd.edu!purdue!mentor.cc.purdue.edu!pop.stat.purdue.edu!hrubin
  4. From: hrubin@pop.stat.purdue.edu (Herman Rubin)
  5. Subject: Re: how to advocate new software/hardware features (Re: Hardware Support for Numeric Algorithms)
  6. Message-ID: <BxtFoF.BGn@mentor.cc.purdue.edu>
  7. Sender: news@mentor.cc.purdue.edu (USENET News)
  8. Organization: Purdue University Statistics Department
  9. References: <Bxr8vG.IpI@mentor.cc.purdue.edu> <1e775rINNslq@network.ucsd.edu> <TMB.92Nov16140138@arolla.idiap.ch>
  10. Date: Mon, 16 Nov 1992 15:43:26 GMT
  11. Lines: 68
  12.  
  13. In article <TMB.92Nov16140138@arolla.idiap.ch> tmb@idiap.ch writes:
  14. >In article <1e775rINNslq@network.ucsd.edu> mbk@lyapunov.ucsd.edu (Matt Kennel) writes:
  15.  
  16. >     Prof. Rubin wants to use a syntax which cannot be parsed with the
  17. >   "standard" tools of compiler contruction kits.  Think of 
  18. >   the old standbys "lex 'n' yacc"---he essentially wants something in
  19. >   which the "tables" themselves could somehow be altered using langauge
  20. >   statements.  Maybe the world doesn't revolve around statically generated
  21. >   context-free unambiguous grammars.
  22.  
  23. >   Too many computer scientists think that "syntax is trivial" or "syntax
  24. >   is uninteresting", which it may be to the inside of a compiler, but isn't
  25. >   to ordinary users.
  26.  
  27. >Far from it. In fact, a lot of research in computer science is
  28. >directed at coming up with ways of letting people specify syntax and
  29. >syntactic transformations as conveniently as possible. Reality is that
  30. >this is a hard problem. That's why there are only compromises
  31. >available.
  32.  
  33. I must agree with Matt's statement.  Probably dozens of articles have
  34. been posted saying that if the semantic aspects are there, the syntax
  35. is not important.  
  36.  
  37. >The available compromises are the following:
  38.  
  39. > * Programming languages themselves nowadays only let you specify very
  40. >   limited syntactic extensions, because such extensions are difficult
  41. >   to scope properly (mind you, the computer and the parser have no
  42. >   problem with this, it is the humans that can't deal with it).  This
  43. >   isn't the result of some kind of "language fascism", but of market
  44. >   forces: languages that have allowed more general syntactic
  45. >   extensions simply never caught on, presumably because such
  46. >   extensions were causing more hassle than they were worth.
  47.  
  48. I am not at all convinced that this is the case.  I doubt that they were
  49. left out of C++ because humans could have problems with them; if that is
  50. the case, a warning should be sufficient.  I believe that the reason the
  51. extensions of this type have not caught on is that they were either extensions
  52. to languages which would not otherwise catch on anyhow, or that they were
  53. highly restricted extensions with a horrible syntax, so it would not be an
  54. improvement.
  55.  
  56. As for the problem with market forces, this is why I would like to see a
  57. separate macro processor.  This would allow the user to work through the
  58. implementation of a translation to what the compiler can handle once, and
  59. separate from the code generation. 
  60.  
  61. > * Some programming languages use limited syntax but allow very
  62. >   general transformations (e.g., Lisp macros).
  63.  
  64. > * There are a number of general-purpose tools for writing systems
  65. >   that perform syntactic transformations (yacc, TXL, Prolog, ...).
  66. >   Such systems let you express just about any syntax you might want
  67. >   to, but because they are so powerful, they are more difficult to
  68. >   use.
  69.  
  70. >Now, there is certainly room for improvement, so if you don't like
  71. >what you are getting right now, maybe you can come up with something
  72. >better.
  73.  
  74. Provide me with a few GOOD CS graduate students, and I might be able to
  75. do it.    t they had better be "hacker" quality.
  76. -- 
  77. Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907-1399
  78. Phone: (317)494-6054
  79. hrubin@snap.stat.purdue.edu (Internet, bitnet)  
  80. {purdue,pur-ee}!snap.stat!hrubin(UUCP)
  81.