On Dec 4, 2012, at 04:52 , Pixie pix@kepibu.org wrote:
On 2012.12.03 09:31, Marco Antoniotti wrote:
Dear all (the few, the self-chosen :) lurking here)
I have been fiddling about with a "pattern compiler" to be made part of a compiler-macro for MATCH-CASE. After reading a few things here and there, I came to the conclusion that for CL and CL-UNIFICATION there is no need for anything particularly sophisticated (things like "partial test/evaluation merging" and whatnot), but I also started to think that maybe it would be better to introduce new syntax. Something along the lines of
(PAT (<object> &key …) <clauses>)
Now. This may look simple, but suppose you wanted to do something like
(let ((x 42)) (y 123)) (pat (x y) ((42 123) t) (_ 'not-matched)))
Now, while in principle this is easy (you just have a "list" instead of an object as first element), things may become hairy very soon when you want to add keywords affecting the matching process (cfr the MATCH-CASE syntax
match-case (<object> &key errorp default-substitution) <clauses>
where grouping is used for the keyword variables errorp default-substitution). With this consideration in mind the above example would become
(let ((x 42)) (y 123)) (pat ((x y)) ((42 123) t) (_ 'not-matched)))
So the questions I have for you are two: (1) do you have any ideas about syntax, even at the cost of introducing some "spurious infix" bit? (2) the PAT above should be really be named MATCH-CASE, but that is already taken; for the sake of backward compatibility, do you think that PAT or CASE-MATCH or SELECT or whatever should be used for the new syntax?
To be honest, I'm not sure I understand what problem you're trying to solve by adding this PAT thing. The extensibility of cl-unification via #t(...) is one of the things I love about it[1], and your PAT syntax doesn't appear to do much outside of lists--which, well, isn't that what the *F variants are for?
Well, the PAT thingy is just a non-completely-backward-compatible version of MATCH-CASE. To tell the truth the problem is all there. Also, I have developed a form of Racket envy given their slew of match** forms. :)
Though if you're in the mood for cl-unification work, my cl-unification repo is still around[2], if you'd be interested in looking at and/or pulling patches from it. ;) Somewhere in the archives of this mailing list is a listing of what I changed and why. (Goodness, has it been several years already?!)
Well, yes. In some ways this says that the library is pretty solid :)
I believe I did incorporate at least some of your patches in the main trunk. I will have a look at your repo (and I should bite the bullet and just switch to git as main repository) and see what is still left out.
[1] Though I've mentioned in the pre-Quicklisp days it'd be nice to have some named-readtable support.
Any specifics?
[2] http://repo.kepibu.org/cl-unification/ -- It's a few patches behind CVS at the moment, alas.
Thanks.
-- Marco Antoniotti