Destructuring / pattern-matching (was: Multiple return values) 
Author Message
 Destructuring / pattern-matching (was: Multiple return values)

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.

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.)

-- JonL --



Wed, 29 Sep 1993 09:36:05 GMT  
 Destructuring / pattern-matching (was: Multiple return values)

   Date: Fri, 12 Apr 91 18:36:05 PDT

   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

--------------------



Sat, 02 Oct 1993 00:33:58 GMT  
 Destructuring / pattern-matching (was: Multiple return values)
re:  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 wouldn't be so sure about this.  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.

re: 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.  :-)

Since you mention the word "release", I must assume you are referring to
the history of the MIT Lisp Machine project, and its notable commercial
follow-on (Symblics), wherein new and often incompatible "releases"
occured nearly every six months.  Indeed, in the time period between
1978 and 1985, one could substantiate the charge you make; but the X3J13
committee (for CL standards) has yet to make a "release".

So how did Common Lisp come by the reputation you mention (I am, sadly,
acknowledging a "ring of truth" if not complete factuality to your
comment)?  First, recall that Common Lisp is the evolutionary extension
of a series of Lisps beginning with the historic "1.5" at MIT nearly
30 years ago  -- progressing through CTSS Lisp  (ever hear of the
"Compatible Time Sharing System?"), PDP6 Lisp, PDP10 MacLisp,
LispMachineLisp, SPICELisp, and so on.  A bit of middle-aged fat is
beginning to show.

But perhaps more importantly is the influence during the early 1980's
of the idea that "Lisp" is the world's best programming _environment_.
A parallel with the Unix world is (1) a computer language usually
known by it's one-letter name, (2) an enormous non-standard set of
library routines and utilities [although some standards bodies are
addressing this question.]  It's probably too late for Common Lisp ever
to go back to a pure "kernel" language idea, but some of the "stock
hardware" vendors of Common Lisp implementations have indeed been
trying to unbundle pieces of the MonsterLispMachine inheritance from
the required part of a Lisp system.  [Contact me privately for details
on what is happening; or, contact your favorite vendor's salesman;
but please try to resist any intrusion of a "Marketing Blitzkrieg"
into this email list, as has already happend on some other lists.]

-- JonL --



Sat, 02 Oct 1993 03:43:04 GMT  
 Destructuring / pattern-matching (was: Multiple return values)
Is this too simple a way to destructure a list of values?
Here we locally destructure the first 3 elements of the list
        multiple-values-as-a-list
into 3 local variables and as well as getting the cdddr in rest.

; first define this simple fcn.....
(define (give value form)    ; give value to a function
        (apply form value))

; use GIVE to destructure a list of multiple values...
(give multiple-values-as-a-list
      (lambda (variable-1 variable-2 variable-3 . rest)
              expr-to-evaled-with-destructured-bindings))

; A macro is unnecessary, but if you used a macro, it could look like...
; (this needs a better mnemonic name)
(give-macro (variable-1 variable-2 variable-3 . rest)
            multiple-values-as-a-list
            expr-to-be-evaled-with-destructured-bindings)

Of course, a single value handled this way will be a list of one item, so it
won't be as transparent as MULTIPLE-VALUE-BIND, yet it seems so simple.

By just extending the lambda form so that the list of formals can be a
list of lists, one can make this quite general...
- Dan Boley



Sat, 02 Oct 1993 08:15:11 GMT  
 Destructuring / pattern-matching (was: Multiple return values)

   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



Sun, 03 Oct 1993 01:43:30 GMT  
 
 [ 5 post ] 

 Relevant Pages 

1. Destructuring / pattern-matching (was: Multiple return values)

2. LOOP destructuring and multiple values

3. returning a part of string using pattern matching

4. pattern matching for multiple line?

5. expect: Matching patterns from multiple spawns simultaneously

6. How to return multiple matches in Regexp?

7. Q:Pattern for nil return values

8. string match return value

9. iss-matching - the free Regular Expression / Pattern Matching cluster

10. return multiple values from an awk function?

11. ???Eiffel idiom for multiple return values???

12. Tuples, iterators, and multiple return values in Eiffel?

 

 
Powered by phpBB® Forum Software