Re: guile-vm 0.4

[Rob Browning]

Keisuke Nishida <address@hidden> writes:

> Some files (not all) are ready to use:
> 
>   % guile
>   guile> (use-modules (system vm slib))
>   guile> (require 'alist)
>   guile> alist-map
>   $1 = #<program alist-map>
>   guile> (alist-map cons '((x 1) (y 2)))
>   $2 = ((x x 1) (y y 2))
>   guile> 
> 
> Your slib directory must be writable, because the compiler
> saves compiled code in files.

So a if I (load/compile "foo.scm"), what happens if foo.scm calls
(require 'bar) or (load "baz.scm")?  Will the vm try and byte compile
those files as well?

If so, then it seems like maybe there ought to be a way to prevent the
vm compile recursion, and/or prevent the filesystem writes (does the
vm require the writes, or are they just a performance win for later
loads?).  Maybe an alternate function:

  (load/compile file . write? recurse?)

or whatever.  I can imagine times when I might not really want to
write the .go files, and I wouldn't mind the increased load times.

(You can ignore this next bit if I'm mistaken in my assumptions
 above...)

Two of the issues I'm concerned about:

  (1) When trying out the vm, users (i.e. me :>) may want only some of
      the files to be byte-compiled.  If nothing else, the vm might
      not be ready to handle some of the files (macros, etc.), and
      requiring the user to re-structure the code so that none of the
      vm compiled files load any sub-files that contain macros,
      etc. is a little inconvenient during incremental adoption.

  (2) Users may want to use the vm on files that load system files
      (slib, ice-9/foo, etc.), but they won't necessarily have write
      permissions to those directories, and even if they did, always
      updating on demand seems like it may cause race conditions with
      other users.

Thanks.

-- 
Rob Browning <address@hidden> PGP=E80E0D04F521A094 532B97F5D64E3930