Hello all,
I encountered some behavior I didn't expect, and I'm not sure if it's
intended or not. The following code works fine:
(use-modules (rnrs base))
However, the next two lines both give errors:
(use-modules (rnrs base (6)))
(use-modules (rnrs base 6))
I didn't expect this because the
Hello!
Julian Graham jool...@gmail.com writes:
Thanks to Andy's heroic work on the expander over the past week or so,
I've just been able to merge `wip-r6rs-libraries' into `master' and
push it!
Cool, congratulations to both of you!
As you'll notice from running `make check
Hi all,
Thanks to Andy's heroic work on the expander over the past week or so,
I've just been able to merge `wip-r6rs-libraries' into `master' and
push it!
As you'll notice from running `make check', there are still a few
issues to be addressed -- specifically, the implementation of `div
Hi Ludo,
I've got some status updates:
As I said, there aren't that many libraries left to do. Off the top
of my head, the still-missing ones are (rnrs eval), (rnrs arithmetic
fixnums), (rnrs arithmetic flonums), and the composite library, (rnrs
rnrs). I also want to move the library form
Ludo wrote:
- Do you plan to work on the remaining parts, in
particular the dreaded (to me) ‘(rnrs io ports)’?
:-)
I've been thinking a little about how (rnrs io ports) might
be accomplished. If no one has been working on it, I could
lay out some of my opinions and something of a plan.
Hi Mike,
Mike Gran spk...@yahoo.com writes:
Ludo wrote:
- Do you plan to work on the remaining parts, in
particular the dreaded (to me) ‘(rnrs io ports)’?
:-)
I've been thinking a little about how (rnrs io ports) might
be accomplished. If no one has been working on it, I could
lay
Hello!
Looking at messages on guile-commits, I’m really amazed by the amount of
work that Julian has been doing on the R6RS front. Now that all this
code is here, I don’t see any reason not to include it in 2.0.
Here’s a random list of things that I think should be considered.
- What’s the
Hi Ludovic,
Looking at messages on guile-commits, I’m really amazed by the amount of
work that Julian has been doing on the R6RS front. Now that all this
code is here, I don’t see any reason not to include it in 2.0.
Thanks! I was going to send a status update on this once I finished
the
Hello,
Neil Jerram n...@ossau.uklinux.net writes:
Julian Graham jool...@gmail.com writes:
On a related note, I assume Emacs' `scheme-mode' has been adding
unwanted tabs? What should I do to correct this in my local
environment?
(setq indent-tabs-mode nil)
We should put that in
Hi all,
Find attached a revised and polished version of the `(ice-9
r6rs-libraries)' module I submitted a couple of months ago. This
version includes the following changes:
* The library transformer code's been cleaned up and compacted (by
more than 30%) and now uses a `defmacro' form similar
On Sun 13 Dec 2009 04:24, Julian Graham jool...@gmail.com writes:
Find attached updated versions of the patches that provide support for
R6RS-compatible versions and renaming bindings on export (the two core
modifications required to support the libraries implementation).
They've been rebased
Julian Graham jool...@gmail.com writes:
On a related note, I assume Emacs' `scheme-mode' has been adding
unwanted tabs? What should I do to correct this in my local
environment?
(setq indent-tabs-mode nil)
Neil
Hi all,
Find attached updated versions of the patches that provide support for
R6RS-compatible versions and renaming bindings on export (the two core
modifications required to support the libraries implementation).
They've been rebased against the current HEAD and some reasonably
comprehensive
Hi Andy,
Note that quasisyntax is now merged. You can do things without
quasisyntax using with-syntax.
Of course -- our version of quasisyntax is implemented in terms of
with-syntax! I was just being lazy.
Your code is remarkably short. That is my initial impression, positive
:-) But I
Andy Wingo wi...@pobox.com writes:
Hi Julian!
On Sun 01 Nov 2009 20:26, Julian Graham jool...@gmail.com writes:
Find attached a working prototype of R6RS library support
I think I missed this one, it was threaded above the end of guile-devel
that I read :-) Sorry about that.
Note that
Julian Graham jool...@gmail.com writes:
I probably should have said rough prototype instead of working
prototype -- the actual macro that transforms library definitions
into module definitions is kind of gross and uses datum-syntax a fair
amount where it probably doesn't need to / shouldn't.
Hi Andreas,
IIRC, R6RS doesn't /require/ that implementations are able to
differentiate bindings from different phases -- e.g. Ikarus essentially
ignores phase specifications (implicit phasing -- there were some
discussions about that on ikarus-users, which I can't find ATM, but [0]
should
As I said earlier, I'm happy to provide full documentation for all of
this code if the consensus is that I'm on the right track.
Any feeling either way on those patches? I'm happy to create a remote
tracking branch if that'd make it easier for people to review.
Hi all,
Find attached a working prototype of R6RS library support, in the form
of a Guile module called `(r6rs-libraries)'. The module depends on
the two attached patches, which add, respectively, support for the
`#:version' keyword [1] and support for renaming bindings on export
[2]. It works
Hi Andy,
It should work now, though with hacks -- if you manipulate the
module-public-interface directly. But perhaps some more baked in support
would be useful.
Oh, certainly -- as I've learned over these many months, you can do
some very interesting things by working with the lower-level
Hi all,
Besides version, another thing that would be very useful to have
native Guile support for is being able to export bindings with names
other than the ones given to them within the module -- that is, to be
able to rename variables exported as part of the module's public
interface in
Hi Guilers,
Okay, after poking around in the manual and the code, it looks like
`load-module' does what I need.
Find attached two patches that, combined, add full support for
R6RS-style version information to Guile's module system. I've done a
bit of testing and believe that this code does the
Hi Guilers,
Having been motivated by an extended discussion with Andy over pints
in Brooklyn last weekend, I've resolved to return to the issue of R6RS
library support once more. As discussed the last time we took this
on, I think the first step is getting support for version information
into
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
. And we
could establish some prescribed mechanisms by which non-R6RS Guile
code could use R6RS libraries (with caveats attached), and just not
support the converse.
I don't know -- this problem seems to get thornier the more we discuss
it, but I still think it's worth solving. Sorry if I've missed
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
library territory, e.g., `(rnrs-import ...)' or
something like that.
Yes, at least as far as R6RS library modules are concerned. I've
reviewed the relevant discussions on this now and am happy that
there's no desire to support multiple live versions of R6RS libraries.
I'd prefer not to rule
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
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
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/
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
Hmm, yes, but how about `foo/bar/baz-6.scm'? Is there a reason to
reject it?
Well, the part of an R6RS library name that comes before its version
is only restricted in that that it must be an identifier -- so a
system that relied on filenames to locate libraries could have trouble
determining
Hi Ludovic,
But dot files are traditionally hidden on Unices. Why not go with
`foo/bar/6/baz.scm'?
Because my initial plan was to make it possible to have R6RS libraries
coexist with Guile modules, using the same directory layout and load
system -- and, as per our earlier discussion, numbers
Hi Rotty,
All R6RS implementations I'm somewhat familiar with (Ikarus, PLT,
Ypsilon) do some kind of name mangling when library names contain
special characters; e.g. (srfi :6 and-let*) maps to
srfi/%3a2/and-let%2a.sls, at least for Ikarus (%-escaped hex of the
utf-8 encoding, IIRC).
Hey,
an existing macro or module system, are several orders
of magnitude larger. Thanks are due to Tom Lord (and everyone else
who designed Guile's module / interface system) for making this
possible, if not downright easy.
* At the moment, R6RS libraries can import Guile modules directly,
but the reverse
Julian Graham jool...@gmail.com writes:
* At the moment, R6RS libraries can import Guile modules directly,
but the reverse is not true, partly because I can't figure out a good
way to map version information onto the filesystem in a way that
Guile's module system can understand. My initial
it, Implicit phasing in R6RS libraries -- but I haven't
been able to find it freely on the web. ACM fail.
* R6RS says that a library's imports need to be visited/instantiated
at the time the bindings they export are referenced. Why? As
above, why can't they be visited/instantiated at the time
Hi everyone,
(Switching this conversation to guile-devel from guile-user, since it
seems more appropriate to this list...)
Alright, so I've been studying the van Tonder and Dybvig-Ghuloum
implementations and banging my head against chapter 7 of R6RS, all
with an eye towards mapping them onto
Hi,
FWIW, I started an implementation of R6RS' bytevector API. It is
available in my Arch archive [0], in the branch named
`guile-r6rs-libs--devo--0'.
Just letting you know so that we avoid duplicating this (tedious) work.
;-)
Thanks,
Ludovic.
[0]
43 matches
Mail list logo
