Thanks, this all makes a lot of sense. I think I will go try and play
with a few example programs using unique types to get a sense for how
those work before I ask any more questions in that direction.
Niko
Graydon Hoare wrote:
On 25/08/2011 5:30 AM, Niko Matsakis wrote:
I don't quite follow the distinctions here. How do I notate a vector
with uniquely-owned components? "vec[~T]" vs "vec[@T]"? Also, what is
the distinction between a "vec" and an "ivec"?
An 'ivec' is just an informal name we have been using during the
gradual conversion of vectors from default-shared to default-unique.
When complete -- and I think it's most useful to speak of what we're
aiming for, rather than the in-transition current state of affairs --
the idea is that [] will be a unique type constructor (a pointer that
uniquely owns a storage vector in the heap) and if you want to make a
shared version, you apply a shared-box to it, like @[].
The notations vec[T] for types and vec(a,b,c) for values have been
replaced, I believe, entirely with the more uniform and shorter
notations [T] for types and [a,b,c] for values.
The components of a vector are *components*, not the vector itself.
When you place shared components in the vector, the vector remains
uniquely owned, but the components may point to shared values. This
makes the *kind* of the vector-of-shared things "shared", despite the
vector type constructor being a unique type constructor. If you keep
all the components (and components-of-components, all the way down)
unique, then the kind of the vector is "unique", and it can be
transmitted over channels or such. If there's any sharing in any
substructure of a type, it is of "shared" kind.
In other words: individual type constructors may be unique or shared
(really only @ is shared) but *kind* judgments are recursive, defined
for a full type expression (and all its subexpressions), not just a
single term in it.
* A box type like @T is an instance of type T that lives in the heap.
The value in the box is immutable. To make it mutable, you do
@mutable T.
Correct. More specifically @T is a *shared* boxed T. It has a refcount
and/or a word of GC header, such that multiple @T variables can point
to the same shared heap allocation.
We are also in the process of implementing a *unique* box type ~T
where there is always exactly one ~T variable pointing to the heap
allocation.
What will be the syntax for working with this unique box type?
Prefix ~ for a unique box, rather than @ for a shared box.
The constructor is the same for type terms, expression terms and
pattern terms. That is, ~int is the type ~10, say, and will match with
a pattern ~p.
This more-or-less corresponds to what I expected. However, it's not
quite what I observed. For example:
if @[1,2,3] == (@[1,2] + @[3]) {
stdout.write_line("TRUE");
}
prints "TRUE". I guess the pointers could be equal but it would be a bit
surprising to me.
Yeah. That's probably a bug.
So this clearly gets into the alias analysis discussion that I saw
earlier (and didn't fully follow, as I hadn't experimented much with
Rust yet). In other words, changes to a mutable alias argument, may
affect the other alias parameters, possibly freeing interior values and
so forth. Is there a summary of the current alias rules (intended or
implemented, as the case may be)?
I haven't written one up, no. Nor am I able to, as Marijn is largely
in charge of that feature, and possibly the only one who has the rules
fresh enough in his mind to elaborate them. He promises a section on
this in the manual :)
Hth, sorry for the slow reply again. You ask good questions, that
require a little free time to answer precisely!
-Graydon
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
