[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: r6rs libraries, round two
From: |
Andy Wingo |
Subject: |
Re: r6rs libraries, round two |
Date: |
Mon, 01 Jun 2009 21:55:32 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/23.0.92 (gnu/linux) |
Hey Julian,
On Sun 31 May 2009 01:22, Neil Jerram <address@hidden> writes:
> Julian Graham <address@hidden> writes:
>
>> 1. Add an optional `version' field to the module record type
>
> Sounds good.
Agreed.
>> * What's a good format here? We could mirror the requirements of R6RS
>> here (i.e., (v1 v2 ...) where vx is a whole number) or be more
>> flexible.
>
> Given that your objective is to get R6RS library support in, I'd say
> just stick to the R6RS format for now. It sounds like it will be
> fairly easy to extend this in future, if we want to.
Also agreed.
>> * Should we establish some rules for what you get when you don't
>> specify a version?
>
> Yes! The latest available?
I don't know. To me this could be a distro decision, like Debian's
"alternatives" system. It would be nice to minimize the number of `stat'
calls it takes to load a library -- which would fall out nicely if when
asking for a module without specifying a version, like `(foo bar)', we
give foo/bar.scm.
In the presence of multiple versions, installation rules could handle
making the symlink so there is a default version -- typically the
version that was installed most recently.
>> Given what we've decided about loading multiple
>> versions of a library (i.e., you can't)
>
> I didn't follow why we decided that, but it feels wrong to me. (It
> seems to me that Guile should be able to handle loading ((foo) v1) and
> ((foo) v2) simultaneously as easily as it could handle loading
> ((foo-v1)) and ((foo-v2)) simultaneously.) I guess I should look up
> the previous thread, please let me know if you have a convenient
> reference.
I agree it would be nice, but as I said in the thread that Julian
referenced, that would take some more thought -- more than the R6RS
editors were willing to give the problem. And for us, I suspect we would
need some changes to our hierarchical namespaces. We probably shouldn't
let this be a sticking point for Guile's R6RS libraries support.
Regards,
Andy
--
http://wingolog.org/
- Re: r6rs libraries, round two,
Andy Wingo <=
- Re: r6rs libraries, round two, Ludovic Courtès, 2009/06/01
- Re: r6rs libraries, round two, Neil Jerram, 2009/06/03
- Re: r6rs libraries, round two, Julian Graham, 2009/06/27
- Re: r6rs libraries, round two, Andy Wingo, 2009/06/28
- Re: r6rs libraries, round two, Julian Graham, 2009/06/29
- Re: r6rs libraries, round two, Ludovic Courtès, 2009/06/29