Re: Guile is becoming as fast as rep

[John Harper]

Keisuke Nishida writes:
|> Wow, that's really impressive (especially as the rep vm has been around
|> longer than yours..)
|
|My VM is still under development, though...

yes, that's what I meant, I'm starting to run out of things to optimize
now, but your vm probably still has untapped potentional :-) 

|(It lacks module support, exception handling, function inlining, etc.)

I haven't got function inlining to work across module boundaries yet
(for ML paper, see http://citeseer.nj.nec.com/context/297296/0)

|
|> I've not been trying to make interpreted code run fast, so I'm not
|> surprised by this..
|
|Why don't you dynamically compile the user input and run it?
|I mean I think your repl could be written as something like
|
|  (define (repl)
|    (print (vm-exec (compile (read)))))
|
|Your compiler is too slow?  Or your VM does not have debugging
|facilities?  Hmm, maybe I should read the source.  Probably
|there are something I can steal :)

I've considered doing this, but compiling ahead of time is more
efficient for the things I normally use the system for..

But you're right, the compiler isn't blindingly fast (peephole
optimization of the bytecode takes most of the time), but I've never
considered this a problem (except when bootstrapping from the
interpreter :-)

And yes, there is no support for debugging compiled code, I've never
found this a problem either. Errors can still print backtraces, and
that's usually enough to fix the problem,

        John