Kevin Ryde <[EMAIL PROTECTED]> writes:
> Neil Jerram <[EMAIL PROTECTED]> writes:
>>
>> It seems to me, though, that this is all a matter of ordering, not of
>> whether the duplicates processing gets invoked.
>
> I thought that too, until just fiddling with the order didn't fix
> srfi-17 (which #:replace's car and friends).
>
>> I don't know all the details of the duplicate processing,
OK, I understand all this now; thanks for being patient for me. (The
effect of #:replace is that the module with the #:replace always win
over another module that doesn't, regardless of ordering.)
>> And then the real problem, as I understand it, would be that the code
>> in script.c generates code which does the (use-modules (srfi srfi-1))
>> before the (top-repl).
>
> Alas of course top-repl doesn't return ...
Indeed. Still, if it would help we could easily make script.c pass in
unevaluated code to top-repl, which top-repl would eval after the
existing module-uses. However, as you say ...
> top-repl only adds some friendly extras like ice-9 debug, session,
> regexp and threads. Hopefully they don't overlap with any srfis, so
> it shouldn't matter if they're after use-srfis. If that sounds right.
Yes, agreed. The (module-use ... 'guile) was a more serious problem
here, but now it is gone (which I agree is a good fix). So no new
script.c hackery is needed.
Regards,
Neil
_______________________________________________
Guile-devel mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/guile-devel
