|
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)
|
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?
