On 12/23/12 4:25 PM, Michael Neumann wrote:
What is the big advantage of having a tracing GC over ref counting?
With GC we'd get rid of the extra indirection and extra operations
during aliasing, so it's basically a performance issue, right?
Yes, and we might also be able to allow temporary parallel access to
GC'd data for pure functions only. If we can root the data in one task
then we can potentially temporarily operate on @ data in parallel.
Unfortunately that's hard to do for reference counted data, because our
reference counts are not thread-safe for performance reasons.
Actually I was thinking of sth like in Ruby:
Array.new(size=10) {|i| i % 2}
gives:
[0, 1, 0, 1, 0, 1, 0, 1...]
Use `vec::from_fn`. For example:
rusti> do vec::from_fn(10) |i| { i % 2 }
~[0, 1, 0, 1, 0, 1, 0, 1, 0, 1]
Is this an issue the LLVM developers are working on?
It's more of a Rust-specific thing. `rustc` should be providing more
hints to LLVM so that it does the right thing. I think that, to a first
approximation, any higher-order function in Rust would benefit from
`always_inline` or at least `inlinehint`.
LLVM's built-in inlining heuristics are more tuned to C++; I don't think
that's likely to change, given upstream LLVM's goals. Maybe if C++11
uses more higher-order functions. In any case, this should be something
fixable in `rustc` itself; I don't think LLVM will need to change much
if any.
Yes, I think sth with copy in the name would be less surprising. Ok,
unwrap makes sense. Or maybe get() and get_copy()?
Yeah, `get_copy` sounds reasonable to me.
So a "const" function (in terms of C++ ;-) would always take a &str
pointer? Makes absolute sense to me.
Yes. You can temporarily "borrow" a ~str as immutable.
Ideally there would be an operator, as writing .append() all the time is
quite tedious.
I think `+=` will have this signature:
trait AddAssign<Rhs,Result> {
fn add_assign(&mut self, other: &Rhs) -> Result;
}
Which would allow += to work as you suggest.
Hm, this is interesting. Is there somewhere a simple example how to use
#[auto_encode] and what my msgpack library needs to implement to work
with it?
Unfortunately I'm not an expert on `auto_encode`. Erick Tryzelaar, Brian
Anderson, or Graydon may know better.
I see. So it would be possible to write a syntax extension called for
example iter_fields!(struct_Type) which could be used to generate i.e.
custom serializers. But that would be probably similar to #auto_encode,
just that it could be more user-defined.
Well, you'd need to write it on the struct definition, so that it has
access to the struct contents (as syntax extensions run before
typechecking).
Actually, #[auto_encode] is a syntax extension itself, as some syntax
extensions can be written using #[] "attribute" notation. This should
eventually extend to user-defined syntax extensions as well.
Patrick
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
