[plt-scheme] Re: plt-scheme Digest, Vol 5, Issue 14

On Fri, 2006-01-06 at 17:34 -0500, Matthias Felleisen wrote:
> On Jan 6, 2006, at 2:45 PM, Bill Wood wrote:
> > I'm finding the separation of the functor from the args of the clause
> > head unnerving.  This syntax seems almost to be an intermediate form a
> > compiler might build after finding all the clauses for a given
> > functor/arity pair.  But hey, we lispers are happy with S expressions,
> > which were originally intended to be essentially ASTs for a more
> > conventional surface syntax.
> 
> The constructor is indeed separated but just like f is separated from
> x in (f x). What do you mean?

I was referring to the syntactic difference between the head clause and
the body clauses of a rule, as in my example

    (%assert %likes (stuff)
      [('john stuff) (%likes 'mary stuff)])

I was looking for something more like

    (%assert %likes (stuff)
      [(%likes 'john stuff) (%likes 'mary stuff)])

It just took me a while (and more careful reading of the doc) to get
what was going on.  Without some explanation newbies could be led to
think, for example, that all of the members of the list of variables,
"(stuff)" above, had to occur in each clause, thus making it impossible
to define a predicate comprised of both (ground) facts and rules in one
defining form.

> If you are referring to the ability to define and redefine your own
> constructor, this increases the power of Prolog: you can match against
> vectors, S-expressions, ref cells, etc.
> 
> This is from the manual:
> 
>  > (which (x) (%add 0 (succ x) (succ x)))
> ((x _))
> 
> Now I define a different constructor:
> 
>  > (define (succ x) `(succ ,x))
>  > (which (x) (%add 0 (succ x) (succ x)))
> ((x _))
> 
> This is neat! What's wrong? -- Matthias

The point being that in the first case two vectors are matched whereas
in the second case two lists are being matched?  I wouldn't dream of
denying its neatness.  I suspect that its leverage comes about through
passage across the embedding interface.  That is to say, I can't think
of many big problems in native Prolog that this facility would solve,
but I've seen nightmarish problems due to passing data across an FFI
interface that this facility could conceivably make more manageable.

Different topic:  Has anyone used schelog enough to get a feel for its
performance profile?  Are asserts really slow?  Does removing
non-determinism pay dividends?  etc., etc., ...

 -- Bill Wood