Am Di., 13. Okt. 2020 um 16:56 Uhr schrieb Felix Thibault
<xxxxxx@gmail.com>:

> On Tue, Oct 13, 2020 at 5:40 AM Marc Nieper-Wißkirchen <xxxxxx@nieper-wisskirchen.de> wrote:
>>
>> (1) The description of the "failure" procedure indicates that it is a
>> continuation that does not return, which is what most people would
>> expect. In the same implementation, however, "failure" returns and

"sample", not "same"...

>> delivers the result of the match with the remaining clauses.
>
>
> I will change the description to clauses to match the definitions I have (and also the behavior described under or patterns, etc.).

Which means? (In my opinion, the sample implementation has to be fixed
by adding one call/cc to escape the body.)

>> (2) The description of tree patterns isn't self-contained. What is a
>> tree? Can it contain vectors? Even records? Can it be safely applied
>> to cyclic data structures? My advice would be to make it optional as
>> some other extensions to the original matcher.
>
>
> I think trees are pairs (at least I had no luck using the tree operator on a JSON representation that had vectors). I will test some more data structures with the tree operator and revise the spec accordingly. I had a question about making it optional in the first draft as an issue (since it was called experimental), but I noticed that it was several years old and I got no feedback on that issue so I took it out.

Do trees work with pairs? Or only with proper lists? If it crashes on
cyclic lists, this feature is probably not usable for user-provided
data.

As trees only work in a very limited area, I would still call them
experimental because it is not clear how to extend them so that, for
example, vectors are/are not included, etc. My advice is to make this
feature optional as I don't think tree patterns are already in their
final shape.

>> (3) Please add a pattern of the form (var <id>), which is just like
>> <id> except that <id> in (var <id>) will always be interpreted as a
>> pattern variable. This allows binding identifiers like $ or _ as
>> pattern variables, but more importantly, it allows to write robust
>> macros using the matcher by wrapping user-provided identifiers into
>> (var ...).
>>
>> The implementation is almost trivial: Define "var" as auxiliary
>> syntax, add another clause in this macro
>> https://github.com/scheme-requests-for-implementation/srfi-204/blob/master/srfi/204/204.scm#L410
>> and extract https://github.com/scheme-requests-for-implementation/srfi-204/blob/master/srfi/204/204.scm#L486
>> into its own macro, say match-var so that it can be used by the "var"
>> clause as well.
>>
>
> There are three parts for any feature:
>
> implementation: I am new at macro writing, but I could dive back in and give it a go.

If you want/need help, I will assist you.

> documentation: this needs examples that show i) how var is meant to be used ii) how it interacts with other features. This would be the first big hurdle since it sounds like this feature is meant to be used primarily in macros.

Example are easy to come by:

(match (list 1 2 3) (((var a) (var b) (var c)) b))

is equivalent to

(match (list 1 2 3) ((a b c) b))

But you can also do

(match (list 1 2 3) (((var _) (var $) (var ...)) (list _ $ ...))) => (1 2 3)

While one may not want to bind a variable like $ in general, by using
var you will always be on the safe side. This is important for when
(a) the user supplies variable names you have no control over (this
concerns macros) or (b) when you want to be 100% sure that your
identifier name will also work in some future extension of SRFI 204 or
some local extension of the pattern matcher. For example, object
wasn't part of the original matcher, I think, so old code may have
used the identifier object as a pattern variable. Using var, it will
remain a pattern variable.

The interaction with other features can be shown with an example as well:

(match (list 1 2 3) (((var ...) ...) ...))

evaluates to (1 2 3): The first occurance of ... is interpreted as a
pattern variable because it is guarded by var against special
interpretation. The second occurance of ... is not guarded and the
ellipsis operator. Finally, the third occurance of ... is in the body
where it is bound to the match.

You can, of course, guard var as well:

(match (list 1 2 3) ((var var) var)) => (1 2 3).

> testing: all the examples from the srfi spec can go in the srfi-test, but that still leaves match-test where var is checked to make sure it does what it's supposed to.

I think you make-chunker example is great and a perfect showcase for
the var feature. The original version from the SRFI is:

(define-syntax make-chunker
  (syntax-rules ()
    ((_ s ...)
     (lambda (l)
       (let lp ((l l))
        (match l (() '())
         ((s ... . rest) (cons (list s ...) (lp rest)))
         (end (list end))))))))

((make-chunker a b c d) (iota 20))
=> ((0 1 2 3) (4 5 6 7) (8 9 10 11) (12 13 14 15) (16 17 18 19))

((make-chunker a b c _) (iota 20))
=> ERROR on line 16: invalid use of syntax as value: _

An improved version with var would be as simple as:

(define-syntax make-chunker
  (syntax-rules ()
    ((_ s ...)
     (lambda (l)
       (let lp ((l l))
        (match l (() '())
         (((var s) ... . rest) (cons (list s ...) (lp rest)))
         (end (list end))))))))

Thank you for your patience!

Marc

> To do 2 and 3, I really need a better understanding of how this feature is meant to be used.
>
> Felix
>
>>
>> Am Di., 13. Okt. 2020 um 08:08 Uhr schrieb Arthur A. Gleckler
>> <xxxxxx@speechcode.com>:
>> >
>> > I've just published draft #9 of SRFI 204. It was submitted by Felix Thibault, author of the SRFI.
>> >
>> > Felix has asked me to announce last call for this SRFI. He believes that it is ready for finalization, but would like to give reviewers one last chance to submit corrections and feedback before we finalize it.
>> >
>> > In particular, I appeal to anyone reading this to try the sample implementation, run the tests, and send feedback about your results.
>> >
>> > If you're interested in this SRFI, please give your feedback via the SRFI 204 mailing list before 2020-10-20. After that, assuming that no major revisions are required, we will declare it final. It is important that we get your feedback before 2020-10-20. If that deadline is too soon for you, but you would like to contribute, please let me know so that I can extend the last-call period.
>> >
>> > Here is the commit summary:
>> >
>> > update TODO/README.md
>> > integrate Chez into testing framework
>> > update TODO/README re Chez testing
>> > update to latest version (chibi match)
>> > update TODO/README
>> > added note to TODO/README about srfi-206
>> > update srfi to require srfi-206
>> > retry foment after response from Mike
>> > added make-pred to forum-topics.scm
>> > begin turn srfi examples -> tests
>> > finish making tests from srfi
>> > srfi tests passing w/guile 2 except empty body pattern
>> > get to pass with Gauche except empty body
>> > get to pass with Chez except empty body
>> > get srfi tests to pass loko except match w/o body
>> > test all srfi-64 implementations w/empty match screen
>> > fix mistakes found in srfi
>> > clean up, fix documentation
>> > add milestones for handling loose threads
>> > try make-setter and make-getter
>> > update TODO/README.md
>> > meet email milestone 1
>> > meet milestone 2
>> > meet email milestone 3
>> > finish email milestones
>> > get tests to run on false branch with util match
>> > fix commented out parts of srfi-test
>> > add record methods to cyclone
>> > remove c files from cyclone
>> > add Gerbil record forms, named record failing
>> > update TODO, add not implemented error for Gerbil records
>> > add equality benchmarks
>> > factor test out of srfi (breaks some includes)
>> > try Gerbil, can't handle (srfi 204)/(srfi srfi-204) vs (srfi-204)
>> > remove Gerbil
>> > get 206 working with chibi, gauche, larceny
>> > try/fail to make guile work with srfi-206
>> > put srfi-204 into r6rs form, srfi-206 not working
>> > try/fail to run chezscheme tests[bad includes]
>> > fix more Makefile environment/test versioning
>> > convert loko library to srfi form
>> > try different approaches to or ellipsis patterns
>> > bring TODO/README up to date
>> > document srfi/204.sld exports
>> > add make-match-xxx documentation, fix typos
>> > document sections of srfi-common.scm
>> > fix Makefile to work with Larceny, correct errors in srfi-test.scm
>> > put Guile module in r6rs form
>> > chezscheme to r6rs, clean up extra files
>> > bring cyclone up to srfi/204/204.scm
>> > take Guile out of 204.sld
>> > clean up code and get rid of not-working
>> > restore old srfi-common.scm as r6rs-srfi-common.scm, fix README
>> > update forum-topics.scm
>> > update documentation, move auxiliary-syntax to srfi/204
>> > get rid of extension helpers
>> > re-run match tests, all passing
>> > test examples, all passing except extract-imports
>> > update TODO/README
>> > get rid of extra logs
>> > corrections, add to TODOs
>> > copy edits
>> > add issues to srfi-204.html
>> > add extract-imports issue
>> > resolve conflicts between srfi-common and r6rs srfi-common
>> > run srfi tests for srfi-64, all passing except extract-imports, Larceny
>> > add forum to Acknowledgements section
>> > Fix errors reported by W3C HTML Validator.
>> > Update abstract.
>> > Fragment ID is missing and unnecessary.
>> > make corrections
>> > edits suggested by Grammarly
>> > Eliminate trailing whitespace.
>> > Publish ninth draft.
>> >
>> > Here's the diff:
>> >
>> > https://github.com/scheme-requests-for-implementation/srfi-204/compare/draft-8..draft-9
>> >
>> > Regards,
>> >
>> >
>> > SRFI Editor