[r6rs-discuss] immutable hash tables and eqv?

From: Ludovic Courtès <ludovic.courtes>
Date: Fri, 25 May 2007 15:00:15 +0200

Hi,

"R. Kent Dybvig" <dyb at cs.indiana.edu> writes:

>> 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.

It'd be nice to have a general `make-immutable' procedure, although that
may be too intrusive to implementors.

This would work as follow:

  (make-immutable obj)

    Return a reference to OBJ (an arbitrary Scheme object) that
    disallows mutations to OBJ. It is not possible to re-create a
    mutation-capable reference to OBJ from the returned reference[*].

Example:

  (define v (make-vector 123))

  (vector-set! v 0 'hello)
  (vector-ref v 0)
  |= hello

  (define v2 (make-immutable v))

  (eqv? v v2)
  |= #t

  (vector-ref v2 0)
  |= hello
  (vector-set! v2 0 'something)
  |- &assertion

  (vector-set! v 0 'world)
  (vector-ref v2 0)
  |= world

This is convenient from a security perspective, i.e., when passing a
reference to an untrusted procedure as noted in [0].

Since pairs and strings are now immutable "by default", this would be
useful mostly for vectors and hash tables.

That said, it might be beyond the scope of R6RS...

Thanks,
Ludovic.


[*] This is typically referred to as "downgrading a capability" in
    capability-based systems. See, e.g.,
    http://www.coyotos.org/docs/osverify-2004/osverify-2004.html .

[0] http://mumble.net/~jar/pubs/secureos/ (Section 3.1)
    It seems that Scheme48 currently doesn't implement it, though.
Received on Fri May 25 2007 - 09:00:15 UTC

This archive was generated by hypermail 2.3.0 : Wed Oct 23 2024 - 09:15:01 UTC