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

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?