The code is hackish but it shows the reason behind the error in the report.

The semantic behind the idea should not be hackish. any expression (x ...)
with no ellipsis var in x has earlier been an error so there is no danger in
corrupting
code out there. On the other hand there is still room to improve it further.
On the other hand, we will miss an oppertunity to find code errors by
missplaced a .... so that is what we will loose by doing this.

I noticed that syntax-rules and case-lambda does either not allow for
recursive uses of ... but signals an error if the same kind of code is
tried. I would like
tghe solution here to be the same for both of these kinds of matchers.

the ___ solution seams also hackish and I do not follow exactly how it is
used.
can you submit an example to show how it works.

What I can think of is that we could use a quotation system e.g. be able to
quote ...
this means that we need to introduce '...  ''...  etc at the right places in
order to exactly
show the intention of how to expand e.g.

(sxml-mathc x ((a ,x ...)
  (list (sxml-match x ((b ,y '...)
      (list (sxml-match y ((c ,z ''...) z)
       '...))
   ...)

To me this is most satisfying because it will keep on finding missplaced ...
and it will
be more exact in the intention of the code it will not be hard to implement.
The downside is that a very small possibly zero number of matchers will stop
working due to the possibility of using quote as a ellipsis variable.

I can very well imagine that quoting is seen as difficult and in order to
promote correct code we should leave the code as is forcing people to cut up
the logic as done in the working example in the original report.

/Stefan
On Tue, Sep 6, 2011 at 11:27 PM, Ludovic Courtès <INVALID.NOREPLY@gnu.org>wrote:

> Follow-up Comment #6, bug #31691 (project guile):
>
> Hmm, that seems a bit hackish.  :-)
>
> (ice-9 match) has `___' as an alternate syntax for `...' in situations
> where
> the latter cannot be used.  Maybe we should just do that?
>
>    _______________________________________________________
>
> Reply to this item at:
>
>  <http://savannah.gnu.org/bugs/?31691>
>
> _______________________________________________
>  Message sent via/by Savannah
>  http://savannah.gnu.org/
>
>