[plt-scheme] SRFI's

From: Noel Welsh (noelwelsh at yahoo.com)
Date: Thu Jun 27 08:56:11 EDT 2002

--- Francisco Solsona <solsona at acm.org> wrote:
> We (the schematics crew) offered to coordinate the
> port of the surfies
> to PLT Scheme, and Matthew agreed to include them in
> the core PLT
> distribution once we were finish, and we're not
> quite there yet.

With a bit of luck we'll never be finished porting
surfies!  Certainly at the moment there are coming out
faster than we can port them.  The only solution I can
see is to turn Schematics projects (namely SchemeUnit
and SchemeQL) into surfies; that way we already have
the reference implementation ported ;-)

Note there is a new (unannounced) srfi.plt release on
Schematics.  v1.2 includes SRFI 26.

And now some general, more rambly comments:

1) Porting all SRFI's requires some cooperation from
Matthew Flatt.  SRFI 4, for example, requires changes
to the reader and write/print/displayer to do
homogenous vector IO.

[To all those doing homogenous matrices (you know how
you are): I'd love to host the project on Schematics. 
I did a port of SRFI-4 to PLT Scheme v103; the code is
still around and may be useful.]

2) A code repository like Perl's CPAN would be a Good
Thing.  If people poke around Schematics they'll find
src/libs/* which is a collection of useful little
libraries.  It would be nice to enable everyone to
contribute to a growing set of libraries like what
we're developing at Schematics.  Whilst SourceForge
can handle the development infrastructure it isn't
really geared up for the distribution problem.  SF
requires one to make new file releases for each new
version.  This won't scale to a bunch of rapidly
changing libraries. 

[I take back my gripes about .plt packaging. I've now
got a nice system that seems to work very well.  It is
still impractical to create a new release everytime a
new library is added.]
I believe Matthew has some plans for this.  He may
wish to share them?  My ideas are:

a) Define a policy for libraries.  Probably a two
level hierarchy like CPAN (and the Yellow Pages) is
best.  So we could define top-level collections like
http, html,   macro etc. and people contribute
collections underneath these (e.g. http/uri-encode 
html/parser).  A lot of the 'good' names are currently
taken (e.g. net, html, xml) which makes it a bit
difficult to smoothly integrate new libraries.

b) Create some tools to download and install
collections (like Debian's dselect, or whatever the
Perl folk use).  I'd like to use XML-RPC for this as
I'd like to play with Matt's XML-RPC server.

c) Someone (Utah?) would have to supply a machine to
store the released libraries. A tool to automate
uploads would also be good.

I'm sure there are issues of package management (like
dependencies) I have even considered.  Maybe those
familiar with Debian or CPAN can comment.


Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup

Posted on the users mailing list.