[rust-dev] Rust Meetup02 Paris !
Hello Remember for the 02 meetup in Paris! When: 31 March 2014 19:00 - 22h Reps page: https://reps.mozilla.org/e/meetup-rust-paris-02/ (Mozillians put your name here!) Pad: https://etherpad.mozilla.org/remo-meetup-rust-paris-02 (Register on it ;)) Reddit: http://www.reddit.com/r/rust/comments/20tx96/meetup_rust_paris_02/ Github: https://github.com/Rust-Meetup-Paris https://reps.mozilla.org/e/meetup-rust-paris-02/ ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Help needed writing idiomatic rust to pass sequences of strings around
Thanks Huon, that really cleared things up for me.
Dum question: What's the reason for str being a special fat pointer as a
language feature rather than just a vanilla struct? E.g. struct StrSliceT
{start: T, length: uint}
(I suppose this question also applies to [T])
On Mon, Mar 24, 2014 at 8:06 AM, Huon Wilson dbau...@gmail.com wrote:
It would be necessary (but not sufficient*) for them to have the same
in-memory representation, and currently ~str and str don't.
~str is `*{ length: uint, capacity: uint, data... }`, a pointer to a
vector with the length and capacity stored inline, i.e. one word; str is
just `{ data: *u8, length: uint }`, a pointer to a chunk of memory along
with the length of that chunk, i.e. two words.
(*E.g. std::cell::Celluint and uint have the same in-memory
representation, but coercing a [uint] to a [Celluint] is a very bad
idea... when it would theoretically be possible relates to subtyping/type
variance.)
Huon
On 24/03/14 17:36, Phil Dawes wrote:
To complete my understanding: is there a reason a 'sufficiently smart
compiler' in the future couldn't do this conversion implicitly?
I.e. if a function takes a borrowed reference to a container of
pointers, could the compiler ignore what type of pointers they are (because
they won't be going out of scope)?
Thanks,
Phil
On Sun, Mar 23, 2014 at 7:14 AM, Patrick Walton pcwal...@mozilla.comwrote:
On 3/23/14 12:11 AM, Phil Dawes wrote:
On Sun, Mar 23, 2014 at 2:04 AM, Patrick Walton pcwal...@mozilla.com
mailto:pcwal...@mozilla.com wrote:
Why not change the signature of `search_crate` to take `~str`?
Patrick
Hi Patrick,
The main reason I haven't done this is that it is already used from a
bunch of places where a path is [str] as the result of an earlier
split_str(::)
e.g.
let path : ~[str] = s.split_str(::).collect();
...
search_crate(path);
Ah, I see. Well, in that case you can make a trait (say, `String`), which
implements a method `.as_str()` that returns an `str`, and have that trait
implemented by both `str` and `~str`. (IIRC the standard library may have
such a trait already, for `Path`?)
You can then write:
fn search_crateT:String(x: [T]) {
...
for string in x.iter() {
... string.as_str() ...
}
}
And the function will be callable with both `str` and `~str`. Again, I
think the standard library has such a trait implemented already, for this
use case.
Patrick
___
Rust-dev mailing
listRust-dev@mozilla.orghttps://mail.mozilla.org/listinfo/rust-dev
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Help needed writing idiomatic rust to pass sequences of strings around
Oops, I sent that before I finished editing it. I meant struct StrSlice
{start: u8, length: uint}
On Tue, Mar 25, 2014 at 4:33 PM, Phil Dawes rustp...@phildawes.net wrote:
Thanks Huon, that really cleared things up for me.
Dum question: What's the reason for str being a special fat pointer as a
language feature rather than just a vanilla struct? E.g. struct StrSliceT
{start: T, length: uint}
(I suppose this question also applies to [T])
On Mon, Mar 24, 2014 at 8:06 AM, Huon Wilson dbau...@gmail.com wrote:
It would be necessary (but not sufficient*) for them to have the same
in-memory representation, and currently ~str and str don't.
~str is `*{ length: uint, capacity: uint, data... }`, a pointer to a
vector with the length and capacity stored inline, i.e. one word; str is
just `{ data: *u8, length: uint }`, a pointer to a chunk of memory along
with the length of that chunk, i.e. two words.
(*E.g. std::cell::Celluint and uint have the same in-memory
representation, but coercing a [uint] to a [Celluint] is a very bad
idea... when it would theoretically be possible relates to subtyping/type
variance.)
Huon
On 24/03/14 17:36, Phil Dawes wrote:
To complete my understanding: is there a reason a 'sufficiently smart
compiler' in the future couldn't do this conversion implicitly?
I.e. if a function takes a borrowed reference to a container of
pointers, could the compiler ignore what type of pointers they are (because
they won't be going out of scope)?
Thanks,
Phil
On Sun, Mar 23, 2014 at 7:14 AM, Patrick Walton pcwal...@mozilla.comwrote:
On 3/23/14 12:11 AM, Phil Dawes wrote:
On Sun, Mar 23, 2014 at 2:04 AM, Patrick Walton pcwal...@mozilla.com
mailto:pcwal...@mozilla.com wrote:
Why not change the signature of `search_crate` to take `~str`?
Patrick
Hi Patrick,
The main reason I haven't done this is that it is already used from a
bunch of places where a path is [str] as the result of an earlier
split_str(::)
e.g.
let path : ~[str] = s.split_str(::).collect();
...
search_crate(path);
Ah, I see. Well, in that case you can make a trait (say, `String`),
which implements a method `.as_str()` that returns an `str`, and have that
trait implemented by both `str` and `~str`. (IIRC the standard library may
have such a trait already, for `Path`?)
You can then write:
fn search_crateT:String(x: [T]) {
...
for string in x.iter() {
... string.as_str() ...
}
}
And the function will be callable with both `str` and `~str`. Again, I
think the standard library has such a trait implemented already, for this
use case.
Patrick
___
Rust-dev mailing
listRust-dev@mozilla.orghttps://mail.mozilla.org/listinfo/rust-dev
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Bounds on type variables in structs, enums, types
On 3/24/14 11:46 PM, Nick Cameron wrote:
Currently we forbid bounds on type parameters in structs, enums, and
types. So the following is illegal:
struct SX: B {
f: ~TX,
}
IIRC Haskell allows bounds on type parameters (and we did once too), but
I heard that considered deprecated and not preferred. I don't recall the
exact reasons, but that's why we removed the feature (and also just for
language simplicity).
Patrick
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Bounds on type variables in structs, enums, types
On Tue, Mar 25, 2014 at 6:00 PM, Patrick Walton pcwal...@mozilla.comwrote:
On 3/24/14 11:46 PM, Nick Cameron wrote:
Currently we forbid bounds on type parameters in structs, enums, and
types. So the following is illegal:
struct SX: B {
f: ~TX,
}
IIRC Haskell allows bounds on type parameters (and we did once too), but I
heard that considered deprecated and not preferred. I don't recall the
exact reasons, but that's why we removed the feature (and also just for
language simplicity).
Patrick
If I remember the reason cited in Haskell design it was that some functions
require more bounds than others.
For example a HashMap generally requires that the key be hashable somehow,
but the isEmpty or size functions on a HashMap have no such requirement.
Therefore, you would end up with a minimal bounds precised at Type level,
and then each function could add some more bounds depending on their needs:
that's 2 places to specify bounds. In the name of simplicity (and maximum
reusability of types) Haskell therefore advise to only use bounds on
functions.
However, I seem to remember than in Haskell the bounds are only Traits;
whereas in Rust some bounds may actually be required to be able to
instantiate the type (Sized ?).
-- Matthieu
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Vector length specified by enum
Would a macro address this situation? -- Ziad On Mon, Mar 24, 2014 at 5:12 PM, comex com...@gmail.com wrote: On Mon, Mar 24, 2014 at 7:32 PM, Richo Healey ri...@psych0tik.net wrote: let vec: [u8, .. FooBar::size()]; Potentially with parens ommittted, to convey that there's no runtime computation? Not sure if it matters, but another thing one might want to use in a constant expression is sizeof, which wouldn't necessarily be amenable to a similar approach. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Vector length specified by enum
I think so. https://github.com/mozilla/rust/blob/master/src/librustc/middle/lang_items.rsemployes such a trick. -Ed On Wed, Mar 26, 2014 at 3:42 AM, Ziad Hatahet hata...@gmail.com wrote: Would a macro address this situation? -- Ziad On Mon, Mar 24, 2014 at 5:12 PM, comex com...@gmail.com wrote: On Mon, Mar 24, 2014 at 7:32 PM, Richo Healey ri...@psych0tik.net wrote: let vec: [u8, .. FooBar::size()]; Potentially with parens ommittted, to convey that there's no runtime computation? Not sure if it matters, but another thing one might want to use in a constant expression is sizeof, which wouldn't necessarily be amenable to a similar approach. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Bounds on type variables in structs, enums, types
Thanks for the info! Sized will be going away very soon, but it will be
replaced by 'unsized' (or something with the same semantics), so we have
exactly the same question.
I don't understand the HashMap example (I'm thinking in Rust terms, and
perhaps you meant it to be a Haskell example, I'm not sure). But if we have
a HashMapT struct, I would expect T to be hashable - I can't construct a
HashMapT if it is not, so there is nothing to call is_empty or size on. I
suppose you could allow empty HashMaps of such types, but that seems
unnecessary.
Cheers, Nick
On Wed, Mar 26, 2014 at 6:32 AM, Matthieu Monrocq
matthieu.monr...@gmail.com wrote:
On Tue, Mar 25, 2014 at 6:00 PM, Patrick Walton pcwal...@mozilla.comwrote:
On 3/24/14 11:46 PM, Nick Cameron wrote:
Currently we forbid bounds on type parameters in structs, enums, and
types. So the following is illegal:
struct SX: B {
f: ~TX,
}
IIRC Haskell allows bounds on type parameters (and we did once too), but
I heard that considered deprecated and not preferred. I don't recall the
exact reasons, but that's why we removed the feature (and also just for
language simplicity).
Patrick
If I remember the reason cited in Haskell design it was that some
functions require more bounds than others.
For example a HashMap generally requires that the key be hashable somehow,
but the isEmpty or size functions on a HashMap have no such requirement.
Therefore, you would end up with a minimal bounds precised at Type
level, and then each function could add some more bounds depending on their
needs: that's 2 places to specify bounds. In the name of simplicity (and
maximum reusability of types) Haskell therefore advise to only use bounds
on functions.
However, I seem to remember than in Haskell the bounds are only Traits;
whereas in Rust some bounds may actually be required to be able to
instantiate the type (Sized ?).
-- Matthieu
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Bounds on type variables in structs, enums, types
The removal was in https://github.com/mozilla/rust/pull/4660, but there is
no discussion of why. Do you recall who promoted the change?
I fear it makes the syntax simpler, but the language more complex and
surprising.
On Wed, Mar 26, 2014 at 6:00 AM, Patrick Walton pcwal...@mozilla.comwrote:
On 3/24/14 11:46 PM, Nick Cameron wrote:
Currently we forbid bounds on type parameters in structs, enums, and
types. So the following is illegal:
struct SX: B {
f: ~TX,
}
IIRC Haskell allows bounds on type parameters (and we did once too), but I
heard that considered deprecated and not preferred. I don't recall the
exact reasons, but that's why we removed the feature (and also just for
language simplicity).
Patrick
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
