Re: [rust-dev] A plea for removing context-free ambiguity / context-required parsing

2012-08-16 Thread Patrick Walton
On 08/16/2012 02:16 PM, David Rajchenbach-Teller wrote: Not sure how that would work out in practice. Btw, in Opa, we used to have lots of bugs caused by this kind of ambiguity (and a purely structural type system), so I believe this is worth spending some time ironing out. I think it's worth

Re: [rust-dev] A plea for removing context-free ambiguity / context-required parsing

2012-08-16 Thread David Rajchenbach-Teller
On 8/16/12 10:51 PM, Patrick Walton wrote: > On 8/16/12 1:33 PM, David Rajchenbach-Teller wrote: >> fwiw, OCaml does >> >> match myfoo with >> | #bar -> (*any item of sum type bar*) >> | `bar -> (*sum constructor `bar*) >> | bar -> (*binding*) >> >> It works nicely in practice. > > Bu

Re: [rust-dev] A plea for removing context-free ambiguity / context-required parsing

2012-08-16 Thread Nathan
I caught up a little on the state of this topic in IRC, and now I see it's an old topic. I don't want to rub old callouses, but I do hope my use cases are motivating. On Thu, Aug 16, 2012 at 2:31 PM, Niko Matsakis wrote: > We have discussed this point for some time, though I don't know if anyon

Re: [rust-dev] proposal: unify module/type namespaces

2012-08-16 Thread Niko Matsakis
On 8/16/12 3:13 PM, Patrick Walton wrote: Might be a good idea to hold off on the dot notation switch though. To be clear: I did not propose removing dot notation or changing it in any way. I just said that if we did merge type/module namespaces, it opens the door to being able to import "me

Re: [rust-dev] proposal: unify module/type namespaces

2012-08-16 Thread Patrick Walton
I'm tentatively in favor of this proposal. Might be a good idea to hold off on the dot notation switch though. I also wonder if one should have to explicitly import trait methods as well. To make Niko's proposal clearer: here's how one would define the MyType: mod foo { mod bar {

Re: [rust-dev] Naming conventions for constructors

2012-08-16 Thread Brian Anderson
On 08/14/2012 04:35 PM, Brian Anderson wrote: Hey. We need a consistent naming scheme for constructor functions. The current convention is to give these functions the same name as the type they create, so `core::dvec::dvec` is created by calling `core::dvec::dvec()`. We are in the process of ch

Re: [rust-dev] A plea for removing context-free ambiguity / context-required parsing

2012-08-16 Thread Niko Matsakis
We have discussed this point for some time, though I don't know if anyone raised the security review angle specifically before. I think there is a good case to be made that lint warnings adequately address this problem. You can set the mode to cause an error if case-distinctions are not obser

Re: [rust-dev] A plea for removing context-free ambiguity / context-required parsing

2012-08-16 Thread Patrick Walton
On 8/16/12 1:33 PM, David Rajchenbach-Teller wrote: fwiw, OCaml does match myfoo with | #bar -> (*any item of sum type bar*) | `bar -> (*sum constructor `bar*) | bar -> (*binding*) It works nicely in practice. But OCaml uses capitalization for sum types, like Haskell does. Also

Re: [rust-dev] A plea for removing context-free ambiguity / context-required parsing

2012-08-16 Thread Patrick Walton
On 8/16/12 1:26 PM, Nathan wrote: The solution I'm proposing is to alter the grammar so that it's possible by looking at only the pattern matching text, without knowing any other context whether it is a discriminator match or a new binding. There are at least two ways to do this: One is to ensu

Re: [rust-dev] A plea for removing context-free ambiguity / context-required parsing

2012-08-16 Thread David Rajchenbach-Teller
On 8/16/12 10:26 PM, Nathan wrote: > One is to ensure that it's always possible when looking at an > identifier in *any* context whether or not it is a discriminator or a > binding/reference. Haskell does this elegantly, IMO, by forcing > discriminators to start with upper case and bindings/refere

[rust-dev] A plea for removing context-free ambiguity / context-required parsing

2012-08-16 Thread Nathan
Hello, I'm brand new to rust. I've read the tutorial once and not the manual. My first attempt at running "make" failed with a compiler error (I'll email or irc separately). I apologize if I'm re-covering ground or missing something, but I felt this general point was important to make as early

Re: [rust-dev] proposal: unify module/type namespaces

2012-08-16 Thread Gustavo Hexsel
Sorry, I just lurk the mailing list once in a while. I just wanted to point that allowing multiple, slightly dissonant ways of calling the same function will inevitably lead to code style wars. Maybe one of them should be pointed as recommended, at least? []s Gus _

Re: [rust-dev] proposal: unify module/type namespaces

2012-08-16 Thread Benjamin Striegel
> For example, `max()` can be defined as a method like so: > > trait Number { > fn max(self, other: self) -> self; > } > > and then used as follows: > > num_a.max(num_b) > > or as follows: > > import Number::max; > ... > max(num_a, num_b) > > whichever is more convenient or more aesthetically pleas

[rust-dev] proposal: unify module/type namespaces

2012-08-16 Thread Niko Matsakis
Currently modules and types occupy distinct namespaces. I propose that we merge them into one. The main reason to do this is that we can write something like: import foo::bar::MyType; ... let instance = MyType::new() where `new()` is a static fn (hereafter, selfless fn, because it is technica