From marcoxa at cs.nyu.edu Mon Dec 3 15:31:06 2012 From: marcoxa at cs.nyu.edu (Marco Antoniotti) Date: Mon, 3 Dec 2012 16:31:06 +0100 Subject: [cl-unification-devel] MATCH and friends usage and changes Message-ID: <30231012-CDE4-42AD-8A81-62CDD8C4CFC9@cs.nyu.edu> 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 ( &key ?) ) 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 ( &key errorp default-substitution) 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? Cheers -- Marco Antoniotti -------------- next part -------------- An HTML attachment was scrubbed... URL: From pix at kepibu.org Tue Dec 4 03:52:30 2012 From: pix at kepibu.org (Pixie) Date: Mon, 03 Dec 2012 21:52:30 -0600 Subject: [cl-unification-devel] MATCH and friends usage and changes In-Reply-To: <30231012-CDE4-42AD-8A81-62CDD8C4CFC9@cs.nyu.edu> References: <30231012-CDE4-42AD-8A81-62CDD8C4CFC9@cs.nyu.edu> Message-ID: <50BD737E.7070808@kepibu.org> 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 ( &key ?) ) > > 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 ( &key errorp default-substitution) > > 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? 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?!) [1] Though I've mentioned in the pre-Quicklisp days it'd be nice to have some named-readtable support. [2] http://repo.kepibu.org/cl-unification/ -- It's a few patches behind CVS at the moment, alas. From marcoxa at cs.nyu.edu Tue Dec 4 10:35:11 2012 From: marcoxa at cs.nyu.edu (Marco Antoniotti) Date: Tue, 4 Dec 2012 11:35:11 +0100 Subject: [cl-unification-devel] MATCH and friends usage and changes In-Reply-To: <31828_1354595782_50BD7DC6_31828_4804_1_50BD737E.7070808@kepibu.org> References: <30231012-CDE4-42AD-8A81-62CDD8C4CFC9@cs.nyu.edu> <31828_1354595782_50BD7DC6_31828_4804_1_50BD737E.7070808@kepibu.org> Message-ID: <7A0E8F03-0F85-4C71-AD87-2F92C8E8129B@cs.nyu.edu> On Dec 4, 2012, at 04:52 , Pixie 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 ( &key ?) ) >> >> 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 ( &key errorp default-substitution) >> >> 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 From pix at kepibu.org Tue Dec 4 14:42:48 2012 From: pix at kepibu.org (Pixie) Date: Tue, 04 Dec 2012 08:42:48 -0600 Subject: [cl-unification-devel] MATCH and friends usage and changes In-Reply-To: <7A0E8F03-0F85-4C71-AD87-2F92C8E8129B@cs.nyu.edu> References: <30231012-CDE4-42AD-8A81-62CDD8C4CFC9@cs.nyu.edu> <31828_1354595782_50BD7DC6_31828_4804_1_50BD737E.7070808@kepibu.org> <7A0E8F03-0F85-4C71-AD87-2F92C8E8129B@cs.nyu.edu> Message-ID: <50BE0BE8.2030804@kepibu.org> On 2012.12.04 04:35, Marco Antoniotti wrote: > > On Dec 4, 2012, at 04:52 , Pixie wrote: > >> On 2012.12.03 09:31, Marco Antoniotti wrote: 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. :) Heh. There's always the option of RACKET-ENVY:MATCH-CASE. ;) >> 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. A few things, yeah. The big scary change to all the MATCH- stuff no, but you quite reasonably wanted more tests for that. (CVS->git conversion via git-cvs works pretty smoothly, in my experience.) >> [1] Though I've mentioned in the pre-Quicklisp days it'd be nice >> to have some named-readtable support. > > Any specifics? [1], basically, though the usage of asdf-system-connections would undoubtedly be overkill nowadays. (in-readtable cl-unification:template-readtable) is very handy! :) [1] http://repo.kepibu.org/browse/darcsweb.cgi?r=cl-unification;a=commitdiff;h=20100205090400-50f04-a1a6ff8f9d56093121ba1e8dce3d6afc7dc9ac96.gz