Re: [rust-dev] Please simplify the syntax for Great Justice
On 11/20/2013 04:03 AM, Val Markovic wrote: Fair point. I give you guys a lot of credit though, Rust is a wonderful language in general. I also admire how willing core Rust devs are to admit ok that was a bad idea, let's try something else. I don't see that every day; Rust is better for it. Please continue being awesome. Agree. Thank you all very much for this effort, and for making it public good. Denis ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Please simplify the syntax for Great Justice
On Tue, Nov 19, 2013 at 5:17 AM, Patrick Walton pcwal...@mozilla.com wrote: I've observed a lot of beginning Rust programmers treat the language as add sigils until it works. (I have specific examples but don't want to name people here; however, feel free to contact me privately if you're curious.) I feel like I have to out myself as one of the idiot newcomers that do this, just for the sake of the discussion. I have no systems language background and frankly never had to consider the difference between the heap or the stack in the past 10-some years of writing code. I don't really think having new vs ~ would help me avoid this problem. The issue I believe is that the language looks understandable enough for the average joe used to higher level web languages (php, python, ruby). That's a great thing of course, that I can just jump in and mostly grasp what's going on, while past attempts at C++ tinkering quickly ended in tears. It also means that you have lots of people that come in and are capable of getting stuff to compile but won't necessarily understand the small print. Often there is an alternative to pooping sigils all over the code, but if you don't understand the concepts behind it it's hard to reason about what those alternatives could be. I think I'm getting better with this over time, and the rust libraries also get more usable and consistent leading to less ~ insanity, but one thing that would have helped early on is a good warning in the docs about this, and a good explanation of what the hell is going on (not one geared towards C++ devs using lingo that only low level devs are familiar with). I realize it's no easy task, and that arguably I should probably just read a book, but at the same time it's an amazing feat I think that the language is so accessible while remaining at such a low level, so if we manage to improve the onboarding process it would probably be very beneficial. There are tons of web devs that are interested in doing things faster/lower level - if only for fun. Maybe it's worth having a chapter for them in the docs. I'd happily help review that and point out unclear things :) Cheers -- Jordi Boggiano @seldaek - http://nelm.io/jordi ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Please simplify the syntax for Great Justice
Is there any specific issue with the current tutorial section on boxes? It mentions every case where owned boxes are useful. http://static.rust-lang.org/doc/master/tutorial.html#boxes I keep hearing that it should be better, but have yet to see any hints on where it falls short. It's not going to change if no one can point out where it confuses them. I do want to rewrite it in a less boring style by having it be an introduction to these concepts by implementing a linked list, but I won't be changing the *content* (at least of Boxes). ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Please simplify the syntax for Great Justice
I don't think there is any particular issue with the tutorial, but we need more recipes on how to handle typical situations. - Gaetan 2013/11/19 Daniel Micay danielmi...@gmail.com Is there any specific issue with the current tutorial section on boxes? It mentions every case where owned boxes are useful. http://static.rust-lang.org/doc/master/tutorial.html#boxes I keep hearing that it should be better, but have yet to see any hints on where it falls short. It's not going to change if no one can point out where it confuses them. I do want to rewrite it in a less boring style by having it be an introduction to these concepts by implementing a linked list, but I won't be changing the *content* (at least of Boxes). ___ 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] Please simplify the syntax for Great Justice
In the french presentation for rust 0.8 [1], the author gives the analogy with C++ semantics - ~ is a bit like unique_ptr - @ is an enhanced shared_ptrT - borrowed pointer works like C++ reference and I think it was very helpful to better understand them. I don't know if it is true or now, but this comparison helps a lot understanding the concepts.You can present them like this, and after, add more precision, and difference with the C++ counter parts. A tutorial to make would be Rust for C++ programmer :) [1] http://linuxfr.org/news/presentation-de-rust-0-8 - Gaetan 2013/11/19 Daniel Micay danielmi...@gmail.com On Tue, Nov 19, 2013 at 4:25 AM, Gaetan gae...@xeberon.net wrote: I don't think there is any particular issue with the tutorial, but we need more recipes on how to handle typical situations. I'm specifically talking about the `Boxes` section in the tutorial and not the whole picture. I keep hearing that the coverage of `~` it's confusing - so can someone elaborate? Rewriting the coverage of boxes and references by walking through the implementation of some data structures is something I'm willing to do, but in my opinion that section is now quite good, other than being dry and not presenting interesting code samples for the use cases it describes. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Please simplify the syntax for Great Justice
On 19/11/13 20:51, Gaetan wrote: In the french presentation for rust 0.8 [1], the author gives the analogy with C++ semantics - ~ is a bit like unique_ptr - @ is an enhanced shared_ptrT - borrowed pointer works like C++ reference and I think it was very helpful to better understand them. I don't know if it is true or now, but this comparison helps a lot understanding the concepts.You can present them like this, and after, add more precision, and difference with the C++ counter parts. A tutorial to make would be Rust for C++ programmer :) Something like that already exists: https://github.com/mozilla/rust/wiki/Rust-for-CXX-programmers Huon ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Please simplify the syntax for Great Justice
On Tue, Nov 19, 2013 at 4:51 AM, Gaetan gae...@xeberon.net wrote: In the french presentation for rust 0.8 [1], the author gives the analogy with C++ semantics - ~ is a bit like unique_ptr - @ is an enhanced shared_ptrT - borrowed pointer works like C++ reference and I think it was very helpful to better understand them. I don't know if it is true or now, but this comparison helps a lot understanding the concepts.You can present them like this, and after, add more precision, and difference with the C++ counter parts. A tutorial to make would be Rust for C++ programmer :) [1] http://linuxfr.org/news/presentation-de-rust-0-8 - Gaetan I wrote a reference for C++ programmers on the wiki some time ago. Rust is very easy to approach as if you have a solid grasp of C++11 so I don't think it's an important area to work on. A C++ programmer already has a thorough understanding of the ownership/lifetime concepts in Rust and the trait system will be familiar because C++ has type traits + enable_if and implicit type concepts that aren't formalized in the language yet. https://github.com/mozilla/rust/wiki/Rust-for-CXX-programmers ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Please simplify the syntax for Great Justice
In case this helps, I recently noticed that the sigils correspond to possessive pronouns: '~' = my, '' = their, '@' = our Of course, `@` might be going away, but `Rc`, `Gc`, and so forth all (will) have the same intuitive content, only different representations (among other properties). Similarly `~Foo` and plain `Foo` both mean my, while having differences in other areas, in which case yeah, telling you that `Foo` is stored in-place while `~Foo` is stored on the heap doesn't help you if you don't know what heap allocation is about. But maybe this is something. On Tue, Nov 19, 2013 at 10:12 AM, Jordi Boggiano j.boggi...@seld.be wrote: On Tue, Nov 19, 2013 at 5:17 AM, Patrick Walton pcwal...@mozilla.com wrote: I've observed a lot of beginning Rust programmers treat the language as add sigils until it works. (I have specific examples but don't want to name people here; however, feel free to contact me privately if you're curious.) I feel like I have to out myself as one of the idiot newcomers that do this, just for the sake of the discussion. I have no systems language background and frankly never had to consider the difference between the heap or the stack in the past 10-some years of writing code. I don't really think having new vs ~ would help me avoid this problem. The issue I believe is that the language looks understandable enough for the average joe used to higher level web languages (php, python, ruby). That's a great thing of course, that I can just jump in and mostly grasp what's going on, while past attempts at C++ tinkering quickly ended in tears. It also means that you have lots of people that come in and are capable of getting stuff to compile but won't necessarily understand the small print. Often there is an alternative to pooping sigils all over the code, but if you don't understand the concepts behind it it's hard to reason about what those alternatives could be. I think I'm getting better with this over time, and the rust libraries also get more usable and consistent leading to less ~ insanity, but one thing that would have helped early on is a good warning in the docs about this, and a good explanation of what the hell is going on (not one geared towards C++ devs using lingo that only low level devs are familiar with). I realize it's no easy task, and that arguably I should probably just read a book, but at the same time it's an amazing feat I think that the language is so accessible while remaining at such a low level, so if we manage to improve the onboarding process it would probably be very beneficial. There are tons of web devs that are interested in doing things faster/lower level - if only for fun. Maybe it's worth having a chapter for them in the docs. I'd happily help review that and point out unclear things :) Cheers -- Jordi Boggiano @seldaek - http://nelm.io/jordi ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev -- Your ship was destroyed in a monadic eruption. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Please simplify the syntax for Great Justice
Can I advise to have a certain constitency in the semantics? Not having ~foo, *foo, Rc, Gc. I would rather prefere having ~foo *foo foo @foo of Somethingfoo, otherfoo, Rc foo By the way, I like pretty much your pronoums thing, this help understanding :) - Gaetan 2013/11/19 Gábor Lehel illiss...@gmail.com In case this helps, I recently noticed that the sigils correspond to possessive pronouns: '~' = my, '' = their, '@' = our Of course, `@` might be going away, but `Rc`, `Gc`, and so forth all (will) have the same intuitive content, only different representations (among other properties). Similarly `~Foo` and plain `Foo` both mean my, while having differences in other areas, in which case yeah, telling you that `Foo` is stored in-place while `~Foo` is stored on the heap doesn't help you if you don't know what heap allocation is about. But maybe this is something. On Tue, Nov 19, 2013 at 10:12 AM, Jordi Boggiano j.boggi...@seld.bewrote: On Tue, Nov 19, 2013 at 5:17 AM, Patrick Walton pcwal...@mozilla.com wrote: I've observed a lot of beginning Rust programmers treat the language as add sigils until it works. (I have specific examples but don't want to name people here; however, feel free to contact me privately if you're curious.) I feel like I have to out myself as one of the idiot newcomers that do this, just for the sake of the discussion. I have no systems language background and frankly never had to consider the difference between the heap or the stack in the past 10-some years of writing code. I don't really think having new vs ~ would help me avoid this problem. The issue I believe is that the language looks understandable enough for the average joe used to higher level web languages (php, python, ruby). That's a great thing of course, that I can just jump in and mostly grasp what's going on, while past attempts at C++ tinkering quickly ended in tears. It also means that you have lots of people that come in and are capable of getting stuff to compile but won't necessarily understand the small print. Often there is an alternative to pooping sigils all over the code, but if you don't understand the concepts behind it it's hard to reason about what those alternatives could be. I think I'm getting better with this over time, and the rust libraries also get more usable and consistent leading to less ~ insanity, but one thing that would have helped early on is a good warning in the docs about this, and a good explanation of what the hell is going on (not one geared towards C++ devs using lingo that only low level devs are familiar with). I realize it's no easy task, and that arguably I should probably just read a book, but at the same time it's an amazing feat I think that the language is so accessible while remaining at such a low level, so if we manage to improve the onboarding process it would probably be very beneficial. There are tons of web devs that are interested in doing things faster/lower level - if only for fun. Maybe it's worth having a chapter for them in the docs. I'd happily help review that and point out unclear things :) Cheers -- Jordi Boggiano @seldaek - http://nelm.io/jordi ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev -- Your ship was destroyed in a monadic eruption. ___ 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] Please simplify the syntax for Great Justice
On Tue, Nov 19, 2013 at 5:56 AM, Gaetan gae...@xeberon.net wrote: Can I advise to have a certain constitency in the semantics? Not having ~foo, *foo, Rc, Gc. I would rather prefere having ~foo *foo foo @foo of Somethingfoo, otherfoo, Rc foo By the way, I like pretty much your pronoums thing, this help understanding :) - Gaetan Containers and smart pointers are plain old generic data types, they don't deserve special construction or type syntax at all in my opinion. If there's something wrong with Rust's syntax for generics, lets fix that. I wouldn't mind not having `~T` in the language at all, but am not really opposed to including it because there's no harm. Choosing to special-case arbitrary non-trivial data structures like vectors and reference counted boxes *is* harmful because alternatives should *not* be second-class. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Please simplify the syntax for Great Justice
On 11/19/2013 10:12 AM, Jordi Boggiano wrote: Often there is an alternative to pooping sigils all over the code, but if you don't understand the concepts behind it it's hard to reason about what those alternatives could be. +++ This is what I'm asking for about pointer variety and memory management in Rust. What does this all mean? Semantics, please ;-) (I mean human semantics, no machine operations) Denis ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Please simplify the syntax for Great Justice
On 11/19/2013 10:51 AM, Gaetan wrote: In the french presentation for rust 0.8 [1], the author gives the analogy with C++ semantics - ~ is a bit like unique_ptr - @ is an enhanced shared_ptrT - borrowed pointer works like C++ reference and I think it was very helpful to better understand them. I don't know if it is true or now, but this comparison helps a lot understanding the concepts.You can present them like this, and after, add more precision, and difference with the C++ counter parts. A tutorial to make would be Rust for C++ programmer :) [1] http://linuxfr.org/news/presentation-de-rust-0-8 This helped me too, even if I'm not a C++ programmer (can only read). However, it is still not enough to understand the meaning of each of those pointer varieties, imo (at least, _i_ still don't get it). What semantic kinds of pointed data should go to each variety? why? I would help at once improving the tutorial if I did understand. @Daniel: I would answer your questions if I did understand the *logic* of Rust's pointers and memory management. The tutorial, in my view, should precisely help on this. Instead, it tells us about machine-side issues without meaning (which are important and we need to know, but don't help in understanding). What is the semantic counter-part of all this? Why does it exist? The logic here is hidden or difficult. As a comparison, we don't need tons of explanations to understand the differences between a sequential collection (array, list) and, say, a set. The logic is nearly obvious, we easily get why both kinds exist. And in fact, the machine-side, implementation counterpart, while important, comes after, once we understand the meaning; then we get to know the price one has to pay for quick, direct access of given items, as opposed to access by index. Denis ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Please simplify the syntax for Great Justice
On Tue, Nov 19, 2013 at 6:45 AM, spir denis.s...@gmail.com wrote: This helped me too, even if I'm not a C++ programmer (can only read). However, it is still not enough to understand the meaning of each of those pointer varieties, imo (at least, _i_ still don't get it). What semantic kinds of pointed data should go to each variety? why? I would help at once improving the tutorial if I did understand. @Daniel: I would answer your questions if I did understand the *logic* of Rust's pointers and memory management. The tutorial, in my view, should precisely help on this. Instead, it tells us about machine-side issues without meaning (which are important and we need to know, but don't help in understanding). What is the semantic counter-part of all this? Why does it exist? The logic here is hidden or difficult. As a comparison, we don't need tons of explanations to understand the differences between a sequential collection (array, list) and, say, a set. The logic is nearly obvious, we easily get why both kinds exist. And in fact, the machine-side, implementation counterpart, while important, comes after, once we understand the meaning; then we get to know the price one has to pay for quick, direct access of given items, as opposed to access by index. Denis So in your opinion, what's wrong with the `Boxes` section? http://static.rust-lang.org/doc/master/tutorial.html#boxes I happen to think it does a pretty good job of explaining why `~` is required for recursive types, which is almost the only use case for it from a purely semantic perspective (not worrying about performance). ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Please simplify the syntax for Great Justice
+1 semantics is so important Le 19 nov. 2013 12:22, spir denis.s...@gmail.com a écrit : On 11/19/2013 10:12 AM, Jordi Boggiano wrote: Often there is an alternative to pooping sigils all over the code, but if you don't understand the concepts behind it it's hard to reason about what those alternatives could be. +++ This is what I'm asking for about pointer variety and memory management in Rust. What does this all mean? Semantics, please ;-) (I mean human semantics, no machine operations) Denis ___ 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] Please simplify the syntax for Great Justice
On 19/11/13 05:17, Patrick Walton wrote: I've observed a lot of beginning Rust programmers treat the language as add sigils until it works. (I have specific examples but don't want to name people here; however, feel free to contact me privately if you're curious.) They end up with slow programs and frustrated with Rust, wondering why they had to fight the compiler if they seemingly didn't gain any performance from it. I think a fair amount of it is that the sigils don't visually convey enough information to the programmer; they feel like something that you just have to add to make the compiler happy. A sigil in Rust's expression grammar as it stands represents an *action*, not a *qualifier* as it does in most other languages (e.g. `$foo` in PHP). Moreover, the `~` expression maps to one of the most expensive machine operations in the entire language semantics! It's thus important in my view to emphasize to newcomers that `~` *means* something; it is not just a qualifier you have to add to make the compiler happy. Indeed, if you are adding it just to make the compiler accept your code, there's something wrong--either the API you're using is inefficient or you're confused about the semantics! I agree 1% with what was said above. /Daniel ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Please simplify the syntax for Great Justice
The most common use case for owned boxes is creating recursive data structures like a binary search tree. I don't think this is the most common use of owned boxes: string management, ... I don't think it a good idea to place binary search tree in a tutorial. You don't do this every day :) - Gaetan 2013/11/19 Gaetan gae...@xeberon.net In the french presentation for rust 0.8 [1], the author gives the analogy with C++ semantics - ~ is a bit like unique_ptr - @ is an enhanced shared_ptrT - borrowed pointer works like C++ reference and I think it was very helpful to better understand them. I don't know if it is true or now, but this comparison helps a lot understanding the concepts.You can present them like this, and after, add more precision, and difference with the C++ counter parts. A tutorial to make would be Rust for C++ programmer :) [1] http://linuxfr.org/news/presentation-de-rust-0-8 - Gaetan 2013/11/19 Daniel Micay danielmi...@gmail.com On Tue, Nov 19, 2013 at 4:25 AM, Gaetan gae...@xeberon.net wrote: I don't think there is any particular issue with the tutorial, but we need more recipes on how to handle typical situations. I'm specifically talking about the `Boxes` section in the tutorial and not the whole picture. I keep hearing that the coverage of `~` it's confusing - so can someone elaborate? Rewriting the coverage of boxes and references by walking through the implementation of some data structures is something I'm willing to do, but in my opinion that section is now quite good, other than being dry and not presenting interesting code samples for the use cases it describes. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Please simplify the syntax for Great Justice
On Tue, Nov 19, 2013 at 7:27 AM, Gaetan gae...@xeberon.net wrote: The most common use case for owned boxes is creating recursive data structures like a binary search tree. I don't think this is the most common use of owned boxes: string management, ... I don't think it a good idea to place binary search tree in a tutorial. You don't do this every day :) - Gaetan ~str isn't an ~T, in the existing type system ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Please simplify the syntax for Great Justice
On 11/19/2013 12:51 PM, Daniel Micay wrote:
So in your opinion, what's wrong with the `Boxes` section?
http://static.rust-lang.org/doc/master/tutorial.html#boxes
I happen to think it does a pretty good job of explaining why `~` is
required for recursive types, which is almost the only use case for it
from a purely semantic perspective (not worrying about performance).
If this is all true, that recursive structures are the main, almost the only
use case of ~ pointers, then the tutorial is in my view rather ok on this
point. But then, why does it seem there are ~ pointers in every corner of Rust
code? Including numerous cases in the tutorial itself.
Also, how would we explain and term this meaning? Indirection is not good
enough (for we introduce indirections for other reasons, if only to have
variable-size content). I'd say self-similarity is the right term here, and
self-explaining (see wikipedia if you are not familiar with the idea). This is,
in fact, the actual idea commonly termed recursivity in programming (wrongly,
in my view, but this is yet another terminological issue). A rule about ~
pointers thus may be:
Whenever one needs self-similarity, use a ~ pointer.
This lets the language store the element through the kind
of indirection that permits a self-similar structure.
(I'm not happy of this formulation, neither, still obscure.)
however, other comments on ~ pointers (eg comparisons with C++ unique_ptr, notes
that it means owned or my) introduce ideas rather different from the one you
suggest here, don't they? Say I manually create a kind of string or fix-size
array:
struct String {
n_bytes : uint,
bytes : ~[u8],
}
struct Array Item {
n_items : uint,
items : ~[Item],
}
Is it wrong here to ~ point to bytes or items? that's what I'd do, anyway... If
it is right, maybe the actual meaning of ~ is something like proper content.
Whenever a structure actually contains content which is actually proper to it,
or more generally has (pointed) data participating to its description, then
these contents or descriptive data should pointed with ~: because they belong /
are proper to it.
struct ComplexVisualForm {
shape : ~ Shape,
style : ~ Style,
}
This matches my distinction between things and data (properly speaking). Data,
even when pointed (for technological rather than semantic reasons), still belong
to whatever they are part of. Data are never referenced (properly speaking), it
makes no sense. Things instead exist by themselves, are always ref'ed, never
copied (or moved), it makes no sense. If the reasoning above about ~ pointers is
more or less correct (i doubt it is), then we have in Rust the proper kind of
pointer to point to data, properly speaking, meaning information about things.
Now, to reference things from multiple points of view, we need something else,
proper refs or links, and they cannot be ordinary pointers (especially not
GC'ed): we need true refs, independant from the data (while pointers hold their
addresses).
Denis
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Please simplify the syntax for Great Justice
I think this is precisely one of the bigest issue, from a newbee point of view. And I agree with spir on this point. It's not that important, but you end up placing them everywhere to make the compiler happy. ~str should be a ~T. If it is not, it should use another semantic. However, I don't see where you explain this subtility in the tutorial, didn't you added it recently? PS: I'm french, I know pretty well that all subtilities (other words for exception to the general rules) my natural language has their own reason, BUT if I wanted to redesign french, I would get rid of all these rules, exceptions, rules in the exceptions. And exceptions in the rules of exceptions... - Gaetan 2013/11/19 Daniel Micay danielmi...@gmail.com On Tue, Nov 19, 2013 at 7:27 AM, Gaetan gae...@xeberon.net wrote: The most common use case for owned boxes is creating recursive data structures like a binary search tree. I don't think this is the most common use of owned boxes: string management, ... I don't think it a good idea to place binary search tree in a tutorial. You don't do this every day :) - Gaetan ~str isn't an ~T, in the existing type system ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Please simplify the syntax for Great Justice
On Tue, Nov 19, 2013 at 7:35 AM, spir denis.s...@gmail.com wrote:
If this is all true, that recursive structures are the main, almost the
only use case of ~ pointers, then the tutorial is in my view rather ok on
this point. But then, why does it seem there are ~ pointers in every corner
of Rust code? Including numerous cases in the tutorial itself.
Also, how would we explain and term this meaning? Indirection is not good
enough (for we introduce indirections for other reasons, if only to have
variable-size content). I'd say self-similarity is the right term here,
and self-explaining (see wikipedia if you are not familiar with the idea).
This is, in fact, the actual idea commonly termed recursivity in
programming (wrongly, in my view, but this is yet another terminological
issue). A rule about ~ pointers thus may be:
Whenever one needs self-similarity, use a ~ pointer.
This lets the language store the element through the kind
of indirection that permits a self-similar structure.
(I'm not happy of this formulation, neither, still obscure.)
however, other comments on ~ pointers (eg comparisons with C++ unique_ptr,
notes that it means owned or my) introduce ideas rather different from the
one you suggest here, don't they? Say I manually create a kind of string or
fix-size array:
struct String {
n_bytes : uint,
bytes : ~[u8],
}
struct Array Item {
n_items : uint,
items : ~[Item],
}
The expression ~([1, 2, 3]) has a different type than the expression
~[1, 2, 3]. The former is an owned box containing a fixed size array
(~[int, ..3]) and the latter is a dynamic array (~[int]).
The ~str and ~[T] types are *not* owned boxes in the current type
system. There has been a proposal for dynamically sized types which
would make them owned boxes, but I only like it as the path forwards
for traits/closures and not vectors.
I don't think dynamic arrays/strings belong as built-in types
hard-wired into the language, especially with a confusing syntax like
this. They should be treated as other containers are.
In what I think is a sane system, dynamic arrays would be a library
`VecT` type just like we have `HashMapK, V` and will have other
vector types like `RopeT` or `SmallVecT, N`.
Is it wrong here to ~ point to bytes or items? that's what I'd do, anyway...
If it is right, maybe the actual meaning of ~ is something like proper
content. Whenever a structure actually contains content which is actually
proper to it, or more generally has (pointed) data participating to its
description, then these contents or descriptive data should pointed with ~:
because they belong / are proper to it.
struct ComplexVisualForm {
shape : ~ Shape,
style : ~ Style,
}
It doesn't make sense to use ~T over T without a reason to need a
pointer-size value. It offers nothing in terms of semantics. It uses
indirection to obtain pointer-size, and adds a destructor (a strict
loss in terms of functionality). If you're not writing a recursive
data structure or using dynamic dispatch via a trait object, you don't
need it.
This matches my distinction between things and data (properly speaking).
Data, even when pointed (for technological rather than semantic reasons),
still belong to whatever they are part of. Data are never referenced
(properly speaking), it makes no sense. Things instead exist by themselves,
are always ref'ed, never copied (or moved), it makes no sense. If the
reasoning above about ~ pointers is more or less correct (i doubt it is),
then we have in Rust the proper kind of pointer to point to data, properly
speaking, meaning information about things. Now, to reference things from
multiple points of view, we need something else, proper refs or links, and
they cannot be ordinary pointers (especially not GC'ed): we need true refs,
independant from the data (while pointers hold their addresses).
Denis
~T and T both have value semantics. Neither has by-reference
semantics, as ~T is always the unique owner of the contained value.
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Please simplify the syntax for Great Justice
On Tue, Nov 19, 2013 at 7:40 AM, Gaetan gae...@xeberon.net wrote: I think this is precisely one of the bigest issue, from a newbee point of view. And I agree with spir on this point. It's not that important, but you end up placing them everywhere to make the compiler happy. ~str should be a ~T. If it is not, it should use another semantic. However, I don't see where you explain this subtility in the tutorial, didn't you added it recently? PS: I'm french, I know pretty well that all subtilities (other words for exception to the general rules) my natural language has their own reason, BUT if I wanted to redesign french, I would get rid of all these rules, exceptions, rules in the exceptions. And exceptions in the rules of exceptions... - Gaetan I don't want to have `~str` and `~[T]` in the language, so I'm not really motivated to spend time trying to paper over the confusion caused by them. I doubt most users of Rust realize that ~([1, 2, 3]) and ~[1, 2, 3] have different types, and dynamically sized types are not going to fix this. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Please simplify the syntax for Great Justice
I think it is one of the first thing to explain, actually... Playing with strings, using the method in std or extra requires to understand it. I wanted to use (and improve) extra::url and others (like std::path,...) and... I was simply lost with all of these ~str... and nothing in the manual or tutorial. - Gaetan 2013/11/19 Daniel Micay danielmi...@gmail.com On Tue, Nov 19, 2013 at 7:40 AM, Gaetan gae...@xeberon.net wrote: I think this is precisely one of the bigest issue, from a newbee point of view. And I agree with spir on this point. It's not that important, but you end up placing them everywhere to make the compiler happy. ~str should be a ~T. If it is not, it should use another semantic. However, I don't see where you explain this subtility in the tutorial, didn't you added it recently? PS: I'm french, I know pretty well that all subtilities (other words for exception to the general rules) my natural language has their own reason, BUT if I wanted to redesign french, I would get rid of all these rules, exceptions, rules in the exceptions. And exceptions in the rules of exceptions... - Gaetan I don't want to have `~str` and `~[T]` in the language, so I'm not really motivated to spend time trying to paper over the confusion caused by them. I doubt most users of Rust realize that ~([1, 2, 3]) and ~[1, 2, 3] have different types, and dynamically sized types are not going to fix this. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Please simplify the syntax for Great Justice
On Tue, Nov 19, 2013 at 7:52 AM, Gaetan gae...@xeberon.net wrote: I think it is one of the first thing to explain, actually... Playing with strings, using the method in std or extra requires to understand it. I wanted to use (and improve) extra::url and others (like std::path,...) and... I was simply lost with all of these ~str... and nothing in the manual or tutorial. - Gaetan It is covered, I rewrote the section on it recently: http://static.rust-lang.org/doc/master/tutorial.html#vectors-and-strings It doesn't go out of the way to explain that they're not owned boxes, but I don't think it should. It's a confusing language wart and should be fixed as far as I am concerned. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Please simplify the syntax for Great Justice
Sorry, but it's not clear. the only occurences of ~str are in Declaring and implementing traits section... Maybe by adding more string specific examples would help... And a special section one why ~str is not a ~T would be so useful! - Gaetan 2013/11/19 Daniel Micay danielmi...@gmail.com On Tue, Nov 19, 2013 at 7:52 AM, Gaetan gae...@xeberon.net wrote: I think it is one of the first thing to explain, actually... Playing with strings, using the method in std or extra requires to understand it. I wanted to use (and improve) extra::url and others (like std::path,...) and... I was simply lost with all of these ~str... and nothing in the manual or tutorial. - Gaetan It is covered, I rewrote the section on it recently: http://static.rust-lang.org/doc/master/tutorial.html#vectors-and-strings It doesn't go out of the way to explain that they're not owned boxes, but I don't think it should. It's a confusing language wart and should be fixed as far as I am concerned. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Please simplify the syntax for Great Justice
However, I want to highlight it is really appreciable that you, the rust team, are so open to our question. Just wanted to give you this feedback, I don't want to be held like the guy who criticize the current work, I know very much that is could be very annoying. Just willing to help :) - Gaetan 2013/11/19 Gaetan gae...@xeberon.net I think this is precisely one of the bigest issue, from a newbee point of view. And I agree with spir on this point. It's not that important, but you end up placing them everywhere to make the compiler happy. ~str should be a ~T. If it is not, it should use another semantic. However, I don't see where you explain this subtility in the tutorial, didn't you added it recently? PS: I'm french, I know pretty well that all subtilities (other words for exception to the general rules) my natural language has their own reason, BUT if I wanted to redesign french, I would get rid of all these rules, exceptions, rules in the exceptions. And exceptions in the rules of exceptions... - Gaetan 2013/11/19 Daniel Micay danielmi...@gmail.com On Tue, Nov 19, 2013 at 7:27 AM, Gaetan gae...@xeberon.net wrote: The most common use case for owned boxes is creating recursive data structures like a binary search tree. I don't think this is the most common use of owned boxes: string management, ... I don't think it a good idea to place binary search tree in a tutorial. You don't do this every day :) - Gaetan ~str isn't an ~T, in the existing type system ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Please simplify the syntax for Great Justice
On Nov 19, 2013, at 3:08 AM, Daniel Micay danielmi...@gmail.com wrote: I wouldn't mind not having `~T` in the language at all, but am not really opposed to including it because there's no harm. Choosing to special-case arbitrary non-trivial data structures like vectors and reference counted boxes *is* harmful because alternatives should *not* be second-class. Alternatives aren’t second-class, they just aren’t special. Vectors in particular are used so ubiquitously that having special syntax is extremely convenient. Anecdotally, Objective-C has moved in the opposite direction to the great happiness of all Obj-C developers. NSArray* and NSDictionary* are the ubiquitous vector/hashtable implementations that everybody uses, but they didn’t have any special language support. Recently, special language support was added so I can say @[@“yes”, @“no”, @“maybe”] instead of [NSArray arrayWithObjects:@“yes”, @“no”, @“maybe”, nil] (and similar syntax for dictionaries, as well as boxed NSNumbers) and it’s made programming in Obj-C significantly nicer. There’s nothing stopping you from using other data structures, but the special syntax for these particular ubiquitous ones just makes everyone’s life easier. So back to Rust. [] and its variants are extremely commonly used. Removing the special syntax for this will do nothing but make it more annoying to use them. It doesn’t do anything to make alternative data structures any easier to use. The one suggestion I’d make is maybe provide hooks for the [] syntax to be used for a different vector implementation on a per-crate basis, although this would mean that [] would actually be something like std::vectorT and [] is just syntactic sugar. Which is generally fine, although it’s awfully nice to have [T] be the actual type name in type signatures, having to use std::vectorT in type signatures and then using [a, b, c] to construct the value in code just feels a bit less nice than what we have in Rust today (but certainly better than no syntactic sugar at all). -Kevin___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Please simplify the syntax for Great Justice
+1 在 2013年11月19日 下午8:27，Gaetan gae...@xeberon.net写道： The most common use case for owned boxes is creating recursive data structures like a binary search tree. I don't think this is the most common use of owned boxes: string management, ... I don't think it a good idea to place binary search tree in a tutorial. You don't do this every day :) - Gaetan 2013/11/19 Gaetan gae...@xeberon.net In the french presentation for rust 0.8 [1], the author gives the analogy with C++ semantics - ~ is a bit like unique_ptr - @ is an enhanced shared_ptrT - borrowed pointer works like C++ reference and I think it was very helpful to better understand them. I don't know if it is true or now, but this comparison helps a lot understanding the concepts.You can present them like this, and after, add more precision, and difference with the C++ counter parts. A tutorial to make would be Rust for C++ programmer :) [1] http://linuxfr.org/news/presentation-de-rust-0-8 - Gaetan 2013/11/19 Daniel Micay danielmi...@gmail.com On Tue, Nov 19, 2013 at 4:25 AM, Gaetan gae...@xeberon.net wrote: I don't think there is any particular issue with the tutorial, but we need more recipes on how to handle typical situations. I'm specifically talking about the `Boxes` section in the tutorial and not the whole picture. I keep hearing that the coverage of `~` it's confusing - so can someone elaborate? Rewriting the coverage of boxes and references by walking through the implementation of some data structures is something I'm willing to do, but in my opinion that section is now quite good, other than being dry and not presenting interesting code samples for the use cases it describes. ___ 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] Please simplify the syntax for Great Justice
在 2013年11月19日 下午8:35，spir denis.s...@gmail.com写道：
On 11/19/2013 12:51 PM, Daniel Micay wrote:
So in your opinion, what's wrong with the `Boxes` section?
http://static.rust-lang.org/doc/master/tutorial.html#boxes
I happen to think it does a pretty good job of explaining why `~` is
required for recursive types, which is almost the only use case for it
from a purely semantic perspective (not worrying about performance).
If this is all true, that recursive structures are the main, almost the
only use case of ~ pointers, then the tutorial is in my view rather ok on
this point. But then, why does it seem there are ~ pointers in every corner
of Rust code? Including numerous cases in the tutorial itself.
+1
Also, how would we explain and term this meaning? Indirection is not
good enough (for we introduce indirections for other reasons, if only to
have variable-size content). I'd say self-similarity is the right term
here, and self-explaining (see wikipedia if you are not familiar with the
idea). This is, in fact, the actual idea commonly termed recursivity in
programming (wrongly, in my view, but this is yet another terminological
issue). A rule about ~ pointers thus may be:
Whenever one needs self-similarity, use a ~ pointer.
This lets the language store the element through the kind
of indirection that permits a self-similar structure.
(I'm not happy of this formulation, neither, still obscure.)
however, other comments on ~ pointers (eg comparisons with C++
unique_ptr, notes that it means owned or my) introduce ideas rather
different from the one you suggest here, don't they? Say I manually create
a kind of string or fix-size array:
struct String {
n_bytes : uint,
bytes : ~[u8],
}
struct Array Item {
n_items : uint,
items : ~[Item],
}
Is it wrong here to ~ point to bytes or items? that's what I'd do,
anyway... If it is right, maybe the actual meaning of ~ is something like
proper content. Whenever a structure actually contains content which is
actually proper to it, or more generally has (pointed) data participating
to its description, then these contents or descriptive data should pointed
with ~: because they belong / are proper to it.
struct ComplexVisualForm {
shape : ~ Shape,
style : ~ Style,
}
This matches my distinction between things and data (properly speaking).
Data, even when pointed (for technological rather than semantic reasons),
still belong to whatever they are part of. Data are never referenced
(properly speaking), it makes no sense. Things instead exist by themselves,
are always ref'ed, never copied (or moved), it makes no sense. If the
reasoning above about ~ pointers is more or less correct (i doubt it is),
then we have in Rust the proper kind of pointer to point to data, properly
speaking, meaning information about things. Now, to reference things from
multiple points of view, we need something else, proper refs or links, and
they cannot be ordinary pointers (especially not GC'ed): we need true refs,
independant from the data (while pointers hold their addresses).
Denis
___
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] Please simplify the syntax for Great Justice
在 2013年11月19日 下午8:41，Gaetan gae...@xeberon.net写道： I think this is precisely one of the bigest issue, from a newbee point of view. And I agree with spir on this point. It's not that important, but you end up placing them everywhere to make the compiler happy. ~str should be a ~T. If it is not, it should use another semantic. +1 However, I don't see where you explain this subtility in the tutorial, didn't you added it recently? PS: I'm french, I know pretty well that all subtilities (other words for exception to the general rules) my natural language has their own reason, BUT if I wanted to redesign french, I would get rid of all these rules, exceptions, rules in the exceptions. And exceptions in the rules of exceptions... - Gaetan 2013/11/19 Daniel Micay danielmi...@gmail.com On Tue, Nov 19, 2013 at 7:27 AM, Gaetan gae...@xeberon.net wrote: The most common use case for owned boxes is creating recursive data structures like a binary search tree. I don't think this is the most common use of owned boxes: string management, ... I don't think it a good idea to place binary search tree in a tutorial. You don't do this every day :) - Gaetan ~str isn't an ~T, in the existing type system ___ 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] Please simplify the syntax for Great Justice
在 2013年11月19日 下午8:44，Daniel Micay danielmi...@gmail.com写道：
On Tue, Nov 19, 2013 at 7:35 AM, spir denis.s...@gmail.com wrote:
If this is all true, that recursive structures are the main, almost the
only use case of ~ pointers, then the tutorial is in my view rather ok
on
this point. But then, why does it seem there are ~ pointers in every
corner
of Rust code? Including numerous cases in the tutorial itself.
Also, how would we explain and term this meaning? Indirection is not
good
enough (for we introduce indirections for other reasons, if only to have
variable-size content). I'd say self-similarity is the right term
here,
and self-explaining (see wikipedia if you are not familiar with the
idea).
This is, in fact, the actual idea commonly termed recursivity in
programming (wrongly, in my view, but this is yet another terminological
issue). A rule about ~ pointers thus may be:
Whenever one needs self-similarity, use a ~ pointer.
This lets the language store the element through the kind
of indirection that permits a self-similar structure.
(I'm not happy of this formulation, neither, still obscure.)
however, other comments on ~ pointers (eg comparisons with C++
unique_ptr,
notes that it means owned or my) introduce ideas rather different
from the
one you suggest here, don't they? Say I manually create a kind of
string or
fix-size array:
struct String {
n_bytes : uint,
bytes : ~[u8],
}
struct Array Item {
n_items : uint,
items : ~[Item],
}
The expression ~([1, 2, 3]) has a different type than the expression
~[1, 2, 3]. The former is an owned box containing a fixed size array
(~[int, ..3]) and the latter is a dynamic array (~[int]).
The ~str and ~[T] types are *not* owned boxes in the current type
system. There has been a proposal for dynamically sized types which
would make them owned boxes, but I only like it as the path forwards
for traits/closures and not vectors.
Are you telling us ~T is not ~T, just as sun is not sun and moon is
not moon?? If they do not have the same semantic, why use the same syntax?
I don't think dynamic arrays/strings belong as built-in types
hard-wired into the language, especially with a confusing syntax like
this. They should be treated as other containers are.
In what I think is a sane system, dynamic arrays would be a library
`VecT` type just like we have `HashMapK, V` and will have other
vector types like `RopeT` or `SmallVecT, N`.
Is it wrong here to ~ point to bytes or items? that's what I'd do,
anyway...
If it is right, maybe the actual meaning of ~ is something like proper
content. Whenever a structure actually contains content which is
actually
proper to it, or more generally has (pointed) data participating to its
description, then these contents or descriptive data should pointed
with ~:
because they belong / are proper to it.
struct ComplexVisualForm {
shape : ~ Shape,
style : ~ Style,
}
It doesn't make sense to use ~T over T without a reason to need a
pointer-size value. It offers nothing in terms of semantics. It uses
indirection to obtain pointer-size, and adds a destructor (a strict
loss in terms of functionality). If you're not writing a recursive
data structure or using dynamic dispatch via a trait object, you don't
need it.
This matches my distinction between things and data (properly speaking).
Data, even when pointed (for technological rather than semantic
reasons),
still belong to whatever they are part of. Data are never referenced
(properly speaking), it makes no sense. Things instead exist by
themselves,
are always ref'ed, never copied (or moved), it makes no sense. If the
reasoning above about ~ pointers is more or less correct (i doubt it
is),
then we have in Rust the proper kind of pointer to point to data,
properly
speaking, meaning information about things. Now, to reference things
from
multiple points of view, we need something else, proper refs or links,
and
they cannot be ordinary pointers (especially not GC'ed): we need true
refs,
independant from the data (while pointers hold their addresses).
Denis
~T and T both have value semantics. Neither has by-reference
semantics, as ~T is always the unique owner of the contained value.
___
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] Please simplify the syntax for Great Justice
On Tue, Nov 19, 2013 at 4:43 AM, Daniel Micay danielmi...@gmail.com wrote: The expression ~([1, 2, 3]) has a different type than the expression ~[1, 2, 3]. The former is an owned box containing a fixed size array (~[int, ..3]) and the latter is a dynamic array (~[int]). The ~str and ~[T] types are *not* owned boxes in the current type system. There has been a proposal for dynamically sized types which would make them owned boxes, but I only like it as the path forwards for traits/closures and not vectors. I don't think dynamic arrays/strings belong as built-in types hard-wired into the language, especially with a confusing syntax like this. They should be treated as other containers are. In what I think is a sane system, dynamic arrays would be a library `VecT` type just like we have `HashMapK, V` and will have other vector types like `RopeT` or `SmallVecT, N`. Agreed with this 100%. From a mental model perspective, you can't have ~foo mean foo is boxed everywhere in the language and then go Oh but ~str and ~[T]? Yeah those are exceptions. You're mental model is wrong. *Everyone* is going to build this incorrect mental model of putting ~ in front of a thing puts that thing in a box and it's not the user's fault, it's Rust's fault for having this silly distinction. ~ in front of a type should mean one thing and one thing only. Otherwise we're just making life difficult for the users for no sensible reason. I read through all the Rust docs several times over the last few months, I have years of experience with C++ and thought I had a rock-solid understanding of ~T (it's just a unique_ptrT) and just a few days ago I learned that ~str and ~[T] are special. And I only learned about this by randomly browsing through rust-dev. I felt cheated a bit TBH. It's such an obvious design mistake IMO; everyone's going to get this wrong because it's counter-intuitive. It's like mutable default arguments in Python 2.x (which was thankfully fixed in 3.0). [I'm not trying to bash a different language, I know that's against the rules of the list. I'm just trying to draw a parallel with a different language design mistake that tripped up everyone as well.] ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Please simplify the syntax for Great Justice
On Tue, Nov 19, 2013 at 5:21 PM, Patrick Walton pcwal...@mozilla.comwrote: I agree that we should change this, but give us some credit: it's only an obvious design mistake now that we've gotten to this point. [...] The current status is the product of the slow evolution of a design that predated the region and slicing system, and what seems obvious now was not obvious in retrospect. Fair point. I give you guys a lot of credit though, Rust is a wonderful language in general. I also admire how willing core Rust devs are to admit ok that was a bad idea, let's try something else. I don't see that every day; Rust is better for it. Please continue being awesome. 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
Re: [rust-dev] Please simplify the syntax for Great Justice
He said IMHO .. An explicit new is a huge indicator of what is going on ... most people are familiar enough with stack allocation early adopters are not 9-5 developers.. Ben On Tue, Nov 19, 2013 at 11:41 AM, Kevin Ballard ke...@sb.org wrote: Is that really why, or are you just guessing? I'm assuming the real reason is that people are used to languages where heap allocation is common and stack allocation rare or nonexistant, and don't understand why boxing everything is a bad idea. In other words, it's a problem that a proper tutorial should be able to help with. I don't think changing syntax is going to make much of a difference. -Kevin ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Please simplify the syntax for Great Justice
On 11/18/13 7:41 PM, Kevin Ballard wrote: Is that really why, or are you just guessing? I'm assuming the real reason is that people are used to languages where heap allocation is common and stack allocation rare or nonexistant, and don't understand why boxing everything is a bad idea. In other words, it's a problem that a proper tutorial should be able to help with. I don't think changing syntax is going to make much of a difference. I've observed a lot of beginning Rust programmers treat the language as add sigils until it works. (I have specific examples but don't want to name people here; however, feel free to contact me privately if you're curious.) They end up with slow programs and frustrated with Rust, wondering why they had to fight the compiler if they seemingly didn't gain any performance from it. I think a fair amount of it is that the sigils don't visually convey enough information to the programmer; they feel like something that you just have to add to make the compiler happy. A sigil in Rust's expression grammar as it stands represents an *action*, not a *qualifier* as it does in most other languages (e.g. `$foo` in PHP). Moreover, the `~` expression maps to one of the most expensive machine operations in the entire language semantics! It's thus important in my view to emphasize to newcomers that `~` *means* something; it is not just a qualifier you have to add to make the compiler happy. Indeed, if you are adding it just to make the compiler accept your code, there's something wrong--either the API you're using is inefficient or you're confused about the semantics! Patrick ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Please simplify the syntax for Great Justice
The name itself is standard, like it is the default settings... Le 12 nov. 2013 02:35, Steven Fackler sfack...@gmail.com a écrit : base64.rs: let s = [52, 53, 54].to_base64(STANDARD); = why adding the standard argument? One will ALWAYS want the STANDARD method of creating the base64 representation of some bytes, why not adding this argument as default. That is not true. If you are going to be putting the Base64 encoded data into a URL you're going to have to use URL_SAFE instead of STANDARD. If you're trying to send an email, you'll need to use MIME instead of STANDARD. If you're talking to a service that requires one of the ~10 other variants of Base64, you'll need to use a custom config struct. Steven Fackler On Mon, Nov 11, 2013 at 5:23 PM, Brendan Zabarauskas bjz...@yahoo.com.auwrote: On 12 Nov 2013, at 10:12 am, John Clements cleme...@brinckerhoff.org wrote: If you had the energy to build an alternate front-end using a parenthesized syntax, I'm sure there are others that would give it a try. Me, for instance! It would be nice if we could: - A: desugar Rust into a small kernel language - B: allow rustc to take in some sort of raw AST data (not sure if that’s already possible) - C: have a way of outputting the AST data in a certain syntax. That would allow folks like me to have a nice Haskelly syntax as well as an s-expr style! Heh. ~Brendan ___ 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] Please simplify the syntax for Great Justice
On 11/11/2013 09:46 PM, Corey Richardson wrote: I don't think Rust can succeed as a language if it massively differs, visually, from the language it intends to offset (C++). I don't think Rust can succeed as a language if it massively resembles the language it intends to offset (C++). Denis ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Please simplify the syntax for Great Justice
Does anyone have empirical data (or even anecdotes) about whether or not C++ hackers find Rust's syntax appealing? :-) On Tue, Nov 12, 2013 at 10:53 AM, spir denis.s...@gmail.com wrote: On 11/11/2013 09:46 PM, Corey Richardson wrote: I don't think Rust can succeed as a language if it massively differs, visually, from the language it intends to offset (C++). I don't think Rust can succeed as a language if it massively resembles the language it intends to offset (C++). Denis ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev -- Your ship was destroyed in a monadic eruption. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Please simplify the syntax for Great Justice
My opinion is that clear semantics and good documentation is much more important than familiar syntax. Besides, it's not too closely C++ syntax; for example `let x : T = v` is much closer to Scala's `val x : T = v` than C++'s `T x = v`. (This is a good choice, as anyone who know's why C++ has a `typename` keyword will realise.) But why is this discussion continuing here? The developers have already stated that major type changes are not an option for Rust 1.0. I have been considering some (fairly major) syntax variations myself, but here is not the place; if you want to try out some other syntax then why not write a compiler extension which allows the option of different syntax through a different file extension (e.g. .rs2) or some such switch? I for one am not convinced that pure syntax changes can make that big a difference; far more interesting would be an interactive IDE which lets the programmer write plain English (or restricted English or German or Japanese or whatever you like) and attempts to infer what code is meant. Of course English is not precise enough to specify exact code (without a _lot_ of words), so the interesting part would be how to make the IDE smart enough and interact with the programmer well enough to produce good code easily. (The point of this in the first place is to allow the programmer to write things like sort this list or give me an n*n identity matrix without expecting the programmer to know in advance how the relevant APIs work.) On Tuesday 12 November 2013 10:59:16 Gábor Lehel wrote: Does anyone have empirical data (or even anecdotes) about whether or not C++ hackers find Rust's syntax appealing? :-) On Tue, Nov 12, 2013 at 10:53 AM, spir denis.s...@gmail.com wrote: On 11/11/2013 09:46 PM, Corey Richardson wrote: I don't think Rust can succeed as a language if it massively differs, visually, from the language it intends to offset (C++). I don't think Rust can succeed as a language if it massively resembles the language it intends to offset (C++). Denis ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev signature.asc Description: This is a digitally signed message part. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Please simplify the syntax for Great Justice
More concretely, a good ide with completion, the right snippets and contextual help is very helpful for learning new language. I thing this could be a good idea to have an official set of snippets, typical every day codes, that can be used to create a common contextual helps for editors (vim, sublim,...) When i arrive in a new language, i m used to gather the common experience and write some automatisation tool and documentation to have a unique point of entry for all what should i do in this situation. This covers: - code styling - source organisation - file handling (open/close) - error handling - for python, import lines organisation - argument passing... Le 12 nov. 2013 11:35, Diggory Hardy li...@dhardy.name a écrit : My opinion is that clear semantics and good documentation is much more important than familiar syntax. Besides, it's not too closely C++ syntax; for example `let x : T = v` is much closer to Scala's `val x : T = v` than C++'s `T x = v`. (This is a good choice, as anyone who know's why C++ has a `typename` keyword will realise.) But why is this discussion continuing here? The developers have already stated that major type changes are not an option for Rust 1.0. I have been considering some (fairly major) syntax variations myself, but here is not the place; if you want to try out some other syntax then why not write a compiler extension which allows the option of different syntax through a different file extension (e.g. .rs2) or some such switch? I for one am not convinced that pure syntax changes can make that big a difference; far more interesting would be an interactive IDE which lets the programmer write plain English (or restricted English or German or Japanese or whatever you like) and attempts to infer what code is meant. Of course English is not precise enough to specify exact code (without a _lot_ of words), so the interesting part would be how to make the IDE smart enough and interact with the programmer well enough to produce good code easily. (The point of this in the first place is to allow the programmer to write things like sort this list or give me an n*n identity matrix without expecting the programmer to know in advance how the relevant APIs work.) On Tuesday 12 November 2013 10:59:16 Gábor Lehel wrote: Does anyone have empirical data (or even anecdotes) about whether or not C++ hackers find Rust's syntax appealing? :-) On Tue, Nov 12, 2013 at 10:53 AM, spir denis.s...@gmail.com wrote: On 11/11/2013 09:46 PM, Corey Richardson wrote: I don't think Rust can succeed as a language if it massively differs, visually, from the language it intends to offset (C++). I don't think Rust can succeed as a language if it massively resembles the language it intends to offset (C++). Denis ___ 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] Please simplify the syntax for Great Justice
Hi, Greg -- At this state in Rust's development, we are unlikely to make any major changes to Rust's syntax. Literally years of effort have gone into desgining the syntax, and at this point in the language's development, our focus is on making any non-backwards-compatible changes in preparation for releasing 1.0. I encourage you to check out Rust's syntax extension / macro system: http://static.rust-lang.org/doc/master/tutorial-macros.html and explore how that can be used to extend the base syntax. Cheers, Tim On Mon, Nov 11, 2013 at 12:27 PM, Greg g...@kinostudios.com wrote: Dear Mozilla, rust devs, and memory-safe enthusiasts everywhere, I'm very happy with the safety improvements that Rust brings. This is true innovation. At the same time, I am disappointed and quite concerned about Rust's unimaginative syntax. It seems to preserve decades of poor decision-making from C++. The FAQ states: The syntax is still evolving I hope this is still true today. Syntax plays a significant role in safety: 1. Simple syntax makes software easier to write. 2. Simple syntax makes software easier to understand. 3. Simple syntax makes inserting a backdoor into an open source project more difficult. 4. Simple syntax leads to fewer mistakes. Were I to have written Rust, I would have modeled its syntax after Clojure/Lisp/Scheme instead of C++ [1]. By this point, I'm aware that this is unlikely to happen. However, I would like to ask the Rust architects to seriously consider this issue, and ask themselves what syntax they can remove from the language while maintaining type-safety. Removing syntax should not raise any fears that the language will lose any features or flexibility. To the contrary, a simpler syntax will likely lead to increased flexibility and possibilities. Lisp has demonstrated unequivocally. Typed Clojure may provide the authors with needed inspiration: https://github.com/clojure/core.typed/wiki https://s3.amazonaws.com/github/downloads/frenchy64/papers/ambrose-honours.pdf Kind regards, Greg [1] https://www.taoeffect.com/blog/2010/01/how-newlisp-took-my-breath-and-syntax-away/ -- Please do not email me anything that you are not comfortable also sharing with the NSA. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev -- Tim Chevalier * http://catamorphism.org/ * Often in error, never in doubt If you are silent about your pain, they'll kill you and say you enjoyed it. -- Zora Neale Hurston ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Please simplify the syntax for Great Justice
On Mon, Nov 11, 2013 at 12:27 PM, Greg g...@kinostudios.com wrote: Dear Mozilla, rust devs, and memory-safe enthusiasts everywhere, I'm very happy with the safety improvements that Rust brings. This is true innovation. At the same time, I am disappointed and quite concerned about Rust's unimaginative syntax. [...] I'm not a rust developer— so consider my comments accordingly worthless. But what you're asking for here is very non-specific. Basically you expect that I should study a number of other languages in general and then infer which specific syntactic changes you might prefer. I think thats asking a little too much. My general impression is that the time for broad bike-shedding of the whole syntactic strategy has passed, ... but regardless of how broad or narrow the changes you hope to see happen, specific and actionable examples of places where the current syntax creates avoidable traps for programmers (esp. where they can't be fixed with a suitable use of macros) would likely be much more helpful than a general call for syntax minimalism. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Please simplify the syntax for Great Justice
At this state in Rust's development, we are unlikely to make any major changes to Rust's syntax. *cries* I encourage you to check out Rust's syntax extension / macro system: http://static.rust-lang.org/doc/master/tutorial-macros.html *clicks link* O_O *cries more* :'-( I'm not sure what stage I'm at right now: https://en.wikipedia.org/wiki/K%C3%BCbler-Ross_model#Stages Either 3 (Bargaining), or 4 (Depression). - Greg -- Please do not email me anything that you are not comfortable also sharing with the NSA. On Nov 11, 2013, at 3:33 PM, Tim Chevalier catamorph...@gmail.com wrote: Hi, Greg -- At this state in Rust's development, we are unlikely to make any major changes to Rust's syntax. Literally years of effort have gone into desgining the syntax, and at this point in the language's development, our focus is on making any non-backwards-compatible changes in preparation for releasing 1.0. I encourage you to check out Rust's syntax extension / macro system: http://static.rust-lang.org/doc/master/tutorial-macros.html and explore how that can be used to extend the base syntax. Cheers, Tim On Mon, Nov 11, 2013 at 12:27 PM, Greg g...@kinostudios.com wrote: Dear Mozilla, rust devs, and memory-safe enthusiasts everywhere, I'm very happy with the safety improvements that Rust brings. This is true innovation. At the same time, I am disappointed and quite concerned about Rust's unimaginative syntax. It seems to preserve decades of poor decision-making from C++. The FAQ states: The syntax is still evolving I hope this is still true today. Syntax plays a significant role in safety: 1. Simple syntax makes software easier to write. 2. Simple syntax makes software easier to understand. 3. Simple syntax makes inserting a backdoor into an open source project more difficult. 4. Simple syntax leads to fewer mistakes. Were I to have written Rust, I would have modeled its syntax after Clojure/Lisp/Scheme instead of C++ [1]. By this point, I'm aware that this is unlikely to happen. However, I would like to ask the Rust architects to seriously consider this issue, and ask themselves what syntax they can remove from the language while maintaining type-safety. Removing syntax should not raise any fears that the language will lose any features or flexibility. To the contrary, a simpler syntax will likely lead to increased flexibility and possibilities. Lisp has demonstrated unequivocally. Typed Clojure may provide the authors with needed inspiration: https://github.com/clojure/core.typed/wiki https://s3.amazonaws.com/github/downloads/frenchy64/papers/ambrose-honours.pdf Kind regards, Greg [1] https://www.taoeffect.com/blog/2010/01/how-newlisp-took-my-breath-and-syntax-away/ -- Please do not email me anything that you are not comfortable also sharing with the NSA. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev -- Tim Chevalier * http://catamorphism.org/ * Often in error, never in doubt If you are silent about your pain, they'll kill you and say you enjoyed it. -- Zora Neale Hurston signature.asc Description: Message signed with OpenPGP using GPGMail ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Please simplify the syntax for Great Justice
On Mon, Nov 11, 2013 at 3:41 PM, Greg g...@kinostudios.com wrote: At this state in Rust's development, we are unlikely to make any major changes to Rust's syntax. *cries* I don't think Rust can succeed as a language if it massively differs, visually, from the language it intends to offset (C++). ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Please simplify the syntax for Great Justice
I don't think Rust can succeed as a language if it massively differs, visually, from the language it intends to offset (C++). Yes, I agree, and that's why I wrote: By this point, I'm aware that this is unlikely to happen. I think it's still possible to simplify Rust's existing syntax while maintaining the features it offers. I am hoping that the developers of Rust will consider this issue important enough to put more thought into it. I am aware that I am jumping into an issue at a point in time that's considered late in the game. From the outside, I can say (with confidence), that Rust is still a nearly unheard-of language, and therefore it still has wiggle-room for improvement, even if the Rust developers and community, because they have been immersed in the language for quite some time, cannot see that this is in fact true. I also believe Tim when he said that years of effort went into designing the syntax. However, during those many years, did any of the brains that were involved in designing the syntax seriously consider Clojure's syntax, or Typed Clojure? I'm almost certain that the answer is no (partly because these languages/dialects did not exist at the time). What about Lua, which is more C-like? Or CoffeeScript? Looking at the Influenced By section on Wikipedia seems to indicate that the answer to these questions is, again, no. The list contains some bad role models (in terms of syntactic elegance and simplicity): C++, Haskell, OCaml, and Ruby. Thankfully Common Lisp is mentioned. Although, of the Lisps I'm familiar with, Common Lisp has the ugliest syntax (still better than C++ though). This is all to say that, from what I can tell, simplicity and elegance of syntax was not a design requirement (or goal) that the Rust developers had in mind. And I think that's quite unfortunate for Rust. I'm sorry I was not able to provide this feedback years ago when it might have been more helpful. I only recently became aware of Rust. - Greg -- Please do not email me anything that you are not comfortable also sharing with the NSA. On Nov 11, 2013, at 3:46 PM, Corey Richardson co...@octayn.net wrote: On Mon, Nov 11, 2013 at 3:41 PM, Greg g...@kinostudios.com wrote: At this state in Rust's development, we are unlikely to make any major changes to Rust's syntax. *cries* I don't think Rust can succeed as a language if it massively differs, visually, from the language it intends to offset (C++). signature.asc Description: Message signed with OpenPGP using GPGMail ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Please simplify the syntax for Great Justice
Hi, I am just a lurker as well, so take all of this with a good dose of salt... At the same time, I am disappointed and quite concerned about Rust's unimaginative syntax. It seems to preserve decades of poor decision-making from C++. Personally, I find it very pleasant. There are a few things I would have done differently (mostly to do using full names for e.g., function), but that is all window dressing. To the contrary, a simpler syntax will likely lead to increased flexibility and possibilities. Lisp has demonstrated unequivocally. Typed Clojure may provide the authors with needed inspiration: Clojure is my main language, so don't take this as an attack on it (or lisps in general), but the flexibility that those languages show is at least in part due to the dynamic type system. Even typed clojure (and typed racket) are dynamically typed, but with posthoc type checking. Although there are many benefits to dynamic typing, neither efficiency, nor provable safety are usually counted amongst them. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Please simplify the syntax for Great Justice
From the outside looking in... I do not see anything preventing Greg from producing many macros or an entire syntax sub-system to emulate and empower him with any sugary languages that he might prefer or desire. It is just going to be quite a bit of work for him, but he could do it himself, if we wanted to turn Rust's syntax into something closer to Type Clojure or create a DSL. Is that not true ? On Mon, Nov 11, 2013 at 3:28 PM, Corey Richardson co...@octayn.net wrote: On Mon, Nov 11, 2013 at 4:07 PM, Greg g...@kinostudios.com wrote: I don't think Rust can succeed as a language if it massively differs, visually, from the language it intends to offset (C++). Yes, I agree, and that's why I wrote: By this point, I'm aware that this is unlikely to happen. I think it's still possible to simplify Rust's existing syntax while maintaining the features it offers. My point is that the familiar syntax *is* a feature. What simplifications do you propose? I think everyone is mostly happy with the syntax at this point, so your proposed changes and justification are going to be very pursuasive, and followed by a PR, for there to be a chance of them being accepted. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev -- -Thad +ThadGuidry https://www.google.com/+ThadGuidry Thad on LinkedIn http://www.linkedin.com/in/thadguidry/ ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Please simplify the syntax for Great Justice
On Nov 11, 2013, at 1:07 PM, Greg wrote: I don't think Rust can succeed as a language if it massively differs, visually, from the language it intends to offset (C++). Yes, I agree, and that's why I wrote: By this point, I'm aware that this is unlikely to happen. ... However, during those many years, did any of the brains that were involved in designing the syntax seriously consider Clojure's syntax, or Typed Clojure? I'm almost certain that the answer is no (partly because these languages/dialects did not exist at the time). What about Lua, which is more C-like? Or CoffeeScript? Greg, thanks for your comments! In fact, nearly all of the designers of Rust are deeply familiar with the syntactic conventions of these and other languages. Speaking only for myself, I come from Racket, and I'm a strong proponent of fully parenthesized syntaxes. But! Rust is not that language. As you suggest (and others confirm), that train left the station long, long ago. The choice of the Rust team to adopt a C++-like syntax was very deliberate, and I'm confident that the members of this team still believe that was the right choice. With that said, though, Rust is a new and exciting language; if you can think of improvements, try coding them up and see what you get! In my experience, the Rust developers are always happy to hear from volunteers who are excited about the language and have concrete pull requests. If you had the energy to build an alternate front-end using a parenthesized syntax, I'm sure there are others that would give it a try. Me, for instance! All the best, John Clements ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Please simplify the syntax for Great Justice
Can we have Two rust? The first one would be easy to learn, easy to read, and do most of ones would expect: on demand garbage collector, traits, Owned pointers,... The second one would include all advanced feature we actually don t need everyday. Of course, we don t want to split the language, but rather présent the current things differently. The tutorials are a good starting point however, the rest of the documentations are quite complex. I would be very delighted to help on this matter. There could be some effort on simplification of the API (std/extra): provides just the right functions first, and allow all flexibility in a second step, maybe in an advanced functions parts in each API doc. For instance url.rs. To parse a string, you have to write this: let u = url::from_str(urlstring).unwrap(); I would propose this solution: let u = parse_url(urlstring); = simpler, easier to read, easier to remember ! Of course, the unwrap thing would still be here. base64.rs: let s = [52, 53, 54].to_base64(STANDARD); = why adding the standard argument? One will ALWAYS want the STANDARD method of creating the base64 representation of some bytes, why not adding this argument as default. There are some minor change to the API that would help a lot the learning of this language, along with adding more code sample in the documentation. After year of writing C++ code with complex API (boost) I enjoy writing with python which seems to provide just the right methods I need. I'll willing to help, but I don't easily find a easy starting point :) Gaetan Le lundi 11 novembre 2013, Brian Anderson a écrit : On 11/11/2013 01:07 PM, Greg wrote: I don't think Rust can succeed as a language if it massively differs, visually, from the language it intends to offset (C++). Yes, I agree, and that's why I wrote: * By this point, I'm aware that this is unlikely to happen.* I think it's still possible to simplify Rust's existing syntax while maintaining the features it offers. I am hoping that the developers of Rust will consider this issue important enough to put more thought into it. I am aware that I am jumping into an issue at a point in time that's considered late in the game. From the outside, I can say (with confidence), that Rust is still a nearly unheard-of language, and therefore it still has wiggle-room for improvement, even if the Rust developers and community, because they have been immersed in the language for quite some time, cannot see that this is in fact true. I also believe Tim when he said that years of effort went into designing the syntax. However, during those many years, did any of the brains that were involved in designing the syntax seriously consider Clojure's syntax, or Typed Clojure? I'm almost certain that the answer is no (partly because these languages/dialects did not exist at the time). What about Lua, which is more C-like? Or CoffeeScript? Looking at the Influenced By section on Wikipedia seems to indicate that the answer to these questions is, again, no. The answer is 'yes'. The designers of Rust are well aware of these languages and many others and have debated syntax issues repeatedly (as it is the most beloved pasttime of language designers). The current syntax was designed very intentionally the way it is. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Please simplify the syntax for Great Justice
Thanks John, for the friendly email. :-) The choice of the Rust team to adopt a C++-like syntax was very deliberate, and I'm confident that the members of this team still believe that was the right choice. I wonder, right for what reason? Do they actually *like* it? I wrote a lot of code in C++ back in the day. Can't touch the stuff anymore. *shudders* Or is it 'right' because it's familiar to C++ developers? I should have mentioned Java in my original post to the list. Java is relevant for a few reasons: 1. It has been around for a long time. 2. It's quite popular. 3. It's C-like, familiar, and attempts to implement some safety into the language 4. Its syntax is fairly simple (compared to C++). And most significantly of all: 5. It has gone through some significant syntactic changes, _years_ after being well established and well known. For example, Java 1.5 added Generics to the language (a simplified version of C++ templates). The recent Java has added anonymous functions (lambdas). Other well established languages have also made significant changes to their syntax well after their first birthday. Objective-C, for example, added properties and Automatic Reference Counting in with it turned 2.0. It also added syntax for various literals (arrays, maps, etc.): http://clang.llvm.org/docs/ObjectiveCLiterals.html So, given the history of these well established languages, I think there's still plenty of opportunity for change with Rust. More so, in fact, due to its alpha status. It's easier to remove syntax while a language is young, and Rust is still very young. With that said, though, Rust is a new and exciting language; if you can think of improvements, try coding them up and see what you get! In my experience, the Rust developers are always happy to hear from volunteers who are excited about the language and have concrete pull requests. If you had the energy to build an alternate front-end using a parenthesized syntax, I'm sure there are others that would give it a try. Me, for instance! I'd love to, but zero time at the moment. :-( Also, I'm not simply advocating a parenthesis-based syntax (though that would be *awesome*!). I think the present syntax is malleable and can be simplified and improved while retaining its C-ness for the sake of developers who haven't quite yet expanded their minds... :-p Cheers, Greg -- Please do not email me anything that you are not comfortable also sharing with the NSA. On Nov 11, 2013, at 6:12 PM, John Clements cleme...@brinckerhoff.org wrote: On Nov 11, 2013, at 1:07 PM, Greg wrote: I don't think Rust can succeed as a language if it massively differs, visually, from the language it intends to offset (C++). Yes, I agree, and that's why I wrote: By this point, I'm aware that this is unlikely to happen. ... However, during those many years, did any of the brains that were involved in designing the syntax seriously consider Clojure's syntax, or Typed Clojure? I'm almost certain that the answer is no (partly because these languages/dialects did not exist at the time). What about Lua, which is more C-like? Or CoffeeScript? Greg, thanks for your comments! In fact, nearly all of the designers of Rust are deeply familiar with the syntactic conventions of these and other languages. Speaking only for myself, I come from Racket, and I'm a strong proponent of fully parenthesized syntaxes. But! Rust is not that language. As you suggest (and others confirm), that train left the station long, long ago. The choice of the Rust team to adopt a C++-like syntax was very deliberate, and I'm confident that the members of this team still believe that was the right choice. With that said, though, Rust is a new and exciting language; if you can think of improvements, try coding them up and see what you get! In my experience, the Rust developers are always happy to hear from volunteers who are excited about the language and have concrete pull requests. If you had the energy to build an alternate front-end using a parenthesized syntax, I'm sure there are others that would give it a try. Me, for instance! All the best, John Clements signature.asc Description: Message signed with OpenPGP using GPGMail ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Please simplify the syntax for Great Justice
On Mon, Nov 11, 2013 at 3:52 PM, Gaetan gae...@xeberon.net wrote: Can we have Two rust? The first one would be easy to learn, easy to read, and do most of ones would expect: on demand garbage collector, traits, Owned pointers,... The second one would include all advanced feature we actually don t need everyday. Of course, we don t want to split the language, but rather présent the current things differently. The tutorials are a good starting point however, the rest of the documentations are quite complex. I would be very delighted to help on this matter. There could be some effort on simplification of the API (std/extra): provides just the right functions first, and allow all flexibility in a second step, maybe in an advanced functions parts in each API doc. We always welcome documentation patches! A more ambitious project would be to add language levels to Rust (like Racket has). If you were interested in pursuing this, you would want to discuss it with members of the core team. I doubt it would be accepted as a patch in the short term (since it's not a 1.0 priority), but in the long term, it's certainly possible. Cheers, Tim For instance url.rs. To parse a string, you have to write this: let u = url::from_str(urlstring).unwrap(); I would propose this solution: let u = parse_url(urlstring); = simpler, easier to read, easier to remember ! Of course, the unwrap thing would still be here. base64.rs: let s = [52, 53, 54].to_base64(STANDARD); = why adding the standard argument? One will ALWAYS want the STANDARD method of creating the base64 representation of some bytes, why not adding this argument as default. There are some minor change to the API that would help a lot the learning of this language, along with adding more code sample in the documentation. After year of writing C++ code with complex API (boost) I enjoy writing with python which seems to provide just the right methods I need. I'll willing to help, but I don't easily find a easy starting point :) Gaetan Le lundi 11 novembre 2013, Brian Anderson a écrit : On 11/11/2013 01:07 PM, Greg wrote: I don't think Rust can succeed as a language if it massively differs, visually, from the language it intends to offset (C++). Yes, I agree, and that's why I wrote: By this point, I'm aware that this is unlikely to happen. I think it's still possible to simplify Rust's existing syntax while maintaining the features it offers. I am hoping that the developers of Rust will consider this issue important enough to put more thought into it. I am aware that I am jumping into an issue at a point in time that's considered late in the game. From the outside, I can say (with confidence), that Rust is still a nearly unheard-of language, and therefore it still has wiggle-room for improvement, even if the Rust developers and community, because they have been immersed in the language for quite some time, cannot see that this is in fact true. I also believe Tim when he said that years of effort went into designing the syntax. However, during those many years, did any of the brains that were involved in designing the syntax seriously consider Clojure's syntax, or Typed Clojure? I'm almost certain that the answer is no (partly because these languages/dialects did not exist at the time). What about Lua, which is more C-like? Or CoffeeScript? Looking at the Influenced By section on Wikipedia seems to indicate that the answer to these questions is, again, no. The answer is 'yes'. The designers of Rust are well aware of these languages and many others and have debated syntax issues repeatedly (as it is the most beloved pasttime of language designers). The current syntax was designed very intentionally the way it is. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev -- Tim Chevalier * http://catamorphism.org/ * Often in error, never in doubt If you are silent about your pain, they'll kill you and say you enjoyed it. -- Zora Neale Hurston ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Please simplify the syntax for Great Justice
On Mon, Nov 11, 2013 at 6:52 PM, Gaetan gae...@xeberon.net wrote: For instance url.rs. To parse a string, you have to write this: let u = url::from_str(urlstring).unwrap(); I would propose this solution: let u = parse_url(urlstring); = simpler, easier to read, easier to remember ! Of course, the unwrap thing would still be here. Rust generally uses sum types to report errors. The `from_str` method doesn't work for all inputs, so it returns `None` in those cases. The ability to handle errors does need to be there, and forcing a concious decision on how to handle common, easily recoverable errors makes a lot of sense to me. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Please simplify the syntax for Great Justice
Mod hat: This thread has become pretty off-topic. Let's wind it down and move any specific questions or concrete proposals regarding Rust to a new, separate thread. Please familiarize yourself with the Conduct section of https://github.com/mozilla/rust/wiki/Note-development-policy , particularly these parts: Respect that people have differences of opinion and that every design or implementation choice carries a trade-off and numerous costs. There is seldom a right answer. Please keep unstructured critique to a minimum. If you have solid ideas you want to experiment with, make a fork and see how it works. In particular, discussing the merits or lack thereof of C or Java syntax is out of scope for this mailing list. I understand that this subject came up because it was cited as a reason for Rust's syntax, but as several people have said, these decisions have been made and won't be revisited (except, *perhaps*, in the presence of a concrete proposal and preferably an implementation). Also, please avoid suggesting that people who do or don't like a particular syntax haven't expanded their mind; it's okay for different people to have different opinions about language design, and choosing any one approach doesn't mean we think less of people who prefer other ones. Cheers, Tim On Mon, Nov 11, 2013 at 4:00 PM, Greg g...@kinostudios.com wrote: Thanks John, for the friendly email. :-) The choice of the Rust team to adopt a C++-like syntax was very deliberate, and I'm confident that the members of this team still believe that was the right choice. I wonder, right for what reason? Do they actually *like* it? I wrote a lot of code in C++ back in the day. Can't touch the stuff anymore. *shudders* Or is it 'right' because it's familiar to C++ developers? I should have mentioned Java in my original post to the list. Java is relevant for a few reasons: 1. It has been around for a long time. 2. It's quite popular. 3. It's C-like, familiar, and attempts to implement some safety into the language 4. Its syntax is fairly simple (compared to C++). And most significantly of all: 5. It has gone through some significant syntactic changes, _years_ after being well established and well known. For example, Java 1.5 added Generics to the language (a simplified version of C++ templates). The recent Java has added anonymous functions (lambdas). Other well established languages have also made significant changes to their syntax well after their first birthday. Objective-C, for example, added properties and Automatic Reference Counting in with it turned 2.0. It also added syntax for various literals (arrays, maps, etc.): http://clang.llvm.org/docs/ObjectiveCLiterals.html So, given the history of these well established languages, I think there's still plenty of opportunity for change with Rust. More so, in fact, due to its alpha status. It's easier to remove syntax while a language is young, and Rust is still very young. With that said, though, Rust is a new and exciting language; if you can think of improvements, try coding them up and see what you get! In my experience, the Rust developers are always happy to hear from volunteers who are excited about the language and have concrete pull requests. If you had the energy to build an alternate front-end using a parenthesized syntax, I'm sure there are others that would give it a try. Me, for instance! I'd love to, but zero time at the moment. :-( Also, I'm not simply advocating a parenthesis-based syntax (though that would be *awesome*!). I think the present syntax is malleable and can be simplified and improved while retaining its C-ness for the sake of developers who haven't quite yet expanded their minds... :-p Cheers, Greg -- Please do not email me anything that you are not comfortable also sharing with the NSA. On Nov 11, 2013, at 6:12 PM, John Clements cleme...@brinckerhoff.org wrote: On Nov 11, 2013, at 1:07 PM, Greg wrote: I don't think Rust can succeed as a language if it massively differs, visually, from the language it intends to offset (C++). Yes, I agree, and that's why I wrote: By this point, I'm aware that this is unlikely to happen. ... However, during those many years, did any of the brains that were involved in designing the syntax seriously consider Clojure's syntax, or Typed Clojure? I'm almost certain that the answer is no (partly because these languages/dialects did not exist at the time). What about Lua, which is more C-like? Or CoffeeScript? Greg, thanks for your comments! In fact, nearly all of the designers of Rust are deeply familiar with the syntactic conventions of these and other languages. Speaking only for myself, I come from Racket, and I'm a strong proponent of fully parenthesized syntaxes. But! Rust is not that language. As you suggest (and others confirm), that train left the station long, long ago. The choice of the Rust team to adopt a
Re: [rust-dev] Please simplify the syntax for Great Justice
On Nov 11, 2013, at 7:05 PM, Tim Chevalier catamorph...@gmail.com wrote: Also, please avoid suggesting that people who do or don't like a particular syntax haven't expanded their mind; it's okay for different people to have different opinions about language design, and choosing any one approach doesn't mean we think less of people who prefer other ones. I probably could have phrased that better to avoid misunderstandings. No offense was intended. The comment is a reference to anyone who is unfamiliar with the syntax of non-C-type languages. It's not a reference to anyone familiar with various syntaxes (C-type and others) and prefers C++. No superiority-complex, condescension, or anything of that sort was intended, please don't misunderstand. Kind regards, Greg -- Please do not email me anything that you are not comfortable also sharing with the NSA. signature.asc Description: Message signed with OpenPGP using GPGMail ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Please simplify the syntax for Great Justice
On 11/12/13 9:00 AM, Greg wrote: Thanks John, for the friendly email. :-) The choice of the Rust team to adopt a C++-like syntax was very deliberate, and I'm confident that the members of this team still believe that was the right choice. I wonder, right for what reason? Do they actually */like*/ it? I wrote a lot of code in C++ back in the day. Can't touch the stuff anymore. *shudders* I prefer C-like (Algol-like, if you want to be pedantic :)) syntax to S-expressions. Patrick ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Please simplify the syntax for Great Justice
On 12 Nov 2013, at 10:12 am, John Clements cleme...@brinckerhoff.org wrote: If you had the energy to build an alternate front-end using a parenthesized syntax, I'm sure there are others that would give it a try. Me, for instance! It would be nice if we could: - A: desugar Rust into a small kernel language - B: allow rustc to take in some sort of raw AST data (not sure if that’s already possible) - C: have a way of outputting the AST data in a certain syntax. That would allow folks like me to have a nice Haskelly syntax as well as an s-expr style! Heh. ~Brendan ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Please simplify the syntax for Great Justice
base64.rs: let s = [52, 53, 54].to_base64(STANDARD); = why adding the standard argument? One will ALWAYS want the STANDARD method of creating the base64 representation of some bytes, why not adding this argument as default. That is not true. If you are going to be putting the Base64 encoded data into a URL you're going to have to use URL_SAFE instead of STANDARD. If you're trying to send an email, you'll need to use MIME instead of STANDARD. If you're talking to a service that requires one of the ~10 other variants of Base64, you'll need to use a custom config struct. Steven Fackler On Mon, Nov 11, 2013 at 5:23 PM, Brendan Zabarauskas bjz...@yahoo.com.auwrote: On 12 Nov 2013, at 10:12 am, John Clements cleme...@brinckerhoff.org wrote: If you had the energy to build an alternate front-end using a parenthesized syntax, I'm sure there are others that would give it a try. Me, for instance! It would be nice if we could: - A: desugar Rust into a small kernel language - B: allow rustc to take in some sort of raw AST data (not sure if that’s already possible) - C: have a way of outputting the AST data in a certain syntax. That would allow folks like me to have a nice Haskelly syntax as well as an s-expr style! Heh. ~Brendan ___ 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
