Re: [rust-dev] average function

[Brendan Zabarauskas]

Base numeric types are implicitly clonable. For example, if you were mapping 
over a `&[int]` vector, for example, you would be able to do `.map(|x| *x)` and 
`x` would be implicitly cloned. For generic types like `T: Clone`, Rust 
complains because it thinks you are trying to move the value out of the vector, 
which is impossible. Therefore you must be explicit by calling `.clone()`.

~B☼ 

On 26/09/2013, at 7:11 AM, Thad Guidry  wrote:

> wait a sec.. your cheating in the benchmark...
> 
> Why did you clone() the array for theirs and not Lawrence's ?
> 
> See here: https://gist.github.com/qznc/6704053#file-benchmark-L76
> 
> 
> 
> On Wed, Sep 25, 2013 at 4:07 PM, Thad Guidry  wrote:
> 
> Apparently, the version of Scott Lawrence is the fastest one, unless I
> made a mistake.
> 
> 
> Longest code (and simplest to understand code)... FTW ! :)  (as usual)
> 
> -- 
> -Thad
> Thad on Freebase.com
> Thad on LinkedIn
> 
> 
> 
> -- 
> -Thad
> Thad on Freebase.com
> Thad on LinkedIn
> ___
> 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

Re: [rust-dev] average function

[Andreas Zwinkau]

I use clone, because the values are moved into the closure. Otherwise
type checker complains about use of moved value.

When I clone for lawrence as well, the numbers do not change.

On Wed, Sep 25, 2013 at 11:11 PM, Thad Guidry  wrote:
> wait a sec.. your cheating in the benchmark...
>
> Why did you clone() the array for theirs and not Lawrence's ?
>
> See here: https://gist.github.com/qznc/6704053#file-benchmark-L76
>
>
>
> On Wed, Sep 25, 2013 at 4:07 PM, Thad Guidry  wrote:
>>>
>>>
>>> Apparently, the version of Scott Lawrence is the fastest one, unless I
>>> made a mistake.
>>>
>>
>> Longest code (and simplest to understand code)... FTW ! :)  (as usual)
>>
>> --
>> -Thad
>> Thad on Freebase.com
>> Thad on LinkedIn
>
>
>
>
> --
> -Thad
> Thad on Freebase.com
> Thad on LinkedIn



-- 
Andreas Zwinkau

work email: zwin...@kit.edu
private email: q...@web.de
homepage: http://beza1e1.tuxen.de
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] "Computed" maps

[Daniel Micay]

On Wed, Sep 25, 2013 at 10:36 PM, David Brown  wrote:

> Let's say I'm implementing some type of map-like structure that I'd
> like to be able to implement the Map trait on.
>
> However, my map doesn't actually store the 'V' directly, but they are
> computed/retrieve/cached in some manner.
>
> Is this possible with the existing map trait?  Given that:
>
>  fn find<'a>(&'a self, key: &K) -> Option<&'a V>;
>
> doesn't the V need to be a pointer to something with the same lifetime
> as self?
>
> Is there a way of dealing with this, or should I just implement my own
> similar find function, not implementing Map, and return an Option
> instead?
>

The Map trait represents a map storing the values, so it can't be used for
that use case.
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

[rust-dev] "Computed" maps

[David Brown]

Let's say I'm implementing some type of map-like structure that I'd
like to be able to implement the Map trait on.

However, my map doesn't actually store the 'V' directly, but they are
computed/retrieve/cached in some manner.

Is this possible with the existing map trait?  Given that:

 fn find<'a>(&'a self, key: &K) -> Option<&'a V>;

doesn't the V need to be a pointer to something with the same lifetime
as self?

Is there a way of dealing with this, or should I just implement my own
similar find function, not implementing Map, and return an Option
instead?

Thanks,
David
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Some suggestions of Rust language

[Patrick Walton]

On 9/25/13 3:41 PM, Kevin Ballard wrote:

I believe the intention was to allow `mut` in the same places you
could put `ref` today in a pattern match.


Yes.

Patrick
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Some suggestions of Rust language

[Benjamin Striegel]

> I believe the intention was to allow `mut` in the same places you could
put `ref` today in a pattern match.

I was also under this impression, though I've never seen it explicitly laid
out anywhere. Would be nice to see if the devs are on board with this
extension to the pattern grammar.
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Should we add a Haskell-like `$` operator?

[Micah Chalmer]

Speaking of macros and overly nested functional style--I had some code with 
deeply nested "do" blocks and experimented with a multi_do macro that creates 
syntax reminiscent of haskell's "do" notation.  It's more syntactically noisy 
than would be preferable--I couldn't get it to parse unambiguously without the 
|| and the =>, which I really didn't want.  Having to put the final block 
inside the parentheses of the macro invocation made it not really worth it, 
because when using it, you're always nested two deep, so it'd only reduce 
indentation for three or more levels deep.  But in case anyone's interested:

macro_rules! multi_do {
(|$args:pat| <- $e:expr; $(|$args_rest:pat| <- $e_rest:expr;)+
 => $blk:block) =>
(do $e |$args| { multi_do!($(|$args_rest| <- $e_rest;)+ => $blk) });
{|$args:pat| <- $e:expr; => $blk:block} => (do $e |$args| $blk);
}

it's used it like this:

multi_do!(
|a| <- first_function(x);
|b| <- second_function(y);
|c| <- third_function();
=> {
compute_stuff_with(a,b, c); 
});

which expands to:

do first_function(x) |a| {
do second_function(y) |b| {
do third_function() |c| {
compute_stuff_with(a, b, c);
}
}
}

On Sep 25, 2013, at 7:39 PM, Marvin Löbel wrote:

> Argh, I forgot about macros! Nevermind then. :P
> 
> On 09/25/2013 08:33 PM, Benjamin Striegel wrote:
>> Note that we reserve the dollar sign ($) for use in macros, so it wouldn't 
>> be able to appear in regular Rust code without some sort of escaping 
>> mechanism. I also don't see anything like this happening before Rust 2.0 at 
>> the earliest.
>> 
>> 
>> On Wed, Sep 25, 2013 at 2:40 PM, Marvin Löbel  
>> wrote:
>> We don't use the symbol in our syntax, but are using functional paradigm 
>> that sometimes result in a bit hard to read nested calls.
>> 
>> I'd propose that it works similar to `do`, in that it allows to move the 
>> last expression of an function or method call after the parentheses, though 
>> they would still remain required for ambiguity reasons:
>> 
>> ~~~
>>a(b(c(1,d(2,3,4,e()
>> == a() $ b() $ c(1) $ d(2,3,4) $ e()
>> 
>> let v: ~[uint] = from_iter() $ range(0, 100);
>> ~~~
>> 
>> In that sense, it wouldn't really be an operator but syntactic sugar for a 
>> function call.
>> It might even be possible to replace `do` with it, though the now required 
>> parentheses would make it longer:
>> 
>> ~~~
>> do task::spawn { ... }
>> task::spawn() $ || { ... }
>> ~~~
>> 
>> Downside is of course that it adds another symbol, which could alienate more 
>> potentiall users, and it could mean a shift-away-from or at least an 
>> inconsistency-with methods and method chaining in general.
>> 
>> Which would be ironic because I wanted it in some complicated Iterator 
>> chain. ;)
>> 
>> It could of course always be implemented as a syntax extension, and in any 
>> case I don't expect this to get any attention before Rust 2.0. :)
>> ___
>> 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
> 
> ___
> 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

Re: [rust-dev] Some suggestions of Rust language

[Kevin Ballard]

On Sep 25, 2013, at 2:58 PM, Jack Moffitt  wrote:

 Miss it? Did it ever work? This seems like a bug though. Mutability is
 inherited, so without this there's no way to do mutable destructuring
 bind right?
>>> Apparently it went away in commit f9b54541 and the workaround used there
>>> is `let (foo, bar) = ...; let mut foo = foo;` etc.
>>> 
>>> Seems intentional, but I don't recall the rationale.
>> 
>> The eventual plan is to say `let (mut foo, bar) = ...;`. We just don't yet 
>> support that.
> 
> The commit's intention as i recall was to change this `let mut foo,
> bar;` which would make bar mutable. I'm not sure the intent was to
> affect destructuring bind.
> 
> While `let (mut foo, bar)` matches pattern syntax for tuples, it seems
> weird for structs, although I guess it probably matches there too.
> 
> `let mut Foo { x: x, y: y } = some_foo;` seems better than `let Foo {
> mut x: x, mut y: y} = some_foo;`. Seems like both are probably
> reasonable to have.
> 
> I don't feel super strongly about this, I just thought it weird that
> destructuring let doesn't work with mut in the obvious (to me anyway)
> way.

I believe the intention was to allow `mut` in the same places you could put 
`ref` today in a pattern match.

-Kevin
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Introducing wxRust

[Martin DeMello]

Did you try using bindgen on the wxc header file? If there were bits
it couldn't handle, I'd be interested in helping fix that.

martin

On Wed, Sep 25, 2013 at 10:49 AM, KENZ gelsoft  wrote:
> Hello, everyone.
>
> I would like to introduce my experimental project, wxRust.
> Which is a wxWidgets binding for Rust.
>
>   https://github.com/kenz-gelsoft/wxRust
>
> This binding is based on the wxHaskell especially its "wxc"*1
> C-Language wxWidgets binding part.
>
> Currently, it just converts wxc's header file to `extern fn`s and
> export them as a rust library.
>
> Test program has just started working which opens a wxFrame
> by calling wxc's C interface from extern fn.
>
> Current state is pre-alpha experimental state, there's no stable API,
> hard to use, but announced here for someone planning similar project.
>
> I'm planning for next generating simple OOP style wrapper as rust
> traits for each classes from wxc's header.
>
> There is many problems to tackle, for example how it can work
> with multitask or, library users can write wx GUI programs easier.
> Any helps or feedbacks are welcome.
>
>  *1: [http://www.haskell.org/haskellwiki/WxHaskell#Status]
>
>
> Thanks,
> --
> KENZ 
>
>
> ___
> 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

Re: [rust-dev] Some suggestions of Rust language

[Jack Moffitt]

>>> Miss it? Did it ever work? This seems like a bug though. Mutability is
>>> inherited, so without this there's no way to do mutable destructuring
>>> bind right?
>> Apparently it went away in commit f9b54541 and the workaround used there
>> is `let (foo, bar) = ...; let mut foo = foo;` etc.
>>
>> Seems intentional, but I don't recall the rationale.
>
> The eventual plan is to say `let (mut foo, bar) = ...;`. We just don't yet 
> support that.

The commit's intention as i recall was to change this `let mut foo,
bar;` which would make bar mutable. I'm not sure the intent was to
affect destructuring bind.

While `let (mut foo, bar)` matches pattern syntax for tuples, it seems
weird for structs, although I guess it probably matches there too.

`let mut Foo { x: x, y: y } = some_foo;` seems better than `let Foo {
mut x: x, mut y: y} = some_foo;`. Seems like both are probably
reasonable to have.

I don't feel super strongly about this, I just thought it weird that
destructuring let doesn't work with mut in the obvious (to me anyway)
way.

jack.
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Some suggestions of Rust language

[Kevin Ballard]

On Sep 25, 2013, at 2:42 PM, Benjamin Herr  wrote:

> On Wed, 2013-09-25 at 15:23 -0600, Jack Moffitt wrote:
>>> (I miss `let mut (a, b) = ...`!)
>> 
>> Miss it? Did it ever work? This seems like a bug though. Mutability is
>> inherited, so without this there's no way to do mutable destructuring
>> bind right?
>> 
>> jack.
> 
> Apparently it went away in commit f9b54541 and the workaround used there
> is `let (foo, bar) = ...; let mut foo = foo;` etc.
> 
> Seems intentional, but I don't recall the rationale.

The eventual plan is to say `let (mut foo, bar) = ...;`. We just don't yet 
support that.

-Kevin
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Some suggestions of Rust language

[Benjamin Herr]

On Wed, 2013-09-25 at 15:23 -0600, Jack Moffitt wrote:
> > (I miss `let mut (a, b) = ...`!)
> 
> Miss it? Did it ever work? This seems like a bug though. Mutability is
> inherited, so without this there's no way to do mutable destructuring
> bind right?
> 
> jack.

Apparently it went away in commit f9b54541 and the workaround used there
is `let (foo, bar) = ...; let mut foo = foo;` etc.

Seems intentional, but I don't recall the rationale.

-benh

___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Should we add a Haskell-like `$` operator?

[Marvin Löbel]

Argh, I forgot about macros! Nevermind then. :P

On 09/25/2013 08:33 PM, Benjamin Striegel wrote:
Note that we reserve the dollar sign ($) for use in macros, so it 
wouldn't be able to appear in regular Rust code without some sort of 
escaping mechanism. I also don't see anything like this happening 
before Rust 2.0 at the earliest.



On Wed, Sep 25, 2013 at 2:40 PM, Marvin Löbel > wrote:


We don't use the symbol in our syntax, but are using functional
paradigm that sometimes result in a bit hard to read nested calls.

I'd propose that it works similar to `do`, in that it allows to
move the last expression of an function or method call after the
parentheses, though they would still remain required for ambiguity
reasons:

~~~
   a(b(c(1,d(2,3,4,e()
== a() $ b() $ c(1) $ d(2,3,4) $ e()

let v: ~[uint] = from_iter() $ range(0, 100);
~~~

In that sense, it wouldn't really be an operator but syntactic
sugar for a function call.
It might even be possible to replace `do` with it, though the now
required parentheses would make it longer:

~~~
do task::spawn { ... }
task::spawn() $ || { ... }
~~~

Downside is of course that it adds another symbol, which could
alienate more potentiall users, and it could mean a
shift-away-from or at least an inconsistency-with methods and
method chaining in general.

Which would be ironic because I wanted it in some complicated
Iterator chain. ;)

It could of course always be implemented as a syntax extension,
and in any case I don't expect this to get any attention before
Rust 2.0. :)
___
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


___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Some suggestions of Rust language

[Keegan McAllister]

I was thinking something like

struct Foo { x: int, y: int }

fn f(foo: &mut Foo) {
(foo.x, foo.y) = g();
}

(I actually get an ICE building this (with with appropriate g() and main()) 
using rustc 0.8 eb55348.)

I kind of like this idea of letting arbitrary lvalues appear in the "variable" 
position in pattern syntax.  But I don't know if it would turn out to be a can 
of worms.

keegan

- Original Message -
From: "Matthew McPherrin" 
To: "Benjamin Striegel" 
Cc: rust-dev@mozilla.org
Sent: Wednesday, September 25, 2013 12:10:29 PM
Subject: Re: [rust-dev] Some suggestions of Rust language

Maybe if you were writing code like this:

let mut a = 1; let mut b = 2;
loop {
...
(a, b) = F();
   ...
}
(b, a)

On Wed, Sep 25, 2013 at 11:29 AM, Benjamin Striegel
 wrote:
> Is there a use case that necessitates such a feature? The following code
> works today:
>
> let a = 1;
> let b = 2;
> let (a, b) = (b, a);
>
> Not sure why that wouldn't be sufficient.
>
>
> On Wed, Sep 25, 2013 at 2:50 PM, Marvin Löbel 
> wrote:
>>
>> On 09/25/2013 06:37 PM, Diggory Hardy wrote:
>>>
>>> Hi,
>>>
>>> On Wednesday 25 September 2013 08:29:17 Patrick Walton wrote:

 On 9/25/13 6:32 AM, Alexander Sun wrote:
>
> Multiple return values
> if has a function like this:
>
> fn addsub(x : int, y : int) -> (int, int) {
>
> return (x+y,x-y);
>
> }
>
> them, this is valid:
>
> let (b,c) = addsub(x, y);
>
> but this is invalid;
>
> let b:int =0;
> let c:int =0;
> (b,c) = addsub(x, y);
>
> also invalid:
>
> let (b,c)  = (0, 0);
> (b,c) = addsub(x, y);

 If we did this, we wouldn't know whether to parse a pattern or an
 expression when starting a statement. This isn't fixable without trying
 to define some sort of cover grammar that covers both expressions and
 patterns, like ECMAScript 6 does. I don't know if this would work in
 Rust.
>>>
>>> Are there any plans to support something like:
>>>
>>> assign (b,c) = addsub(x,y);
>>>
>>> for existing b,c? The best I could come up with is:
>>>
>>>  match two_nums(2) {
>>>  (x,y) => {a=x;b=y;}
>>>  }
>>>
>>> Not that I need this; just curious.
>>
>> I had the idea once to reuse the `in` keyword for that:
>>
>> let mut a = 0; let mut b = 1;
>> in (a, b) = (b, a);
>>
>> No idea how feasible that would be, though.
>>
>> ___
>> 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
>
___
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

Re: [rust-dev] Some suggestions of Rust language

[Jack Moffitt]

> (I miss `let mut (a, b) = ...`!)

Miss it? Did it ever work? This seems like a bug though. Mutability is
inherited, so without this there's no way to do mutable destructuring
bind right?

jack.
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Some suggestions of Rust language

[Benjamin Herr]

On Wed, 2013-09-25 at 14:29 -0400, Benjamin Striegel wrote:
> Is there a use case that necessitates such a feature? The following
> code works today:
> 
> 
> let a = 1;
> 
> let b = 2;
> 
> let (a, b) = (b, a);
> 
> 
> Not sure why that wouldn't be sufficient.

Motivating toy example then ;)

fn fib() {
let mut a = 0;
let mut b = 1;

loop {
printfln!(a);
(a, b) = (b, a + b);
}
}


(I miss `let mut (a, b) = ...`!)

-benh


___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] average function

[Thad Guidry]

wait a sec.. your cheating in the benchmark...

Why did you clone() the array for theirs and not Lawrence's ?

See here: https://gist.github.com/qznc/6704053#file-benchmark-L76



On Wed, Sep 25, 2013 at 4:07 PM, Thad Guidry  wrote:

>
>> Apparently, the version of Scott Lawrence is the fastest one, unless I
>> made a mistake.
>>
>>
> Longest code (and simplest to understand code)... FTW ! :)  (as usual)
>
> --
> -Thad
> Thad on Freebase.com 
> Thad on LinkedIn 
>



-- 
-Thad
Thad on Freebase.com 
Thad on LinkedIn 
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] average function

[Thad Guidry]

>
>
> Apparently, the version of Scott Lawrence is the fastest one, unless I
> made a mistake.
>
>
Longest code (and simplest to understand code)... FTW ! :)  (as usual)

-- 
-Thad
Thad on Freebase.com 
Thad on LinkedIn 
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] average function

[Andreas Zwinkau]

Thanks, I used it for a benchmarking mod. Since we have three
different versions of average here, I benchmarked them.

https://gist.github.com/qznc/6704053

Apparently, the version of Scott Lawrence is the fastest one, unless I
made a mistake.

-- 
Andreas Zwinkau

work email: zwin...@kit.edu
private email: q...@web.de
homepage: http://beza1e1.tuxen.de
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Introducing wxRust

[Corey Richardson]

Very cool! It's nice to actually say we have a binding to *some* GUI library.

On Wed, Sep 25, 2013 at 1:49 PM, KENZ gelsoft  wrote:
> Hello, everyone.
>
> I would like to introduce my experimental project, wxRust.
> Which is a wxWidgets binding for Rust.
>
>   https://github.com/kenz-gelsoft/wxRust
>
> This binding is based on the wxHaskell especially its "wxc"*1
> C-Language wxWidgets binding part.
>
> Currently, it just converts wxc's header file to `extern fn`s and
> export them as a rust library.
>
> Test program has just started working which opens a wxFrame
> by calling wxc's C interface from extern fn.
>
> Current state is pre-alpha experimental state, there's no stable API,
> hard to use, but announced here for someone planning similar project.
>
> I'm planning for next generating simple OOP style wrapper as rust
> traits for each classes from wxc's header.
>
> There is many problems to tackle, for example how it can work
> with multitask or, library users can write wx GUI programs easier.
> Any helps or feedbacks are welcome.
>
>  *1: [http://www.haskell.org/haskellwiki/WxHaskell#Status]
>
>
> Thanks,
> --
> KENZ 
>
>
> ___
> 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

Re: [rust-dev] Some suggestions of Rust language

[Matthew McPherrin]

Maybe if you were writing code like this:

let mut a = 1; let mut b = 2;
loop {
...
(a, b) = F();
   ...
}
(b, a)

On Wed, Sep 25, 2013 at 11:29 AM, Benjamin Striegel
 wrote:
> Is there a use case that necessitates such a feature? The following code
> works today:
>
> let a = 1;
> let b = 2;
> let (a, b) = (b, a);
>
> Not sure why that wouldn't be sufficient.
>
>
> On Wed, Sep 25, 2013 at 2:50 PM, Marvin Löbel 
> wrote:
>>
>> On 09/25/2013 06:37 PM, Diggory Hardy wrote:
>>>
>>> Hi,
>>>
>>> On Wednesday 25 September 2013 08:29:17 Patrick Walton wrote:

 On 9/25/13 6:32 AM, Alexander Sun wrote:
>
> Multiple return values
> if has a function like this:
>
> fn addsub(x : int, y : int) -> (int, int) {
>
> return (x+y,x-y);
>
> }
>
> them, this is valid:
>
> let (b,c) = addsub(x, y);
>
> but this is invalid;
>
> let b:int =0;
> let c:int =0;
> (b,c) = addsub(x, y);
>
> also invalid:
>
> let (b,c)  = (0, 0);
> (b,c) = addsub(x, y);

 If we did this, we wouldn't know whether to parse a pattern or an
 expression when starting a statement. This isn't fixable without trying
 to define some sort of cover grammar that covers both expressions and
 patterns, like ECMAScript 6 does. I don't know if this would work in
 Rust.
>>>
>>> Are there any plans to support something like:
>>>
>>> assign (b,c) = addsub(x,y);
>>>
>>> for existing b,c? The best I could come up with is:
>>>
>>>  match two_nums(2) {
>>>  (x,y) => {a=x;b=y;}
>>>  }
>>>
>>> Not that I need this; just curious.
>>
>> I had the idea once to reuse the `in` keyword for that:
>>
>> let mut a = 0; let mut b = 1;
>> in (a, b) = (b, a);
>>
>> No idea how feasible that would be, though.
>>
>> ___
>> 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
>
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Should we add a Haskell-like `$` operator?

[Benjamin Striegel]

Note that we reserve the dollar sign ($) for use in macros, so it wouldn't
be able to appear in regular Rust code without some sort of escaping
mechanism. I also don't see anything like this happening before Rust 2.0 at
the earliest.


On Wed, Sep 25, 2013 at 2:40 PM, Marvin Löbel wrote:

> We don't use the symbol in our syntax, but are using functional paradigm
> that sometimes result in a bit hard to read nested calls.
>
> I'd propose that it works similar to `do`, in that it allows to move the
> last expression of an function or method call after the parentheses, though
> they would still remain required for ambiguity reasons:
>
> ~~~
>a(b(c(1,d(2,3,4,e()
> == a() $ b() $ c(1) $ d(2,3,4) $ e()
>
> let v: ~[uint] = from_iter() $ range(0, 100);
> ~~~
>
> In that sense, it wouldn't really be an operator but syntactic sugar for a
> function call.
> It might even be possible to replace `do` with it, though the now required
> parentheses would make it longer:
>
> ~~~
> do task::spawn { ... }
> task::spawn() $ || { ... }
> ~~~
>
> Downside is of course that it adds another symbol, which could alienate
> more potentiall users, and it could mean a shift-away-from or at least an
> inconsistency-with methods and method chaining in general.
>
> Which would be ironic because I wanted it in some complicated Iterator
> chain. ;)
>
> It could of course always be implemented as a syntax extension, and in any
> case I don't expect this to get any attention before Rust 2.0. :)
> __**_
> 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

Re: [rust-dev] Some suggestions of Rust language

[Benjamin Striegel]

Is there a use case that necessitates such a feature? The following code
works today:

let a = 1;
let b = 2;
let (a, b) = (b, a);

Not sure why that wouldn't be sufficient.


On Wed, Sep 25, 2013 at 2:50 PM, Marvin Löbel wrote:

> On 09/25/2013 06:37 PM, Diggory Hardy wrote:
>
>> Hi,
>>
>> On Wednesday 25 September 2013 08:29:17 Patrick Walton wrote:
>>
>>> On 9/25/13 6:32 AM, Alexander Sun wrote:
>>>
 Multiple return values
 if has a function like this:

 fn addsub(x : int, y : int) -> (int, int) {

 return (x+y,x-y);

 }

 them, this is valid:

 let (b,c) = addsub(x, y);

 but this is invalid;

 let b:int =0;
 let c:int =0;
 (b,c) = addsub(x, y);

 also invalid:

 let (b,c)  = (0, 0);
 (b,c) = addsub(x, y);

>>> If we did this, we wouldn't know whether to parse a pattern or an
>>> expression when starting a statement. This isn't fixable without trying
>>> to define some sort of cover grammar that covers both expressions and
>>> patterns, like ECMAScript 6 does. I don't know if this would work in
>>> Rust.
>>>
>> Are there any plans to support something like:
>>
>> assign (b,c) = addsub(x,y);
>>
>> for existing b,c? The best I could come up with is:
>>
>>  match two_nums(2) {
>>  (x,y) => {a=x;b=y;}
>>  }
>>
>> Not that I need this; just curious.
>>
> I had the idea once to reuse the `in` keyword for that:
>
> let mut a = 0; let mut b = 1;
> in (a, b) = (b, a);
>
> No idea how feasible that would be, though.
>
> __**_
> 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

[rust-dev] Introducing wxRust

[KENZ gelsoft]

Hello, everyone.

I would like to introduce my experimental project, wxRust.
Which is a wxWidgets binding for Rust.

  https://github.com/kenz-gelsoft/wxRust

This binding is based on the wxHaskell especially its "wxc"*1
C-Language wxWidgets binding part.

Currently, it just converts wxc's header file to `extern fn`s and
export them as a rust library.

Test program has just started working which opens a wxFrame
by calling wxc's C interface from extern fn.

Current state is pre-alpha experimental state, there's no stable API,
hard to use, but announced here for someone planning similar project.

I'm planning for next generating simple OOP style wrapper as rust
traits for each classes from wxc's header.

There is many problems to tackle, for example how it can work
with multitask or, library users can write wx GUI programs easier.
Any helps or feedbacks are welcome.

 *1: [http://www.haskell.org/haskellwiki/WxHaskell#Status]


Thanks,
--
KENZ 
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Should we add a Haskell-like `$` operator?

[Andres Osinski]

What is the possibility that Rust allow certain traits for operators such
as these to be implemented as libraries?

I can certainly see the benefits of stuff like that, although I don't think
it might be a good idea to depend on such operators (I *love* overloaded
operators in linear algebra and combinators, but they are questionable
outside of specific niches, thus their introduction as traits would
probably be best)


On Wed, Sep 25, 2013 at 1:50 PM, Oren Ben-Kiki  wrote:

> Not sure about $ but I sometimes miss the |> operator (which takes the
> value from the left and inserts it as the 1st argument of the function call
> to the right).
>
> foo(a, b) |> bar(c, d) |> baz(e, f)
> == baz(bar(foo(a, b), c, d), e, f)
>
> This allows for easier "functional" decompsition of chains of operations.
> I found it to be very useful when writing Elixir; in Rust there's the
> OO-like traits which may make it less useful - it still might be worthwhile
> for people writing more functional code.
>
>
> On Wed, Sep 25, 2013 at 9:40 PM, Marvin Löbel wrote:
>
>> We don't use the symbol in our syntax, but are using functional paradigm
>> that sometimes result in a bit hard to read nested calls.
>>
>> I'd propose that it works similar to `do`, in that it allows to move the
>> last expression of an function or method call after the parentheses, though
>> they would still remain required for ambiguity reasons:
>>
>> ~~~
>>a(b(c(1,d(2,3,4,e()
>> == a() $ b() $ c(1) $ d(2,3,4) $ e()
>>
>> let v: ~[uint] = from_iter() $ range(0, 100);
>> ~~~
>>
>> In that sense, it wouldn't really be an operator but syntactic sugar for
>> a function call.
>> It might even be possible to replace `do` with it, though the now
>> required parentheses would make it longer:
>>
>> ~~~
>> do task::spawn { ... }
>> task::spawn() $ || { ... }
>> ~~~
>>
>> Downside is of course that it adds another symbol, which could alienate
>> more potentiall users, and it could mean a shift-away-from or at least an
>> inconsistency-with methods and method chaining in general.
>>
>> Which would be ironic because I wanted it in some complicated Iterator
>> chain. ;)
>>
>> It could of course always be implemented as a syntax extension, and in
>> any case I don't expect this to get any attention before Rust 2.0. :)
>> __**_
>> 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
>
>


-- 
Andrés Osinski
http://www.andresosinski.com.ar/
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Should we add a Haskell-like `$` operator?

[Oren Ben-Kiki]

Not sure about $ but I sometimes miss the |> operator (which takes the
value from the left and inserts it as the 1st argument of the function call
to the right).

foo(a, b) |> bar(c, d) |> baz(e, f)
== baz(bar(foo(a, b), c, d), e, f)

This allows for easier "functional" decompsition of chains of operations.
I'm not certain it is as useful in an "OO-like" language like Rust - I cer


On Wed, Sep 25, 2013 at 9:40 PM, Marvin Löbel wrote:

> We don't use the symbol in our syntax, but are using functional paradigm
> that sometimes result in a bit hard to read nested calls.
>
> I'd propose that it works similar to `do`, in that it allows to move the
> last expression of an function or method call after the parentheses, though
> they would still remain required for ambiguity reasons:
>
> ~~~
>a(b(c(1,d(2,3,4,e()
> == a() $ b() $ c(1) $ d(2,3,4) $ e()
>
> let v: ~[uint] = from_iter() $ range(0, 100);
> ~~~
>
> In that sense, it wouldn't really be an operator but syntactic sugar for a
> function call.
> It might even be possible to replace `do` with it, though the now required
> parentheses would make it longer:
>
> ~~~
> do task::spawn { ... }
> task::spawn() $ || { ... }
> ~~~
>
> Downside is of course that it adds another symbol, which could alienate
> more potentiall users, and it could mean a shift-away-from or at least an
> inconsistency-with methods and method chaining in general.
>
> Which would be ironic because I wanted it in some complicated Iterator
> chain. ;)
>
> It could of course always be implemented as a syntax extension, and in any
> case I don't expect this to get any attention before Rust 2.0. :)
> __**_
> 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

Re: [rust-dev] Some suggestions of Rust language

[Marvin Löbel]

On 09/25/2013 06:37 PM, Diggory Hardy wrote:

Hi,

On Wednesday 25 September 2013 08:29:17 Patrick Walton wrote:

On 9/25/13 6:32 AM, Alexander Sun wrote:

Multiple return values
if has a function like this:

fn addsub(x : int, y : int) -> (int, int) {

return (x+y,x-y);

}

them, this is valid:

let (b,c) = addsub(x, y);

but this is invalid;

let b:int =0;
let c:int =0;
(b,c) = addsub(x, y);

also invalid:

let (b,c)  = (0, 0);
(b,c) = addsub(x, y);

If we did this, we wouldn't know whether to parse a pattern or an
expression when starting a statement. This isn't fixable without trying
to define some sort of cover grammar that covers both expressions and
patterns, like ECMAScript 6 does. I don't know if this would work in Rust.

Are there any plans to support something like:

assign (b,c) = addsub(x,y);

for existing b,c? The best I could come up with is:

 match two_nums(2) {
 (x,y) => {a=x;b=y;}
 }

Not that I need this; just curious.

I had the idea once to reuse the `in` keyword for that:

let mut a = 0; let mut b = 1;
in (a, b) = (b, a);

No idea how feasible that would be, though.
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Should we add a Haskell-like `$` operator?

[Oren Ben-Kiki]

Not sure about $ but I sometimes miss the |> operator (which takes the
value from the left and inserts it as the 1st argument of the function call
to the right).

foo(a, b) |> bar(c, d) |> baz(e, f)
== baz(bar(foo(a, b), c, d), e, f)

This allows for easier "functional" decompsition of chains of operations. I
found it to be very useful when writing Elixir; in Rust there's the OO-like
traits which may make it less useful - it still might be worthwhile for
people writing more functional code.


On Wed, Sep 25, 2013 at 9:40 PM, Marvin Löbel wrote:

> We don't use the symbol in our syntax, but are using functional paradigm
> that sometimes result in a bit hard to read nested calls.
>
> I'd propose that it works similar to `do`, in that it allows to move the
> last expression of an function or method call after the parentheses, though
> they would still remain required for ambiguity reasons:
>
> ~~~
>a(b(c(1,d(2,3,4,e()
> == a() $ b() $ c(1) $ d(2,3,4) $ e()
>
> let v: ~[uint] = from_iter() $ range(0, 100);
> ~~~
>
> In that sense, it wouldn't really be an operator but syntactic sugar for a
> function call.
> It might even be possible to replace `do` with it, though the now required
> parentheses would make it longer:
>
> ~~~
> do task::spawn { ... }
> task::spawn() $ || { ... }
> ~~~
>
> Downside is of course that it adds another symbol, which could alienate
> more potentiall users, and it could mean a shift-away-from or at least an
> inconsistency-with methods and method chaining in general.
>
> Which would be ironic because I wanted it in some complicated Iterator
> chain. ;)
>
> It could of course always be implemented as a syntax extension, and in any
> case I don't expect this to get any attention before Rust 2.0. :)
> __**_
> 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

Re: [rust-dev] Should we add a Haskell-like `$` operator?

[Oren Ben-Kiki]

Not sure about $ but I sometimes miss the |> operator (which takes the
value from the left and inserts it as the 1st argument of the function call
to the right).

foo(a, b) |> bar(c, d) |> baz(e, f)
== baz(bar(foo(a, b), c, d), e, f)

This allows for easier "functional" decompsition of chains of operations. I
found it to be very useful when writing Elixir; in Rust there's the OO-like
traits which may make it less useful - it still might be worthwhile for
people writing more functional code.


On Wed, Sep 25, 2013 at 9:40 PM, Marvin Löbel wrote:

> We don't use the symbol in our syntax, but are using functional paradigm
> that sometimes result in a bit hard to read nested calls.
>
> I'd propose that it works similar to `do`, in that it allows to move the
> last expression of an function or method call after the parentheses, though
> they would still remain required for ambiguity reasons:
>
> ~~~
>a(b(c(1,d(2,3,4,e()
> == a() $ b() $ c(1) $ d(2,3,4) $ e()
>
> let v: ~[uint] = from_iter() $ range(0, 100);
> ~~~
>
> In that sense, it wouldn't really be an operator but syntactic sugar for a
> function call.
> It might even be possible to replace `do` with it, though the now required
> parentheses would make it longer:
>
> ~~~
> do task::spawn { ... }
> task::spawn() $ || { ... }
> ~~~
>
> Downside is of course that it adds another symbol, which could alienate
> more potentiall users, and it could mean a shift-away-from or at least an
> inconsistency-with methods and method chaining in general.
>
> Which would be ironic because I wanted it in some complicated Iterator
> chain. ;)
>
> It could of course always be implemented as a syntax extension, and in any
> case I don't expect this to get any attention before Rust 2.0. :)
> __**_
> 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

Re: [rust-dev] Should we add a Haskell-like `$` operator?

[Andres Osinski]

As a potential user of the language I've been toying with using combinators
to make compile-time checked DSLs, and this would be enourmously useful.

Rust is still lacking a few features for my proposed use case (varargs
and/or kwargs would be fantastic, but I'm already well aware that those are
post-1.0 requests).

However, I disagree with the idea that it would alienate users. Function
composition is useful but not as critical as in a language like Haskell,
and aside from the admittedly difficult memory management concepts Rust
introduces, it is a very clean and easy-to-understand language, and has far
fewer caveats than both C and C++ (at least so far), and much less
complexity than academic functional languages.


On Wed, Sep 25, 2013 at 3:40 PM, Marvin Löbel wrote:

> We don't use the symbol in our syntax, but are using functional paradigm
> that sometimes result in a bit hard to read nested calls.
>
> I'd propose that it works similar to `do`, in that it allows to move the
> last expression of an function or method call after the parentheses, though
> they would still remain required for ambiguity reasons:
>
> ~~~
>a(b(c(1,d(2,3,4,e()
> == a() $ b() $ c(1) $ d(2,3,4) $ e()
>
> let v: ~[uint] = from_iter() $ range(0, 100);
> ~~~
>
> In that sense, it wouldn't really be an operator but syntactic sugar for a
> function call.
> It might even be possible to replace `do` with it, though the now required
> parentheses would make it longer:
>
> ~~~
> do task::spawn { ... }
> task::spawn() $ || { ... }
> ~~~
>
> Downside is of course that it adds another symbol, which could alienate
> more potentiall users, and it could mean a shift-away-from or at least an
> inconsistency-with methods and method chaining in general.
>
> Which would be ironic because I wanted it in some complicated Iterator
> chain. ;)
>
> It could of course always be implemented as a syntax extension, and in any
> case I don't expect this to get any attention before Rust 2.0. :)
> __**_
> Rust-dev mailing list
> Rust-dev@mozilla.org
> https://mail.mozilla.org/**listinfo/rust-dev
>



-- 
Andrés Osinski
http://www.andresosinski.com.ar/
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Some suggestions of Rust language

[Oren Ben-Kiki]

On Wed, Sep 25, 2013 at 6:29 PM, Patrick Walton  wrote:

> On 9/25/13 6:32 AM, Alexander Sun wrote:
>
>> Embedded anonymous structure?
>>
> Embedded anonymous structure in Go is good idea, I think.
>>
>
> Not the way Go does it, where you can have method conflicts like C++
> multiple inheritance and it can be surprising which method gets called when
> two anonymous fields have a method with the same name. I'm not necessarily
> opposed to anonymous fields, but we should tread carefully.


Can you say a bit more about that? I thought if two anonymous fields
supported a method than it was a conflict and one had to refer to it with
the specific field type (foo.TypeOfFirstField.method or
foo.TypeOfSecondField.method as opposed to foo.method - the latter would be
an error). This sounds pretty reasonable...

Since Rust has no implicit traits anywhere, it seems reasonable to require
an explicit impl Trait for Container, but allow omitting functions that are
obtained from anonymous field(s) - unless one wants to override them, or
when they are in conflict between more than one such field. This ensures
all type checking is done at declaration rather than in code that uses the
traits.

It sounds like something along these lines could work in Rust, and it would
be very useful...
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

[rust-dev] Should we add a Haskell-like `$` operator?

[Marvin Löbel]

We don't use the symbol in our syntax, but are using functional paradigm 
that sometimes result in a bit hard to read nested calls.


I'd propose that it works similar to `do`, in that it allows to move the 
last expression of an function or method call after the parentheses, 
though they would still remain required for ambiguity reasons:


~~~
   a(b(c(1,d(2,3,4,e()
== a() $ b() $ c(1) $ d(2,3,4) $ e()

let v: ~[uint] = from_iter() $ range(0, 100);
~~~

In that sense, it wouldn't really be an operator but syntactic sugar for 
a function call.
It might even be possible to replace `do` with it, though the now 
required parentheses would make it longer:


~~~
do task::spawn { ... }
task::spawn() $ || { ... }
~~~

Downside is of course that it adds another symbol, which could alienate 
more potentiall users, and it could mean a shift-away-from or at least 
an inconsistency-with methods and method chaining in general.


Which would be ironic because I wanted it in some complicated Iterator 
chain. ;)


It could of course always be implemented as a syntax extension, and in 
any case I don't expect this to get any attention before Rust 2.0. :)

___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Some suggestions of Rust language

[Diggory Hardy]

Hi,

On Wednesday 25 September 2013 08:29:17 Patrick Walton wrote:
> On 9/25/13 6:32 AM, Alexander Sun wrote:
> > Multiple return values
> > if has a function like this:
> > 
> > fn addsub(x : int, y : int) -> (int, int) {
> > 
> > return (x+y,x-y);
> > 
> > }
> > 
> > them, this is valid:
> > 
> > let (b,c) = addsub(x, y);
> > 
> > but this is invalid;
> > 
> > let b:int =0;
> > let c:int =0;
> > (b,c) = addsub(x, y);
> > 
> > also invalid:
> > 
> > let (b,c)  = (0, 0);
> > (b,c) = addsub(x, y);
> 
> If we did this, we wouldn't know whether to parse a pattern or an
> expression when starting a statement. This isn't fixable without trying
> to define some sort of cover grammar that covers both expressions and
> patterns, like ECMAScript 6 does. I don't know if this would work in Rust.

Are there any plans to support something like:

assign (b,c) = addsub(x,y);

for existing b,c? The best I could come up with is:

match two_nums(2) {
(x,y) => {a=x;b=y;}
}

Not that I need this; just curious.

signature.asc
Description: This is a digitally signed message part.
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Some suggestions of Rust language

[Jason E. Aten]

On Wed, Sep 25, 2013 at 8:29 AM, Patrick Walton  wrote:

> Slice?
>> Provide first class support of array, slice(not borrowed pointer to
>> vector). And support slice operation, like a[0:5].
>>
>
> How is a slice different from a borrowed pointer to a vector? Note that
> you can take a borrowed pointer to a subrange of a vector.



And at last: could support default parameter in function/method?

>
> This has been discussed and the consensus, at least for now, is that
> statics plus functional record update syntax is enough.


Hi Patrick,

could you give examples of how the slicing (with borrowed pointer to a
vector) and the default parameter usage would/will look like in actual use?

Thanks!

Jason
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Some suggestions of Rust language

[Masklinn]

On 2013-09-25, at 17:29 , Patrick Walton wrote:
> 
>> Multiple return values
>> if has a function like this:
>> 
>> fn addsub(x : int, y : int) -> (int, int) {
>>  return (x+y,x-y);
>> }
>> 
>> them, this is valid:
>> 
>> let (b,c) = addsub(x, y);
>> 
>> but this is invalid;
>> 
>> let b:int =0;
>> let c:int =0;
>> (b,c) = addsub(x, y);
>> 
>> also invalid:
>> 
>> let (b,c)  = (0, 0);
>> (b,c) = addsub(x, y);
> 
> If we did this, we wouldn't know whether to parse a pattern or an
> expression when starting a statement. This isn't fixable without trying
> to define some sort of cover grammar that covers both expressions and
> patterns, like ECMAScript 6 does. I don't know if this would work in
> Rust.

There seems to be a bug somewhere though, ignoring that the bindings are
not mut in the example (making them immutable unless that's changed
recently) the compiler freaks out quite a bit:

test.rs:8:4: 8:10 error: internal compiler error: trans_lvalue reached
fall-through case: expr_tup(~[@{id: 38, node: expr_path(@{span: {lo:
{__field__: 121}, hi: {__field__: 122}, expn_info: None}, global: false,
idents: ~[{name: 70, ctxt: 0}], rp: None, types: ~[]}), span: {lo:
{__field__: 121}, hi: {__field__: 122}, expn_info: None}}, @{id: 39,
node: expr_path(@{span: {lo: {__field__: 124}, hi: {__field__: 125},
expn_info: None}, global: false, idents: ~[{name: 71, ctxt: 0}], rp:
None, types: ~[]}), span: {lo: {__field__: 124}, hi: {__field__: 125},
expn_info: None}}])
test.rs:8 (b, c) = addsub(1, 2);

___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Some suggestions of Rust language

[Patrick Walton]

On 9/25/13 6:32 AM, Alexander Sun wrote:

Ownership, Owned Box, Managed Box
What about hide the ownership, owned box, managed box to users? Just a
borrowed pointer and a dereferencing pointer, like Go.


This is contrary to the design goals of Rust. Go is a fully garbage 
collected language and provides neither optional GC nor explicit control 
over allocation on the heap or stack, both of which are important Rust 
features.



Slice?
Provide first class support of array, slice(not borrowed pointer to
vector). And support slice operation, like a[0:5].


How is a slice different from a borrowed pointer to a vector? Note that 
you can take a borrowed pointer to a subrange of a vector.




Loop
Simplify the for loop:
Hide the complexity of iterator, use "for x in xx", like Python(I
think I saw it in 0.8 Manual).
for int:range(0, 10), for uint:range(0, 10), ... to "for range(0, 10)"
for int:range_step(0,10,2) are the same.


This was on the roadmap at least at one point, but I'm not sure it works 
due to some issues regarding method lookup. strcat knows more.




Improve the function declare:
fn foo(x : int, y : int, z: int) to fn foo(x, y, z: int)


This would be somewhat ad-hoc when we move to arbitrary type ascription 
in patterns (e.g. `fn foo(MyStruct { x: int, y: int }) { ... }`).



And could make the expression valid?
(index = count % 2) == 0, Just like the meaning in C++. Currently
(index = count % 2) == () is valid, but it make no sense.


This would conflict with the warn-unused-result warning I would like to 
add, and would also cause a lot of spurious type errors in match arms.




Multiple return values
if has a function like this:

fn addsub(x : int, y : int) -> (int, int) {
return (x+y,x-y);
}

them, this is valid:

let (b,c) = addsub(x, y);

but this is invalid;

let b:int =0;
let c:int =0;
(b,c) = addsub(x, y);

also invalid:

let (b,c)  = (0, 0);
(b,c) = addsub(x, y);


If we did this, we wouldn't know whether to parse a pattern or an 
expression when starting a statement. This isn't fixable without trying 
to define some sort of cover grammar that covers both expressions and 
patterns, like ECMAScript 6 does. I don't know if this would work in Rust.



Embedded anonymous structure?
Embedded anonymous structure in Go is good idea, I think.


Not the way Go does it, where you can have method conflicts like C++ 
multiple inheritance and it can be surprising which method gets called 
when two anonymous fields have a method with the same name. I'm not 
necessarily opposed to anonymous fields, but we should tread carefully.



And at last: could support default parameter in function/method?


This has been discussed and the consensus, at least for now, is that 
statics plus functional record update syntax is enough.



English is not my native language, so sorry for the grammar mistake.


No problem, thanks for your input!

Patrick

___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

[rust-dev] Some suggestions of Rust language

[Alexander Sun]

I am not a language developer, just an user. I like Rust, so could I
please to give some suggestions about improve Rust?

Recently, I try to use Rust to build a GUI library prototype. Just
like wxWidget or SWT, wrap the native API(win32 and gtk+, cocoa in
plan if possible). At the meantime, I am writing a Rust tutorial.
During the developing and writing, I got a some questions.

We all(at least I) hope Rust could get wildly use. I think readability
and learnability take emphatically considered. Rust does these well,
and could do better.

Here are my suggestions about Rust(based on 0.7). Note: Just a user
opinions, not a developer perspective. Forgive me if I was wrong.

Ownership, Owned Box, Managed Box
What about hide the ownership, owned box, managed box to users? Just a
borrowed pointer and a dereferencing pointer, like Go.

Slice?
Provide first class support of array, slice(not borrowed pointer to
vector). And support slice operation, like a[0:5].

Loop
Simplify the for loop:
Hide the complexity of iterator, use "for x in xx", like Python(I
think I saw it in 0.8 Manual).
for int:range(0, 10), for uint:range(0, 10), ... to "for range(0, 10)"
for int:range_step(0,10,2) are the same.

Improve the function declare:
fn foo(x : int, y : int, z: int) to fn foo(x, y, z: int)

And could make the expression valid?
(index = count % 2) == 0, Just like the meaning in C++. Currently
(index = count % 2) == () is valid, but it make no sense.

Multiple return values
if has a function like this:

fn addsub(x : int, y : int) -> (int, int) {
return (x+y,x-y);
}

them, this is valid:

let (b,c) = addsub(x, y);

but this is invalid;

let b:int =0;
let c:int =0;
(b,c) = addsub(x, y);

also invalid:

let (b,c)  = (0, 0);
(b,c) = addsub(x, y);

Module: code module and file module?
I call module declare with mod keyword is "code module", and call rust
source file is "file module".
import a code module in other code module in same source file, we
should use keyword "use", but if we want to import file module, we
need to use keyword "mod". I know mod xxx means find xxx.rs, But could
we unify it?

According the official "Rust tutorial", a mod member is private by
default. But it seems that we can access submod in a accessible mod
directly.

Embedded anonymous structure?
Embedded anonymous structure in Go is good idea, I think.

And at last: could support default parameter in function/method?

English is not my native language, so sorry for the grammar mistake.

Best Regards
Sun
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev