Hi Stefan, On Sun 23 May 2010 16:52, stefan <stefan.ta...@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/
