Email list hosting service & mailing list manager

SRFI 204: Wright-Cartwright-Shinn Pattern Matcher Arthur A. Gleckler (16 Jul 2020 06:10 UTC)
Re: SRFI 204: Wright-Cartwright-Shinn Pattern Matcher Panicz Maciej Godek (16 Jul 2020 08:29 UTC)
(missing)
Fwd: SRFI 204: Wright-Cartwright-Shinn Pattern Matcher Felix Thibault (16 Jul 2020 10:20 UTC)
Re: SRFI 204: Wright-Cartwright-Shinn Pattern Matcher Arthur A. Gleckler (16 Jul 2020 15:07 UTC)
Re: SRFI 204: Wright-Cartwright-Shinn Pattern Matcher Duy Nguyen (16 Jul 2020 10:11 UTC)
Re: SRFI 204: Wright-Cartwright-Shinn Pattern Matcher Arthur A. Gleckler (16 Jul 2020 15:03 UTC)
Re: SRFI 204: Wright-Cartwright-Shinn Pattern Matcher Marc Nieper-Wißkirchen (17 Jul 2020 09:56 UTC)
Re: SRFI 204: Wright-Cartwright-Shinn Pattern Matcher Felix Thibault (17 Jul 2020 11:34 UTC)
Re: SRFI 204: Wright-Cartwright-Shinn Pattern Matcher Marc Nieper-Wißkirchen (17 Jul 2020 11:47 UTC)

Re: SRFI 204: Wright-Cartwright-Shinn Pattern Matcher Marc Nieper-Wißkirchen 17 Jul 2020 11:46 UTC

Am Fr., 17. Juli 2020 um 13:34 Uhr schrieb Felix Thibault
<xxxxxx@gmail.com>:

> 1) That section was originally called "Syntax" but then I added in a section called "Pattern Syntax" so I renamed that original syntax section "Procedures" (it should have been "Macros" or "Exported Forms") since it was a list of applications with their descriptions. I could rename that second section "Pattern Grammar" if that is more accurate. If I hadn't made the original change I would have had "Patterns" "Pattern Syntax" and "Syntax" as the three sections of specification. I'm open to other names (maybe "Introduction," "Pattern Grammar," and "Syntax") as long as they don't all run together.

In existing SRFIs, the section name "Syntax" is usually used for the
exported syntax keywords.

> 2) I know that at the very least there are problems doing $ @ object struct in a portable way, it has already been mentioned that  we should either make those optional (my preference) or not include them in the SRFI.

If they are made optional, there is still the question of how to
specify them fully. If they are not specified to some extent, such an
optional section would just be an informative section.

> The pattern language is in syntax-rules (_ __ ... ..1 ..= ..*  etc.). The only exports are match, match-let, etc. Maybe it is best to call that section "Exported Forms" then.

Technically, not the forms are exported but identifiers together with
their bindings are. So "Exported Identifiers" is a much better way.

The identifiers ..1, ..=, ..*, etc. must be bound and exported as well
much like "else" from the R6RS/R7RS. For symmetry, I would reexport _,
___, and, or, ... from (scheme base) as well.

Marc

> 3)The named-record test is currently failing for both implementations I've tried so far so any ideas would be appreciated.
> The main match module is https://github.com/scheme-requests-for-implementation/srfi-204/blob/master/srfi/match/match.scm,
> the Guile library definition is https://github.com/scheme-requests-for-implementation/srfi-204/blob/master/srfi/guile2.2/match.scm,
>  the Gauche library definition is https://github.com/scheme-requests-for-implementation/srfi-204/blob/master/srfi/gauche0.9.6/match.scm [the import statement in my repo also has (only (gauche base) is-a? slot-ref slot-set!) but I still haven't got the record tests to pass.]
> and this is the testing directory with logs https://github.com/scheme-requests-for-implementation/srfi-204/tree/master/srfi/test
>
> On Fri, Jul 17, 2020 at 5:56 AM Marc Nieper-Wißkirchen <xxxxxx@nieper-wisskirchen.de> wrote:
>>
>> (1) One section is called "Procedures" but it seems that syntax is described.
>>
>> (2) Is it intended that the syntax described in this SRFI is being
>> packaged in an R7RS library "(srfi 204)"? It would be very helpful to
>> clarify what this library would export. In particular, it should
>> export all the symbols _, quote, $, struct, @, object, =, and, or,
>> not, ?, set!, get!, quasiquote, ..., ___, ..1, ..=, ..* bound to their
>> usual meaning or (if there is none) bound to some auxiliary syntax to
>> preserve the spirit of R6RS and R7RS when it comes to auxiliary
>> keywords and to be able to preserve hygiene.
>>
>> (3) The slot names for records cannot fully work portably if a record
>> type has two slots with the same name (as a symbol). If a matching
>> pattern against record getter procedures were added, it would always
>> work (and also hygienically).
>>
>> Marc
>>
>> Am Do., 16. Juli 2020 um 08:10 Uhr schrieb Arthur A. Gleckler
>> <xxxxxx@speechcode.com>:
>> >
>> > Scheme Request for Implementation 204,
>> > "Wright-Cartwright-Shinn Pattern Matcher,"
>> > by Felix Thibault,
>> > is now available for discussion.
>> >
>> > Its draft and an archive of the ongoing discussion are available at https://srfi.schemers.org/srfi-204/.
>> >
>> > You can join the discussion of the draft by filling out the subscription form on that page.
>> >
>> > You can contribute a message to the discussion by sending it to xxxxxx@srfi.schemers.org.
>> >
>> > Here's the abstract:
>> >
>> > Pattern matching is a way of decomposing a compound data structure into its component parts and assigning those parts to variables. This SRFI describes a pattern-matching library which is already in use by several scheme implementations which is able to match many common compound data structures.
>> >
>> > Regards,
>> >
>> >
>> > SRFI Editor