Re: [rust-dev] 2 possible simplifications: reverse application, records as arguments

2012-04-24 Thread Niko Matsakis
Record patterns are fairly close to what you want. We don't use them consistently, but if we did, they would allow us to write things like: alt it.node { ast::item_impl({tps, _}) { ... } ast::item_enum({tps, _}) { ... } ... } It has an extra level of braces,

Re: [rust-dev] 2 possible simplifications: reverse application, records as arguments

2012-04-23 Thread gasche
I've been wondering about a problem tightly related to named parameters: named enum constructor arguments. SML has had the ability to define algebraic datatypes as sum of (named) records, and I think that is something that is missing in current rust. The code antipattern that cries for it is

Re: [rust-dev] 2 possible simplifications: reverse application, records as arguments

2012-04-23 Thread Patrick Walton
On 04/21/2012 10:28 AM, gasche wrote: I've been wondering about a problem tightly related to named Re. function types: if you consider those parameter-passing structures as first class (which does necessarily mean that they are convenient to use, for example if they're not adressable they will

Re: [rust-dev] 2 possible simplifications: reverse application, records as arguments

2012-04-23 Thread Joe Groff
On Apr 23, 2012, at 8:34 AM, Patrick Walton pwal...@mozilla.com wrote: * We'd still need formal parameters for C interoperability. At the ABI level, a single-argument function applied to a 3-ary tuple is very different from a function with 3 arguments. Could the rust calling convention

Re: [rust-dev] 2 possible simplifications: reverse application, records as arguments

2012-04-16 Thread Graydon Hoare
On 12-04-13 11:07 PM, Kobi Lurie wrote: one is reverse application. it's actually logical and might simplify things. (similar to extension methods in c#) there are no classes, but a syntax like: obj.method(b,c) still exists. from what I could tell, the function is really method(obj,b,c), and

Re: [rust-dev] 2 possible simplifications: reverse application, records as arguments

2012-04-16 Thread Nate Bragg
On Mon, Apr 16, 2012 at 3:22 PM, Graydon Hoare gray...@mozilla.com wrote: - Our records are order-sensitive, to be C-structure compatible. Keyword arguments are usually argued-for (as you are doing here) as a way to make function arguments order-insensitive. We'd need to decide whether

[rust-dev] 2 possible simplifications: reverse application, records as arguments

2012-04-14 Thread Kobi Lurie
such a flurry of activity here :-D I saw a few things I liked, in the felix language (and some that are above my head for now.) Do you think they fit rust well or not? one is reverse application. it's actually logical and might simplify things. (similar to extension methods in c#) there are

Re: [rust-dev] 2 possible simplifications: reverse application, records as arguments

2012-04-14 Thread David Rajchenbach-Teller
On 4/14/12 8:07 AM, Kobi Lurie wrote: such a flurry of activity here :-D I saw a few things I liked, in the felix language (and some that are above my head for now.) Do you think they fit rust well or not? one is reverse application. it's actually logical and might simplify things.

Re: [rust-dev] 2 possible simplifications: reverse application, records as arguments

2012-04-14 Thread Benjamin Striegel
So this would basically mean that a function like: fn wtever(foo: int, bar: str) { ... } could be called as either: wtever(1, hello); // tuple syntax wtever{foo: 1, bar: hello}; // record syntax Not sure how I feel about invoking a function using a record literal, its' a little bit elegant