GNU bug report logs -
#49707
Documentation and behavior differ for match (not ...) pattern
Previous Next
To reply to this bug, email your comments to 49707 AT debbugs.gnu.org.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-guile <at> gnu.org
:
bug#49707
; Package
guile
.
(Fri, 23 Jul 2021 09:47:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
"Jakub Wojciech" <jakub-w <at> riseup.net>
:
New bug report received and forwarded. Copy sent to
bug-guile <at> gnu.org
.
(Fri, 23 Jul 2021 09:47:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
The documentation states:
> (not pat_1 ... pat_n) if all pat_1 thru pat_n don't match
The code only implements (not pat), for a singular pattern, e.g:
(match 2
((not 1) 'not-one)
(1 'one)
(2 'two))
=> not-one
According to the documentation this should work, but the result is erroneous:
(match 3
((not 1 2) 'not-one-nor-two)
(1 'one)
(2 'two)
(3 'three))
=> three
So it fails silently.
RhodiumToad on #guile proposed the simple fix that I took a liberty of
attaching to this message.
It adds a clause for (not ...), delegating it to 'or': (not (or ...)).
However RhodiumToad also raised another issue: is the code wrong or is
the documentation wrong?
The documentation in the file itself states:
> The 'not' operator succeeds if the given pattern doesn't match.
The test from upstream also only checks for the singular pattern inside
the 'not' clause.
This means that the idea behind this code is to allow one and only one
pattern.
Although I lean towards fixing the code to match the Guile's
documentation (i.e. applying the attached patch), I also wonder about
the relation with the upstream - Chibi Scheme.
There are three possibilities:
1. Diverge from their implementation.
2. Try to convince them to apply that patch too.
3. Make passing more than one pattern to 'not' clause a syntax error and
changing the info manual documentation.
The question is: which one do we want to choose?
The rationale for not selecting option 3 is the fact that the change is
non-breaking, adds a functionality, and conforms to both SRFI-200 and
SRFI-204 drafts and the original Wright-Duba paper.
[match-patch.diff (text/x-patch, attachment)]
This bug report was last modified 3 years and 326 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.