Re: New draft (#9) and last call for comments on SRFI 204: Wright-Cartwright-Shinn Pattern Matcher Marc Nieper-Wißkirchen (14 Oct 2020 05:32 UTC)

Re: New draft (#9) and last call for comments on SRFI 204: Wright-Cartwright-Shinn Pattern Matcher Marc Nieper-Wißkirchen 14 Oct 2020 05:32 UTC

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

>> > 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.
>
>
> I'll try to run as many scenarios as I can think of in the next few days and document how they behave.

As I commented earlier on this list, I think it makes more sense
(unless one has several independent implementations to test) to
document the intended behavior first and then to see whether the
existing implementation(s) behave accordingly.

> what about (match (list 1 2 3 4) ((a b (var a) (var b)) 'ok) (_ 'fail)) ?

This is equivalent to

(match (list 1 2 3 4) ((a b a b) 'ok) (_ 'fail))

So it would be an error if repeated pattern variables are not
supported and would evaluate to fail otherwise.

Marc