Merging R6RS libraries?

Merging R6RS libraries?

[Ludovic Courtès]

Hello!

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.

Here’s a random list of things that I think should be considered.

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

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

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

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

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

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

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

What do you think?

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

Thanks,
Ludo’.

Re: Merging R6RS libraries?

[Julian Graham]

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

Re: Merging R6RS libraries?

[Julian Graham]

Hi Ludo,

I've got some status updates:


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

The above are done and pushed.

At the moment, though, there are some broken bits related to the
arithmetic libraries -- specifically, all of the procedures related to
R6RS `div' and `mod'.  They just weren't fully enough specified to
implement: R6RS-lib says they "implement number-theoretic integer
division" [0].  (The main R6RS spec says even less.)  I peeked at
PLT's implementation, which uses, I think, a stanard
"number-theoretic" division algorithm and tweaks it to match the
examples in R6RS-lib.  We could poach theirs or write our own, but I'm
not enough of a mathematician to know what the Right Thing to do here
is.


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

This also seems to be happening with plain old `make'.  I've been
trying to figure out what's different between running:

$ ./meta/uninstalled-env guile-tools compile module/6/rnrs.scm

...and executing

scheme@(guile-user)> (compile-file "module/6/rnrs.scm")

...from inside an instance of ./meta/guile (which works), but so far
I've come up empty.  This is pretty much the only thing I'd like to
fix before telling Andy to pull the merge trigger.  Any ideas?


Regards,
Julian


[0] - http://www.r6rs.org/final/html/r6rs-lib/r6rs-lib-Z-H-1.html#node_toc_node_sec_11.2

Re: Merging R6RS libraries?

[Andy Wingo]

Hi Julian,

Sounds like you've had some great progress! This is excellent :-)

On Sun 11 Apr 2010 05:50, Julian Graham <joolean@gmail.com> writes:

> $ ./meta/uninstalled-env guile-tools compile module/6/rnrs.scm
> [does not work]
>
> scheme@(guile-user)> (compile-file "module/6/rnrs.scm")
> [works]

Dunno, will poke. I was about to merge, until you mentioned that I
should hold off. Seems I have an itchy trigger finger :-)

Andy
-- 
http://wingolog.org/

Re: Merging R6RS libraries?

[Julian Graham]

Hi all,

Thanks to Andy's heroic work on the expander over the past week or so,
I've just been able to merge `wip-r6rs-libraries' into `master' and
push it!

As you'll notice from running `make check', there are still a few
issues to be addressed -- specifically, the implementation of `div'
and `mod' [0].  Anyone have any thoughts?  I guess I'll start digging
into some number theory.


Regards,
Julian

[0] - http://www.mail-archive.com/guile-devel@gnu.org/msg05278.html

Re: Merging R6RS libraries?

[Ludovic Courtès]

Hello!

Julian Graham <joolean@gmail.com> writes:

> Thanks to Andy's heroic work on the expander over the past week or so,
> I've just been able to merge `wip-r6rs-libraries' into `master' and
> push it!

Cool, congratulations to both of you!

> As you'll notice from running `make check', there are still a few
> issues to be addressed -- specifically, the implementation of `div'
> and `mod' [0].  Anyone have any thoughts?

Not quite, but I trust you’ll find out.  ;-)

Thanks,
Ludo’.

Re: Merging R6RS libraries?

[Mike Gran]

Ludo wrote:

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

I've been thinking a little about how (rnrs io ports) might
be accomplished.  If no one has been working on it, I could
lay out some of my opinions and something of a plan.

-Mike

Re: Merging R6RS libraries?

[Ludovic Courtès]

Hi Mike,

Mike Gran <spk121@yahoo.com> writes:

> Ludo wrote:
>
>>  - Do you plan to work on the remaining parts, in 
>> particular the dreaded (to me) ‘(rnrs io ports)’?  
>> :-)
>
> I've been thinking a little about how (rnrs io ports) might
> be accomplished.  If no one has been working on it, I could
> lay out some of my opinions and something of a plan.

Yes, please!

Thanks,
Ludo’.