On Tuesday 22 June 2010 01:49:59 pm Ludovic Courtès wrote: > Hi Stefan, > > stefan <stefan.ta...@spray.se> writes: > > http://gitorious.org/guile-unify/ > > > > I think it's a good start. Also I will try to make a less rude > > version of it. Until then you would not like to merge that code. > > so it is best to keep it in "playground" for some time. > > What justifies such a tight coupling with Guile core? > > It would really help maintenance and review if this were an independent > package. Only then should you consider optimizations that can only go > in Guile core, IMO. > > Thanks, > Ludo’. >
I wanted to branch the repo into an orthogonal code at a point and move everything into the prolog directory under lang just as you want. I think that this approach is a logical approach to combining a prolog vm and a scheme vm though. why? 1. the vm has some registers like sp,ip that the prolog logic can take advantage of. 2. doing it in scheme only lead to a waste of stack space. There is a "almost tail" call logic inside prolog. 3. prolog is very much like mathematical expressions. virtually every operation will be a foreign call if the core is pushed into c which is not a stupid thing to want. 4. this aproach matches gprologs WAM in speed if I'm not misstaken, but I think that by combining scheme and unification + backtracking means that this approach have a selling edge. 5. A language component need to be performant, the competition is hard and also by pushing to the edge you will know that it is a good approach if it matches other mature implementations. 6. Although a tight coupling is difficult and cumbersome, other aspects will line up very nicly and can nullify this difficulty. Also I want the repo to be a case for anybody interested in how to mod a vm into beeing performant logic programming engine as well. I don't think you will get the same speed with java or c# whatever you do. And last as a hacker I love to push things to the limits. I just wan't a have fun :-) Regards Stefan