Re: [NOISE] Curly braces [was Re: Curl]

[Guy Steele - Sun Microsystems Labs <address@hidden>]

   Date: Fri, 30 Nov 2001 01:58:46 -0500 (EST)
   From: Dan Weinreb <dlw@exceloncorp.com>
   To: matrix@alum.mit.edu
   CC: mvanier@bbb.caltech.edu, matthias@ccs.neu.edu, matrix@alum.mit.edu, 
ll1-discuss@ai.mit.edu
   Subject: Re: [NOISE] Curly braces [was Re: Curl]
   
      Date: Thu, 29 Nov 2001 22:11:44 -0800 (PST)
      From: Morgan McGuire <morgan3d@yahoo.com>
   
      Infix math is a special language well suited to dense algebraic
      expressions, just like Scheme is a special language well suited to
      writing compilers.  Scheme is good for walking around on parse trees
      (of itself!), infix is good for math.  
   
   A compensation for having graying hair is that I get to toss in
   old-fogey comments like this: an infix syntax for math that could be
   used anywhere in Lisp already existed over 25 years ago, at the MIT AI
   lab.  ...

A compensation that *I* claim is getting to quote myself (though the
recycling of old thoughts might be thought by some to indicate an
absence of new ones).  In any case, some of you might enjoy what
Dick Gabriel and I wrote on this topic back in 1993:

  The idea of introducing Algol-like syntax into Lisp keeps popping up
  and has seldom failed to create enormous controversy between those who
  find the universal use of S-expressions a technical advantage (and
  don't mind the admitted relative clumsiness of S-expressions for
  numerical expressions) and those who are certain that algebraic syntax
  is more concise, more convenient, or even more {\it natural} (whatever
  that may mean, considering that all these notations are artificial).

  We conjecture that Algol-style syntax has not really caught on in the
  Lisp community as a whole for two reasons.  First, there are not
  enough special symbols to go around.  When your domain of discourse is
  limited to numbers or characters, there are only so many operations of
  interest, so it is not difficult to assign one special character to
  each and be done with it.  But Lisp has a much richer domain of
  discourse, and a Lisp programmer often approaches an application as
  yet another exercise in language design; the style typically involves
  designing new data structures and new functions to operate on
  them---perhaps dozens or hundreds---and it's too hard to invent that
  many distinct symbols (though the APL community certainly has tried).
  Ultimately one must always fall back on a general function-call
  notation; it's just that Lisp programmers don't wait until they fail.

  Second, and perhaps more important, Algol-style syntax makes programs
  look less like the data structures used to represent them.  In a
  culture where the ability to manipulate representations of programs is
  a central paradigm, a notation that distances the appearance of a
  program from the appearance of its representation as data is not
  likely to be warmly received (and this was, and is, one of the
  principal objections to the inclusion of {\tt loop} in Common Lisp).

  On the other hand, precisely because Lisp makes it easy to play with
  program representations, it is always easy for the novice to
  experiment with alternative notations.  Therefore we expect future
  generations of Lisp programmers to continue to reinvent Algol-style
  syntax for Lisp, over and over and over again, and we are equally
  confident that they will continue, after an initial period of
  infatuation, to reject it.  (Perhaps this process should be regarded
  as a rite of passage for Lisp hackers.)

	Steele, Guy L., Jr., and Gabriel, Richard P.  The Evolution of
	Lisp.  Proc. Second ACM SIGPLAN History of Programming Languages
	Conference (HOPL-II), Boston, April 1993.  ACM SIGPLAN Notices 28, 3
	(March 1993), 231-270.  Also in In Bergin, Thomas J., Jr., and Gibson,
	Richard G., Jr., eds. History of Programming Languages II.  ACM Press,
	New York, and Addison-Wesley, Reading, Massachusetts (1996).

--Guy