[E-Lang] Immutable map operations

[Mark S. Miller]

At 11:51 AM Sunday 4/1/01, zooko@zooko.com wrote:
> MarkM wrote:
>> IMO, this entire direction isn't worth pursuing unless we give up on mutable 
>> collections.  I see no way to retain mutable indexable collections without 
>> retaining the security problem.
>
>This is obviously very important to you, but I haven't yet grokked the security
>issue.  Could you give me a URL or a summary or example?

If the following short explanations isn't clear, lemme know and I'll try to 
find some URLs.

    class BlobMaker(list) :any {
        def Blob {
            to get(index) :any { list[index] }
            to getStuff() :any { list }
            .... list ...
        }
    }

    def Alice() {
        def list := [1, 2, 3]
        ...
        def blob := BlobMaker(list)
        Mallet hello(blob)
        ... blob ...
    }

BlobMaker is written to rely on its argument, list, and therefore the 
author of BlobMaker is assuming that BlobMaker will only be called by code 
not attempting to subvert it.  Ie, BlobMaker is delicate -- it is written to 
rely on its callers.

The Blobs it makes are supposed to be robust -- a Blob's correctness 
should not be vulnerable to misbehavior by its callers.  Above we see 
mutually cooperative Alice and BlobMaker.  The blob handed to Mallet is also 
used by Alice, and must be incorruptible by Mallet.  So far so good.

One day a maintenance programmer changes Alice so that the 'list' passed to 
BlobMaker is mutable.  If an unmutated mutable list responds to the set of 
messages actually being used just as an immutable list would, everything, 
including Mallet, continues to work perfectly the next day, and so the bug 
isn't easily caught.  However, Mallet's been accidentally given the 
opportunity to corrupt the blob.

If you think it becomes relevant, feel free to forward or quote to the list.


        Cheers,
        --MarkM