guile-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: The progress of hacking guile and prolog


From: Ludovic Courtès
Subject: Re: The progress of hacking guile and prolog
Date: Thu, 04 Nov 2010 00:43:54 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (gnu/linux)

Hi Stefan,

Lots of stuff here, which is why I took the time to read it.  :-)

Stefan Israelsson Tampe <address@hidden> writes:

> 1. The theorem prover (leanCop) is a nice exercise 

[...]

> 2. Kanren is a nice way to program like with prolog,

Great that you’re mentioning them.  It looks like there’s a lot of
interesting work that’s been done around Kanren, such as the “toy” type
inference engine and, better, αleanTAP.  I don’t grok it all I’m glad
you’re looking at it from a Guile perspective.  :-)

> 4. The umatch hackity hack was turned into a much more hygienic creature.

Funny sentence.  :-)

> 5) Typechecking is for safty and optimisation, in the end it can be cool to 
> have and I'm working to understand all sides of this and have a pretty good 
> idea what is needed. It will be a goos testcase for the code.

Yes, if the type inference engine that comes with Kanren could somehow
be hooked into Guile’s compiler, so that it can emit type-mismatch
warnings or determine whether type-checks can be optimized away (which
would require changes in the VM), that’d be great.

What’s amazing is that Kanren + type-inference.scm weigh in at “only”
~3,500 SLOC.

> 6) I copied the  glil->assembly compiler and modded the code to spit out 
> c-code in stead of assembly. For functions which does not call other scheme
> functions except in tail call manner this should be quite fast to adapt. And
> of cause loops becomes wickedly fast when compiling this way. Wingo:s example 
> without consing tok 7ns for each loop on my machine.

Interesting.  Is it a sufficiently isolated change that you could point
us to?

Thanks,
Ludo’.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]