Steve,
Thanks for your comments.
[AS]
> > I've reimplemented that in the new cleaner operator doesmatch, available
> > in
> > ftp://ftp.cs.bham.ac.uk/pub/ dist/poplog/auto/doesmatch.p
> >
> > which also works with ordinary pattern variables. (I can email it if
> > anyone has trouble getting it via ftp. )
[sfk]
> This is good news. Is it a candidate for replacing the current
> matcher?
That's up to ISL/Sussex. As far as I am concerned it is available
for incorporation into Poplog, alongside matches and fmatches.
By the way, the provisionsl help file is
ftp://ftp.cs.bham.ac.uk/pub/dist/poplog/help/doesmatch
It's essentially a proper procedural version of fmatches (i.e. not a
syntactic operator). Also instead of idval it uses nonactive_valof
because I assumed nobody would want an active variable to get its
"active" value via the pattern matcher (????. Oh well, I guess
someone does... There's always someone different. I should change it
to valof I suppose).
There are a few other differences.
> I have always hated the multiple segment matching
> defect because I knew I would always forget about it at some
> inconvenient time. If it is better, let's use it.
doesmatch is better than matches in that it copes with more cases. (The
original algorithm used in fmatches (full-matches) was due to Jonathan
Cunningham, used in the Mac AlphaPop matcher, though, with his
permission, I adopted it, and transformed it in various ways for
fmatches).
doesmatch is worse than matches in that it creates more garbage. I think
that could be fixed by doing a preliminary run through the pattern to
see if there are any sublists with two segment elements, and if not use
the standard matcher, using a property to cache the decision.
There's another cause of garbage in all the three matchers in that the
value of popmatchvars is a list that holds variables that have been
assigned values in the current match, and after each recursive call it
is re-set if the match is unsuccessful. Preventing garbage due to the
use of popmatchvars could be tricky. It would be unavoidable if we
used Kers' suggestion of having the matcher return a set (list?) of
bindings.
Also the repeated linear scan of popmatchvars can slow things down if
there are lots of variables in a pattern. (Also I think the system
version uses member (or lmember?) instead of fast_lmember). I suspect
this is unavoidable, since creating a property to avoid linear search
would probably take up more time. Alternatively the syntax ![ .... ]
could be used to compile the pattern at compile time into a procedure
that matches itself with optimal efficiency. But getting that right
would probably take me six months, and I don't intend to try!
Maybe doesmatch (which also has the option of a procedure to check
that the match is OK) should replace the default matcher, which could be
renamed as fast_matches. Similarly sysmatch and fast_sysmatch
I'll leave it for others to decide whether to ask for this. Could be a
bit premature just now.
etc.
Aaron
|