unified field theory!

[stefan <stefan.tampe@spray.se>]

Hi,

I)
I did introduce prompts to the example unify code, and the comparison 
resulted in
no-prompt     :  37ms
gp-prompt     :  35ms
guile-prompts :  49ms

I think using guile prompts are acceptable here. But they are on the expensive 
side, especially in the light that unwinding should not put a significan
mark on the timings.

II)
unify variables and fluid variables are close in nature. So it would be cool
to understand the difference better. i will dive in on that. 

III)
One cool thing is to abstract out matchers. As a result you get a little tool
to create top down parsers. here we go, consider

(udef <i> (((? integer? X) . L) (cons X  L)
	   (L                   (cons #f L))))

A matcher for an integer!

the output of a matcher has to be of the from (cons Val Rest). when Val 
equals #f it sends the signal of a failure. (perhaps use (values Val Rest) 
instead)

now we can use this as
(udef f ((<i> <i> 'a 'b) 'ok)) 

and 

(f '(1 2 a b)) will match to 'ok

But it's really nice to have arguments to the matcher so consider

(udef <...> ((F   (  (<> F)   (<...> F)  )  (cons (cons F.0 <...>.0) 
						  <...>...))
	     (F    L                        (cons '() L))))

F.0   is the value of the (<> F) match. F... is the rest of the same match and
so on. Now <...> is a gready matcher that has one argument F that itself is 
a matcher and now we can use it accordingly. if a symbol looks like <symb>
then it's a matcher abstraction. (<> F) is used when the matcher has a name
not of that form.

(udef f ((   (<...> <i>) . L)  L))

and

(f '(1 23 4 a b)) 

gives

'(a b)

Have fun,

Stefan