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.
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.
>> (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?
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?
>> (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".
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.
(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.
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?
Felix