[Top][All Lists]

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

Re: r6rs standard libraries

From: Andy Wingo
Subject: Re: r6rs standard libraries
Date: Mon, 25 Jan 2010 15:50:50 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.92 (gnu/linux)


On Sun 24 Jan 2010 18:53, Julian Graham <address@hidden> writes:

> As mentioned in an earlier email [0], I've been working on
> implementations for the libraries that make up the so-called R6RS
> Standard Libraries [1], along with test suites.  Where possible, I've
> tried to wrap existing Guile functionality instead of writing things
> from scratch.  Speaking optimistically, I think I'm about 80% of the
> way there (minus the test cases).  There are quite a few files, so, to
> facilitate review, I've uploaded them to my web site [2].  There's
> also an updated copy of the `(ice-9 r6rs-libraries)' module there,
> which resolves a couple of issues present in the most recent version I
> submitted to the list.
> What do people think?

Excellent hacking! I think this is fantastic. I want to get on
I did some tests with Clinger's R5RS benchmarks, showing pretty good
performance for Guile, but I think he's only really working on the R6RS
ones now. I would like to smoke a couple of other Schemes ;-)

> One point that may be of interest is that I've chosen to provide the
> code in the form of R6RS libraries rather than Guile modules.  My
> thinking is that the primary utility of most of these libraries lies
> in the cross-Scheme compatibility they provide, and thus they're not
> of particular interest to users writing code intended only for Guile.
> In cases where there's actual new functionality, such as with the
> bytevector features, a Guile module representation is probably more
> useful.


Personally I'm ready to merge this code whenever you want, as long as it
has tests. A section in the manual about what we implement of R6RS and
what the differences are would be useful as well.

I also think we should have `library' and `import' in the basic
environment. In order to do this I would like for them in boot-9.scm,
not in a separate module, and implemented in terms of syntax-case.

Implementing `library' in terms of syntax-case will allow `library' to
expand out to (begin (define-module (foo) #:pure) (import a ...) ...),
which allows imports to be processed only in the `import' macro. The
`import' macro will be resolved in `(guile)' even though the module is
pure, due to hygiene. No toplevel-defined helper functions will be

Does this sound sensible to you?

If so, can you make a git branch that (1) adds `library' and `import' to
boot-9, then adds the other modules, one-by-one with tests? I've got my
finger on the merge trigger :)



reply via email to

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