[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Merging Guile-R6RS-Libs in `master'

From: Andy Wingo
Subject: Re: Merging Guile-R6RS-Libs in `master'
Date: Tue, 21 Apr 2009 23:58:36 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.92 (gnu/linux)

Hello Ludovic,

On Tue 21 Apr 2009 23:18, address@hidden (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 version number `(6)' as part of
>      the name as well, which we don't support.
>      Modules could be called `(r6rs ...)', which would address the
>      version number problem, or even `(ice-9 ...)', which would make it
>      clear that the implementation is not R6RS-compliant but rather
>      "inspired" by R6RS APIs.
>      I'm not sure which one of these 3 options is the best one.  This
>      will probably depend on how Unicode support evolves.

My intuition is that the Guile module `(foo)' should be representable as
the R6RS module `(foo)', and vice versa. At this point, I know of no

If this intuition is correct, `rnrs' should be the prefix; what to do
with (6) is another question. Julian, do you know of any pitfalls in
unifying the R6RS module namespace with the Guile module namespace?

>   2. C name space
>      C function/macro/variable names are all prefixed with `scm_r6rs_'.
>      Should it change to `scm_'?

FWIW, I think so.

>   3. Bytevectors as generalized vectors?
>      We could easily make bytevectors accessible through the generalized
>      vector API.
>      Pros: good integration, intuitive, convenient.
>      Cons: incentive to use a "standard" API in a non-standard way.
>      The latter may not be a problem since SRFI-4 vectors already behave
>      this way.

I have never used e.g. generalized-vector-ref. Too much typing. Do it if
it makes sense, or if it's too much work add a FIXME to the docs so
someone else can come along and take care of it.

>   4. Bytevector read syntax
>      ... needs to be implemented.

You are the reader master :)

> Comments welcome.

o/~ Did you ever know that you're my hero o/~


reply via email to

[Prev in Thread] Current Thread [Next in Thread]