Re: How can I tell guile to shut up? ;)

Re: How can I tell guile to shut up? ;)

[Andy Wingo]

Hi Juhani,

Sorry for the delay in the response!

On Wed 02 Mar 2011 09:22, "Juhani Viheräkoski" <moonshine@kapsi.fi> writes:

> $ ./test-script
> ;;; note: source file /home/misty/moonshine/yarg/scripts/./race
> ;;;       newer than compiled
> /home/misty/.cache/guile/ccache/2.0-LE-4-2.0/home/misty/moonshine/yarg/scripts/test-script.go
> ;;; note: auto-compilation is enabled, set GUILE_AUTO_COMPILE=0
> ;;;       or pass the --no-auto-compile argument to disable.
> ;;; compiling /home/misty/moonshine/yarg/scripts/./test-script
> ;;; compiled
> /home/misty/.cache/guile/ccache/2.0-LE-4-2.0/home/misty/moonshine/yarg/scripts/test-script.go

> It seems there is no option to disable these annoying messages in guile
> 2.0. I do scripts using guile and I would appreciate not getting these
> messages that interfere with other output. It is possible to use
> 2>/dev/null but what would I do if my script would output error messages
> (as it will probably do at some point)?

I entirely agree that it's a problem.  By default, running a Guile
script should not cause Guile itself to print anything, to any port.

These messages are useful at times, but they were more useful last year
when compilation didn't work as well as it does now, and they could
probably be pared down a bit.

In addition there are actual compilation warnings:

   $ cat /tmp/foo.scm
   #!/opt/guile/env guile
   !#
   (+ 23 foo)
   $ /tmp/foo.scm
   ;;; note: source file /tmp/foo.scm
   ;;;       newer than compiled /home/wingo/.cache/guile/ccache/2.0-LE-8-2.0/tmp/foo.scm.go
   ;;; note: auto-compilation is enabled, set GUILE_AUTO_COMPILE=0
   ;;;       or pass the --no-auto-compile argument to disable.
   ;;; compiling /tmp/foo.scm
   ;;; /tmp/foo.scm:3:0: warning: possibly unbound variable `foo'
   ;;; compiled /home/wingo/.cache/guile/ccache/2.0-LE-8-2.0/tmp/foo.scm.go

See that warning is useful!  And perhaps you'd want to see it, even when
you don't see some or all of the other lines.  Unlike the
autocompilation debugging, the unbound variable warning will probably go
away before you distribute your script to users, because you'll fix the
bug.

Anyway, I just mean to say that the problem is a bit complicated.

> My suggestion is to add option --quiet to guile.

Hmm.  I think prefer adding -Wfoo, for warnings, like GCC does.  It's
not getopt-long compatible, but we already have -ds.  For other
informational messages, it does seem that we need something like
--quiet, or --verbosity=..., or something.  Not quite sure what that
is.  I've copied guile-devel on this mail to see if anyone else has
opinions on this.

Thanks for the reminder!

Andy
-- 
http://wingolog.org/

Re: How can I tell guile to shut up? ;)

[Andy Wingo]

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

Hi,

On Thu 31 Mar 2011 13:11, Andy Wingo <wingo@pobox.com> writes:

> On Wed 02 Mar 2011 09:22, "Juhani Viheräkoski" <moonshine@kapsi.fi> writes:
>
>> $ ./test-script
>> ;;; note: source file /home/misty/moonshine/yarg/scripts/./race
>> ;;;       newer than compiled
>> /home/misty/.cache/guile/ccache/2.0-LE-4-2.0/home/misty/moonshine/yarg/scripts/test-script.go
>> ;;; note: auto-compilation is enabled, set GUILE_AUTO_COMPILE=0
>> ;;;       or pass the --no-auto-compile argument to disable.
>> ;;; compiling /home/misty/moonshine/yarg/scripts/./test-script
>> ;;; compiled
>> /home/misty/.cache/guile/ccache/2.0-LE-4-2.0/home/misty/moonshine/yarg/scripts/test-script.go
>
>> It seems there is no option to disable these annoying messages in guile
>> 2.0. I do scripts using guile and I would appreciate not getting these
>> messages that interfere with other output. It is possible to use
>> 2>/dev/null but what would I do if my script would output error messages
>> (as it will probably do at some point)?
>
> I entirely agree that it's a problem.  By default, running a Guile
> script should not cause Guile itself to print anything, to any port.
>
> These messages are useful at times, but they were more useful last year
> when compilation didn't work as well as it does now, and they could
> probably be pared down a bit.
[...]
>
>> My suggestion is to add option --quiet to guile.
>
> Hmm.  I think prefer adding -Wfoo, for warnings, like GCC does.  It's
> not getopt-long compatible, but we already have -ds.  For other
> informational messages, it does seem that we need something like
> --quiet, or --verbosity=..., or something.  Not quite sure what that
> is.  I've copied guile-devel on this mail to see if anyone else has
> opinions on this.

After some thinking, the base thing to do is just to add a warning port,
and make warnings (non-fatal informative messages) write to that port.
I have done this in the attached patches.  Any objections?

Andy


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-add-current-warning-port.patch --]
[-- Type: text/x-diff, Size: 3935 bytes --]

From cf289add3ef2144b1341f6f8afe06931d6007721 Mon Sep 17 00:00:00 2001
From: Andy Wingo <wingo@pobox.com>
Date: Tue, 28 Jun 2011 23:24:43 +0200
Subject: [PATCH 1/2] add current-warning-port

* libguile/ports.h:
* libguile/ports.c (scm_current_warning_port)
  (scm_set_current_warning_port): New functions, wrapping the Scheme
  ones.

* module/ice-9/boot-9.scm (current-warning-port)
  (set-current-warning-port): New functions, defining a port for
  warnings.
  (%current-warning-port): New public fluid.  A good idea or not?  We
  commit, you decide!
---
 libguile/ports.c        |   24 ++++++++++++++++++++++++
 libguile/ports.h        |    2 ++
 module/ice-9/boot-9.scm |   27 +++++++++++++++++++++++++++
 3 files changed, 53 insertions(+), 0 deletions(-)

diff --git a/libguile/ports.c b/libguile/ports.c
index 6bb9610..be91b3e 100644
--- a/libguile/ports.c
+++ b/libguile/ports.c
@@ -412,6 +412,17 @@ SCM_DEFINE (scm_current_error_port, "current-error-port", 0, 0, 0,
 }
 #undef FUNC_NAME
 
+SCM
+scm_current_warning_port (void)
+{
+  static SCM cwp_var = SCM_BOOL_F;
+
+  if (scm_is_false (cwp_var))
+    cwp_var = scm_c_private_lookup ("guile", "current-warning-port");
+  
+  return scm_call_0 (scm_variable_ref (cwp_var));
+}
+
 SCM_DEFINE (scm_current_load_port, "current-load-port", 0, 0, 0,
 	    (),
 	    "Return the current-load-port.\n"
@@ -466,6 +477,19 @@ SCM_DEFINE (scm_set_current_error_port, "set-current-error-port", 1, 0, 0,
 }
 #undef FUNC_NAME
 
+
+SCM
+scm_set_current_warning_port (SCM port)
+{
+  static SCM scwp_var = SCM_BOOL_F;
+
+  if (scm_is_false (scwp_var))
+    scwp_var = scm_c_private_lookup ("guile", "set-current-warning-port");
+  
+  return scm_call_1 (scm_variable_ref (scwp_var), port);
+}
+
+
 void
 scm_dynwind_current_input_port (SCM port)
 #define FUNC_NAME NULL
diff --git a/libguile/ports.h b/libguile/ports.h
index 6a669b6..fcf1424 100644
--- a/libguile/ports.h
+++ b/libguile/ports.h
@@ -247,10 +247,12 @@ SCM_API SCM scm_drain_input (SCM port);
 SCM_API SCM scm_current_input_port (void);
 SCM_API SCM scm_current_output_port (void);
 SCM_API SCM scm_current_error_port (void);
+SCM_API SCM scm_current_warning_port (void);
 SCM_API SCM scm_current_load_port (void);
 SCM_API SCM scm_set_current_input_port (SCM port);
 SCM_API SCM scm_set_current_output_port (SCM port);
 SCM_API SCM scm_set_current_error_port (SCM port);
+SCM_API SCM scm_set_current_warning_port (SCM port);
 SCM_API void scm_dynwind_current_input_port (SCM port);
 SCM_API void scm_dynwind_current_output_port (SCM port);
 SCM_API void scm_dynwind_current_error_port (SCM port);
diff --git a/module/ice-9/boot-9.scm b/module/ice-9/boot-9.scm
index a70b9f7..f07094c 100644
--- a/module/ice-9/boot-9.scm
+++ b/module/ice-9/boot-9.scm
@@ -227,6 +227,8 @@ If there is no handler at all, Guile prints an error and then exits."
 
 (define pk peek)
 
+;; Temporary definition; replaced later.
+(define current-warning-port current-error-port)
 
 (define (warn . stuff)
   (with-output-to-port (current-error-port)
@@ -665,6 +667,31 @@ If there is no handler at all, Guile prints an error and then exits."
 
 
 \f
+;;;
+;;; Warnings.
+;;;
+
+;; Here it would be better to use mutable parameters or something, to
+;; avoid exposing the fluid as a binding.
+;;
+(define %current-warning-port (make-fluid))
+
+;; Instead of initializing %current-warning-port to
+;; (current-error-port), let's be sloppy and leave current-warning-port
+;; dynamically scoped, defaulting to (current-error-port).  This lets
+;; (with-error-to-port ...) redirect warnings, at least in the default
+;; setup.  Is it bad idea?  Let us know!
+;;
+(define (current-warning-port)
+  (or (fluid-ref %current-warning-port) (current-error-port)))
+
+(define (set-current-warning-port port)
+  (let ((old (current-warning-port)))
+    (fluid-set! %current-warning-port port)
+    old))
+
+
+\f
 
 ;;;
 ;;; Extensible exception printing.
-- 
1.7.5.4


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #3: 0002-warnings-written-to-warning-port.patch --]
[-- Type: text/x-diff, Size: 8126 bytes --]

From b2ca6679ecc0304a2fbc0d758ae93fb54bc2782c Mon Sep 17 00:00:00 2001
From: Andy Wingo <wingo@pobox.com>
Date: Tue, 28 Jun 2011 23:43:14 +0200
Subject: [PATCH 2/2] warnings written to warning port

* libguile/deprecation.c (scm_c_issue_deprecation_warning):
* libguile/load.c (auto_compile_catch_handler):
  (scm_sys_warn_auto_compilation_enabled, scm_primitive_load_path):
* module/ice-9/boot-9.scm (warn, %load-announce, duplicate-handlers)
  (load-in-vicinity):
* module/system/base/message.scm (warning): Write to the warning port.
  (*current-warning-port*): Alias the warning port.
---
 libguile/deprecation.c         |    4 ++--
 libguile/load.c                |   20 ++++++++++----------
 module/ice-9/boot-9.scm        |   18 +++++++++---------
 module/system/base/message.scm |   10 ++++------
 4 files changed, 25 insertions(+), 27 deletions(-)

diff --git a/libguile/deprecation.c b/libguile/deprecation.c
index be5fffc..0822707 100644
--- a/libguile/deprecation.c
+++ b/libguile/deprecation.c
@@ -89,8 +89,8 @@ scm_c_issue_deprecation_warning (const char *msg)
             fprintf (stderr, "%s\n", msg);
           else
             {
-              scm_puts (msg, scm_current_error_port ());
-              scm_newline (scm_current_error_port ());
+              scm_puts (msg, scm_current_warning_port ());
+              scm_newline (scm_current_warning_port ());
             }
         }
     }
diff --git a/libguile/load.c b/libguile/load.c
index b06fd77..9f995be 100644
--- a/libguile/load.c
+++ b/libguile/load.c
@@ -741,18 +741,18 @@ auto_compile_catch_handler (void *data, SCM tag, SCM throw_args)
   oport = scm_open_output_string ();
   scm_print_exception (oport, SCM_BOOL_F, tag, throw_args);
 
-  scm_puts (";;; WARNING: compilation of ", scm_current_error_port ());
-  scm_display (source, scm_current_error_port ());
-  scm_puts (" failed:\n", scm_current_error_port ());
+  scm_puts (";;; WARNING: compilation of ", scm_current_warning_port ());
+  scm_display (source, scm_current_warning_port ());
+  scm_puts (" failed:\n", scm_current_warning_port ());
 
   lines = scm_string_split (scm_get_output_string (oport),
                             SCM_MAKE_CHAR ('\n'));
   for (; scm_is_pair (lines); lines = scm_cdr (lines))
     if (scm_c_string_length (scm_car (lines)))
       {
-        scm_puts (";;; ", scm_current_error_port ());
-        scm_display (scm_car (lines), scm_current_error_port ());
-        scm_newline (scm_current_error_port ());
+        scm_puts (";;; ", scm_current_warning_port ());
+        scm_display (scm_car (lines), scm_current_warning_port ());
+        scm_newline (scm_current_warning_port ());
       }
 
   scm_close_port (oport);
@@ -770,7 +770,7 @@ SCM_DEFINE (scm_sys_warn_auto_compilation_enabled, "%warn-auto-compilation-enabl
     {
       scm_puts (";;; note: auto-compilation is enabled, set GUILE_AUTO_COMPILE=0\n"
                 ";;;       or pass the --no-auto-compile argument to disable.\n",
-                scm_current_error_port ());
+                scm_current_warning_port ());
       message_shown = 1;
     }
 
@@ -891,9 +891,9 @@ SCM_DEFINE (scm_primitive_load_path, "primitive-load-path", 0, 0, 1,
       if (scm_is_true (scm_stat (fallback, SCM_BOOL_F))
           && compiled_is_fresh (full_filename, fallback))
         {
-          scm_puts (";;; found fresh local cache at ", scm_current_error_port ());
-          scm_display (fallback, scm_current_error_port ());
-          scm_newline (scm_current_error_port ());
+          scm_puts (";;; found fresh local cache at ", scm_current_warning_port ());
+          scm_display (fallback, scm_current_warning_port ());
+          scm_newline (scm_current_warning_port ());
           return scm_load_compiled_with_vm (fallback);
         }
     }
diff --git a/module/ice-9/boot-9.scm b/module/ice-9/boot-9.scm
index f07094c..0cdd851 100644
--- a/module/ice-9/boot-9.scm
+++ b/module/ice-9/boot-9.scm
@@ -231,7 +231,7 @@ If there is no handler at all, Guile prints an error and then exits."
 (define current-warning-port current-error-port)
 
 (define (warn . stuff)
-  (with-output-to-port (current-error-port)
+  (with-output-to-port (current-warning-port)
     (lambda ()
       (newline)
       (display ";;; WARNING ")
@@ -1429,7 +1429,7 @@ VALUE."
 
 (define (%load-announce file)
   (if %load-verbosely
-      (with-output-to-port (current-error-port)
+      (with-output-to-port (current-warning-port)
         (lambda ()
           (display ";;; ")
           (display "loading ")
@@ -3380,7 +3380,7 @@ module '(ice-9 q) '(make-q q-length))}."
                  #f))
     
     (define (warn module name int1 val1 int2 val2 var val)
-      (format (current-error-port)
+      (format (current-warning-port)
               "WARNING: ~A: `~A' imported from both ~A and ~A\n"
               (module-name module)
               name
@@ -3402,7 +3402,7 @@ module '(ice-9 q) '(make-q q-length))}."
     (define (warn-override-core module name int1 val1 int2 val2 var val)
       (and (eq? int1 the-scm-module)
            (begin
-             (format (current-error-port)
+             (format (current-warning-port)
                      "WARNING: ~A: imported module ~A overrides core binding `~A'\n"
                      (module-name module)
                      (module-name int2)
@@ -3514,13 +3514,13 @@ module '(ice-9 q) '(make-q q-length))}."
               go-path
               (begin
                 (if gostat
-                    (format (current-error-port)
+                    (format (current-warning-port)
                             ";;; note: source file ~a\n;;;       newer than compiled ~a\n"
                             name go-path))
                 (cond
                  (%load-should-auto-compile
                   (%warn-auto-compilation-enabled)
-                  (format (current-error-port) ";;; compiling ~a\n" name)
+                  (format (current-warning-port) ";;; compiling ~a\n" name)
                   (let ((cfn
                          ((module-ref
                                (resolve-interface '(system base compile))
@@ -3528,15 +3528,15 @@ module '(ice-9 q) '(make-q q-length))}."
                               name
                               #:opts %auto-compilation-options
                               #:env (current-module))))
-                    (format (current-error-port) ";;; compiled ~a\n" cfn)
+                    (format (current-warning-port) ";;; compiled ~a\n" cfn)
                     cfn))
                  (else #f))))))
       (lambda (k . args)
-        (format (current-error-port)
+        (format (current-warning-port)
                 ";;; WARNING: compilation of ~a failed:\n" name)
         (for-each (lambda (s)
                     (if (not (string-null? s))
-                        (format (current-error-port) ";;; ~a\n" s)))
+                        (format (current-warning-port) ";;; ~a\n" s)))
                   (string-split
                    (call-with-output-string
                     (lambda (port) (print-exception port #f k args)))
diff --git a/module/system/base/message.scm b/module/system/base/message.scm
index 95468ca..84d6c41 100644
--- a/module/system/base/message.scm
+++ b/module/system/base/message.scm
@@ -54,11 +54,9 @@
 ;;; Warnings
 ;;;
 
-(define *current-warning-port*
-  ;; The port where warnings are sent.
-  (make-fluid))
-
-(fluid-set! *current-warning-port* (current-error-port))
+;; This name existed before %current-warning-port was introduced, but
+;; otherwise it is a deprecated binding.
+(define *current-warning-port* %current-warning-port)
 
 (define *current-warning-prefix*
   ;; Prefix string when emitting a warning.
@@ -196,7 +194,7 @@
   "Emit a warning of type TYPE for source location LOCATION (a source
 property alist) using the data in ARGS."
   (let ((wt   (lookup-warning-type type))
-        (port (fluid-ref *current-warning-port*)))
+        (port (current-warning-port)))
     (if (warning-type? wt)
         (apply (warning-type-printer wt)
                port (location-string location)
-- 
1.7.5.4


[-- Attachment #4: Type: text/plain, Size: 25 bytes --]

-- 
http://wingolog.org/

Re: How can I tell guile to shut up? ;)

[Andreas Rottmann]

Andy Wingo <wingo@pobox.com> writes:

> After some thinking, the base thing to do is just to add a warning port,
> and make warnings (non-fatal informative messages) write to that port.
> I have done this in the attached patches.  Any objections?
>
Great thing to do -- this adds quite some flexibility that can be put to
good use.  

One thing about the implementation, though: I don't quite like that
`%current-warning-port' (as already hinted at in the source) is intended
to be private (but isn't, but that's another, harder, issue), however
there is no way to redirect the warnings to another port for a dynamic
extent save for using that (assumably) private API.  How about
(especially since it looks like R7RS will include a subset of it in the
small language) moving SRFI 39 into the core and using that?

Regards, Rotty
-- 
Andreas Rottmann -- <http://rotty.yi.org/>

Re: How can I tell guile to shut up? ;)

[Andy Wingo]

Hi Andreas,

Thanks for looking at the patch!

On Thu 30 Jun 2011 03:24, Andreas Rottmann <a.rottmann@gmx.at> writes:

> Andy Wingo <wingo@pobox.com> writes:
>
>> After some thinking, the base thing to do is just to add a warning port,
>> and make warnings (non-fatal informative messages) write to that port.
>> I have done this in the attached patches.  Any objections?
>>
> Great thing to do -- this adds quite some flexibility that can be put to
> good use.  
>
> One thing about the implementation, though: I don't quite like that
> `%current-warning-port' (as already hinted at in the source) is intended
> to be private (but isn't, but that's another, harder, issue), however
> there is no way to redirect the warnings to another port for a dynamic
> extent save for using that (assumably) private API.  How about
> (especially since it looks like R7RS will include a subset of it in the
> small language) moving SRFI 39 into the core and using that?

I agree, but it's tricky.

  1) Our definition of `parameterize' should allow compilation to
     <dynlet>.  In practice this means it needs to expand to
     `with-fluids', not `with-fluids*'.

  2) `parameterize' should not have hacks for "swapper" procedures,
     currently needed due to ports.  (Ports should be parameters,
     natively.)

  3) The "get-fluid" and "get-converter" tokens should not have
     user-visible bindings.  I guess this means that make-parameter
     should be bound in the same lexical contour as hypothetical
     `parameter-fluid' and `parameter-converter' procedures.

  4) Our fluids currently have problems with threads: if a thread not
     spawned by a Guile thread enters Guile, its fluids are bound to
     #f.  This should be fixed; in the meantime though we hack around
     that with the (or ...) clause, which is not a hack that will work
     for parameters (though perhaps it would, with a wrapper
     procedure).

I'm also a little concerned about parameters, in that in some ways they
are like records, having fluid and converter fields, but they are also
procedures, so there is no predicate for that data type.

I suppose it would be acceptable to have them be applicable
structs... hmmm.  How about this:

  (define <parameter>
    ;; Three fields: the procedure itself, the fluid, and the converter.
    (make-struct <applicable-struct-vtable> 0 'pwprpr))
  (set-struct-vtable-name! <parameter> '<parameter>)

  (define (parameter? x) (and (struct? x) (eq? (struct-vtable x) <parameter>)))
  (define (parameter-fluid p) (struct-ref p 1))
  (define (parameter-converter p) (struct-ref p 2))

  (define* (make-parameter init #:optional (conv (lambda (x) x)))
    (let ((fluid (make-fluid)))
      (fluid-set! fluid (conv init))
      (make-struct <parameter> 0
                   (case-lambda
                     (() (fluid-ref fluid))
                     ((x) (fluid-set! fluid (conv x))))
                   fluid conv)))

  (define-syntax parameterize
    (syntax-rules ()
      ((_ ((param value) ...) body body* ...)
       (let ((p param) ...)
         (with-fluids (((parameter-fluid p) ((parameter-converter p) value))
                       ...)
           body body* ...)))))

If we had a decent inliner this would be good enough.  As it is we
should probably handle the case in which `param' is an identifier
specially, to avoid creating the `let' binding.  Or maybe not; maybe we
should just fix our inliner.

WDYT?  I can work on this tomorrow.  I guess the thing to do would be to
add these parameters to boot-9, replacing and deprecating the
make-mutable-parameter that is there.  Then we somehow change the
`current-input-port' binding to be a <parameter>, and turn srfi-39 into
a noop (mostly).  Then we add warnings in terms of parameters.

Andy
-- 
http://wingolog.org/

Re: How can I tell guile to shut up? ;)

[Ludovic Courtès]

Hi!

Andy Wingo <wingo@pobox.com> skribis:

>   4) Our fluids currently have problems with threads: if a thread not
>      spawned by a Guile thread enters Guile, its fluids are bound to
>      #f.  This should be fixed; in the meantime though we hack around
>      that with the (or ...) clause, which is not a hack that will work
>      for parameters (though perhaps it would, with a wrapper
>      procedure).

Does your parameter proposal intend to address this?  (My understanding
is “no.”)

>   (define <parameter>
>     ;; Three fields: the procedure itself, the fluid, and the converter.
>     (make-struct <applicable-struct-vtable> 0 'pwprpr))
>   (set-struct-vtable-name! <parameter> '<parameter>)
>
>   (define (parameter? x) (and (struct? x) (eq? (struct-vtable x) <parameter>)))
>   (define (parameter-fluid p) (struct-ref p 1))
>   (define (parameter-converter p) (struct-ref p 2))

Maybe we should provide ‘define-applicable-record-type’ in
(srfi srfi-9 gnu).  :-)

>   (define* (make-parameter init #:optional (conv (lambda (x) x)))
>     (let ((fluid (make-fluid)))
>       (fluid-set! fluid (conv init))
v>       (make-struct <parameter> 0
>                    (case-lambda
>                      (() (fluid-ref fluid))
>                      ((x) (fluid-set! fluid (conv x))))
>                    fluid conv)))
>
>   (define-syntax parameterize
>     (syntax-rules ()
>       ((_ ((param value) ...) body body* ...)
>        (let ((p param) ...)
>          (with-fluids (((parameter-fluid p) ((parameter-converter p) value))
>                        ...)
>            body body* ...)))))

To me it looks like we’re adding a 3rd variation on the theme (well,
‘make-mutable-parameter’ already existed, but it’s not meant to be used,
is it?).

Personally, I’ve typically used the fluids API within Guile, for the
sake of consistency, and SRFI-39 elsewhere.  What does it buy us to use
our own ‘parameterize’ variants in parts of Guile?

[...]

> Then we somehow change the
> `current-input-port' binding to be a <parameter>

How about exposing the fluids the underlie ‘current-input-port’ &
co. instead?  This would allow the use of ‘with-fluids’ instead of
fiddling with ‘dynamic-wind’ and the like, while being consistent with
the rest of Guile.

Thanks,
Ludo’.

Re: How can I tell guile to shut up? ;)

[Andy Wingo]

Hi!

Thanks for thinking this through!

On Thu 30 Jun 2011 23:27, ludo@gnu.org (Ludovic Courtès) writes:

> Andy Wingo <wingo@pobox.com> skribis:
>
>>   4) Our fluids currently have problems with threads: if a thread not
>>      spawned by a Guile thread enters Guile, its fluids are bound to
>>      #f.  This should be fixed; in the meantime though we hack around
>>      that with the (or ...) clause, which is not a hack that will work
>>      for parameters (though perhaps it would, with a wrapper
>>      procedure).
>
> Does your parameter proposal intend to address this?  (My understanding
> is “no.”)

Indeed, no.  I think we need to fix fluids.

>>   (define <parameter>
>>     ;; Three fields: the procedure itself, the fluid, and the converter.
>>     (make-struct <applicable-struct-vtable> 0 'pwprpr))
>>   (set-struct-vtable-name! <parameter> '<parameter>)
>>
>>   (define (parameter? x) (and (struct? x) (eq? (struct-vtable x) <parameter>)))
>>   (define (parameter-fluid p) (struct-ref p 1))
>>   (define (parameter-converter p) (struct-ref p 2))
>
> Maybe we should provide ‘define-applicable-record-type’ in
> (srfi srfi-9 gnu).  :-)

Yes!  However that doesn't help us in boot-9 :)

> To me it looks like we’re adding a 3rd variation on the theme (well,
> ‘make-mutable-parameter’ already existed, but it’s not meant to be used,
> is it?).
>
> Personally, I’ve typically used the fluids API within Guile, for the
> sake of consistency, and SRFI-39 elsewhere.  What does it buy us to use
> our own ‘parameterize’ variants in parts of Guile?

Third time's the charm, as they say... here's the deal.  `with-fluids'
is fairly efficient, because its body does not need to be allocated as a
closure, but it doesn't provide you any guarantees about the values
bound to the fluids.  Parameter objects are better in that way, because
their converter can check the values.  Parameterize is just as short as
with-fluids, but preserves this correctness property, so it's a good
thing.

However parameterize was not as efficient as `with-fluids', because its
body must be a closure.  This version fixes that, so perhaps parameters
are the thing now.

Also, (fluid-ref x) is more typing than (x), and the dance needed to
define a fluid, init val, and accessor takes longer than (make-parameter
'foo).  So parameters are a win IMO.

>> Then we somehow change the
>> `current-input-port' binding to be a <parameter>
>
> How about exposing the fluids the underlie ‘current-input-port’ &
> co. instead?  This would allow the use of ‘with-fluids’ instead of
> fiddling with ‘dynamic-wind’ and the like, while being consistent with
> the rest of Guile.

Would you like users to be able to (fluid-set! %current-input-port
'not-a-port)?  Or to (with-fluids ((%current-input-port 'foo)) ...) ?
Probably not.  I think that we should be switching to parameters for
user-facing dynamic bindings.  Fluids are to dynamic bindings what
variables are to toplevel bindings: useful building blocks, but not
usually what you want to give to the user.

WDYT? :)

Andy
-- 
http://wingolog.org/

Re: How can I tell guile to shut up? ;)

[Ludovic Courtès]

Hello!

Andy Wingo <wingo@pobox.com> skribis:

> Third time's the charm, as they say... here's the deal.  `with-fluids'
> is fairly efficient, because its body does not need to be allocated as a
> closure, but it doesn't provide you any guarantees about the values
> bound to the fluids.  Parameter objects are better in that way, because
> their converter can check the values.  Parameterize is just as short as
> with-fluids, but preserves this correctness property, so it's a good
> thing.

Yes, agreed.  I prefer parameters too, but I was concerned that using
parameters in Guile’s API would introduce an inconsistency, break the
rule of least surprise, etc.

> However parameterize was not as efficient as `with-fluids', because its
> body must be a closure.  This version fixes that, so perhaps parameters
> are the thing now.

OK, understood.

>> How about exposing the fluids the underlie ‘current-input-port’ &
>> co. instead?  This would allow the use of ‘with-fluids’ instead of
>> fiddling with ‘dynamic-wind’ and the like, while being consistent with
>> the rest of Guile.
>
> Would you like users to be able to (fluid-set! %current-input-port
> 'not-a-port)?  Or to (with-fluids ((%current-input-port 'foo)) ...) ?
> Probably not.

No, but OTOH, I *think* it would lead to a graceful type error sooner or
later, as opposed to a crash.

> I think that we should be switching to parameters for user-facing
> dynamic bindings.  Fluids are to dynamic bindings what variables are
> to toplevel bindings: useful building blocks, but not usually what you
> want to give to the user.

Yes, agreed in principle—though in practice variables can be set
arbitrarily.

The problem I have is that (1) I don’t see how we could migrate the
existing public fluids to parameters without breaking the API, and (2)
it’s unpleasant to my eye to have both fluids and parameters in the core
API.

WDYT?

Thanks,
Ludo’.

Re: How can I tell guile to shut up? ;)

[Andy Wingo]

Hi!

On Fri 01 Jul 2011 15:04, ludo@gnu.org (Ludovic Courtès) writes:

> Andy Wingo <wingo@pobox.com> skribis:
>
>> here's the deal.

I think I just read three emails of mine with this phrase in it.
Terrible.  I promise more syntactic variability in the future.

>> (with-fluids ((%current-input-port 'foo)) ...) ?  Probably not.
>
> No, but OTOH, I *think* it would lead to a graceful type error sooner or
> later, as opposed to a crash.

True.  Still, not very nice :)

> The problem I have is that (1) I don’t see how we could migrate the
> existing public fluids to parameters without breaking the API, and (2)
> it’s unpleasant to my eye to have both fluids and parameters in the core
> API.

As an example let's take *repl-stack* from boot-9.  Here's what we
could do:

  (define repl-stack (make-parameter #f)))

and in deprecated.scm:

  (define *repl-stack* (parameter-fluid repl-stack))

Ideally we would change *repl-stack* to be an identifier-syntax like:

  (define-syntax *repl-stack*
    (identifier-syntax
      (begin
        (issue-deprecation-warning "it's dead jim")
        (parameter-fluid repl-stack))))

but in 2.0 that would break binary compat.  We could do that in 2.2, or
otherwise just remove it in 2.2, depending on what the situation was.

So I am optimistic regarding our ability to gradually change over to
parameters, if you are in agreement that parameters are the interface
that we should export.

Cheers,

Andy
-- 
http://wingolog.org/

Re: How can I tell guile to shut up? ;)

[Ludovic Courtès]

Hello!

Andy Wingo <wingo@pobox.com> skribis:

> As an example let's take *repl-stack* from boot-9.  Here's what we
> could do:
>
>   (define repl-stack (make-parameter #f)))
>
> and in deprecated.scm:
>
>   (define *repl-stack* (parameter-fluid repl-stack))
>
> Ideally we would change *repl-stack* to be an identifier-syntax like:
>
>   (define-syntax *repl-stack*
>     (identifier-syntax
>       (begin
>         (issue-deprecation-warning "it's dead jim")
>         (parameter-fluid repl-stack))))

OK, looks like a nice plan.  Fine with me, then!

Thanks,
Ludo’.

Fluids vs parameters: which API is better?

[Mark H Weaver]

Hi Andy,

Andy Wingo <wingo@pobox.com> writes:
> So I am optimistic regarding our ability to gradually change over to
> parameters, if you are in agreement that parameters are the interface
> that we should export.

I'm sorry to throw a monkey wrench into this nice plan, but I would like
to briefly argue that fluids are the far superior interface.

From an efficiency perspective, it is much more straightforward and
reliable for a compiler to understand what operation is done by
(fluid-ref x) than (x).  Granted, this requires an assumption that
`fluid-ref' has not been set to something else, but we're already making
similar assumptions for many other common operations, and there are
various ways we can manage these assumptions more cleanly in the future.

More generally, from a perspective of semantics and security, it is
preferable for a program to apply a known operation (e.g. `fluid-ref')
to some data, than to call the `data' as a procedure and ask it to do
something.  Yes, there are cases when the flexibility of message passing
is worthwhile, but there are significant disadvantages.  Once you do
this, you can no longer analyze the behavior of a procedure without
knowing a lot about the data itself.

In this particular case I think it would be a shame to enshrine the
disadvantages of message passing into our API, on such a fundamentally
important set of primitives.

What do you think?

    Best,
     Mark

Re: Fluids vs parameters: which API is better?

[Andy Wingo]

Hi Mark,

On Mon 18 Jul 2011 23:57, Mark H Weaver <mhw@netris.org> writes:

> From an efficiency perspective, it is much more straightforward and
> reliable for a compiler to understand what operation is done by
> (fluid-ref x) than (x).

This is true.

> More generally, from a perspective of semantics and security, it is
> preferable for a program to apply a known operation (e.g. `fluid-ref')
> to some data, than to call the `data' as a procedure and ask it to do
> something.  Yes, there are cases when the flexibility of message passing
> is worthwhile, but there are significant disadvantages.  Once you do
> this, you can no longer analyze the behavior of a procedure without
> knowing a lot about the data itself.

Here I disagree.  From the perspective of semantics and security, it's
important to be able to make assertions as to the type of value returned
by a procedure -- that (current-input-port) returns a port.  The same
goes for (current-language) and all the other dynamic parameters.
Parameters allow us to make guarantees like that.

> In this particular case I think it would be a shame to enshrine the
> disadvantages of message passing into our API, on such a fundamentally
> important set of primitives.

Fluids will still exist, of course.  But I think you are conflating two
things:

  1) Optimizability.  I don't think this matters much TBH.  One could
     define an inlinable parameter and have all the safety guarantees of
     parameters compiling down to a fluid-ref.

  2) Perspicacity (from a tools POV?).  Again, not much has changed
     here.  Parameters can be recognized as such by any tool.  In the
     general case you need whole-program analysis to recover the
     bindings of fluids anyway.

Parameters have a long history in Scheme, from current-input-port to
SRFI-39, to R6RS and now probably in R7RS.  I think they're close to the
right thing, and given that you can get the fluids from the parameters
if you want, there's not much of a down-side.  And, they are more terse
to use.

Have I convinced you now? :-)

Andy
-- 
http://wingolog.org/

Re: Fluids vs parameters: which API is better?

[BT Templeton]

Andy Wingo <wingo@pobox.com> writes:

> Hi Mark,
>
> On Mon 18 Jul 2011 23:57, Mark H Weaver <mhw@netris.org> writes:
>
>> From an efficiency perspective, it is much more straightforward and
>> reliable for a compiler to understand what operation is done by
>> (fluid-ref x) than (x).
>
> This is true.
>
>> More generally, from a perspective of semantics and security, it is
>> preferable for a program to apply a known operation (e.g. `fluid-ref')
>> to some data, than to call the `data' as a procedure and ask it to do
>> something.  Yes, there are cases when the flexibility of message passing
>> is worthwhile, but there are significant disadvantages.  Once you do
>> this, you can no longer analyze the behavior of a procedure without
>> knowing a lot about the data itself.
>
> Here I disagree.  From the perspective of semantics and security, it's
> important to be able to make assertions as to the type of value returned
> by a procedure -- that (current-input-port) returns a port.  The same
> goes for (current-language) and all the other dynamic parameters.
> Parameters allow us to make guarantees like that.

Why is it uniquely useful to be able to make these guarantees for
dynamically-bound values? Static/soft typing would be more generally
useful than parameters.

Also, I'd prefer it if parameters used a type predicate or a type
specifier object instead of a conversion procedure. ISTM that the
current interface conflates type checking and coercion.

-- 
Inteligenta persono lernas la lingvon Esperanton rapide kaj facile.
Esperanto estas moderna, kultura lingvo por la mondo. Simpla, fleksebla,
belsona, Esperanto estas la praktika solvo de la problemo de universala
interkompreno. Lernu la interlingvon Esperanton!

Re: Fluids vs parameters: which API is better?

[Ludovic Courtès]

Hi BT,

BT Templeton <bpt@hcoop.net> skribis:

> Andy Wingo <wingo@pobox.com> writes:

[...]

>> Here I disagree.  From the perspective of semantics and security, it's
>> important to be able to make assertions as to the type of value returned
>> by a procedure -- that (current-input-port) returns a port.  The same
>> goes for (current-language) and all the other dynamic parameters.
>> Parameters allow us to make guarantees like that.
>
> Why is it uniquely useful to be able to make these guarantees for
> dynamically-bound values? Static/soft typing would be more generally
> useful than parameters.

I agree it’s not specific to dynamically-bound values.

Andy mentioned that exporting, say, the fluid that underlies
‘current-output-port’ would be a problem because you could ‘fluid-set!’
it to anything, which would lead to an obscure wrong-type-arg error
sometime.

OTOH it could be argued that this is no different with mutable global
variables.

> Also, I'd prefer it if parameters used a type predicate or a type
> specifier object instead of a conversion procedure. ISTM that the
> current interface conflates type checking and coercion.

Well, Andy’s proposal is similar to SRFI-39 and I find it convenient
this way.

Thanks,
Ludo’.

Re: Fluids vs parameters: which API is better?

[Andy Wingo]

Hello!

On Mon 25 Jul 2011 11:24, ludo@gnu.org (Ludovic Courtès) writes:

> BT Templeton <bpt@hcoop.net> skribis:
>
>> Andy Wingo <wingo@pobox.com> writes:
>
> [...]
>
>>> Here I disagree.  From the perspective of semantics and security, it's
>>> important to be able to make assertions as to the type of value returned
>>> by a procedure -- that (current-input-port) returns a port.  The same
>>> goes for (current-language) and all the other dynamic parameters.
>>> Parameters allow us to make guarantees like that.
>>
>> Why is it uniquely useful to be able to make these guarantees for
>> dynamically-bound values? Static/soft typing would be more generally
>> useful than parameters.
>
> I agree it’s not specific to dynamically-bound values.
>
> Andy mentioned that exporting, say, the fluid that underlies
> ‘current-output-port’ would be a problem because you could ‘fluid-set!’
> it to anything, which would lead to an obscure wrong-type-arg error
> sometime.
>
> OTOH it could be argued that this is no different with mutable global
> variables.

FWIW I think it's fine to export the fluid corresponding to
current-output-port -- and indeed the `parameter-fluid' accessor would
allow you to get at these values.  But, if you would like to provide a
minimal environment for untrusted code, you wouldn't provide
parameter-fluid (or struct-ref) to that code.

In Guile we have a tension between providing both hackability and
reliability.  We have many ways of resolving this tension -- modules,
convention, and tools among them.  In this case I would use all three --
expose the fluids you need to, but only if you need to; by convention,
avoid direct fluid access to other modules' fluids; and such access
should cause compile-time warnings (to give feedback to the user about
our conventions).

We should do the same for global variables, btw.  Set! to a variable
exported by another module should produce a warning.

As you mention BT, typing (and contracts) can help too.  We don't have
them currently, but that's no reason to eschew the tools that we do
have.

>> Also, I'd prefer it if parameters used a type predicate or a type
>> specifier object instead of a conversion procedure. ISTM that the
>> current interface conflates type checking and coercion.
>
> Well, Andy’s proposal is similar to SRFI-39 and I find it convenient
> this way.

In addition, this step does not preclude type specifier objects, were
Guile to get them at some point.  They can be defined as wrappers to
`make-parameter' et al.  Racket is really leading the way here, I
think; do read Findler's contracts work if you have an interest in such
things.

Andy
-- 
http://wingolog.org/

Re: How can I tell guile to shut up? ;)

[Andy Wingo]

Hi,

On Thu 30 Jun 2011 03:24, Andreas Rottmann <a.rottmann@gmx.at> writes:

> Andy Wingo <wingo@pobox.com> writes:
>
>> After some thinking, the base thing to do is just to add a warning port,
>> and make warnings (non-fatal informative messages) write to that port.
>> I have done this in the attached patches.

I have pushed patches implementing (current-warning-port) to
stable-2.0.  Now we need some command-line arg to silence the warning
port :)

> How about (especially since it looks like R7RS will include a subset
> of it in the small language) moving SRFI 39 into the core and using
> that?

I have done this as well, following the discussion in this thread.

Regards,

Andy
-- 
http://wingolog.org/

Re: How can I tell guile to shut up? ;)

[Ludovic Courtès]

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

Hi Andy,

Andy Wingo <wingo@pobox.com> skribis:

> After some thinking, the base thing to do is just to add a warning port,
> and make warnings (non-fatal informative messages) write to that port.
> I have done this in the attached patches.  Any objections?

Ideally I’d preferred to keep current-warning-port in (system base
message), but since it’s needed in boot-9, we may have to make it
global.  Or would the following work?


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Type: text/x-patch, Size: 493 bytes --]

diff --git a/module/ice-9/boot-9.scm b/module/ice-9/boot-9.scm
index 1ddb0ff..e1582a3 100644
--- a/module/ice-9/boot-9.scm
+++ b/module/ice-9/boot-9.scm
@@ -3767,6 +3767,7 @@ module '(ice-9 q) '(make-q q-length))}."
 ;; Set filename to #f to prevent reload.
 (define-module (guile-user)
   #:autoload (system base compile) (compile compile-file)
+  #:autoload (system base message) (%current-warning-port)
   #:filename #f)
 
 ;; Remain in the `(guile)' module at compilation-time so that the

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


Besides, it would be great if ‘*current-warning-prefix*’ were handled
consistently, too.  All this could certainly be factorized in a Scheme/C
function that takes care of using the right port and prefix.

WDYT?

Thanks,
Ludo’.

Re: How can I tell guile to shut up? ;)

[Andy Wingo]

Hi,

On Thu 30 Jun 2011 23:37, ludo@gnu.org (Ludovic Courtès) writes:

> Andy Wingo <wingo@pobox.com> skribis:
>
>> After some thinking, the base thing to do is just to add a warning port,
>> and make warnings (non-fatal informative messages) write to that port.
>> I have done this in the attached patches.  Any objections?
>
> Ideally I’d preferred to keep current-warning-port in (system base
> message), but since it’s needed in boot-9, we may have to make it
> global.  Or would the following work?

Yeah I tried to do that, but since it's needed in C (potentially quite
early, even before modules) and in Scheme I just bit the bullet and
added it to the default env.

>  (define-module (guile-user)
>    #:autoload (system base compile) (compile compile-file)
> +  #:autoload (system base message) (%current-warning-port)
>    #:filename #f)

Wouldn't work, because it's needed in (guile), not (guile-user).

> Besides, it would be great if ‘*current-warning-prefix*’ were handled
> consistently, too.  All this could certainly be factorized in a Scheme/C
> function that takes care of using the right port and prefix.

It would, but then you're talking about standardizing a `warning'
function, and that's problematic, as some warnings will have source
locations and others will not, and we already have `warn' in the base
env which has a rest arg so it's not extensible with keywords, etc etc,
and system base message is really about compiler warnings (requiring
source location) and not all warnings, so it's a bit of a mess.  (And
that's not to mention more general logging facilities, with levels and
categories and such.)

Note that it is also possible to prefix all output with soft ports.

Basically I appreciate the concerns but have not found a way to solve
the whole problem nicely, so I kept it simple.  As it seems we agree on
the need for higher-level solutions based on a warning port accessible
in (guile) and C, I'm going to see about committing something along
these lines, and we can work on higher-level warning facilities later.

Regards,

Andy
-- 
http://wingolog.org/

Re: How can I tell guile to shut up? ;)

[Ludovic Courtès]

Andy Wingo <wingo@pobox.com> skribis:

> Basically I appreciate the concerns but have not found a way to solve
> the whole problem nicely, so I kept it simple.  As it seems we agree on
> the need for higher-level solutions based on a warning port accessible
> in (guile) and C, I'm going to see about committing something along
> these lines, and we can work on higher-level warning facilities later.

Sounds like a plan, yes.

Thanks,
Ludo'.