Am Sa., 29. Aug. 2020 um 21:15 Uhr schrieb Felix Thibault
<xxxxxx@gmail.com>:
>
>
>
> On Sat, Aug 29, 2020 at 11:40 AM Marc Nieper-Wißkirchen <xxxxxx@nieper-wisskirchen.de> wrote:
>>
>> (1) In the Specification section, it says: "All of this syntax not
>> already defined by an implementation is exported by this library."
>>
>> What does it concretely mean about the set of exports of the (srfi
>> 204) library? The set of exported bindings should be stable and not
>> vary between one implementation and the other.
>
>
> It means that the exports are limited as follows:
>
> and or not = _ ... set! are not defined and exported in any version of the library
> @ was not defined and exported in the Guile version because Guile has a @ macro
> $ is not defined and exported in the Gauche version  because Gauche has a $ macro
> struct wouldn't be defined and exported in a Racket version
> **1 =.. *.. ? get! object *** are defined and exported in every version of the library

Should SRFI 204 become part of a future Scheme standard, we need a
stable set of identifiers that are exported. What militates against
exporting @, $, and struct in all cases? Both the R7RS and the Guile
module system allow re-exporting identifiers with their original
bindings.

(For completeness, I would also re-export all other keywords from
(scheme base).)

> I thought we were going to bind everything that isn't already syntax:
> **1 =.. *.. ? get! object *** struct $
> in the star library, then it would get used like:
>
> (import (except (srfi 206 *) $)
>         (gauche-base))

I meant the specification section, not the implementation itself.

So, say we are given the following imports:

(import (srfi 204))
(import (only (srfi 206 *) ?)

is there a guarantee that both imports of `?` won't clash or is it
implementation-dependent? In the latter case, it would reduce the idea
of SRFI 206 to absurdity.

>> (3) Is the ellipsis only allowed at the end of a list (or vector) of
>> patterns? If so, why? Syntax-rules don't have this restriction.
>>
>
> No, this works:
>
>  (match '(1 2 3 4 5) ((a b ... c) (list a b c))) => (1 (2 3 4) 5)

I know that the sample implementation allows this, but it is not part
of the pattern grammar, is it?

>> (4) Match, match-let, and the other forms apparently cannot bind
>> identifiers whose current binding is the same as one of the following:
>> and, not, ..., or, =, and whatever.
>>
>> This should be added to the specification and the list ("... and
>> whatever") be completed.

> Does it need to be somewhere different from the pattern grammar? Like a statement right after the pattern operator index stating "None of the above symbols or @ can be used as a pattern variable" [or is @ not a problem anymore?]

Whether @ is a problem or not seems to be more related to the reader, I think.

But I have to apologize. In my first reading, I overlooked your
definition of "patvar", which says everything. However, it is not
about the above "symbols" but whether the identifier in question is
bound to one of the locations or keywords above. So, I would at least
replace "symbol" by "identifier".

(5) Racket's match has a special pattern (var <id>), which allows any
identifier. It looks like a sensible addition to the WCS pattern
matcher as well because this way, *any* identifier can be bound if
needed (or if one is in doubt whether a specific identifier may be in
use as a keyword by some WCS extension).