On 15/05/2011, at 10:15 PM, David Herman wrote: > FWIW, I have plenty of friends in the PL research world who design type > systems that are not based on your restrictive definitions (type system = > initial algebra, type system design = category theory). But I have no > interest in a theoretical shouting match. We'd probably lose -- no one on our > team is a category theorist -- so there's no point in fighting.
I'm not either, I'm just making a comment. Note I said "modern type system". Clearly I am talking about what theoreticians think a type system is these days. None of the ones I know would accept that C++ has a type system in that sense, for example. Anyhow, please ignore my comment, it was just off the cuff and really it was intended to be a bit humorous! I should remember email isn't so good for that;( > > Regardless, I believe our policies are clear. And I believe that it's pretty > common etiquette in many cultures throughout the world that you don't walk > into a community and tell them "do things my way or give up everything you're > doing because otherwise it's all doomed." That's rude, it's presumptuous, and > I would suggest it's an awfully self-destructive way to think. Dave, I'm not trying to be presumptuous or rude. I'm actually trying to help by imparting a little of my experience. And also I'm trying to learn enough about Rust and the team working on it to decide whether to give up my own project in favour of it. I spent 10 years on the C++ committee, a lot of it working on templates. [As an NB representative] Then I designed my own language to overcome many of the shortcomings of C++. So basically I've been into programming for 35 years and 20 or so of that seriously into languages, and around 15 I think actually writing a compiler. Much of that was full time and entirely unpaid. I am trying to present a case that not using tuples for function arguments has a high price, and that the justification for multiple arguments, to support aliases, to support statically assured down stack pointers for efficiency .. may not be as strong as is believed. At this point in time I believe it is true that on an ABI boundary, it is necessary in some cases for maximum optimisation. But in some cases it isn't necessary, and it is never necessary calling a known function (I mean, the function definition is known) which I think you would say is "in the same crate" if I understand crates properly. This basically means that whilst you're "all in Rust" you probably have the option to widen the "definition" of a crate dynamically from small during prototyping to "whole program" later, and get major optimisations benefits .. including the removal of overheads from tuples vs multiple arguments. I'm not saying you should do this, but I am warning that, well, when someone gets a new language the first thing they will probably do after "hello world" is try to implement some basic data structures, lists, trees etc, because without them they can't write applications, and naturally they would want those data structures to be polymorphic. Anyhow there are lots of other things that could be talked about. I have some interesting algorithms that might be useful, for example parallel assignment, which is used to optimise tail recursive function calls to minimise the number of temporaries. [That problem is NP complete so the algorithm is only a heuristic]. I also know how to do inlining (including polymorphic functions), in the presence of nested functions (does Rust have nested functions?), and although the algorithm isn't nearly as good as it could be I think it is the best one available (it does a much better job than MLton for example). Most of this stuff is about performance, and I understand that matters to Rust people? And most of it achieves a lot more than minor tweaks at interface boundaries because it tries to eliminate boundaries (which of course isn't possible in the interface of a function of a binary library). -- john skaller [email protected] _______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
