guile-devel
[Top][All Lists]
Advanced

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

Re: top-repl priority of guile module


From: Neil Jerram
Subject: Re: top-repl priority of guile module
Date: Sat, 30 Dec 2006 23:34:57 +0000
User-agent: Gnus/5.1007 (Gnus v5.10.7) Emacs/21.4 (gnu/linux)

Kevin Ryde <address@hidden> writes:

> Neil Jerram <address@hidden> 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





reply via email to

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