Steve,
Thanks for the comment.
> > The generalisation of "valof" makes a huge difference to what you can do
> > with the Pop-11 pattern matcher, and makes LIB FMATCHES redundant, at
> > last.
>
> Sadly, lib fmatches is not made redundant. Firstly, fmatches does not
> suffer from the multiple segment matching defect of matches and that
> alone makes it indispensible.
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. )
However, like fmatches it will generate unnecessary garbage if you do
not need a solution to the multiple segment matching problem because all
your patterns have a simple enough structure for the old matcher to
cope.
Actually all three matchers generate garbage because of the temporary
creation and release of lists of variables that have been bound
(popmatchvars). I should have a go at restoring these to the free list,
or perhaps replacing popmatchvars with a long re-usable vector?
> ...More importantly, fmatches does not
> suffer from the data/pattern confusion of matches which makes matches
> inherently dangerous.
I don't understand this. Can you elaborate?
A very serious problem with fmatches is that all patterns have to be
inline. I.e. you cannot pass a pattern as an argument to fmatches and
therefore it is useless for defining procedures which e.g. take lists of
patterns as arguments and iterate over them, or which take a pattern and
a database, etc.
Could it be that this flaw is what you regard as a benefit, i.e. you
think patterns should be regarded as code not as data?? That's a
distinction I prefer to abolish!
Aaron
|