Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uwm.edu!zaphod.mps.ohio-state.edu!think.com!mintaka!bloom-beacon!dont-send-mail-to-path-lines
From: jeff@aiai.edinburgh.ac.UK (Jeff Dalton)
Newsgroups: comp.lang.scheme
Subject: Destructuring / pattern-matching (was: Multiple return values)
Message-ID: <21983.9104161743@subnode.aiai.ed.ac.uk>
Date: 16 Apr 91 17:43:30 GMT
Sender: daemon@athena.mit.edu (Mr Background)
Organization: The Internet
Lines: 61

I wrote:

   Another problem with patterns in general is that they usually do
   not respect the abstract structure of objects.

Richard O'Keefe suggested a form

   (define-pattern (<name> <parameter>...)
        <simple backquote expression>)

I've done something slightly different.  I wanted to try patterns
similar to those in functional languages where, say, (CONS A B) can be
used as a pattern that mateches a pair, binding A to the car and B to
the CDR.  So I have a form

   (define-view <constructor> (<accessor> ...))

The view for a pair would be 

   (define-view cons (car cdr))

But neither solution feels entirely "right" to me, which makes me
think (hope?) better solutions must be possible.  That's one reason
I felt 

   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.

To which JonL replied:

   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.

And later:

   The problem is one of complexity -- current buzzword: MegaProgramming
   -- and not of whether the interface is procedureal, functional,
   meta (macros and "hooks"), or what-not.

I would, of course, agree that it would be a mistake for programmers
working together on a project to use personal, idiosyncratic macros.
But good macros should decrease complexity, and it is still worth
asking: how do we get better macros?  This is where the "evolution"
comes in.  The early stanges, at laast, can't happen in industrial
projects, but those aren't the only programs being written.

Indeed, some interesting results have already appeared.  For example,
we have extend-syntax for defining macros and the various iteration
macros described in CLtL II.  We can't yet tell whether they, or their
successors, will ever be readily accpted in industrial projects; but I
still think the development of better macros is an effort worth
making.

-- jeff