Re: unified field theory!

[Andy Wingo <wingo@pobox.com>]

Hi Stefan,

On Sun 23 May 2010 16:52, stefan <stefan.tampe@spray.se> writes:

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

Good news that it's OK, and agreed that it's on the expensive side; but
this may be fixed in Guile.

(For example, we could (and probably should) maintain the dynamic
context as a proper stack rather than a consed list. This has the same
performance tradeoffs that heap frames versus stack frames have,
regarding continuations; but the advantages to the normal case are more
important. In addition some prompts and aborts may be reduced to normal
control flow at compile time. This is a parenthetical note, due to the
tangential relevance to your code.)

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

Interesting question. Please let us know of your results.

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

All of this is very stimulating! Perhaps even more so for someone as
ignorant as myself, as I have more to learn.

It does seem that you are nearing a point where your code can be
generally useful. What do you think about starting a project on savannah
or gitorious, and tracking your code in git, together with these test
cases? If you are not familiar with the process, we can help you out. It
would be interesting to follow your hackings.

Cheers,

Andy
-- 
http://wingolog.org/