Re: [rust-dev] do
On Sat, Nov 30, 2013 at 9:34 AM, Oren Ben-Kiki o...@ben-kiki.org wrote: That would help a bit, but it would still require the programmer to manually setup and teardown the tuples, pass them to the closure, and so on. We'll also need to change each and every function that takes an action parameter to take the extra tuple in every container or container-like type. And then there's the possibility of modifying variables... It sounds like a lot of effort working around something the compiler can do automatically and actually already does automatically; all it needs is the ability to communicate the programmer intent via the type system so it can support and enforce it. I agree, having annotations so that the type system can enforce safety is a better idea than hacking around it with alternate versions of every function for taking closures only used once. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Fwd: Please simplify the syntax for Great Justice
On Tue, Nov 12, 2013 at 12:37 PM, Greg g...@kinostudios.com wrote: On Nov 12, 2013, at 12:15 PM, Tiffany Bennett tiff...@stormbit.net 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. ~[OptionBucketK,V] 2. fn linear_map_with_capacityK:Eq + Hash,V(capacity: uint) - LinearMapK,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 RCT/GCT), 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 Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Fwd: Please simplify the syntax for Great Justice
Sorry, I did go a bit overboard On Tue, Nov 12, 2013 at 12:48 PM, Tim Chevalier catamorph...@gmail.comwrote: Hey Tiffany -- Just wanted to let you know that I thought this was a totally appropriate email on your part :-) Normally I would warn about the code of conduct, but tbh, in this case I think Greg deserved it. Just my opinion, of course, and not the official opinion of the team :-) That said, when you want to shut people down in the future (a role that is very much needed given the number of cranks that Rust attracts, especially now that neither I nor Graydon will be mods after this week), try to do it in a way that you can argue is kind and courteous (as per the conduct section of https://github.com/mozilla/rust/wiki/Note-development-policy ), so that the other list mods will have no reason to criticize it :-) Cheers, Tim On Tue, Nov 12, 2013 at 9:15 AM, Tiffany Bennett tiff...@stormbit.net wrote: On Mon, Nov 11, 2013 at 4:07 PM, Greg g...@kinostudios.com wrote: I think it's still possible to simplify Rust's existing syntax while maintaining the features it offers. You haven't actually explained which syntax you want to remove. I'm almost certain that the answer is no (partly because these languages/dialects did not exist at the time). The language is very similar in semantics to OCaml, to say that Rust is only inspired by C++ would be a lie. What about Lua, which is more C-like? You've obviously never used Lua, it's nothing like C. Or CoffeeScript? Coffeescript is the exact opposite of what you ask - it's a superset of javascript that adds some syntax sugar. The fact it compiles to very readable javascript is a testament to this. The list contains some bad role models (in terms of syntactic elegance and simplicity): C++, Haskell, OCaml, and Ruby. I seriously doubt your taste in syntax if you think Haskell and OCaml are undesirable. Thankfully Common Lisp is mentioned. Although, of the Lisps I'm familiar with, Common Lisp has the ugliest syntax (still better than C++ though). You are clearly misusing the word syntax... Common lisp's syntax consists of only S-exprs and the quote sugar, as other lisps do. 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. The goal of Rust was to produce a type-safe, memory-safe, programmer-safe programming language, in the niche of system's languages. And I think that's quite unfortunate for Rust. It's quite unfortunate that the language doesn't abide by your nebulous, sparsely defined ideas of what a good language looks like? 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. I doubt it would have been taken seriously then. - 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++). ___ 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 -- 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] Abandoning segmented stacks in Rust
If you really need such a small memory footprint for your tasks, I am of the opinion that it would be less error prone (whoops, accidentally used 64 bytes of stack than I should have, now I'm using twice as much memory!) to use an async event loop, like libevent, rather than a task model. It just doesn't seem like it's as worthwhile - if you really need to have that faux synchronous IO, you could use FRP. I'm sure a lot of people would disagree with me, given the general direction rust has been going with tasks (IO, task-local errors, etc.) ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
