Re: Some ideas for the spec cleanup

Show/hide message thread

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 04 Jul 2021 11:49 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?