Re: [rust-dev] In favor of types of unknown size
I must say I prefer Graydon's syntax. `[]T` sets off all kinds of alarms in my head. I have no strong opinion on dynamically-sized types. Not having them is definitely a win in terms of compiler complexity, but yes, some of the things that they make possible are nice to have. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] In favor of types of unknown size
On Sat, Apr 28, 2012 at 8:12 AM, Marijn Haverbeke mari...@gmail.com wrote: I must say I prefer Graydon's syntax. `[]T` sets off all kinds of alarms in my head. I have no strong opinion on dynamically-sized types. Not having them is definitely a win in terms of compiler complexity, but yes, some of the things that they make possible are nice to have. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev Hello Niko, First I really appreciate you thinking hard about it and if you don't want to bother the list I would certainly not mind talking it out with you in private; I feel it's very important for these things to be thought through extensively and I really like that decisions in Rust are always considered carefully and objectively. That being said, I have two remarks: I would like to ask a question on the vectors syntax: why the focus on [] ? I understand it in the literal form, however a string type is denoted as `str` so why not denote a vector of Ts as `vecT` ? Yes, it's slightly more verbose, but this is how all the other generic types will be expressed anyway. Similarly, since a substring is expressed as `substr`, one could simply express a slice as `sliceT` or `svecT` or even `array_refT`. I don't think being overly clever with the syntax type will really help the users. Imagine grepping for all uses of the slice type in a crate ? It's so much simpler with an alphabetic name. (Also, `[:]/r T` feel *really* weird, look at the mess C is with its pointer to function syntax that let's you specify the name in the *middle* of the type...) As for types of unknown sizes, I would like to point out that prevent users from having plain `str` attributes in their records is kinda weird. The pointer syntax is not only more verbose, it also means that suddenly getting a local *copy* of the string gets more difficult. Sure it's equivalent (semantically) to a unique pointer `~str`, but it does not make copying easier, while it's one of the primary operations in impure languages (because the original may easily get modified at a later point in time). I think that `rust_vecT` having an unknown size rather than being (in effect) a pointer to a heap allocated structure is nice from an implementation point of view, but it should not get in the way of using it. I would therefore venture that either it has an unknown size and the compiler just extend this unknown size property to all types so they can have `vecT` and `str` attributes naturally, or it's better for it *not* to have an unknown size. I would also like to point out that if it's an implementation detail, the actual representation might vary from known size to unknown size without impact for the user, so starting without for the moment because it's easier and refining it later is an option. Another option is to have a fixed size with an alternative representation using something similar to SSO (Short String Optimization); that is small vectors/strings allocate their storage in place while larger ones push their storage to the heap to avoid trashing the stack. Hope this does not look harsh, I sometimes have difficulties expressing my opinions without being seen as patronizing: I can assure you I probably know less than you do :) -- Matthieu ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] In favor of types of unknown size
On 04/28/2012 03:17 AM, Matthieu Monrocq wrote: I would also like to point out that if it's an implementation detail, the actual representation might vary from known size to unknown size without impact for the user, so starting without for the moment because it's easier and refining it later is an option. Another option is to have a fixed size with an alternative representation using something similar to SSO (Short String Optimization); that is small vectors/strings allocate their storage in place while larger ones push their storage to the heap to avoid trashing the stack. We tried this once. It was a disaster in terms of code size; you really don't want all strings and vectors doing this. Patrick ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] iter library
On Apr 27, 2012, at 11:03 PM, Marijn Haverbeke mari...@gmail.com wrote:
What Joe meant is that you could simply write multiple impls on the
same type with different names for the various modes of iteration.
impl of iter for maptype { ... }
impl iter_keys of iter for maptype { ... }
impl iter_vals of iter for maptype { ... }
You could then do 'import map::iter_keys;` at the top of a block to
force the key-iterating impl to take precedence there.
I think the ergonomics of this kind of trick didn't work out as well
as hoped, though. You'd get multiple applicable impl errors when
importing `map::*`, and seeing which impl is currently closest in a
scope is somewhat indirect and confusing.
That is indeed what I was going for, but I suggested it thinking it
was possible to instantiate a named impl explicitly when multiple
impls are in scope. If that's not the case then wrapper types make
sense, but this looks like a prime use case of named impls to me. Are
there problems with allowing impls to be used as a constructor or
cast, to allow for example `iter_keys(map).each` or
`map.(iter_keys).each` to just work given an impl iter_keys?
-Joe
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] In favor of types of unknown size
I'd honestly be ok with going back to vecT or vecmut T for the vector type and using [T] for the slice, to discourage this hazard. I think this could be a win for clarity. There are enough potential use cases here that overloading [] doesn't seem to give all that much benefit. On Sat, Apr 28, 2012 at 6:53 AM, Patrick Walton pwal...@mozilla.com wrote: On 04/27/2012 03:15 PM, Niko Matsakis wrote: Hi, This is a post I recently put on my blog. I thought I'd post it to the mailing list as it pertains to our recent discussion on the syntax of vectors, slices, and so forth. I feel like I'm harping on this issue so I think it's the last thing I will write about it for a while. =) I like the idea of eliminating [T]/@ in favor of @[T]; it simplifies the user-facing syntax and semantics a lot. On the other hand, I agree with Marijn that []T doesn't look as nice as [T] (although Go is popularizing the former). [:]T is also strange-looking. There's also the issue that users might use []T, which is almost never useful, instead of the more-useful [:]T. I'd honestly be ok with going back to vecT or vecmut T for the vector type and using [T] for the slice, to discourage this hazard. Patrick __**_ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/**listinfo/rust-devhttps://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] In favor of types of unknown size
The main thing I was trying to argue for is not a specific syntax but rather the idea that a leading @, ~, or sigil indicates the kind of pointer, and what comes after indicates the data that is being pointed at. The orthogonality appeals to me; it seems to make the language fit together more neatly. As far as pure visual aesthetics, I think what I prefer most is `[T]` for slices and `vecT` for vectors. I proposed this previously but amended it because we would need to support types like `vecmut int`, which are different from ordinary type parameters that do not permit a `mut` qualifier. Since type names are no longer keywords, this is somewhat awkward to do, though of course we could manage it (either by making `vec` a keyword or by allow `mut T` as an alternate type parameter syntax that can only be used with vectors). Niko On 4/27/12 11:12 PM, Marijn Haverbeke wrote: I must say I prefer Graydon's syntax. `[]T` sets off all kinds of alarms in my head. I have no strong opinion on dynamically-sized types. Not having them is definitely a win in terms of compiler complexity, but yes, some of the things that they make possible are nice to have. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] In favor of types of unknown size
On Fri, Apr 27, 2012 at 3:15 PM, Niko Matsakis n...@alum.mit.edu wrote: The types `[]T` and `str` would represent vectors and strings, respectively. These types have the C representation `rust_vecT` and `rust_vecchar`. They are of *dynamic size*, meaning that their size depends on their length. The literal form for vectors and strings are `[a, b, c]` and `foo`, just as normal. Back when I was entertaining the idea of writing my own rust-like language (before I was aware of rust's existence), I had the idea that all records/objects cold have dynamic size if any of their members had dynamic size (and the root cause of dynamic size would be fixed-size arrays - fixed at the time of construction, not a static constant size). This is only slightly related, but it's too close that I can't resist presenting gist of it (it's not completely worked out), in case anyone else wants to figure it out and see if it makes sense :-) Basically the idea spawned from the attempt of trying to avoid pointers as much as possible. Keep things packed, with chunky objects, reduce the complexity for GC/RC, reduce memory fragmentation, etc.. Aside from actual honest-to-goodness graphs (which fairly rare, and most are small, and unavoidable anyway). The conjecture is that the main source of pointers are arrays. Okay, so basically the idea is that arrays are length-prefixed blocks of elements. They're statically sized (can't be expanded), but you can pass in a dynamic, non-constant value when you construct them. Unlike C/C++ though these arrays can still live *inside* an object. There's some fiddlyness here.. e.g.. do you put all arrays (except ones which true const sizes?) at the end of the object so other members have a constant offset? If you have more than a small number of arrays in an object it probably makes to have a few pointers indicating the start of each instead of having to add up the sizes of preceeding arrays each time an access is made to one of the later arrays. So, during Construction of an object, you'd have to proceed in two phases. First is the constructor logic where you compute values, and the second is the allocation of the object and moving the values into it. You need to hold off on allocation because you don't know the size of any member objects until you've constructed them. Moving an array is now expensive, since it requires a copy, not just a pointer move. So ideally the compiler would try to move the allocation to happen as early as possible so most of the values can be written directly to its final location instead of having to be constructed on the stack (or heap) and then moved. There are of course cases where this couldn't be done. E.g. if the size of an array X, depends on some computation done on array Y in the same object - you have to create Y on the stack, or heap, to run the computation before you can know the total size of the object, and only then can you allocate the final object and copy the arrays into it. I'm not 100% sold on the idea, since it does make things a bit more complex, but it is pretty appealing to me that you can allocate dynamic-but-fixed sized arrays on the stack, inside other objects etc.. For a language that emphasizes immutable data structures I'd imagine the opportunity to use these fixed arrays in-place would be extremely frequent. Seb -- Sebastian Sylvan ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
