Re: Why 3 different evaluators?
On Wed 16 Nov 2011 06:00, ri...@happyleptic.org writes: > According to the doc, guile currently maintain 3 evaluators: > > - the new VM > - an evaluator written in scheme > - the old C evaluator, used for bootstrapping the compiler. > > That's a lot of code just to bootstrap the compiler. Why not bootstrapping > the > compiler from either previous installed guile or (as fall-back) some provided > .go bytecode instead? Wouldn't that make guile code significantly simpler to > maintain and faster to compile? No :) If I bootstrap Guile-X from Guile-Y, I have to make sure that Guile-X's code can load in Guile-Y -- not trivial -- and I have to trust the output of Guile-Y. If I bootstrap Guile-X from GCC, I have to trust GCC. I trust GCC more than Guile-Y. You can use GUILE_FOR_BUILD if you want to speed things up. Andy -- http://wingolog.org/
Re: Why 3 different evaluators?
-[ Wed, Nov 16, 2011 at 10:31:31AM +0100, Andy Wingo ] > If I bootstrap Guile-X from Guile-Y, I have to make sure that Guile-X's > code can load in Guile-Y -- not trivial -- and I have to trust the > output of Guile-Y. You have to make sure that the evaluator that's written in scheme can be run by Guile-Y. This evaluator migh as well be written to be runnable by many other scheme implementations, if you really do not trust Guile :-) This is how GHC is bootstrapped BTW, any sufficiently standard haskell compiler can do it. > If I bootstrap Guile-X from GCC, I have to trust GCC. And the code for this C evaluator that's almost used nowhere thus probably much less tested than the rest of Guile. > You can use GUILE_FOR_BUILD if you want to speed things up. That's nice, will try it.
scm_local_eval V2 question
Hi all, Ironically, one of the LilyPond developers has been giving the Lily parser a spring-clean, and found scm_local_eval as the answer to his problems in the API. Unfortunately it's not just deprecated in Guile V2, it's been totally nuked, according to NEWS. Is there any C code from V1.8 you could help us to hack into our code base to provide a scheme evaluation within a single lexical context? The comments between the two Guile versions in eval.c imply we might get away with copying the scm_local_eval code and substituting the calls to scm_i_eval with eval. What would be the scope of doing this, given that we are parsing Scheme code embedded in LilyPond source. Thanks in advance for any pointers, Cheers, Ian Hulin
Re: Why 3 different evaluators?
On Wed 16 Nov 2011 11:17, ri...@happyleptic.org writes: >> If I bootstrap Guile-X from GCC, I have to trust GCC. > > And the code for this C evaluator that's almost used nowhere thus > probably much less tested than the rest of Guile. On the contrary, it is used to interpret the entire compiler, when compiling eval.go. It runs on every system that builds Guile. Also it is very simple, and uses the same algorithm as eval.scm. Andy -- http://wingolog.org/
Re: Why 3 different evaluators?
Very good then. Forget about my remark then.
Re: Why 3 different evaluators?
> From: Andy Wingo > On Wed 16 Nov 2011 11:17, ri...@happyleptic.org writes: > >>> If I bootstrap Guile-X from GCC, I have to trust GCC. >> >> And the code for this C evaluator that's almost used nowhere thus >> probably much less tested than the rest of Guile. > > On the contrary, it is used to interpret the entire compiler, when > compiling eval.go. It runs on every system that builds Guile. Also it > is very simple, and uses the same algorithm as eval.scm. I believe that you can still run the whole test suite on the C evaluator by erasing all the .go files from the modules lib, setting auto compile off, then running the check-guile script. It does take a while to start up, though, since it reads the psyntax file each time a new script starts. Haven't tried it lately, but, it has worked on previous versions of 2.0. -Mike
Re: Why 3 different evaluators?
-[ Wed, Nov 16, 2011 at 11:43:52AM -0800, Mike Gran ] > I believe that you can still run the whole test suite on the C evaluator > by erasing all the .go files from the modules lib, setting auto compile off, > then running the check-guile script. I though it would run the evaluator written in scheme in that case.
