New draft (#9) and last call for comments on SRFI 204: Wright-Cartwright-Shinn Pattern Matcher
Arthur A. Gleckler
(13 Oct 2020 06:08 UTC)
|
Re: New draft (#9) and last call for comments on SRFI 204: Wright-Cartwright-Shinn Pattern Matcher
Marc Nieper-Wißkirchen
(13 Oct 2020 09:40 UTC)
|
Re: New draft (#9) and last call for comments on SRFI 204: Wright-Cartwright-Shinn Pattern Matcher
Felix Thibault
(13 Oct 2020 14:56 UTC)
|
Re: New draft (#9) and last call for comments on SRFI 204: Wright-Cartwright-Shinn Pattern Matcher
Marc Nieper-Wißkirchen
(13 Oct 2020 15:22 UTC)
|
Re: New draft (#9) and last call for comments on SRFI 204: Wright-Cartwright-Shinn Pattern Matcher
Felix Thibault
(13 Oct 2020 21:31 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)
|
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