On 11-03-15 02:17 PM, Rafael Avila de Espindola wrote:
Anyway, that's a summary of how I saw the conversation unfold; correct
anything you see as wrong in this summary. It got a little heated and I
don't want to misrepresent anyone's opinion.
I think you just missed one of the points why I wanted to introduce a
cycle. The structure is semantically cyclic. We just represent one of
the edges with "these two integers are the same". Having a real pointer
makes it easier to understand.
Yeah, I gather that. And you're totally right, a pointer would, in the
context you're discussing, be easier to understand. It'd just shift a
lot of cost elsewhere, a hit I'm not comfortable taking just now.
This also got to the question of how to control what can mutate a data
structure. In clang (which is written is C++ and compiles C++), it is
really important that random parts of the FE don't mutate the AST since
changes to it can invalidate things like C++'s crazy name lookup rules.
To have that and at the same time allow for cycles, the AST is a friend
of the parts that construct it. Which is ugly, but does allow them to be
sure about which parts of the code can mutate the AST.
Yeah. Some freeze/thaw logic ought to be able to play in similar fields
as that. I hope.
Sorry for bringing even harder questions,
Oh, no need to apologize; the harder questions were the more interesting
ones! ("how do we get cyclic immutables", say; I really hope the
const-blob-with-a-refcounted-root idea works!)
but this also got me thinking
about one of the nice features of C/C++: the ability to represent not
only cycles, but arbitrary memory layout. Is there a plan to implement
something similar in rust?
Arbitrary is such an arbitrary word :)
I'm not sure how to answer it in general. "Represent" in what sense? A
pointer is just a number. Since we permit a modest amount of fiddling
around with raw pointers from C-land as numbers, I imagine you have
something more explicit in mind.
I am sure this is not safe in general, but it would be sad to have to go
back to C/C++ for any unsafe operation.
My general sense is that a small number of C/C++ operations + a majority
of connective code in rust manipulating opaque native pointers (possibly
through resources and tags that wrap them) is the best we can do. Or at
least the best we can do without totally blowing the cognitive budget of
the language (no typed assembly language and memory regions, thanks).
An example that is probably closer to the issues we will have after
bootstrap: can rust's garbage collector be written in rust?
Yeah, but it'll involve a number of unsafe calls. I figure with a few
unsafe primitives, the rest is mostly feasible in rust.
I wrote the one in rustboot in asm (actually in the mutant IL/x86
pseudo-asm) but that was mostly for expedience; didn't have to teach
trans to look through itself. It's actually not a very big algorithm.
You mark and you sweep. Mostly through lists. The whole thing runs on a
task's own stack so there's no need to play sneaky scheduling games.
-Graydon
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
