Re: match-abs

[Stefan Israelsson Tampe]

On Tuesday, August 31, 2010 12:55:15 am Ludovic Courtès wrote:
> Hmm, sorry, I don’t understand what you mean here.  Can you come up with
> a simpler example?
> 
> What does ‘<>’ mean?  Is there a connection between occurrences of
> ‘<op>’ in patterns and the fact that the procedure is bound to ‘<op>’?
> 
> Thanks,
> Ludo’.


Don't be sorry, Communicating is not my strongest asset.

Anyway  consider a list [a a b b] and let <a> be a function so that

(<a> [a a b b]) -> (cons [a a] [b b])
(<b> [b b])     -> (cons [b b] [])

e.g. <a> macthes a sequence of a:s and <b> macthes a sequence of b:s. a
failure in this protocol is represented by the car of the retruning cons 
beeing false.

Note, we could use a plain multiple return values protocol but that is for
later discussion.

so using match-abs we would like the following 

(match [a a b b] ((<a> <b>)  (append <b>.r <a>.r)))

to result in [b b a a].

e.g. function <a> retrurn in (cons [a a] [b b]), where <a>.r is bounded 
to the car, e.g. [a a] and [b b] is fed into the next one, <b>. For which
<b> returns (cons [b b] []), where the car, e.g. [b b] is binded to <b>.r
and the cdr is matched aginst '() and the whole match succeeds and the result
expressing is calcultaed yielding [b b a a].

Now, the construct is anaphoric and also some magic happens so that <a> is
understood as beeing a matcher abstraction.

One idea that is coded is to name the matchers and corresponding variables
that is bound to leading to the suggested 

(match abstractions ((<a> <a>.r1 <a>.r2) (<b> <b>.r))
       [a a b b a a]
       ((<a> <b> <a>)   (append <b>.r <a>.r1 <a>.r2)))

Note how we use <a> two times and the first time it is bound to <a>.r1 and the 
second time it's result is bound to <a>.r2.

Now putting some semmatics in a header can make the matchers themselves look
cleaner and save on vertical space. In match-abs there is an alternative way
of express this acording to

(match [a a b b a a]
       ([(<> <a> <a>.r1) (<> <b> <b>.r) (<> <a> <a>.r2)]
        (append <b>.r <a>.r1> <a>.r2)))

Now, this is more direct, it's simple to implement and are more general. But
The resulting matchers are much harder to read and I would personally prefere 
the header approach when using matchers in 90% of the cases.

Now the rest of the previous mail just describes that we can send parameters
down to the matcher to take full use of an abstraction. 

Another interesting extension that I think You indicate is that one might want 
to use custom variants of car,cdr,pair?,equal?

consider working of objects [List,Depth,Length]
(#car    [List,Depth,Length])   -> [(car List),(+ Depth 1),0]
(#cdr    [List,Depth,Length])   -> [(cdr List),Depth,(+ Length 1)]
(#pair?  [List,Depth,Length])   -> (pair? List)
(#equal? [List,Depth,Length] A) -> (equal? List A)

Now just generate the usual matcher and search and replace and we can track
position and depth as we match. Kind of cool!

Regards
Stefan