taylanbayi...@gmail.com (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.
