[e-lang] using @inert with collection APIs

Kevin Reid kpreid at mac.com
Fri Sep 26 19:33:01 CDT 2008


On Sep 26, 2008, at 18:10, Tyler Close wrote:
> On Fri, Sep 26, 2008 at 2:47 PM, Kevin Reid <kpreid at mac.com> wrote:
>> On Sep 24, 2008, at 16:45, Tyler Close wrote:
>>> 1. We were unable to use the standard iteration API, since it uses a
>>> mutable iterator object. So the following code would generate a
>>> verifier error:
>>>
>>>   Iterator<SomeMutable> i = someKeys.iterator();    // cannot hold
>>> return value in non- at inert variable
>>>
>>> and so would:
>>>
>>>   @inert Iterator<SomeMutable> i = someKeys.iterator();
>>>   i.next();    // cannot call non- at inert method on @inert reference.
>>
>> It seems to me that what you want to express here is
>>
>>  Iterator<@inert SomeMutable> i = someKeys.iterator();
>
> That's interesting, but not quite what is needed. We need to know that
> the iterator itself won't mutate the values in the map, not just that
> it won't let the caller mutate the returned values. For example, what
> if the Iterator.next() implementation was:
>
> T next() {
>    this.underlyingMap.get(0).sneakyModification();
>    T r = ...  // get next value.
>    return r;
> }

So let's say that you can only use the above declaration if the  
iterator class is audited to not do this -- i.e. to treat its  
parameter as inert, whether or not the caller does.

>> Whether something equivalent to this is possible in Java I don't  
>> know.
>
> Unfortunately, the syntax also doesn't support this expression.

How about something like @inert-in-type-parameter(0)  
Iterator<SomeMutable>?

-- 
Kevin Reid                            <http://homepage.mac.com/kpreid/>




More information about the e-lang mailing list