top-repl priority of guile module

top-repl priority of guile module

[Kevin Ryde]

Sven Hartrumpf on guile-user a while ago reported on a run of

	guile --use-srfi=1

leaves the REPL with the core `iota', not the srfi-1 one.  What's the
theory behind this bit of top-repl (in boot-9.scm),

    ;; so that builtin bindings will be checked first
    (module-use! guile-user-module (resolve-interface '(ice-9 r5rs)))
    (module-use! guile-user-module (resolve-interface '(guile)))

The effect is to override any bindings that srfi modules attempt to
replace.  So srfi-17 car or srfi-39 current-input-port are similarly
afflicted.

I'm thinking of removing that last line

    (module-use! guile-user-module (resolve-interface '(guile)))

to stop the core being elevated.


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: top-repl priority of guile module

[Ludovic Courtès]

Hi,

Kevin Ryde <user42@zip.com.au> writes:

> Sven Hartrumpf on guile-user a while ago reported on a run of
>
> 	guile --use-srfi=1
>
> leaves the REPL with the core `iota', not the srfi-1 one.  What's the
> theory behind this bit of top-repl (in boot-9.scm),
>
>     ;; so that builtin bindings will be checked first
>     (module-use! guile-user-module (resolve-interface '(ice-9 r5rs)))
>     (module-use! guile-user-module (resolve-interface '(guile)))
>
> The effect is to override any bindings that srfi modules attempt to
> replace.  So srfi-17 car or srfi-39 current-input-port are similarly
> afflicted.

Wild guess:  Does the following fix the problem:

  (module-use-interfaces! guile-user-module
                          (resolve-interface '(ice-9 r5rs))
                          (resolve-interface '(guile)))

(instead of the two `module-use!' line.)

IIRC, `module-use-interfaces!' calls `process-duplicates', which in turn
correctly honors the `replace' policy for duplicate bindings.

Conversely, `module-use!' just conses the given modules to the module's
use list without invoking `process-duplicates', hence the problem you
are seeing (the interface of `(guile)' ends up before that of
`srfi-XX' in the module use list).

Thanks,
Ludovic.


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: top-repl priority of guile module

[Kevin Ryde]

ludovic.courtes@laas.fr (Ludovic Courtès) writes:
>
> Wild guess:  Does the following fix the problem:
>
>   (module-use-interfaces! guile-user-module
>                           (resolve-interface '(ice-9 r5rs))
>                           (resolve-interface '(guile)))

No, apparently, though the theory would seem sound ...

I guess top-repl really should just do the equivalent of use-modules
for extra bits it wants.  I can't see the point of "use-modules
(guile)" when that core is already in use in the guile-user module.


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: top-repl priority of guile module

[Kevin Ryde]

[-- Attachment #1: Type: text/plain, Size: 146 bytes --]

I wrote:
>
> No, apparently, though the theory would seem sound ...

Oops, I was doing it wrong, that does work.
Though the change I propose is:


[-- Attachment #2: boot-9.scm.core-no-override.diff --]
[-- Type: text/plain, Size: 560 bytes --]

--- boot-9.scm.~1.356.2.4.~	2006-11-29 05:55:55.000000000 +1100
+++ boot-9.scm	2006-12-05 14:14:31.000000000 +1100
@@ -3397,9 +3397,7 @@
 					  '(ice-9 debugger) '(debug)))
     (module-use! guile-user-module (resolve-interface '(ice-9 session)))
     (module-use! guile-user-module (resolve-interface '(ice-9 debug)))
-    ;; so that builtin bindings will be checked first
     (module-use! guile-user-module (resolve-interface '(ice-9 r5rs)))
-    (module-use! guile-user-module (resolve-interface '(guile)))
 
     (set-current-module guile-user-module)
 

[-- Attachment #3: Type: text/plain, Size: 143 bytes --]

_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: top-repl priority of guile module

[Ludovic Courtès]

Hi,

Kevin Ryde <user42@zip.com.au> writes:

> Though the change I propose is:
>
> --- boot-9.scm.~1.356.2.4.~	2006-11-29 05:55:55.000000000 +1100
> +++ boot-9.scm	2006-12-05 14:14:31.000000000 +1100
> @@ -3397,9 +3397,7 @@
>  					  '(ice-9 debugger) '(debug)))
>      (module-use! guile-user-module (resolve-interface '(ice-9 session)))
>      (module-use! guile-user-module (resolve-interface '(ice-9 debug)))
> -    ;; so that builtin bindings will be checked first
>      (module-use! guile-user-module (resolve-interface '(ice-9 r5rs)))
> -    (module-use! guile-user-module (resolve-interface '(guile)))

Yeah, that should be sufficient here.

Thanks,
Ludovic.


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: top-repl priority of guile module

[Kevin Ryde]

[-- Attachment #1: Type: text/plain, Size: 294 bytes --]

Actually, I find my change is enough for srfi-1 iota, but not for
srfi-17 car in 1.8, probably because it's a #:replacement.

Does the change below to use process-use-modules in both use-srfis and
top-repl seem better?  The idea would be to do the same as the guts of
an ordinary use-modules.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: boot-9.scm.use-srfi-2.diff --]
[-- Type: text/x-diff, Size: 1740 bytes --]

--- boot-9.scm.~1.356.2.5.~	2006-12-09 08:11:09.000000000 +1100
+++ boot-9.scm	2006-12-09 08:13:50.000000000 +1100
@@ -3313,13 +3313,11 @@
 ;; numbers, which are the numbers of the SRFIs to be loaded on startup.
 ;;
 (define (use-srfis srfis)
-  (let lp ((s srfis))
-    (if (pair? s)
-        (let* ((srfi (string->symbol
-                      (string-append "srfi-" (number->string (car s)))))
-               (mod-i (resolve-interface (list 'srfi srfi))))
-          (module-use! (current-module) mod-i)
-          (lp (cdr s))))))
+  (process-use-modules
+   (map (lambda (num)
+	  (list (list 'srfi (string->symbol
+			     (string-append "srfi-" (number->string num))))))
+	srfis)))
 
 \f
 
@@ -3387,19 +3385,23 @@
 
     ;; Use some convenient modules (in reverse order)
 
-    (if (provided? 'regex)
-	(module-use! guile-user-module (resolve-interface '(ice-9 regex))))
-    (if (provided? 'threads)
-	(module-use! guile-user-module (resolve-interface '(ice-9 threads))))
+    (set-current-module guile-user-module)
+    (process-use-modules 
+     (append
+      '(((ice-9 r5rs))
+	((ice-9 session))
+	((ice-9 debug)))
+      (if (provided? 'regex)
+	  '(((ice-9 regex)))
+	  '())
+      (if (provided? 'threads)
+	  '(((ice-9 threads)))
+	  '())))
     ;; load debugger on demand
     (module-use! guile-user-module
 		 (make-autoload-interface guile-user-module
 					  '(ice-9 debugger) '(debug)))
-    (module-use! guile-user-module (resolve-interface '(ice-9 session)))
-    (module-use! guile-user-module (resolve-interface '(ice-9 debug)))
-    (module-use! guile-user-module (resolve-interface '(ice-9 r5rs)))
 
-    (set-current-module guile-user-module)
 
     (let ((old-handlers #f)
 	  (signals (if (provided? 'posix)

[-- Attachment #3: Type: text/plain, Size: 143 bytes --]

_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: top-repl priority of guile module

[Kevin Ryde]

Oh, and I added test-suite/standalone/test-use-srfi exercising this
stuff.  The "guile" in the script is the uninstalled guile during a
"make check", you might have to search and replace it to
pre-inst-guile if you want to run outside that.


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: top-repl priority of guile module

[Neil Jerram]

Kevin Ryde <user42@zip.com.au> writes:

> Oh, and I added test-suite/standalone/test-use-srfi exercising this
> stuff.  The "guile" in the script is the uninstalled guile during a
> "make check", you might have to search and replace it to
> pre-inst-guile if you want to run outside that.

Sorry for coming late to this discussion.

It seems to me, though, that this is all a matter of ordering, not of
whether the duplicates processing gets invoked.  I don't know all the
details of the duplicate processing, but by default I would expect a
later use-modules (or similar operation) to override an earlier one.
Is that what happens?

Then, if it is the case that

$ guile

sets up a standard environment, it seems obvious to me that if one
does

$ guile --srfi=1

the "--srfi=1" should take effect after the standard environment has
been set up.

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).

What do you think?  Have I completely misunderstood?

Regards,
     Neil



_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: top-repl priority of guile module

[Kevin Ryde]

Neil Jerram <neil@ossau.uklinux.net> 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,

Me neither :).

> 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 ...

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.


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: top-repl priority of guile module

[Neil Jerram]

Kevin Ryde <user42@zip.com.au> writes:

> Neil Jerram <neil@ossau.uklinux.net> 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
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: top-repl priority of guile module

[Ludovic Courtès]

Hi,

Neil Jerram <neil@ossau.uklinux.net> writes:

> It seems to me, though, that this is all a matter of ordering, not of
> whether the duplicates processing gets invoked.  I don't know all the
> details of the duplicate processing, but by default I would expect a
> later use-modules (or similar operation) to override an earlier one.
> Is that what happens?

Roughly, yes.  However, the semantics of `module-use!' are very
different from those of `use-modules' (unlike what one might think ;-)).
While `use-modules' honors the duplicate binding policies, including
`replace' as Kevin noted, `module-use!' does no such thing: it blindly
overrides bindings.  A more important concern is that the order of
`module-use!' invocations matters, which leads to all these strange side
effects.

`module-use!' is a low-level primitive that really should not be used by
the "normal user" IMO.  Instead, one should rather use
`module-use-interfaces!' which has the same semantics as `use-modules'.

Getting back to the problem at hand: Since we want to emulate the
behavior of `use-modules', the safest way would be to use
`module-use-interfaces!', although we can certainly find (fragile?)
workarounds.

Thanks,
Ludovic.


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: top-repl priority of guile module

[Neil Jerram]

ludovic.courtes@laas.fr (Ludovic Courtès) writes:

> Hi,
>
> Neil Jerram <neil@ossau.uklinux.net> writes:
>
>> It seems to me, though, that this is all a matter of ordering, not of
>> whether the duplicates processing gets invoked.  I don't know all the
>> details of the duplicate processing, but by default I would expect a
>> later use-modules (or similar operation) to override an earlier one.
>> Is that what happens?
>
> Roughly, yes.  However, the semantics of `module-use!' are very
> different from those of `use-modules' (unlike what one might think ;-)).
> While `use-modules' honors the duplicate binding policies, including
> `replace' as Kevin noted, `module-use!' does no such thing: it blindly
> overrides bindings.  A more important concern is that the order of
> `module-use!' invocations matters, which leads to all these strange side
> effects.
>
> `module-use!' is a low-level primitive that really should not be used by
> the "normal user" IMO.  Instead, one should rather use
> `module-use-interfaces!' which has the same semantics as `use-modules'.

Absolutely, yes.  One day we should get to de-polluting the guile-user
namespace ...

> Getting back to the problem at hand: Since we want to emulate the
> behavior of `use-modules', the safest way would be to use
> `module-use-interfaces!', although we can certainly find (fragile?)
> workarounds.

Yes, except that I think Kevin's patch using process-use-modules is
even better, because it avoids needing the resolve-interface calls,
and also does the call-with-deferred-observers thing, which looks
appropriate here.

Regards,
     Neil



_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: top-repl priority of guile module

[Kevin Ryde]

Neil Jerram <neil@ossau.uklinux.net> writes:
>
> Absolutely, yes.  One day we should get to de-polluting the guile-user
> namespace ...

Document or hide.

> Yes, except that I think Kevin's patch using process-use-modules is
> even better, because it avoids needing the resolve-interface calls,
> and also does the call-with-deferred-observers thing, which looks
> appropriate here.

I would have used `use-modules', but it objects to not being
top-level, and as a macro you can't easily construct args for it.
(One of the greatest downsides to all macros.)


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel