Am So., 30. Aug. 2020 um 00:29 Uhr schrieb Felix Thibault
<xxxxxx@gmail.com>:
>
>> 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.
>
>
> I thought the way I would end up using srfi 206 would be along the lines of
> taking my current the implementations, like:
>
> (cond-expand
>   (chibi
>     (define-library (srfi-204)
>       (export match match-lambda match-lambda* match-let match-letrec match-let*
>      ___ **1 =.. *.. *** ? $ struct object get!)
>       (import (chibi))
>       (include  "srfi-204/srfi-204.scm")
>       (include "auxiliary-syntax.scm")
>       (begin
>         (define-auxiliary-keywords ___ **1 =.. *.. *** ? $ struct object get!))))
> ...)
>
> and refactor them to something like:
>
> (cond-expand
>   (chibi
>     (define-library (srfi-204)
>       (export match match-lambda match-lambda* match-let match-letrec match-let*
>      ___ **1 =.. *.. *** ? $ struct object get!)
>       (import (chibi))
>       (import (only (srfi 206 *) ___ **1 =.. *.. *** ? $ struct object get!))
>       (include  "srfi-204/srfi-204.scm")))
> ...)
>
> Am I misunderstanding how that library works? I think that would mean the exports wouldn't clash that you refer to above.

The implementation looks fine as far as I can see. But I was talking
about the specification. Does it force the latter implementation or is
the former implementation allowed as well?

If the former implementation were allowed as well, the original idea
of SRFI 206 wouldn't help. Another SRFI that exports auxiliary syntax
"?", even when it does so through SRFI 206, may clash with a
particular implementation of SRFI 204.

>> >> (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.

> If I were to change the grammar from:
> (pat1 ... patN patN+1 ooo)
> to
> (pat1 ... patN patN+1 ooo [patN+2])
> would that cover it or is there some other way to show something is optional or do I need to show both cases?

I'd take a look at the syntax-rules description in section 4.3 of the
R7RS where syntax-rules's pattern language is described in detail.
(The problem with your proposed grammar is that it still does not
allow for more than one pattern after the ellipsis.

> I have a feeling plenty of people might overlook things in the grammar so I do think it might be a good idea to reiterate (preiterate?) this in the index. I'll change "symbol" to "identifier" (or "name" ?). Some of the other grammars also have unquote and unquote-splicing, so I may need to add those to the list.

Identifier is better because this is what the R7RS also uses. Equality
of identifiers here is in the sense of free-identifier=?. And yes, I
think as well that unquote and unquote-splicing should be added as
well.

>> (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).
>
>
> Right now I'm on the feature/new-chibi-match branch. The feature/renamed-fields branch is at a standstill because the code won't run. I may open feature/letrec-star, feature/quasiquote-patterns and feature/var branches later but I am not there yet and I do want to update all the documentation and refactor for srfi-206 (if it is in a stable state), along with checking the implementations in not-working  once  more to see if the changes we've made recently have made any difference, then either integrating or deleting them. Aside from the things I mentioned I also have an outstanding issue on the testing suite where the output of the implementations that use srfi-64 varies from highly verbose to "80 tests completed" and I wanted to get them all using the same runner so that wasn't an issue. There may be some other stuff I was wanting to do with testing but I didn't put in an issue on it.

No hurry! It's a very complex SRFI that is moreover meant to be highly portable.

> Speaking of testing, as I understand it, there is no implementation independent way to tell whether an error is an unbound variable error or a syntax error, so I can't have tests to see if the auxiliary syntax is exported, right?

The state of portability situation is even worse here, I think. Some
implementations raise an error at expansion time when they see an
unbound variable; other implementations defer this error until runtime
when the unbound variable is accessed.