|
Some ideas for the spec cleanup
Felix Thibault
(02 Jul 2021 22:30 UTC)
|
|
Re: Some ideas for the spec cleanup
Arthur A. Gleckler
(03 Jul 2021 18:05 UTC)
|
|
Re: Some ideas for the spec cleanup
Marc Nieper-Wißkirchen
(03 Jul 2021 19:09 UTC)
|
|
Re: Some ideas for the spec cleanup
Felix Thibault
(03 Jul 2021 22:55 UTC)
|
|
Re: Some ideas for the spec cleanup
Felix Thibault
(04 Jul 2021 11:49 UTC)
|
|
Re: Some ideas for the spec cleanup Felix Thibault (04 Jul 2021 11:50 UTC)
|
|
Re: Some ideas for the spec cleanup
Marc Nieper-Wißkirchen
(04 Jul 2021 12:06 UTC)
|
|
Re: Some ideas for the spec cleanup
Felix Thibault
(05 Jul 2021 16:22 UTC)
|
Sorry, that message was supposed to include this link: https://github.com/fthibault1969/srfi-204/blob/doc/separate-examples/ref/match-syntax-1.md On Sun, Jul 4, 2021 at 7:49 AM Felix Thibault <xxxxxx@gmail.com> wrote: > > This is my first attempt at writing up the syntax; I haven't figured > out how to make markdown do the hanging indents under each item yet. > > On Sat, Jul 3, 2021 at 6:55 PM Felix Thibault <xxxxxx@gmail.com> wrote: > > > > Ok, I'll work on restructuring the syntax section like that. I also > > moved it ahead of the grammar section, right after the term > > definitions. I looked at r7rs and I'm guessing by this > > logic: > > > > <expression> -> <macro-use> > > <macro-use> -> (<keyword> <datum>*) > > > > you're saying a pattern is a datum, not an expression. I can make that > > change in the syntax section and look at what I have elsewhere. > > > > On Sat, Jul 3, 2021 at 3:09 PM Marc Nieper-Wißkirchen > > <xxxxxx@gmail.com> wrote: > > > > > > The reordering you propose, Felix, looks good to me. > > > > > > That said, it probably makes sense to write a formal specification (without examples and rationales and motivating text) from scratch and then weave it into the main text. > > > > > > E.g. something along the following lines (written down too quickly to foreclose any mistakes and with a lot stolen from the R7RS): > > > > > > ** > > > (match <expr> <clause> ...) [SYNTAX] > > > => [AUXILIARY SYNTAX] > > > > > > Syntax: <expr> is an expression. Each <clause> has the form (<pattern> <body>) or (<pattern> (=> <failure>) <body>), where each <pattern> is a pattern, <failure> is an identifier, and <body> is a body as defined by the R7RS. It is an error of <failure> is one of the pattern variables. > > > > > > A <pattern> is either an identifier, a constant, or one of the following > > > > > > (<pattern> ...) > > > (quote <datum>) > > > (? <predicate> <pattern> ...) > > > ..., > > > > > > where <predicate> is an expression and <datum> is a datum as defined by the R7RS. > > > > > > Semantics: <expr> and the <predicate>s appearing the <pattern> are evaluated in an unspecified order. It is an error if any of these evaluations yield no or more than one value. It is an error if any <predicate> does not evaluate to a procedure taking one argument. The value of <expr> is the matched against each <pattern> in order. If the value does not match against a pattern, matching is continued with the next. It is an error if there is no further <pattern>. If a value does match a pattern, the match variables of the patterns are bound to fresh locations holding the matched values. If the corresponding clause is of the second form, <failure> is bound to a special continuation that takes no argument. Then the body is evaluated in the extended environment. If the last expression in <body> returns, further matching is abandoned and the resulting values are returned to the continuation of the match expression. Each binding of a pattern variable and the binding of <failure>, if present, has the <body> as its region. Invoking <failure> abandons the current continuation and continues with matching against the next <pattern> in order. It is an error if there is no further <pattern>. > > > > > > An identifier within a pattern can be an underscore (_), ?, .... All other identifiers appearing within a <pattern> are pattern variables. > > > > > > Pattern variables match any value. > > > > > > Underscores also matches arbitrary values but are no pattern variables. > > > > > > When a value is matched against a pattern of the form (<pattern> ...) and the value is not a list of as many elements as there are <pattern>s, the value does not match the pattern. Otherwise, the elements of the list are matched against the corresponding <pattern>s in an arbitrary order. If an element does not match one of the <pattern>s, further matching against the <pattern>s is abandoned and the value does not match the pattern. Otherwise, it matches the pattern. > > > > > > A pattern of the form (quote <datum>) matches a value if <datum> is equal? to the value. > > > > > > When a value is matched against a pattern of the form (? <predicate> <pattern> ...), the procedure yielded by the evaluation of <predicate> is applied to the value. It is an error if this application yields no or more than one value. If it yields #f, the value does not match the pattern. Otherwise, the value is matched against the <pattern>s in order. If it does not match one of the <patterns>, further matching against the <pattern>s is abandoned and the value does not match the pattern. Otherwise, it matches the pattern. > > > > > > ... > > > ** > > > > > > -- Marc > > > > > > PS There are still a lot of inaccuracies in the document; for example, at one point patterns are called expressions (which they aren't); somewhere else, the ellipsis is called a pattern (what it isn't). This does not cause misunderstandings but should probably be corrected in the final version. > > > > > > PPS Some other things should be specified as well, e.g. when and how often certain forms are evaluated, e.g. the <predicate> in the ? pattern. > > > > > > Am Sa., 3. Juli 2021 um 20:05 Uhr schrieb Arthur A. Gleckler <xxxxxx@speechcode.com>: > > >> > > >> Can someone please give Felix feedback on his plans below? > > >> > > >> Thanks. > > >> > > >> On Fri, Jul 2, 2021 at 3:30 PM Felix Thibault <xxxxxx@gmail.com> wrote: > > >>> > > >>> (the changes I mentioned before are in my repo under feature/later-binding) > > >>> I was thinking I could move what is listed under > > >>> Specification.Patterns to a separate section called Pattern Examples, > > >>> so then the information under the specification would be: > > >>> Pattern Grammar > > >>> Syntax > > >>> Tail Contexts > > >>> Side Effects > > >>> Errors > > >>> Using in Other Macros > > >>> > > >>> and I was thinking of moving the examples in the syntax section to the > > >>> Pattern Examples Section if there were still no examples using those > > >>> forms, and adding something like: > > >>> > > >>> a match-lambda* form like this: > > >>> (define check-and-sum > > >>> (match-lambda* (((? number? a) (? number? b)) (+ a b)) > > >>> (_ 'fail))) > > >>> > > >>> is equivalent to a regular match form like this: > > >>> (define (check-and-sum . arg*) > > >>> (match arg* > > >>> (((? number? a) (? number? b)) (+ a b)) > > >>> (_ 'fail))) > > >>> > > >>> or maybe something simpler that just gets the syntax across. Would > > >>> those changes make a big difference in how easy the spec is to use > > >>> from an implementation perspective or is there something else I need > > >>> to look at?
