Re: Where the next effort in prolog will be and a cool match hack!!

[Stefan Israelsson Tampe]

Hi Alex,

On Monday, September 13, 2010 04:32:13 am Alex Shinn wrote:
> On Fri, Sep 10, 2010 at 6:15 AM, Stefan Israelsson Tampe
> 
> <address@hidden> wrote:
> > I just wanted to share some ideas that come to my mind to churn the
> > prolog into something more useful.
> 
> Have you played with schelog and kanren?

Yeah, I looked briefly at schelog. I'm trying to have both a shelog like 
version to code as well the possibility to link in code written in 
pure prolog. Then there
is a C-backend which I play with quite severly investigating intersting 
extensions to prolog. Like the ability to handle a massive number of 
continuations sharing state in a compact way e.g. compress the redo tree. The
speed is ok and on par with non compiled gprolog programs (probably wam
bytecode). Also being guile centric, hence today leads to quite dramatic 
speedups using a C backend with the drawback of complicating life :-)

Anyhow my view is that at the heart of a prolog system lies a matcher, just 
like yours, where one just have redefined car,cdr,pair?,null? and equal? Ontop
of this is a small macro framework to facilitate tree search.

But point is taken and I will code some example in schelog to compare.

> > So I have been trying to rework Shins hygienic version if ice-9 match so
> > that it can be used as a backbone for it.
> 
> [That's "Shinn" with two n's.]

Oh, hmm, to equalize the balance in universe you may call me stefann from 
now on ;-), 

> > ;; defining xmatch utility - this just will use match but automatically
> > fill in ;; the header and make sure to use correct syntactic
> > environment. ;; (make-phd-matcher name phd abs)
> > ;; defaults is to use (*car ...), - means usual match will be done by
> > (car ...) ;; we also tell the matcher to use a set of abstractions with
> > appropriate ;; variables to bind to. xmatch will be anaphoric though.
> 
> Right, a limitation of Wright's syntax is that "match" itself isn't
> extensible, so to build on it you need to define syntax which
> defines new pattern matchers.

Yep that is a good point. On the other hand I think
that Wright's matchers look nicer on many common patterns than to 
do the below ritual.
 
> The default matcher in Racket is extensible by dispatching
> on the first symbol in each list, so a pair is (cons a b) and a
> list would be (list a b c).  This is slightly more verbose, and
> looks like how you would generate the data rather than its
> actual structure, but at least is extensible.

Yep, it's really not a stupid thing to design it this way.

> It would be possible to build on Wright's syntax with a
> single hook, e.g. patterns of the form
> 
>   (extended-match match-dispatcher data ...)
> 
> possibly abbreviated
> 
>   (: match-dispatcher data ...)
> 
> where `match-dispatcher' is an extension macro following
> some CPS API.  A kludge, but perhaps better than
> redefining a matcher for every extension.

Yeah, cool. But replacing car cdr ... needs a separate code path added
letting the symbols used for list processing flow with the pattern 
compilation process and then one can use the : syntax to define a
dispatcher that alters the meaning of the list processing like in the 
example I made in the previous mail.

maybe (: (match-dispatcher1 data1 ...)
         (match-dispatcher2 data2 ...))

and allow for this pattern only at the top of the match, so by doing
(match (:) ...) will be exactly Wrights matcher?

/Stefan