|
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)
|
Re: Some ideas for the spec cleanup Felix Thibault 05 Jul 2021 16:21 UTC
https://github.com/fthibault1969/srfi-204/blob/doc/separate-examples/ref/match-syntax-2.md is a second draft of syntax. I will get the semantics in later. There was some stuff where I was uncertain "Is this an error?" and I may have a look at 4.3.2 again and bring it more in line with that section and away from 7.1, which is what I was looking at last night. On Sun, Jul 4, 2021 at 8:06 AM Marc Nieper-Wißkirchen <xxxxxx@gmail.com> wrote: > > Am So., 4. Juli 2021 um 13:49 Uhr schrieb Felix Thibault <xxxxxx@gmail.com>: >> >> 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. > > > More or less everything is a datum because source code is just a sequence of datums. A pattern is just a pattern, whose syntax is to be explained in detail. > > Writing down grammar production rules certainly helps, but it is the semantics (see below in my rash try) that is the crucial part. I would propose to follow the example of section 4.3.2 of the R7RS and write a very similar spec for `match'. It is a bit more complicated for `match' because the matching is not stateless, so `matching against' is an operation. > > -- Marc > >> >> > >> > 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?