On Tue, Nov 12, 2013 at 12:37 PM, Greg <[email protected]> wrote: > On Nov 12, 2013, at 12:15 PM, Tiffany Bennett <[email protected]> > wrote: > > [.. a bunch of flamebait ..] > > Sorry, not gonna bite. > > I think there was one reply-worthy comment buried in there, perhaps a > tacit request for remove-worthy syntax examples? > > I can point out syntax that I don't like, but I think it'd be more > productive to simultaneously offer alternatives, and I haven't studied Rust > in enough depth to where I'd be comfortable doing that. > > Here are some areas that caught my eye in the Doc-language-FAQ on Github. > If I were to start using Rust, I'd research these in more depth to try and > simplify the syntax: > > 1. ~[Option<Bucket<K,V>>] > > 2. fn linear_map_with_capacity<K:Eq + Hash,V>(capacity: uint) -> > LinearMap<K,V> > > 3. fn contains_key(&self, k: &K) > > My approach would be to try and get rid of templates through better type > inference in the compiler. I'd introduce the common brace literal syntax > for maps that can be found in JS and elsewhere, and perhaps additional > literal syntax (ala ObjC + Clojure). >
Type inference for function signatures leads to programmer errors where it infers the wrong type. You seem to have the idea that much of this syntax is unnecessary, when it really is - all of it is important to specifying exactly what you mean. In a system's language like Rust, there are a lot of things that you could mean. You should try providing real examples of how you could simplify the examples you provided. > I'd also look at the symbols '~', '@', and '&', and see what could be done > to remove or simplify those. > Anything you do to simplify Rust's memory management will be of detriment to the language, because it is an important part of Rust's ability to function as a system's language. Each of those symbols has an important meaning in regards to memory management - ~ being RAII-like, @ being garbage collected (and now behind a feature gate while everyone figures out whether to keep the symbol or just use RC<T>/GC<T>), & is a way to take temporary references to something. > I'd look to see whether ARC could be used instead of garbage collection, > and whether that would have an impact on syntax or not. > ARC /is/ garbage collection. It's an atomic reference counter that can be sent between tasks. > There's also the question of whether symbols (ala Lisp/Scheme/Clojure) > could be useful in simplifying the language and making it more versatile. > > Finally, if all else fails, I'd go for broke and S-expr the whole thing. > :-p > I've tried implementing an S-expr based language myself, and the benefits are really not as great as they first seem. One thing you eventually realize is that although lisp has an incredible macro system, needing macros in the first place is often a sign of a type system that isn't powerful enough to express many concepts. Do you often see macros used in languages like Haskell or Idris? > - Greg > > P.S. Accusing me of lying, and then misrepresenting what I said, is not > going to take this conversation down a productive path. You'll probably > just end up getting ignored (or worse). > > -- > Please do not email me anything that you are not comfortable also sharing > with the NSA. > >
_______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
