On Wed, Nov 3, 2010 at 7:03 PM, Ben Kloosterman <[email protected]> wrote:

>  My 2c
>
>
>
> Agree vectors should not be a  primitive type..they are just a collection
> which may use an underlying array ( or even linked list) , speaking of which
> do we support  user defined index like properties  on structs /objects  ?
>

Other collections should be indexable, and it should be possible to
construct nat-indexable collections that do not use arrays as their
implementation. But "vector as reference to array whose size is not part of
its type" is still a very useful concept.

What you call user-defined indexing is what I have previously called
generalized accessors. In brief, it's the mechanism that lets you build an
accessor that returns what in C we would call an L-value. It's not in yet,
because it requires some type system changes that I don't want to do in a
throw-away implementation. It's coming.


>   And yes mutability  here is meaningless.
>

I'll come back to this - I haven't yet seen other responses.


>   >One other point while I'm stirring the pot here: a non-mutable vector
> is an example of a mutability constraint that is neither fully shallow nor
> fully transitive. The elements may be immutable, but they may be references
> to objects that *are* in turn mutable. This takes us head on into
> challenging territory that we have visited (unsatisfactorily) before: how to
> state the scope (coverage?) of contract in an object graph? Alternatively,
> how to capture the relationship between the programmer notion of "object" as
> a coherent functional unit, and the runtime notion of object as a collection
> of primitive data structures.
>
>
>
> Has anyone solved this  it comes up time and time again even in programming
> ?  Basically if any part of the structure is mutable than the whole
> structure is mutable.    The only way I know is to ensure immutability is to
> use types or wrappers of types that are immutable
>

This needs a longer discussion, which I'll kick off in a moment.
_______________________________________________
bitc-dev mailing list
[email protected]
http://www.coyotos.org/mailman/listinfo/bitc-dev

Reply via email to