Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!zaphod.mps.ohio-state.edu!think.com!mintaka!bloom-beacon!dont-send-mail-to-path-lines
From: mkatz@garlic.stanford.EDU (Morris Katz)
Newsgroups: comp.lang.scheme
Subject: Destructuring / pattern-matching (was: Multiple return values)
Message-ID: <9104151633.AA16272@garlic.Stanford.EDU>
Date: 15 Apr 91 16:33:58 GMT
References: <9104130136.AA06792@kuwait>
Sender: daemon@athena.mit.edu (Mr Background)
Organization: The Internet
Lines: 48


   Date: Fri, 12 Apr 91 18:36:05 PDT
   From: Jon L White <jonl%kuwait@lucid.com>

   In isssue Scheme Digest V3 #184, Jeff Dalton recounts the ways that 
   LET, DESTRUCTURING-BIND, and MULTIPLE-VALUE-BIND could be unified
   by a single user-defined macro:

       Nonetheless, I think the best way to proceed would be for people to
       write macros that they find useful, let others use them, and see what
       solutions evolve. 

   I know this sort of topic has already been flamed-out on this list, but 
   the irresitable force of macro power does come up against the immovable 
   object of a community of programmers.  That is to say, as long as I was 
   working only by myself, or with a VERY small set of hackers, Jeff's 
   suggestion for extra macrofication works fine.  But somehere around 
   the 20-person "industrial quality" project you find that the number 
   of idiosyncratic, personalized syntax macros is too large for anyone 
   to comprehend.  It just takes one conservative member of the team to 
   demand that no macros be used for trivial extensions; and this rules 
   out the one-liner JONL-BIND in favor of the three-lines involving LET, 
   DESTRUCTURING-BIND, and MULTIPLE-VALUE-BIND.

I sure hope they don't feel the same way about procedures.  :-)  If not, I
think that they should consider for a while why procedural abstraction is
acceptable, but abstration using macros is not.  I suspect that the answer has
more to do with documentation conventions and other development environment
considerations than anything to do with language semantics, per se.  If my
suspicion is correct, then I advocate fixing our tools rather than changing the
language. 

   The above paragraph is based on hard experience (my own) with a group
   considerably smaller than 20.

   Of course, it is easier to bear if all 20 persons believe that the
   macro in question is about to be "a standard" in the language.  (This
   may explain why there are so many constructs being suggested for
   standardization; but let us drink no standards before their time.)

The logical extension of this argument is CommonLisp.  Dump so much in the
language that noone can ever imagine extending it in any way.  If you do find a
way, just go to the CL standard committee and they will add it to the next
release.  :-)
--------------------
Morry Katz
katz@cs.stanford.edu
--------------------