On 5/24/07, R. Kent Dybvig <dyb at cs.indiana.edu> wrote:
>
> > But as long as the implementation is not required to signal anything
> when
> > storing into an immutable object, the CSP library can't guarantee
> anything,
> > so scheme would still not be able to emulate CSP-style programming.
>
> > It would be good to require support for immutable objects in scheme.
>
> It's there already. You can't create mutators for the immutable fields of
> a record, so as long as your communication uses only immutable records,
> you're safe. You have no access to operations that can mutate pairs or
> strings if you don't import the mutable-lists or mutable-strings
> libraries, so you're safe with immutable pairs and strings too.
I think it is a little harsh to require CSP programs to have no access to
mutable-lists or mutable-strings just so that they can pass pairs and
strings between processes.
Also, as a library implementor, can I specify that the code using my library
will not have access to mutable operations on lists and strings?
The alternative method for creating immutable strings, (symbol->string
(string->symbol msg)) is inelegant. I don't think an artifact of an
optimization of ancient symbol implementations should be the preferred
method for creating immutable strings.
For vectors and pairs, I don't know how to create non-literal immutable
objects of these types. I might have missed something.
If there was something like:
(vector-copy vector) ; For completeness
(vector-copy vector mutable)
(cons-copy pair) ; For completeness
(cons-copy pair mutable)
(string-copy string mutable)
etc.. there are lots of data types in the library as well..
Then it would be possible to write an immutabilizer!
Still, the language guarantee would be "should" and not "must".
This reminds me of a discussion I had with a coworker about what guarantees
the (old?) filesystem in FreeBSD gave in case of catastrophic system
failure. Meta-data for files was guaranteed to be synced to disk, but not
the contents of the files. So you "would never lose your files" (i.e. the
names of them!), but you could lose the content!
To get around this, we laughed about converting all data into filenames and
storing all information in the file names. That way we would not lose any
data!
In scheme, it seems that one might want to convert ones data structure into
symbols to ensure immutability and eqv?. Then put an eqv?-guaranteed
emulation layer for pairs, vectors etc on top of symbols like we could do
for storing meta-data in the freebsd file system.
Alexander
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://lists.r6rs.org/pipermail/r6rs-discuss/attachments/20070525/2959bf3d/attachment.htm
Received on Thu May 24 2007 - 18:58:10 UTC