Re: [bug #31691] Ellipsis not supported in nested `sxml-match' forms [1.9.13]

[Stefan Israelsson Tampe]

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 <address@hidden> 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/