Re: [MIT-Scheme-devel] improving integration of VALUES and CALL-WITH-VALUES

[Chris Hanson]

I think this could be done and would be an interesting experiment.
However, unlike ordinary pattern matchers, which return the matched
components, this one would additionally need to return templating
procedures.  So, in our canonical example,

((let ((a (foo)) (b (bar)))
   (lambda (receiver)
     ...body...))
 (lambda (x y z)
   ...))

there might be a pattern like this:

((?* wrapper
     match-wrapper
     (lambda (receiver)
       (? generator)))
 (lambda (x y z)
   (? consumer)))

This would return three values, one of which (wrapper) is a procedure
that will reconstruct the stuff wrapped around the generator
procedure.  Then one could write rules to recursively match the
wrapper, like this:

(define-template-rule (match-wrapper target-pattern)
  (let (? bindings)
    (?* body
        match-wrapper
        target-pattern)))

(define-template-rule (match-wrapper target-pattern)
  (begin
    (?? actions)
    (?* value-expr
        match-wrapper
        target-pattern)))

These rules would construct the templating procedure incrementally.

This is only a sketch, and I've blown some of the details, but I think
the idea is sound.

Joe, you want to give this a try in your copious free time?  I think
you could have some fun with this.  And it would be an interesting
technique to add to our toolboxes.

On Mon, Sep 21, 2009 at 10:16 AM, Taylor R Campbell <address@hidden> wrote:
>   Date: Mon, 21 Sep 2009 09:54:47 -0700
>   From: Joe Marshall <address@hidden>
>
>   It'd be nice if the optimizations were rule-based rather than
>   having these deep, ad-hoc conditionals.  Then the description of
>   the transform would *be* the transform.
>
>   Would it be possible to get the *parser to involved here to simplify
>   this sort of stuff?
>
> Well, *PARSER works only on strings.  The runtime's structure parser
> works on more general sequences of objects, but whatever rule language
> you use, it would have to be fairly sophisticated to capture many of
> these rules.  I gave several simple examples, but actually the pattern
> is doubly recursive: it descends down a tree of combinations whose
> operators are procedures whose bodies are combinations (recursion #1),
> *or* of combinations whose operators can be transformed according to
> the same rule (recursion #2).  That ignores the complications of
> declarations and sequences, too.
>
> If you can come up with a nice rule language to express this, I'd be
> happy to try it!  But I haven't tried to come up with one because I
> don't think I'm clever enough to do so.
>