[cl-unification-devel] MATCH and friends usage and changes

[Marco Antoniotti]

On Dec 4, 2012, at 04:52 , Pixie <pix at 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