On Saturday, September 04, 2010 02:44:49 pm Ludovic Courtès wrote: > Hello! > > Stefan Israelsson Tampe <stefan.ta...@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
