guile-devel
[Top][All Lists]
Advanced

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

Re: Merging R6RS libraries?


From: Julian Graham
Subject: Re: Merging R6RS libraries?
Date: Mon, 29 Mar 2010 19:06:34 -0400

Hi Ludovic,


> Looking at messages on guile-commits, I’m really amazed by the amount of
> work that Julian has been doing on the R6RS front.  Now that all this
> code is here, I don’t see any reason not to include it in 2.0.

Thanks!  I was going to send a status update on this once I finished
the few remaining libraries and test cases, but now's as good a time
as any.


>  - What’s the status of your work wrt. to R6RS-lib?

As I said, there aren't that many libraries left to do.  Off the top
of my head, the still-missing ones are (rnrs eval), (rnrs arithmetic
fixnums), (rnrs arithmetic flonums), and the composite library, (rnrs
rnrs).  I also want to move the library form definitions out of
boot-9, as you suggested.

There's also some subtler, scarier stuff that's related to R6RS-lib
but that I haven't taken on.  In particular, pairs and strings now
have a notion of mutability that doesn't currently exist (I don't
think) in the core; a lot of the core functions (i.e. ones that I've
merely "repackaged" for R6RS-lib) now have more specific error
behaviors that I've decided to punt on for the moment.


>  - Do you plan to work on the remaining parts, in particular the
>    dreaded (to me) ‘(rnrs io ports)’?  :-)

I uh... wasn't planning to, but that's just because I figured they
were already done.  :-)  I dread them a little bit as well, since they
seem more likely to require changes to the core.


>  - Does the code borrow snippets from reference implementations or some
>    such?

Yes -- in cases in which R6RS-libs makes a suggestion for the
implementation of a particular procedure or syntactic form, I've taken
it.  The rest (I think) of the code is by me, for better or for worse.


>  - How much code do unit tests cover?  It’d be nice to try the test
>    suite of the PLT folks,
>    
> <http://groups.google.com/group/comp.lang.scheme/browse_thread/thread/a7d691b5ca87b94f/6bb6e09f1d39d828>.

The tests cover the cases where the complexity or "newness" of the
code seemed to warrant it.  For example, I don't have any unit tests
for libraries that are simply repackagings of existing Guile
functionality.

Let's definitely run against PLT's suite.


>  - Are there any known problems with the library/module integration, or
>    pitfalls that ought to be documented?

Hmmm.  None that are so serious that they're currently blocking me --
I've been developing and testing the libraries using the
library/module integration, so I'm quite sensitive to problems when
they arise.  :-)  At the moment, the only thing that's bugging me is
an issue with tests that use syntax exported from libraries fail when
run via 'make check' but pass when loaded from the REPL.


>  - In terms of documentation, we definitely don’t want to duplicate
>    R6RS.  However, it would be nice to have at least a node listing the
>    available libraries and what they’re about.  For those that provide
>    features not available elsewhere in Guile, it’d be nice to have more
>    detailed documentation (we’ve done that for bytevectors and I/O
>    ports).

Sure.  The records, conditions, exceptions, and enums bear more
detailed documentation.  And I'd add that the library/module
integration itself should probably get a node or two, since aspects of
its behavior are non-obvious.


> Julian: would you like review on specific parts of your work?  (I
> personally don’t have much time to dedicate to it these days but I could
> look at things you think are important.)

Sure!  I wouldn't mind a review of what I think are some of the more
complex (and central) bits, which, to my mind, are (rnrs records *),
(rnrs conditions), and (rnrs exceptions).


> Is it reasonable to add it to the to-do list of 2.0?

I don't know.  2.0's coming out pretty soon, right?  The hours at my
day job can be sort of unpredictable, and I wouldn't want to hold up
the release because I'm strapped for time.


Regards,
Julian




reply via email to

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