srfi | 30 Jun 18:02 2003

Final SRFI 39: Parameter objects

This announces that

Scheme Request for Implementation 39

"Parameter objects"

by Marc Feeley.

has gone into ``final'' status.

The document and an archive of the discussion is available at


The SRFI Editors


New revision of SRFI 39 available

... at the usual place:


Cheers =8-} Mike
Friede, Völkerverständigung und überhaupt blabla

Felix Winkelmann | 13 May 08:19 2003

New draft available

Marc Feeley prepared a new draft, which is available at



felix | 6 May 23:04 2003

About moving ahead...

So how about it?


Matthias Radestock | 18 Apr 01:15 2003

is it a new data type?

A few questions/comments:

Are parameters a new data type? This srfi does not define any procedures 
on parameters, so in that sense they are not. However, implementations 
may want to define such procedures, in which case having a predicate 
|parameter?| would be essential. Note however that r5rs compliance would 
still require |procedure?| to return #t for parameters.

What happens when the converter procedure returns more than once, e.g. 
when a continuation captured inside it is invoked?

It would be useful for (<parameter> <value>) to return the existing 
value since a lot of uses of dynamic parameters are of the pattern:
  * get parameter value -> old_value
  * set parameter value
  * do something
  * set parameter value to old_value
Having a setter that returns the existing value allows elimination of 
the first step.


Alan Watson | 17 Apr 08:47 2003

Uniform names

This SRFI has a lot of good in it, but I'm glad the thread-specific
aspects are being treated separately.

A minor suggestion. One of the nice things about Scheme is it's
relatively uniform names. With this in mind, I'd propose:

   (make-parameter initial-value converter) => parameter
   (set-parameter! parameter value)

Then, as Olin Scrivers suggested, add the library procedure and derived

   (with-parameter parameter value thunk)
   (let-parameter ((parameter value) ...) body)
   (let-parameter* ((parameter value) ...) body)

When you do deal with threads, please be careful when using the phrase
"mutable parameter", as different types of parameter can be "mutable"
with different semantics (for example, globally shared, shared between
parents and children, not shared). Please use a more specific term, like
thread-local, depending on the exactly what you mean.



Dr Alan Watson
Instituto de Astronomía UNAM

(Continue reading)


Delay and dynamic extent

> Note that the lambda form does not close over the dynamic
> environment so why should it be different from delay?  Well if you
> did this the "dynamic environment" would in fact be the lexical
> environment so you would lose all the benefits of dynamic binding.
> When one writes a function with lambda there is an expectation that
> the dynamic environment is abstracted over.  However when using a
> DELAY the expectation is that only the evaluation time is changed,
> not the computation being performed (unless side-effects are
> performed that expose the evaluation order).

I'm afraid I can see problems with that characterization of delay. I'd
also like to show an example that seems to demonstrate why delay
should _not_ be closed over the dynamic environment.

It is sometimes convenient to invert an iteration "inside-out" --
turn an iteration over a collection into a lazy list of the traversed
elements. Generators in Icon, Ruby and now Python use a similar
trick. Here's a generic iteration inverter:

(define (foreach->lazy-list foreach-fn collection)
      (lambda (k-main)
	  (lambda (val)
	      (lambda (k-reenter)
		(k-main (cons val
(Continue reading)

Marc Feeley | 7 Mar 23:09 2003

Moving ahead

I apologize for the long delay in moving SRFI-39 forward...

There is clearly discord in how dynamic binding should behave in the
presence of threads.  On the other hand, when threads are not
involved, it seems that we all agree on how dynamic binding should

It appears that the best solution in this case is to separate the
issues into several SRFIs.  SRFI-39 can specify the parameter API and
the behaviour in the absence of threads.  It will be up to individual
thread SRFIs to specify a particular semantics to dynamic binding.

If anyone objects to this approach please let me know.  Otherwise I
will revise the SRFI accordingly.

There is however the issue of the interaction of dynamic binding and
the DELAY special form.  In my opinion the body of the DELAY form
should be evaluated in the same dynamic environment as the DELAY form
itself.  For example in the code

  (with-output-to-file "foo"
    (lambda ()
      (let ((x (delay (display "hello"))))
        (with-output-to-file "bar"
          (lambda ()
            (display "world")
            (force x))))))

we want "hello" to go to the file "foo" and "world" to go to the file
"bar".  This is consistent with the concept of delaying the
(Continue reading)

shivers | 26 Jan 09:45 2003

Comments on SRFI-39

Hello, guys.

I'm coming to this discussion somewhat late. Bravo, Marc, for tackling this one.

SRFI says:
    A parameter object created by the procedure make-mutable-parameter is
    a procedure which accepts zero or one argument (what happens
    when two or more arguments is given is completely
    implementation dependent). A parameter object created by the
    procedure make-parameter is a procedure which accepts no argument
    (what happens when one or more argument is given is completely
    implementation dependent). 

Why do we say extra args to a parm object is undefined? Why not error?

Why is PARAMETERIZE syntax? Make it a function, and render all issues
of eval-order irrelevant. Having captured the core idea as a procedure,
then define a litle piece of binding syntax in terms of it:
  (paramterize param val thunk)				; Procedure
  (let-parameter  ((param val) ...) body ...)		; Derived syntax
  (let-parameter* ((param val) ...) body ...)		; Derived syntax
Or punt the macros and just stick to basic functionality.

Why is the PROMPT mutable param implementation-dependent when passed "> "? It
seems like it's definitely defined, since it's a mutable parameter, to alter
the binding to "> ". Am I missing something here?

Matthew asked "Why mutable params?" I support them, with the *exact* semantics
Marc provides -- threads *inherit* the dynamic bindings. This allows thread
code to be written that interacts w/other threads via shared state accessed
(Continue reading)


Purpose of SRFI 39

I'd like to ask a question about the fundamental purpose of SRFI 39.

Is it there primarily to a) codify existing practice (which seems
reasonable given that many Scheme implementations already have a
parameter-like API) or b) to present a decent API for putting stuff into
the dynamic environment?

Of course, it could be both, but I'd like to argue that it's far from
a good API for what it's trying to do.  My two main objections are:

- The representation for parameters isn't abstract.  Of course, we
  don't know that we'll want to do things not easily doable with the
  procedural representation in the future, but it's possible.
  (Similar to the case Marc argued for CALL/CC.)

- The procedure representing a parameter does two completely different
  things depending on its number of arguments.  It may be just me, but
  I don't think that's a particularly good design.

I'd also like to point out that automatic parameter inheritance is not
necessarily a natural choice.  In particular, it duplicates
functionality already available via lexical scoping.  (I've seen
arguments on this list saying that this is a good thing.  I disagree.)
Moreover, it harbors the potential for space leaks because you create
implicit references to objects by spawning threads.

Of course, this is a plug for our paper

Martin Gasbichler, Michael Sperber: Processes vs. User-Level Threads
(Continue reading)

felix | 22 Dec 01:20 2002

Some comments

- Most existing versions of `parameterize' evaluate the
   new parameter values in parallel (as in `let'). Is there
   a particular reason why this SRFI insists on doing the
   evaluation in `let*' fashion?

- I'm not sure with this one, but (if I haven't overlooked
   something in the SRFI-18 specification), is the definition
   of `dynamic-bind' in the reference implementation reentrant?
   It might be possible that `current-thread' in the before
   thunk refers to a different thread than the one active in
   the after thunk.

- Is it really desirable to separate parameters into two
   classes (i.e. mutable and (perhaps) non-mutable)? The whole
   specification is uncomfortably vague with respect to non-mutable
   parameters and I don't really see the advantage of having
   the non-thread-local kind. Or is this just an attempt to
   somehow cram some degree of portability in this SRFI?

I propose a much simpler and more portable solution:
(and you won't like it ;-)

1) Dump `make-mutable-parameter'. `make-parameter' returns
    a mutable parameter object.
2) `parameterize' changes the parameters by "swapping", as
    in the traditional implementation.
3) Make all parameters thread-local, child threads inherit
    the parameter-settings of their parents.

(Continue reading)