Re: What happened to the ex-Guile VM?

[Mikael Djurfeldt]

Keisuke Nishida <address@hidden> writes:

> I found somebody was working on a bytecode interpreter (VM) for
> Guile around 1997.  What happened to it?  Why does it not exist now?
> The message I read was about the VM's unsatisfactory efficiency.
> Was it the only reason that Guile did not adopt a VM?

Yes.

We are not conservative, except when we have good reason (API) to be
so.  A decision to replace the evaluator is solely based upon the
relative merits of the current evaluator versus the new solution +
maybe influences of future plans.  The work required to replace the
normal evaluator is probably healthy for Guile, because it will mean
further orthogonalization and modularization.

> Or is there any fatal reason of not supporting a VM?

No.  In my personal opinion, we should replace the normal evaluator
with a VM as soon as possible.  Candidates are your VM and the new
QScheme VM, and possibly work by Marius connected to GNU Lightning.
Of course, the best would be to try to integrate the best ideas from
each project...

Actually, it will probably be Marius who will supervise such an
integration.  Please take this letter partly as my personal view.

> Anyway, this is a brief summary of the current status of my VM.

Thank you for providing this.  I really appreciate it.

> One is for fast execution, and one is for debugging execution.

One idea could be to drop the conditional compilation in eval.c and
only keep the debugging evaluator, and replac the "normal" evaluator
with your VM.  But it would of course be nicer if we could replace the
current evaluator completely.  At the same time, we wouldn't like to
downtrade a lot with regard to for example the quality of backtraces.
The current backtraces are very informative when debugging.  We should
work on getting a similar quality of source level backtraces when
using your VM.

> More advanced stuff like importing/exporting variables is
> supported by the intermediate language and the compiler.
> All variables are statically identified at compile time,
> and the compiler produces `global-ref' as necessary.  The
> compiler must also take care of run-time recompilation of
> pre-compiled code during an interactive session.
> 
> All languages, including Scheme, are to be translated into an
> intermediate language, called GCIL (formerly called iScheme).

This is *very* interesting.  Current policy with regard to Guile and
language translation is to have translators translate into Scheme.
The reason for this policy is that we don't want translators tied to a
particular VM.  However, if your language GCIL is in itself generic
enough, we should consider the possibility of using that instead as a
target for translators.

> The following is the definition of the language R5RS:
> 
>   (define-language r5rs
>     :title        "Standard Scheme (R5RS + syntax-case)"
>     :version      "0.3"
>     :reader       read
>     :expander     expand
>     :translator   translate
>     :printer      write
>     :environment  (global-ref 'Language::R5RS::core)
>     )
> 
> The following procedures are provided:
> 
>   (read-in PORT LANG)
>   (compile-in FORM ENV LANG . OPTS)
>   (compile-file-in SOURCE TARGET LANG . OPTS)
>   (eval-in FORM ENV LANG)
>   (load-in FILE LANG)
>   (print-in VAL PORT LANG)

(BTW, have you studied the language translation proposal?
 guile-core/devel/translation/langtools.text)

> I just wanted to let you know I am still working on Guile VM and
> going to continue doing ;)

That's great!

Thanks!

Mikael