Re: new match system bug?

[Stefan Israelsson Tampe <stefan.tampe@spray.se>]

On Saturday, September 04, 2010 02:44:49 pm Ludovic Courtès wrote:
> Hello!
> 
> Stefan Israelsson Tampe <stefan.tampe@spray.se> writes:
> > While eating the dogfood of the new match macro I come across a bug
> > e.g, this does not work!
> > 
> > (match '(a b) ((and x (a ... b)) a))
> 
> But:
> 
>   scheme@(guile-user)> (match '(a b) ((and x (a . b)) a))
>   $1 = a
> 
> According to the grammar in the manual, I don’t think literal ‘...’ can
> be used in the middle of a list; it should only be used at the end of a
> list, where it means “zero or more”:
> 
>   scheme@(guile-user)> (match '(a b) ((a ...) a))
>   $2 = (a b)
> 
> Thanks,
> Ludo’.

How true, It's just that the code we took has an extension with a Bug in it.
It was intended to work for that case as well.

From match.upstream.scm:
;; 2007/07/21 - allowing ellipse patterns in non-final list positions

They just stopped variants of
the form (a ... b ...) cause it led to higher order matchers that could be
avoided by another means me thinks. 

So either.
1. we allow for this extension. or
2. Add a nice error message explaining that that feature is not suported.
   Right now - this is a Bug :-)

Note. I would like to allow multiple a ... patterns but warn against it use 
and change the algorithm. The reason is that there exists a common pattern 
idiom. Namely ( a a a a - b b b b b - c c c c c)  e.g. using separators. 
essentially it is very kind to allow people to do:

   (match list ((x ... '- . l) (begin (handle x) (f l))))

So you essentially allow a anti gready ... operator. Note here that using <x> 
abstractions althogh it works for the above example, it cannot reproduce a non
gready operator. For that you would need the continuation inside the match
abstractions.

Cheers
Stefan