[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: LFM + LFSP = LFE?




   Date: Fri, 13 Jun 2003 18:34:40 -0700
   X-Authentication-Warning: orchestra.cs.caltech.edu: mvanier set sender to 
mvanier@cs.caltech.edu using -f
   From: Michael Vanier <mvanier@cs.caltech.edu>
   To: sk@cs.brown.edu
   Cc: ll1-discuss@ai.mit.edu
   Subject: Re: LFM + LFSP = LFE?
   
   
   My understanding is that there have been a number of efforts over the years
   to put a more "conventional" syntax on top of scheme or lisp.  Of course,
   they don't get far because after a while, people prefer the s-expression
   syntax (which is more powerful once you factor in macros etc.).  However,
   this approach might be worth trying again.  Perhaps this would be one way
   to give scheme the LFE-nature.  Does DrScheme have anything like this?
   
   Parenthetically (pun intended), the guile scheme people did this a few
   years ago but abandoned the effort.

I can't resist quoting this snippet from

  Steele, Guy L., Jr. and Gabriel, Richard P.  "The Evolution of Lisp."
  In Bergin, Thomas J., Jr. and Gibson, Richard G., Jr. (eds.),
  History of Programming Languages, ACM Press, New York, 1996, 233-330.

on the subject of "conventional" syntax for Lisp:

  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 "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, and 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 just 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 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.)

--Guy Steele