>The way to make the matcher intoa really useful tool would be to make
>it a first class part of the language. "matches" and ---> would need
>to be known to the compiler and a pattern would be a special kind of
>thing rather than just a list which is interpreted at run time.
Thats effectively what fmatches does.
An idea that has bounded around for a while is to introduce a special kind of
ref to the system which can have an 'unassigned' contents, and which is
treated specially by `=', i.e. if its contents are unassigned then `=' returns
true and as a side effect sets the contents to the item that it is equal to.
If it has an assigned contents then `=' returns true only if the contents
are = to the item.
Call this special unifying ref a 'uniref', whose field is called 'unicont'.
We could do:
lvars funny = newuniref();
[1 2 3] = [1 2 ^funny] =>
** true
funny.unicont =>
** 3
;;; note that:
funny = 3 =>
** true
;;; and:
funny = 4 =>
** false
With some simple syntax a mechanism like this would be far more useful
to me than the matcher is.
e.g. a macro called -uniref- which declares an lvars, initialises it to an
unassigned uniref, and returns the uniref. This allows you to simplify the
above statement to:
[1 2 ^uniref funny] = [1 2 3] =>
** true
funny.unicont =>
** 3
Comments?
Jon.
|