From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Israelsson Tampe Newsgroups: gmane.lisp.guile.bugs Subject: Re: [bug #31691] Ellipsis not supported in nested `sxml-match' forms [1.9.13] Date: Wed, 7 Sep 2011 13:13:27 +0200 Message-ID: References: <20101118-091036.sv0.12070@savannah.gnu.org> <20101119-162848.sv20118.34131@savannah.gnu.org> <20101119-164144.sv20118.81348@savannah.gnu.org> <20110715-113622.sv78157.99468@savannah.gnu.org> <20110902-171735.sv20118.41353@savannah.gnu.org> <20110905-134004.sv78157.88536@savannah.gnu.org> <20110906-212726.sv15145.16521@savannah.gnu.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=90e6ba61522a88a71404ac5808f5 X-Trace: dough.gmane.org 1315394034 28583 80.91.229.12 (7 Sep 2011 11:13:54 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 7 Sep 2011 11:13:54 +0000 (UTC) Cc: jim@benderweb.net, =?ISO-8859-1?Q?Ludovic_Court=E8s?= , bug-guile@gnu.org To: =?ISO-8859-1?Q?Ludovic_Court=E8s?= Original-X-From: bug-guile-bounces+guile-bugs=m.gmane.org@gnu.org Wed Sep 07 13:13:48 2011 Return-path: Envelope-to: guile-bugs@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1R1G4h-0004yu-07 for guile-bugs@m.gmane.org; Wed, 07 Sep 2011 13:13:47 +0200 Original-Received: from localhost ([::1]:43571 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R1G4g-0007oS-9V for guile-bugs@m.gmane.org; Wed, 07 Sep 2011 07:13:46 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:60560) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R1G4a-0007oH-Ui for bug-guile@gnu.org; Wed, 07 Sep 2011 07:13:45 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1R1G4V-0005oZ-6x for bug-guile@gnu.org; Wed, 07 Sep 2011 07:13:40 -0400 Original-Received: from mail-gy0-f169.google.com ([209.85.160.169]:63698) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R1G4O-0005o7-LD; Wed, 07 Sep 2011 07:13:28 -0400 Original-Received: by gyf1 with SMTP id 1so3537471gyf.0 for ; Wed, 07 Sep 2011 04:13:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=WJKVVgBybdp/diTpdqahiIKJb6E5GRipw0V2LEUmVyI=; b=KJD0GQTJ16oPr0I90smN6Cbn/juPo6uIlEJUydmk4syclsvGd1shNtRq/495gN/jSY MBjOUbDLQ6LLllZA9p3cBa+PmueRKNmQse+QSdWeui5XbXnoX3tSWhE4aaIxXIDYn0db TnRscGlTxL5oHl0V0h/db5TNlFwyiFWKnzUuE= Original-Received: by 10.42.162.74 with SMTP id w10mr3480808icx.163.1315394007115; Wed, 07 Sep 2011 04:13:27 -0700 (PDT) Original-Received: by 10.231.127.83 with HTTP; Wed, 7 Sep 2011 04:13:27 -0700 (PDT) In-Reply-To: <20110906-212726.sv15145.16521@savannah.gnu.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-Received-From: 209.85.160.169 X-BeenThere: bug-guile@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Bug reports for GUILE, GNU's Ubiquitous Extension Language" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-guile-bounces+guile-bugs=m.gmane.org@gnu.org Original-Sender: bug-guile-bounces+guile-bugs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.bugs:5815 Archived-At: --90e6ba61522a88a71404ac5808f5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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 i= n 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 i= n 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 sto= p 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 u= p the logic as done in the working example in the original report. /Stefan On Tue, Sep 6, 2011 at 11:27 PM, Ludovic Court=E8s 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: > > > > _______________________________________________ > Message sent via/by Savannah > http://savannah.gnu.org/ > > --90e6ba61522a88a71404ac5808f5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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 not= iced 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 trie= d. I would like
tghe solution here to be the same for both of these kind= s of matchers.

the ___ solution seams also hackish and I do not foll= ow 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 m= eans that we need to introduce '...=A0 ''...=A0 etc at the righ= t places in order to exactly
show the intention of how to expand e.g.

(sxml-mathc x ((a ,x ...) <= br>=A0 (list (sxml-match x ((b ,y '...)
=A0=A0=A0=A0=A0 (list (sxml= -match y ((c ,z ''...) z)
=A0=A0=A0=A0=A0=A0 '...))
=A0= =A0 ...)

To me this is most satisfying because it will keep on findi= ng 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 s= top 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 cu= t 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=E8s <INVALID.NOREPLY@gnu.org> wrote:
Follow-up Comment #6, bug #31691 (project guile):

Hmm, that seems a bit hackish. =A0:-)

(ice-9 match) has `___' as an alternate syntax for `...' in situati= ons where
the latter cannot be used. =A0Maybe we should just do that?

=A0 =A0_______________________________________________________

Reply to this item at:

=A0<h= ttp://savannah.gnu.org/bugs/?31691>

_______________________________________________
=A0Message sent via/by Savannah
=A0http://savannah.= gnu.org/


--90e6ba61522a88a71404ac5808f5--