Re: [PATCH] Transform R6RS SRFI module name on definition.

[Taylan Ulrich Bayırlı/Kammer]

address@hidden (Taylan Ulrich "Bayırlı/Kammer") writes:

> Currently our R6RS 'import' form automatically transforms an import like
> (srfi :n ...) to (srfi srfi-n ...).
>
> This works fine with the SRFIs that ship with Guile and any extra SRFI
> modules defined with the verbose name format (srfi srfi-n ...).
>
> However, when one really defines a library named (srfi :n ...), then
> 'import' fails to find this because it only looks for the verbose name.
>
> Here a transcript showcasing the issue:
>
> --- snip ---
> scheme@(guile-user)> (library (srfi :200) (export test) (import (rnrs base)) 
> (define test 'test))
> scheme@(srfi :200)> ,m guile-user
> scheme@(guile-user)> (import (srfi :200))
> While compiling expression:
> ERROR: no code for module (srfi srfi-200)
> scheme@(guile-user)> ,use (srfi :200)
> scheme@(guile-user)> test
> $2 = test
> scheme@(guile-user)>
> --- snip ---
>
> (Use-modules actually finds it, as you see.)
>
> The attached patch makes our R6RS 'library' form automatically transform
> a library name like (srfi :n ...) to (srfi srfi-n ...).
>
> Will this leak out to the user in such a way that it breaks conformance
> or creates problems?  Is it bad that this time 'use-modules' won't be
> able to find (srfi :n ...)?  I don't think it is; users should just use
> (srfi :n ...) with 'import' and (srfi srfi-n ...) with 'use-modules'.
>
> Note that it's actually not 'import' itself that does the reverse
> transform but a deeper part of the system, and thus for instance the
> 'environment' form from (rnrs eval) also correctly resolves the module
> name (srfi :n ...) to (srfi srfi-n ...).  If there are any "holes" left
> where the transform doesn't happen, we should be able to plug those too.
>
> WDYT?

Ping.