guile-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

GNU Guile meeting notes


From: Neil Jerram
Subject: GNU Guile meeting notes
Date: Tue, 25 Aug 2009 22:53:03 +0100
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux)

Andy, Ludo and I actually met in Real Life (tm) a couple of weeks ago,
and spent a day talking through lots of Guile stuff.  It was fun.

With apologies for the delay (which reflects nothing but my lack of
time), below are my notes from that meeting.

     Neil


* 2.0 release milestones

We discussed and agreed the following items as things that we really
want to get done before the 2.0 release.

Bearing in mind all of the following, we also agreed to move the
tentative 2.0 date from 15th October to 15th December.

** GC

i.e. switching to using Boehm-Deimers-Weiser libgc, instead of Guile's
own.

Our plan is to merge this work to master before the next 1.9.x
prerelease.

** Module name spaces

i.e. we'd really like to get rid of the `%app' and
`%module-public-interface' hacks before 2.0.

** Scheme eval

Implementing eval in Scheme, and compiling it, will solve current
problems of bouncing between compiled and interpreted code, and of not
being able to tail-call between them.

** Fix problems with read options and current-reader

The fact that a whole file is read and compiled together - as opposed
to each top level expression being read and then evaluated in turn -
means that these no longer work as they used to.

Plan to fix this by making read-set! etc. a macro.

** GOOPS dispatch in the VM

Look at using polymorphic inline caches here.

Andy adds: "I ran into this issue on wip-eval-cleanup; it
self-compiles until reaching occam-channel, because it's the first
thing that uses GOOPS.

I think this is going to be an early priority for me, along with
cleaning up subr dispatch (so it's easy to get into the VM)."

** Merge most of Andy's array refactoring

Most of this branch has since been merged.  We're still not quite
agreed on the bytevector/SRFI-4 unification; Andy's going to prepare
an updated patch for that.

** ECMAscript test and documentation

We have another working language, so we should show it off!

** Testing the main Guile applications

As much as we can; by encouraging the application developers to test
against the prereleases and/or doing this ourselves.

** Multiple value handling

Largely eliminate the #<values ...> object.  Allow passing multiple
values to a single value continuation, by using just the first value.

(The compiler does this already; this change is about making the
interpreter do the same thing.)

** Import Guile-Lib

Subject to legal details.


* 2.0 release optional items

We also discussed the following as things that would be nice for 2.0,
but not required

** Function inlining in the compiler

e.g. inlining (map ... ) calls

** Support for using R6RS libraries

** An FFI

** Completing the MOP for generic functions

** ECMAscript - completing the implementation

We don't yet support the whole standard, and it would be nice (or at
least neater) to do so.

** Enlarge the space of SMOB numbers


* Native compilation

Given a compiler that produces VM code, it's a relatively short extra step
to produce native code instead.  Sassy can help with this.


* Debugging and stack layout

A hassle with VM development has been handling different
representations of debugging information (i.e. in the C eval and in
the VM), and compiling backtraces that may include segments of both
kinds.  With a Scheme eval this becomes much easier; and if we design
the stack layout carefully, the same debug info representation can
work for native code too.


* Elisp

Agreed that we need to implement dynwind directly in the VM, so that
dynamic binding can be efficient.

Need to review and merge Mark Weaver's patches.

Andy is going to merge Daniel's work soon; at that time, most of the
old lang/elisp stuff will be removed (to avoid confusion!).


* Really delete environments.[ch]

There's no plan now to use this code, so we will delete it to avoid
confusion.


* Benchmarking

We'd like to have an easy way of storing off performance results over
time; e.g. `make benchmark' running the benchmarks, and then also
storing the results somewhere persistent.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]