Re: r6rs standard libraries

[Andy Wingo <wingo@pobox.com>]

Hi,

On Sun 24 Jan 2010 18:53, Julian Graham <joolean@gmail.com> 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
http://www.ccs.neu.edu/home/will/Larceny/benchmarksGenuineR6Linux.html.
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.

Agreed.

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
necessary.

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 :)

Cheers,

Andy
-- 
http://wingolog.org/