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

Re: initial impressions/questions

This page is part of the web mail archives of SRFI 39 from before July 7th, 2015. The new archives for SRFI 39 contain all messages, not just those from before July 7th, 2015.

> The distinction between `make-parameter' and `make-mutable-parameter'
> is a reasonable compromise.
> MzScheme can't currently support `make-mutable-parameter'. I imagine a
> revision in the near future that will allow it,

Can't you simply use the reference implementation?  You can implement
make-mutable-parameter rather easily if you have a working
make-parameter.  You need to define a parameter that corresponds to
the dynamic environment, and then use that instead of the global
variable dynamic-env-local.

>  but I wonder what kinds
> of tasks make mutable parameters useful. (No doubt I've asked before,
> but the answer didn't stick. In the future, I can consult the archive
> of this list. :)

I don't really think of it in those terms.  For one thing I tend to
avoid mutation when possible, so it is hard for me to make a
convincing case that you need mutable parameters.  But just like some
people find it is easier to express a computation using a mutable
lexical variable, or a mutable data-structure, I think some people
will find it is easier to express a computation using mutable
parameters.  It's a question of "freedom of speech".

Let me also explain what motivated the semantics.  There are two

1) The non-copying semantics specified in the SRFI is closer to the
   semantics of lexical variables.  New threads don't get a fresh copy
   of the lexical variables, so I don't see why parameter objects
   (which are just dynamic variables) should be any different.

   If threads did copy their lexical environment (as is the case with
   UNIX processes created with fork), then I think the dynamic
   environment should also be copied.  But I don't think this is the
   model of threads people want for Scheme (at least it is not the
   model of SRFI 18 which is the only specification for Scheme threads
   we have at this point).

   From a pragmatic point of view, it seems futile to copy the cells
   of the dynamic environment (hoping to make the child and parent
   independant) if the objects that are contained in those cells are

2) Copying the dynamic environment slows down thread creation.  A
   simple implementation will take time proportional to the number
   of parameter objects.

> The body of a `parameterize' is not in tail position, right?

Correct.  This is implementation dependent.

> Typo in `make-parameter' example: it uses `make-mutable-parameter'.

Fixed.  Thanks.