home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / lang / pop / 166 < prev    next >
Encoding:
Internet Message Format  |  1992-12-22  |  3.4 KB
  1. Path: sparky!uunet!pipex!bnr.co.uk!uknet!bhamcs!axs
  2. From: axs@cs.bham.ac.uk (Aaron Sloman)
  3. Newsgroups: comp.lang.pop
  4. Subject: Re: POP syntax
  5. Summary: Embaras de richesse
  6. Keywords: syntax, list, lexical, unfortunate
  7. Message-ID: <Bzo9FJ.AIC@cs.bham.ac.uk>
  8. Date: 22 Dec 92 17:47:43 GMT
  9. References: <57553@dime.cs.umass.edu>
  10. Sender: news@cs.bham.ac.uk
  11. Organization: School of Computer Science, University of Birmingham, UK
  12. Lines: 75
  13. Nntp-Posting-Host: emotsun
  14.  
  15. pop@cs.umass.edu ( Robin Popplestone ) writes:
  16.  
  17. > Date: 15 Dec 92 14:00:38 GMT
  18. > Organization: University of Massachusetts, Amherst
  19.  
  20. > .....
  21.  
  22. > Another thing I would like is a neat, concise syntax for anonymous
  23. > functions. The old LAMBDA .......END construct was painful enough, without
  24. > being replaced by procedure.....endprocedure. ML's  fn <patt> => <body> is
  25. > neat.
  26.  
  27. I think neatness (which includes conciseness and syntactic economy)
  28. is the last thing that programming language designers should go for
  29. if they are designing a language that is to be used for production
  30. code on software projects where many thousands of lines of code are
  31. to be produced by large and changing teams of programmers and
  32. maintained over many years.
  33.  
  34. Any language to be used for that purpose should have a highly
  35. redundant syntax that is easily parsed by human brains, including
  36. people who are non-mathematicians.
  37.  
  38. ML is notoriously difficult for human brains to parse because it
  39. uses an extraordinarily economical syntax requiring people to
  40. remember precedences in order to read any expression going over more
  41. than a few lines.
  42.  
  43. Lisp is nearly as bad - though at least the parentheses remove the
  44. problem of grouping. But the shortage of keywords, especially
  45. keywords in the middle of constructs, makes it difficult for people
  46. to parse long expressions. E.g.
  47.  
  48.     (( .... ) (....))
  49. could mean all sorts of different things in different contexts and
  50. is therefore far more ambiguous and liable to cause errors than
  51.  
  52.     elseif .... then .....
  53.  
  54. > On a more radical note, I have been doing some C programming recently. Now
  55. > as far as the semantics of C go, it feels rather like wiring one's house
  56. > with bare copper. But one has to admit that the syntax has a certain
  57. > concise elegance.
  58.  
  59. A similar objection can be made to C syntax: but it's not as bad as
  60. Lisp or ML because what you can do in it is far more restricted, and
  61. therefore the syntactic poverty matters less!
  62.  
  63. Try out a CPOP (Popsie is already spoken for)
  64. >
  65. >     maplist(x,f) { x=[]?[]:f(x)::maplist(tl(x),f)}
  66.  
  67. This sort of compact definition is lovely for mathematicians, but
  68. has the kind of conciseness that I think is dangerous in a language
  69. to be used for large software projects.
  70.  
  71. > An interesting point is whether there is any way of getting rid of the
  72. > distinction between application and partial application, which is not a
  73. > fundamental distinction of the lambda calculus, but is only (there) an
  74. > implementation issue.
  75.  
  76. Presumably because in lambda calculus application is itself just a
  77. matter of textual substitution. As soon as one allows, in addition,
  78. the notion of invoking an opaque sub-routine via its name plus some
  79. input values, then surely the distinction between application and
  80. partial application is unavoidable?
  81.  
  82. I'll leave it to others to comment on Robin's other comments!
  83. Aaron
  84. ---
  85. -- 
  86. Aaron Sloman, School of Computer Science,
  87. The University of Birmingham, B15 2TT, England
  88. EMAIL   A.Sloman@cs.bham.ac.uk  OR A.Sloman@bham.ac.uk
  89. Phone: +44-(0)21-414-3711       Fax:   +44-(0)21-414-4281
  90.