[Date Prev] [Date Next] [Thread Prev] [Thread Next] Date Index Thread Index Search archive:
Date:Mon Jun 30 18:32:27 1993 
Subject:Re: Not a bug but a feature? 
From:jonm (Jonathan Meyer) 
Volume-ID:930630.10 

>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.