Re: 2.9.5 build segfault on Ubuntu 18.04 [WAS: Nyacc and guile-nearly-3.0 (progress report)]
On Mon, Dec 02, 2019 at 05:09:42PM -0800, Matt Wette wrote: > > On 12/2/19 6:28 AM, Matt Wette wrote: > >I'm building 2.9.5 now but running into errors (ubuntu 18.04): > >/bin/bash: line 6: 14657 Segmentation fault (core dumped) > >GUILE_AUTO_COMPILE=0 ../meta/build-env guild compile > >--target="x86_64-pc-linux-gnu" -O1 -Oresolve-primitives -L > >"/home/mwette/proj/guile/guile-2.9.5/module" -L > >"/home/mwette/proj/guile/guile-2.9.5/guile-readline" -o > >"system/vm/linker.go" "../module/system/vm/linker.scm" > So, as a random check, I first verified that I could reproduce the > above error at the command line. I did. > > Then I removed "-Oresolve-primitives" and it compiled without > error. Any help? OK -- compiles successfully now. I realize in hindsight that my answers sometimes went (only) to guile-devel, so I re-quote that one where I "solved" configury: > OK, solved this one -- will try to follow up with the rest. > > I just had to set GUILE_PROGS in etc/configure.ac besides GUILE_PKG, > like so: > > GUILE_PKG([3.0]) > GUILE_PROGS([2.9.5]) > > Configure now does "something". Next steps later. So far, so good. Now it compiles "cleanly" (but there's no -Oresolve-primitives option in sight in all of the compile; no idea why). A cursory test (with the example from the man page) shows signs of life. Yay! Thanks -- tomás signature.asc Description: Digital signature
Re: 2.9.5 build segfault on Ubuntu 18.04 [WAS: Nyacc and guile-nearly-3.0 (progress report)]
On Tue, Dec 03, 2019 at 10:15:35AM +0100, to...@tuxteam.de wrote: > On Mon, Dec 02, 2019 at 05:09:42PM -0800, Matt Wette wrote: > > > > On 12/2/19 6:28 AM, Matt Wette wrote: > > >I'm building 2.9.5 now but running into errors (ubuntu 18.04): > > [...] > > > So, as a random check, I first verified that I could reproduce the > > above error at the command line. I did. > > > > Then I removed "-Oresolve-primitives" and it compiled without > > error. Any help? > > Thanks -- I seem to be stuck at an earlier point, see my other > post; but once I get past that, your hint will surely be helpful. OK, solved this one -- will try to follow up with the rest. I just had to set GUILE_PROGS in etc/configure.ac besides GUILE_PKG, like so: GUILE_PKG([3.0]) GUILE_PROGS([2.9.5]) Configure now does "something". Next steps later. Thanks so far -- and looking forward to playing nyacc :-) Cheers -- tomás signature.asc Description: Digital signature
Re: 2.9.5 build segfault on Ubuntu 18.04 [WAS: Nyacc and guile-nearly-3.0 (progress report)]
On Mon, Dec 02, 2019 at 05:09:42PM -0800, Matt Wette wrote: > > On 12/2/19 6:28 AM, Matt Wette wrote: > >I'm building 2.9.5 now but running into errors (ubuntu 18.04): [...] > So, as a random check, I first verified that I could reproduce the > above error at the command line. I did. > > Then I removed "-Oresolve-primitives" and it compiled without > error. Any help? Thanks -- I seem to be stuck at an earlier point, see my other post; but once I get past that, your hint will surely be helpful. Cheers & thanks -- tomás signature.asc Description: Digital signature
2.9.5 build segfault on Ubuntu 18.04 [WAS: Nyacc and guile-nearly-3.0 (progress report)]
On 12/2/19 6:28 AM, Matt Wette wrote: I'm building 2.9.5 now but running into errors (ubuntu 18.04): /bin/bash: line 6: 14657 Segmentation fault (core dumped) GUILE_AUTO_COMPILE=0 ../meta/build-env guild compile --target="x86_64-pc-linux-gnu" -O1 -Oresolve-primitives -L "/home/mwette/proj/guile/guile-2.9.5/module" -L "/home/mwette/proj/guile/guile-2.9.5/guile-readline" -o "system/vm/linker.go" "../module/system/vm/linker.scm" So, as a random check, I first verified that I could reproduce the above error at the command line. I did. Then I removed "-Oresolve-primitives" and it compiled without error. Any help? Matt
progress
Hi, OK, the last progress for the rtl compilation is make it work to something as close as the current RTL VM, I have added a few variables that can control the kind of compilation strategy we would like to have as an output. I can for example now do (define f ((c (lambda (x) (let loop ((s 0) (i 0)) (if (eq? i x) s (loop (+ s i) (+ i 1 ;; This will compile the following RTL Code ((begin-program program278) (assert-nargs-ee/locals 0 1) (label :LCASE273) (make-empty-closure 0 program277 0) (return 1) (end-program) (begin-program program277) (assert-nargs-ee/locals 1 2) (label :LCASE272) (br :L274) (label :LCASE271) (br-if-eq 2 0 1 :L275) (mov 0 1) (return 1) (label :L275) (add 1 1 2) (add1 2 2) (br :LCASE271) (label :L274) (load-constant 1 0) (load-constant 2 0) (br :LCASE271) (end-program)) Then we can do (define g (lambda (x) (let loop ((s 0) (i 0)) (if (eq? i x) s (loop (+ s i) (+ i 1)) And compare, ,time (g 1000) $3 = 499500 ;; 0.293595s real time, 0.290550s run time. 0.00s spent in GC. scheme@(guile-user) ,time (f 1000) $4 = 499500 ;; 0.158049s real time, 0.150505s run time. 0.00s spent in GC So it starts to live in some sense. Now I consider the compile-rtl code as a research code e.g. it can compile correctly but it's a bit of a hack to churn in the rtl functionality in the old compile-glil code. It seems to work and I have made enough tooling so that the changes are clean in some sense at the higher level. On the lower level I rest on fluids and hacks with set! to achieve what I need. Anyway the abstractions are powerful enough so that I could build several compilation strategies and mix between them, for example we could have a native startegy and vm strategy that is more optimized if we have a vm or is running native. There are a few more options as well. The idea I have is that I would like to have a fairly complete picture of how to compile to the current RTL VM and not introduce too large deviations from wingo's strategy. But instead make it work and build explore from that base. Again having something that run's before trying to tweak is a good strategy I would say. Anyway, as you see there is some progress. Cheers Stefan
Re: progress with native code generation in guile
Hi Stefan! This sounds fun! Similarly, there’s the old Guile-Lightning, which could achieve something similar, albeit in an abstract ISA and not entirely in Scheme. Might be worth a look. Thanks, Ludo’.
progress with native code generation in guile
Hi, On linux, x86-64 I can now write, (use-modules (native aschm)) (define b (asm (inst mov rbx 10) ;rbx = 1000,000,000 loop: (inst cmp rbx 0) (inst jmp #:eq out:) (inst dec rbx) (inst jmp loop:) out: (inst mov rax 2) ; return value in register rax (inst pop rbx); we pushed the return adress before (inst jmp rbx))) ; jump back (mk-rwx b) ; Make the memory pages read write and ; execute (run-native b) ; run the code using a simple scheme And the code loops and return 0 (2). So it is possible to generate assembler from whithin guile and execute it which is pretty cool. If you have the right architecture, you can play with it at: https://gitorious.org/aschm Have fun Stefan
Re: The progress of hacking guile and prolog
Hi Noah, On Wed 24 Nov 2010 02:54, Noah Lavine noah.b.lav...@gmail.com writes: What I'm thinking of is like racket contracts, but with the idea of trusted modules, which might involve static checking. Yeah, definitely. Like the interface between typed and untyped code in racket, also. I don't know very much about the relationship between types and contracts, though. I'm curious in general though whether it would be possible and worthwhile to statically check programmer-defined ideas, as long as the interface is easy enough to use. For instance, what if you could ask Guile to check that your tree structure always remained a binary tree? Or better, what if you wrote a GUI program and checked that the callbacks you passed to the GUI library would always return? (I know it's not possible in general, but I think it will work for a subset of procedures that will include some interesting ones.) It's certainly interesting! As I understand things (which is not very far), Racket allows for this via other languages. Guile could do that too. We might need some more generic support for this kind of thing in the compiler infrastructure or in tree-il or whatever, but I would like to make it possible to experiment with these linguistic ideas, with the kind of isolation provided by modules. Cheers, Andy -- http://wingolog.org/
Re: The progress of hacking guile and prolog
Hello, Though I’d recommend working on JIT for Guile before you get stuck in a meta-circular Curry-Howardish enlightenment period. :-) I agree. :-) Noah
Re: The progress of hacking guile and prolog
Hi! Noah Lavine noah.b.lav...@gmail.com writes: What I'm thinking of is like racket contracts, but with the idea of trusted modules, which might involve static checking. For instance, if the contract is that map's second parameter is a list, you'd normally want to check that. But if a module that used map could guarantee that it would always pass a list as the second argument, then you'd arrange things so the second module could skip the type check. In Guile, modules are dynamic by nature: they are assembled at run-time (everything is “dynamically linked”). My feeling is that cross-module static analysis doesn’t fit well in this framework. I'm curious in general though whether it would be possible and worthwhile to statically check programmer-defined ideas, as long as the interface is easy enough to use. For instance, what if you could ask Guile to check that your tree structure always remained a binary tree? I think you’ll be interested in dependent types: https://secure.wikimedia.org/wikipedia/en/wiki/Dependent_types Though I’d recommend working on JIT for Guile before you get stuck in a meta-circular Curry-Howardish enlightenment period. :-) Thanks, Ludo’.
Re: The progress of hacking guile and prolog
Hi Noah, On Wednesday, November 24, 2010 02:54:37 am Noah Lavine wrote: Hello, That might make sense. The documentation certainly looks interesting. What I'm thinking of is like racket contracts, but with the idea of trusted modules, which might involve static checking. For instance, if the contract is that map's second parameter is a list, you'd normally want to check that. But if a module that used map could guarantee that it would always pass a list as the second argument, then you'd arrange things so the second module could skip the type check. Sure static typechecking can save some time, but also note that it can bring in applications that would not be on a scheme platform without static typechecking/proofing due to code safety reason imaginable or not (again static versus dynamic). An intersting note, one here stories about codebases around a popular dynamically p.l. where the test harness grow out of bounds and where the major part of it is test that the static typechecker would have been performed by default in both a much faster manner and also more rigourusly. Personally I prefere dynamic - but that is from my usage pattern which is mainly smaller programs that automate. Form this I'm wondering if the people in this hersay really take advantage of testing only the relevant parts of the code in light of done changes. I'm curious in general though whether it would be possible and worthwhile to statically check programmer-defined ideas, as long as the interface is easy enough to use. For instance, what if you could ask Guile to check that your tree structure always remained a binary tree? Or better, what if you wrote a GUI program and checked that the callbacks you passed to the GUI library would always return? (I know it's not possible in general, but I think it will work for a subset of procedures that will include some interesting ones.) Yep I agree with you here. Here is an idea: You can try to say something like this function argument will never be returned or kept in a closure etc. Then you might allocate that object from the stack. Again it is not always ways to proove this but sometimes you can. So the function argument could be of a proved not proved and don't know and you can make sure to use the safe way. Then you can guide a user to prove that it is indeed so or let the user say it is so or just take the safe path and allocate from the heap. There is a nice pattern here that one could employ when there is a compiler for guile (without compiler the speedup is not that exiting on a relative scale). Process the code and builed up the result using a tail call paraadigm, e.g. there is a parameter res that is constructed. Then at the end return (heapify (revers ret)) and transfere the constructed ret object to the heap by trying to fill a continuous segment on the heap by cons cells that is linked appropriated. That way you get some work to align objects on the heap, allocate a big chunk at the time and the overall performance scale and is performat. I would say that 99% of the code I write that use or could use this pattern can be typechecked to proove that res could be builed up from stack elements. The typical usage scenario here is to speed up functional (no mutating) code transformations. Have fun Stefan
Re: The progress of hacking guile and prolog
Hello, That might make sense. The documentation certainly looks interesting. What I'm thinking of is like racket contracts, but with the idea of trusted modules, which might involve static checking. For instance, if the contract is that map's second parameter is a list, you'd normally want to check that. But if a module that used map could guarantee that it would always pass a list as the second argument, then you'd arrange things so the second module could skip the type check. I'm curious in general though whether it would be possible and worthwhile to statically check programmer-defined ideas, as long as the interface is easy enough to use. For instance, what if you could ask Guile to check that your tree structure always remained a binary tree? Or better, what if you wrote a GUI program and checked that the callbacks you passed to the GUI library would always return? (I know it's not possible in general, but I think it will work for a subset of procedures that will include some interesting ones.) Noah On Sat, Nov 20, 2010 at 6:25 AM, Andy Wingo wi...@pobox.com wrote: Hi Noah, On Thu 04 Nov 2010 03:40, Noah Lavine noah.b.lav...@gmail.com writes: I think that Guile should offer optional static checking - not just of types, but of everything that we can check. It seems like you're really asking for *dynamic* checking -- not only checking properties that can be proved statically, without running the program, but also runtime properties. In this regard, I have a positive impression of the work that people are doing on contracts, especially the Racket folks. http://docs.racket-lang.org/reference/contracts.html Happy reading, Andy -- http://wingolog.org/
Re: The progress of hacking guile and prolog
Hi Noah, On Thu 04 Nov 2010 03:40, Noah Lavine noah.b.lav...@gmail.com writes: I think that Guile should offer optional static checking - not just of types, but of everything that we can check. It seems like you're really asking for *dynamic* checking -- not only checking properties that can be proved statically, without running the program, but also runtime properties. In this regard, I have a positive impression of the work that people are doing on contracts, especially the Racket folks. http://docs.racket-lang.org/reference/contracts.html Happy reading, Andy -- http://wingolog.org/
Re: The progress of hacking guile and prolog
Hi again, The more apropos link to Racket's contracts would probably be: http://docs.racket-lang.org/guide/contracts.html Cheers, Andy -- http://wingolog.org/
Re: The progress of hacking guile and prolog
Hi, Noah Lavine noah.b.lav...@gmail.com writes: On a completely different note, I'm now looking at writing a compiler for a subset of C, which could eventually become a JIT compiler. If we could attach your GLIL-C compiler to that, it could produce a full Scheme-machine code compiler in Guile. Interesting. I thought you were going rather to compile a subset of Scheme to C, which could be used to implement VM instructions, no? Thanks, Ludo’.
Re: The progress of hacking guile and prolog
Hello, I think that we have similar synaptical fireworks here. The actual implementation and syntax should be a result of understanding the line of reasoning in these theorem povers and checkers. So let my try to explain what I'm heading. I will try to write a little about where I am in a few days and we can continue the discussion then. Great! Shall we say that you implement a JIT compiler and I progress with the glil-c stuff. I was uncertain an a little afraid that I toed you here. That sounds good. In general though, please don't worry about treading on my territory or anything like that. I will be happy as long as Guile gets new features, and I am fine not being the person who writes them. Noah
Re: The progress of hacking guile and prolog
Yes, that's right. I was unclear. I am intending to come up with a language that I can compile to C, to implement VM instructions. I meant I would compile something to C, not from it to machine code. Just to clarify, it probably won't be a subset of Scheme (although one could compile a subset of Scheme to this language). I was thinking of something more like register transfer language, so the compiler will be very simple. Noah On Thu, Nov 11, 2010 at 11:26 AM, Ludovic Courtès l...@gnu.org wrote: Hi, Noah Lavine noah.b.lav...@gmail.com writes: On a completely different note, I'm now looking at writing a compiler for a subset of C, which could eventually become a JIT compiler. If we could attach your GLIL-C compiler to that, it could produce a full Scheme-machine code compiler in Guile. Interesting. I thought you were going rather to compile a subset of Scheme to C, which could be used to implement VM instructions, no? Thanks, Ludo’.
Re: The progress of hacking guile and prolog
Interesting. I thought you were going rather to compile a subset of Scheme to C, which could be used to implement VM instructions, no? Yes, that was my plan, sorry. I want to compile things to C, not from C to machine code. Also, to clarify, I am looking at compiling not a subset of C, but something like register transfer language. That way the compiler can be very simple and hopefully obviously correct. Noah
Re: The progress of hacking guile and prolog
On Thursday, November 04, 2010 03:40:09 am Noah Lavine wrote: Hello all, Not to derail the thread of discussion, but I've had an idea for a feature bouncing around that I think might hook into this. I think that Guile should offer optional static checking - not just of types, but of everything that we can check. It could be used partly for optimization, but partly also as a way to verify that you're reasoning about the program correctly. (Like assert, but you prove things correct.) For instance, (define (map func list) (check (= (arity func) 1)) ) or (define (search-binary-search-tree tree key) (check (binary-search-tree? tree) ; or whatever conditions make sense ) I'm afraid I don't know much about how theorem provers like that would be used to make static checkers, but is there a way to use LeanCOP or Kanren to provide something like this? I think the easiest interface would be one where you could put arbitrary Scheme code in check statements, but the prover would be able to reject it as unable to check this, in which case it could insert a runtime check (if you asked it to). I think that we have similar synaptical fireworks here. The actual implementation and syntax should be a result of understanding the line of reasoning in these theorem povers and checkers. So let my try to explain what I'm heading. I will try to write a little about where I am in a few days and we can continue the discussion then. On a completely different note, I'm now looking at writing a compiler for a subset of C, which could eventually become a JIT compiler. If we could attach your GLIL-C compiler to that, it could produce a full Scheme-machine code compiler in Guile. Shall we say that you implement a JIT compiler and I progress with the glil-c stuff. I was uncertain an a little afraid that I toed you here. /Stefan
Re: The progress of hacking guile and prolog
Ok, for the c generator, here are some code attached. I would
just study this there is bit's still missing and you need to wait for me to
dig up the details. My point is to suggest ideas for what can be done.
I don't assume that this is it. But it's a nice playing ground.
So it is a hack, here is what I do.
(use modules (language glil compile-assembly))
(set! *compile-to-c* #t)
(define (f N)
(set! c-dummy 'c-code-tag) ;; This tagg!! initiate the compiler
;; and c-fkn will use the
;; c-code-tag slot :-)
(let loop ((I N) (X 0))
(if (eq? I 0)
X (loop
(- I 1) (+ X 1)
(generate-c-fkns fkn)
Then in a sub-directory called cboost from the starting directory you find
fkn.c and a makefile. e.g.
Makefile:
=
libguile-fkn.so : fkn.c
gcc -shared -O2 -o libguile-fkn.so -fPIC fkn.c
fkn.c:
==
#include cfkn.h
#define LOCAL_REF(i) fp[i]
#define LOCAL_SET(i,v) fp[i] = (v)
void cfkn3676(SCM *fp, SCM **spp)
{
/* setup of environment */
SCM *objects, *free, program, *sp, sss[100];
sp = sss;
program = fp[-1];
objects = SCM_I_VECTOR_WELTS (SCM_PROGRAM_OBJTABLE (program));
free= SCM_PROGRAM_FREE_VARIABLES(program);
/* compiled section */
LCASE3666:
goto L3668;
LCASE3665:
sp++; *sp = LOCAL_REF(1);
sp++; *sp = SCM_I_MAKINUM(0);
sp-=2; if(!scm_is_eq(sp[1],sp[2])) goto L3669;
sp++; *sp = LOCAL_REF(2);
RETURN;
L3669:
sp++; *sp = LOCAL_REF(1);
SUB1;
sp++; *sp = LOCAL_REF(2);
ADD1;
LOCAL_SET(2,*sp) ; sp--;
LOCAL_SET(1,*sp) ; sp--;
goto LCASE3665;
L3668:
sp++; *sp = LOCAL_REF(0);
sp++; *sp = SCM_I_MAKINUM(0);
LOCAL_SET(2,*sp) ; sp--;
LOCAL_SET(1,*sp) ; sp--;
goto LCASE3665;
}
void init_fkn.c()
{
SCM cfkn3676_sym;
cfkn3676_sym = scm_from_locale_symbol(cfkn3676);
printf(loading fkn %s as adres %x.\n,cfkn3676,cfkn3676);
scm_define(cfkn3676_sym,SCM_PACK(((scm_t_bits) cfkn3676) | 2));
}
So compileing and loading the shared library into guile you should be able
to issue (f 100) and get a correct and fast result.
I'm did not find my cfkn.h file but I'll send you the stuff I have. I modify
glil-assembly and add offload some bit's into an extra file into the same
directory also a vm-instruction is added to be able to start the c-code.
Have fun
Stefan
compile2c.tar.gz
Description: application/compressed-tar
Re: The progress of hacking guile and prolog
On Thursday, November 04, 2010 12:43:54 am Ludovic Courtès wrote: Hi Stefan, Lots of stuff here, which is why I took the time to read it. :-) Stefan Israelsson Tampe stefan.ita...@gmail.com 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. :-) Yes, but I would like to be more true to it then I am right now. So is it enough to reproduce minikanren? Also I've reading in on racklog so I guess what I have right now is correct conceptually but not syntactically. But of cause this can be fixed. So If you think it is worthwhile I will download the minikanren sorce hack on. 4. The umatch hackity hack was turned into a much more hygienic creature. Funny sentence. :-) Well I have two versions one based on the match-phd and is not touching guiles internals and is based on passing continuations closures and has the property that all calls are tail calls for basic prolog usage patterns. Also note that this principle is not as expensive that one may think if you take into acount a system that inline functions acording to findings from profiling. So in principle all this pushing parameters to the heap could be mitigated. The other one is the hackety hack that tend to be fast on the vm. 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. Notes. 1. It's when compilers start to work you will gain from removing type checks. It's probably not worth it in vm land 2. If a function is used like (f 0.1) in function g and you recompile function f to just allow only fixnums you may end up with havoc. So either function dependencies is tracked or you use the racket way of executing code if going down this optimizing path in a safe way. 3. Of cause local entities can be tracked and optimized away and maybe we should stick to only that. What’s amazing is that Kanren + type-inference.scm weigh in at “only” ~3,500 SLOC. Hence is a powerful concept :-) Hmm I'm also keen to match what typed racket does. I will look into this. 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? Uhmm, I was just curious to se what the overhead of dispatching instructions in a goto-loop would give when I did it. But just think of it as a tool that just inline the c-code behind some simple vm instructions in stead of the actual vm-instructions. Actually all prolog vanilla prolog code should be able to be compiled quite effectively this way cause it's all tail calls. I'm not sure my code is that interesting though Probably the idea is more interesting and should be discussed. The basic idea is to pair the c-code generation with the glil-assembly code so that the compiling function and all it's internal lambda get's corresponding c-function quite automagically and then be gcc:d into linkable code and hooked int these functions vm part that now just act like a trampoline into C land. Do you see it? Have fun Stefan
Re: The progress of hacking guile and prolog
Hi Stefan, Lots of stuff here, which is why I took the time to read it. :-) Stefan Israelsson Tampe stefan.ita...@gmail.com 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’.
Re: The progress of hacking guile and prolog
Hello all, Not to derail the thread of discussion, but I've had an idea for a feature bouncing around that I think might hook into this. I think that Guile should offer optional static checking - not just of types, but of everything that we can check. It could be used partly for optimization, but partly also as a way to verify that you're reasoning about the program correctly. (Like assert, but you prove things correct.) For instance, (define (map func list) (check (= (arity func) 1)) ) or (define (search-binary-search-tree tree key) (check (binary-search-tree? tree) ; or whatever conditions make sense ) I'm afraid I don't know much about how theorem provers like that would be used to make static checkers, but is there a way to use LeanCOP or Kanren to provide something like this? I think the easiest interface would be one where you could put arbitrary Scheme code in check statements, but the prover would be able to reject it as unable to check this, in which case it could insert a runtime check (if you asked it to). On a completely different note, I'm now looking at writing a compiler for a subset of C, which could eventually become a JIT compiler. If we could attach your GLIL-C compiler to that, it could produce a full Scheme-machine code compiler in Guile. Noah On Wed, Nov 3, 2010 at 7:43 PM, Ludovic Courtès l...@gnu.org wrote: Hi Stefan, Lots of stuff here, which is why I took the time to read it. :-) Stefan Israelsson Tampe stefan.ita...@gmail.com 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’.
The progress of hacking guile and prolog
Hi,
I think it's good to discuss what I do with the prolog and unifer. So this
is what I've been doing.
1. Incorporate a theorem prover for extension and playing
2. Kanren like hygienic macro package
3. Make the c-code variables printable and hence much less segfaults at bt :-)
e.g. robustify
4. Hygienify the fast umatcher.
5. try to design a type checker mimiking typed racket.
6. Play with compiled guile vm code to check for speed
7. Redesign and unugglify and improve the main prolog compiler
8. Introduce interesting features like higher order functional behavior.
9. Move the code over closer to guile Head.
Hew oh well, thats feels like a lot, let's check it out.
1. The theorem prover (leanCop) is a nice exercise to incorporate and use
because it uses quite a lot of prolog features and beeing able to compile that
into working code led me back to read up about some of my ignorantic parts of
prolog I've not setled here how to solve it. the thing is that one meld the
operator parser in prolog to whatever one may like and use that to parse
general code. I really don't like that the core languge changes behavior as
you parse language x, and added a feature where the parser enters a new
context e.g. the parsing language x and hence one can separate the two. This
is
not iso behavior although you can still modify the core language. There will
be incompabilities but you can give the users some advice how to avoid these
by using parenthesises. I think that this is a design choise for the better
though. Anyhow with some luck there will be a code prover for guile in a
couple of years :-)
2. Kanren is a nice way to program like with prolog, but using code more true
to scheme. So I've been working with a hygienic macro package that should
give such a feature. These macros will then be used in the prolog compiler
to beutyfy it. I reallt think that this is the right way and really like
what I've churn out so far.
3. The speedy umatch thingy was quite terrible to work with because it entered
these home cooked c variables into guile which just segfaulted when trying to
print it. (ugly) Anyway the print routine was hacked in my repo to print the
it better. Still there probably are some dragons sleeping here but at least
the coding experience is much better.
4. The umatch hackity hack was turned into a much more hygienic creature. Not
perfect but at least it should now play much nicer with the macro system. The
key issue was that everything was a defmacro (i did not now better then) and
the matcher introduced syntactics from outer s(pace)cope so it was not to just
bless the beast with (datum-syntax). One needed to take the x in
(syntax-datum x) and split it up, tryying to keep bits of syntactic
information to transfer it into the old macro compiler. Here comes a
pretty cool hack actually. Consider the following module:
---
(define-module (ice-9 syntax-matcher)
#:use-module (ice-9 match-phd-lookup)
#:export (match-syntax-hack))
(define (syntax-null? x ) (null? (syntax-datum1 x)))
(define (syntax-equal? x y) (equal? (syntax-datum1 x) y))
(define (syntax-id x)
(define (syntax? x) (not (eq? x (syntax-datum1 x
(if (pair? x)
x
(let ((r (syntax-datum1 x)))
(if (pair? r)
(let ((h (if (syntax? (car r)) (car r) (datum-syntax x (car r
(l (if (syntax? (cdr r)) (cdr r) (datum-syntax x (cdr
r)
(cons h l))
x
(make-phd-matcher match-syntax-hack ( (car cdr pair? syntax-null?
syntax-equal? syntax-id) ()))
syntax-datum1 transfer a syntax object to a datum for only it's root, e.g. it
does not try to make everything a datum.
id is a lookup creature and match-phd-lookup is a modded match generator that
uses custom lookup or syntax-id as I call it. it's just an unpacking command
that is done befor car cdr and pair? is executes like
(let ((v (lookup v))) (if (pair? v) (f (car v) (cdr v
so it's a stupid efficiency hack so that we don't lookup all the time. Now
syntax id will open up a pair and if some of them it's children is not of a
syntax kind it will bless the child with the syntax of the parent syntax
object. Now with this matcher I want to chop up the following structure
(arg1 ... argn ((pat1, ..., patn code) ...))
and can then use:
(define (my-unsyntax X)
(define (unsyntax2 X)
(define (unsyntax3 X)
(define (unsyntax4 X)
(match-syntax-hack X
(('unquote X) (list 'unquote X))
(('uunquote X) (list 'uunquote X))
(('?X) (list '?X))
(('= X P) (list '=X (unsyntax4 P)))
(('? X P) (list '?X (unsyntax4 P)))
((H . L) (cons (unsyntax4 H) (unsyntax4 L)))
( H(syntax-datum1 H
Progress in porting to 1.7, but still work to do
I have *two* problems. First, after emitting the error text below,
Guile 1.7.2 is calling, exit(0) not exit(EXIT_FAILURE).
That's wrong. Additionally, I am not getting the file/line
stuff using the code I thought we worked out.
--- error.out6 Sun Dec 4 13:41:27 2005
***
*** 1,5
! error.tpl6:7:4: In expression (stumble-over-unbound-variable):
! error.tpl6:7:4: Unbound variable: stumble-over-unbound-variable
Scheme evaluation error. AutoGen ABEND-ing in template
error.tpl6 on line 3
Failing Guile command: = = = = =
--- 1,4
! ERROR: Unbound variable: stumble-over-unbound-variable
Scheme evaluation error. AutoGen ABEND-ing in template
error.tpl6 on line 3
Failing Guile command: = = = = =
+ exit 1
Wasn't this supposed to work?
SCM port = scm_open_input_string( scm_from_locale_string( pzExpr ));
{
static SCM file = SCM_UNDEFINED;
static char* pzOldFile = NULL;
if ((pzOldFile == NULL) || (strcmp( pzOldFile, pzFile ) != 0)) {
if (pzOldFile != NULL)
free( pzOldFile );
pzOldFile = strdup( pzFile );
}
file = scm_from_locale_string( pzFile );
scm_set_port_filename_x( port, file );
}
{
SCM ln = scm_from_int( line );
scm_set_port_line_x( port, ln );
}
{
SCM ans = SCM_UNSPECIFIED;
/* Read expressions from that port; ignore the values. */
for (;;) {
SCM form = scm_read( port );
if (SCM_EOF_OBJECT_P( form ))
break;
ans = scm_primitive_eval_x( form );
}
return ans;
}
___
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel
