Hi Andy,
Back to your question though, what did you think about my symlink
solution[1]?
[1] http://article.gmane.org/gmane.lisp.guile.devel/8585
It's fine, although any length suffix of a version specifier can be
omitted in the case of a match -- that is, you can do without the
version
Hi Andy,
Your solution of doing whole-program analysis is very much in the spirit
of R6RS, but it is not in the spirit of Lisp, in my opinion at least.
Well, to be fair, it's not whole-program analysis -- as Neil pointed
out, we only need to analyze the library and program headers. But,
sure,
Hello!
Julian Graham jool...@gmail.com writes:
It's a fine way of handling version-less dependencies, but I don't see
how it solves the determinism issue. Let's say my program (or code
stream or script or whatever you want to call it) uses libraries from
two different authors. Author A
Julian Graham jool...@gmail.com writes:
Hi Guilers,
With the 1.9 series launched, I wanted to start thinking about R6RS
libraries again, since it would be awesome to have some semblance of
an implementation ready by October.
Indeed, yes.
I assume the objective here is to allow a Guile
Hi Neil,
I assume the objective here is to allow a Guile program or module to
use a portable R6RS library; i.e., specifically, allowing
`(use-modules ...)' or `#:use-module (...)' to resolve to an R6RS
library. Is that correct?
Actually, my immediate-term goal was to add versioning info to
Hi Julian,
On Sun 28 Jun 2009 02:20, Julian Graham jool...@gmail.com writes:
With the 1.9 series launched, I wanted to start thinking about R6RS
libraries again, since it would be awesome to have some semblance of
an implementation ready by October.
Yes!
I think such issues should lead us
Hi Guilers,
With the 1.9 series launched, I wanted to start thinking about R6RS
libraries again, since it would be awesome to have some semblance of
an implementation ready by October.
I think such issues should lead us to have a `:version' option that does
just what's needed for R6RS, and
l...@gnu.org (Ludovic Courtès) writes:
This is IMO a terrific part of version handling in R6 modules. What
will it mean for a 2009 program to import `(rnrs base)' when R27RS is
released?
By `terrific' do you mean good or bad? Normally terrific means good,
and `terrible' means bad, and I
Hey Julian,
On Sun 31 May 2009 01:22, Neil Jerram n...@ossau.uklinux.net writes:
Julian Graham jool...@gmail.com 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.,
Hello!
Andy Wingo wi...@pobox.com writes:
* Should we establish some rules for what you get when you don't
specify a version?
Yes! The latest available?
I don't know.
This is IMO a terrific part of version handling in R6 modules. What
will it mean for a 2009 program to import `(rnrs
Hi Neil,
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
Hi Guilers,
I'd like to take another stab at getting R6RS library support in, this
time by extending the capabilities of the module system. Here's what
I've got in mind to start with:
1. Add an optional `version' field to the module record type
* What's a good format here? We could mirror the
12 matches
Mail list logo
