Hi Ludovic!
On Thu 28 May 2009 00:27, l...@gnu.org (Ludovic Courtès) writes:
Attached is my initial patch to integrate Guile-R6RS-Libs (bytevectors
and I/O ports). I'll commit it shortly to `master' if nobody objects.
Yay!
It adds a dependency on GNU libunistring (by Bruno Haible). We
Hello!
Andy Wingo wi...@pobox.com writes:
This is unfortunate, to have a new dependency, and on a library that's
not in released distros, nor even very googlable. (I'm on the fedora 11
prereleases, and it seems there is no unistring package.)
I agree. Hopefully libunistring will become more
Hi Julian,
Julian Graham jool...@gmail.com writes:
On a related note, have you had a chance to review the R6RS library
search mechanism I proposed a while back? [1] Using that algorithm
(and going with the `ice-9' prefix), your modules could be wrapped
such that:
* There would exist a
Hello,
Julian Graham jool...@gmail.com writes:
Hey, if we're open to extending the module system, then sure -- that
would certainly make for a cleaner, more efficient implementation.
That's got my vote.
Cool! ;-)
The trick is to extend it in a backward-compatible way as much as
possible.
Cool! ;-)
The trick is to extend it in a backward-compatible way as much as
possible. But now that we have hygiene and `use-syntax' has been
sort-of phased out (Andy?), that should be doable.
Perhaps we could create a branch so that you could experiment things?
*Urk* You didn't mean
On Wed 22 Apr 2009 17:53, l...@gnu.org (Ludovic Courtès) writes:
Julian Graham jool...@gmail.com writes:
Hey, if we're open to extending the module system, then sure -- that
would certainly make for a cleaner, more efficient implementation.
That's got my vote.
Mine too :)
The trick is to
Hello Andy,
Andy Wingo wi...@pobox.com writes:
On Wed 22 Apr 2009 09:55, l...@gnu.org (Ludovic Courtès) writes:
The main differences between these two module systems are module
versioning, and phase separation. Fortunately, R6RS' system is a
superset of Guile's, so we could extend the
Hi Julian!
On Wed 22 Apr 2009 20:32, Julian Graham jool...@gmail.com writes:
I have to confess, I'm totally at a loss as to how we're going to make
versioning work with the autoload system.
In particular, I see some difficulty in terms of determining whether
to fully load and evaluate a
Andy Wingo wi...@pobox.com writes:
On Wed 22 Apr 2009 17:53, l...@gnu.org (Ludovic Courtès) writes:
Perhaps we could create a branch so that you could experiment things?
What would it have? Module versions?
Yes, to start with.
We should probably take advantage
of the occasion to separate
Andy Wingo wi...@pobox.com writes:
But given that the non-normative Appendix F states:
[...]
In particular, it is recommended that new versions of libraries
that are conservative extensions of old ones differ only in the
version, not in the name. Correspondingly, it is
Besides that, I don't think that phasing has any practical implication,
given the loopholes in the spec -- the set of bindings that a module
needs can be determined for *all* phases. That is to say, there is one
set of bindings that satisfies the needs of the spec for all phases of
evaluation
Hi Andy,
Guile should probably only support one live version of a module. So
Guile's internal module namespace stays the same. Versions are only
important when loading files from disk. I propose that we do it like
this:
Actually, I'd like to disagree here -- maybe I've been writing too
much
On Wed 22 Apr 2009 22:22, Julian Graham jool...@gmail.com writes:
Hi Andy,
Guile should probably only support one live version of a module. So
Guile's internal module namespace stays the same. Versions are only
important when loading files from disk. I propose that we do it like
this:
Hello Ludovic,
On Tue 21 Apr 2009 23:18, l...@gnu.org (Ludovic Courtès) writes:
Hello Guilers!
I think it'd be nice to merge what's in Guile-R6RS-Libs into `master'.
I do too!
The 2 available modules are named `(rnrs ...)', as described in
R6RS. However, R6RS specifies the
14 matches
Mail list logo
