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 <address@hidden> writes:

> Andy Wingo <address@hidden> 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/