Re: role of guile-lib

[Julian Graham]

Hola Andy!  Sorry if that email sounded bitchy.

> Ooh, sorry about that. I've been spread a little thin recently. And the
> hosting situation does suck a bit. On the other hand, I've been trying
> to get another guile-lib maintainer for a while now -- you interested?

Well, I would be, except I'm spread a bit thin right now, too (working
for a startup that's on the verge of a release).  Plus, I don't know
that I have a thorough enough understanding of Guile or Scheme to do
the job effectively.  I'd be happy to help out as much as I can,
though.  Is it possible to, uh, wrest control of the hosting
situation?  Or would it be better to start fresh with a new location /
list?


>> But it does raise the question of what the proper role for guile-lib
>> is, given that no one seems to have touched it in more than a year.
>
> What do you want to do with it?
>
> A few different options come to mind:
>
>  * Include (parts of?) it within Guile itself. This probably would
>    require copyright assignment, though perhaps not, if we put them
>    within a contrib/ section of the source distro (I would not want to
>    put `contrib' in the module name, however).
>
>  * Make it a part of Guile, but not a part of the guile source
>    distribution. This way all Guile committers could administer it, and
>    perhaps it could just share the same mailing lists.

I like that second option (although it doesn't do anything for
cross-Scheme compatibility), and I'd imagine it'd go over better with
Guile developers than making it part of Guile itself.


>> Evan Prodromou's (net http)
>
> I haven't seen this code, but I want it! :)

I think this is the most recent release:

http://evan.prodromou.name/software/net-http/

>From what I can tell, it's no longer maintained (and as I remember was
only partially complete), but even as a starting point for a real HTTP
client implentation for Guile, you could do a lot worse.


>> Another possibility is that the Snow project could meet this need, but
>> there are some Guile-side technical hurdles to be jumped before it'd
>> be viable -- and it's not like they don't have their own problems with
>> bit-rot.
>
> Yes, and another option (parallel effort?) is to hack in support for
> R6RS modules, and rely on other distributions.

Hey, sure -- although we'd still need a way to locate modules.  And
could we actually rely on other distributions?  My outsider impression
is that there was a minor revolt when R6RS was passed (but maybe the
library system was less offensive to people?).  The only reason I
suggested Snow was that it seemed, for whatever reason -- and however
briefly -- to have a tiny bit of cross-platform traction.  The R6RS
library syntax ain't bad, though, now that I read the spec.  I'll take
a look at how hard it'd be to wedge it into Guile.


>> It seems like other parts of Guile are being re-organized a bit right
>> now -- any chance we could take a look at this as well?
>
> Let's make this situation suck less! Do you want to handle this? (Also,
> it would be nice to move this code to git.)

Well, I can make some suggestions!  In addition to the above, maybe we
could do a module-by-module audit of the current suite of code in
guile-lib and see what the current state of each is -- i.e., whether
it's compatible with Guile 1.8 / HEAD; if it's been superceded by code
added to Guile core, etc.  Would that be useful?


Regards,
Julian