Re: [rust-dev] Function definition syntax

[Armin Ronacher]

Hi,

On 30/07/2013 01:29, Wojciech Miłkowski wrote:

Is it constructed to mimic mathematical form f(x)->y or is there other
reason i.e. syntax ambiguity?
I find it makes it vastly easier to read if a function shows up in a 
another function's signature.


  fn foo(f: &fn() -> int)

vs

  fn foo(f: &fn(): int)


Aside from that I just want to point out that this syntax for types is 
consistent with Python which uses the colon as a general general 
indentation marker:


   def foo(bar: int) -> int:
   pass


Regards,
Armin

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

Re: [rust-dev] Function definition syntax

[Lindsey Kuper]

On Mon, Jul 29, 2013 at 4:29 PM, Wojciech Miłkowski  wrote:
> That said I wonder why the function definition has form:
> fn name(var: type, ...) -> return_type {...}
> instead of more unified:
> fn name(var: type, ...): return_type {...}
>
> Is it constructed to mimic mathematical form f(x)->y or is there other
> reason i.e. syntax ambiguity?

There's long precedent for `->` in function type signatures in, among
other languages, Haskell, ML, and OCaml.

In Rust, I like it better than `:` for reasons of readability -- it
visually splits up the argument and return types nicely.  If it came
to a vote, my vote would be to keep it.

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

[rust-dev] RFC: Overloadable dereference operator

[Patrick Walton]

Hi everyone,

I've recently started thinking that a number of use cases that we've 
wanted to solve at some point could be solved if the dereference 
operator could be overloaded much like the other operators. Most 
importantly, this addresses a missing part of the puzzle for custom 
smart pointers, but it also fixes issues relating to autoderef on 
newtypes and "common fields".


# Mechanics

We introduce a new lang item trait:

#[lang="deref"]
pub trait Deref {
fn deref(&'self self) -> &'self Result;
}

This `deref` method is invoked by the compiler in two cases:

1. When the unary `*` operator is used on a value. In this case, the 
result pointer type is automatically dereferenced and becomes an lvalue 
(albeit an immutable one).


2. When method lookup or field projection fails. In this case, the 
method lookup or field projection is tried again with the `Result` type.


It would be nice if `Result` were a functional dependency of `Self` 
above (e.g. simultaneous `impl Result for Foo` and `impl 
Result for Foo` would be forbidden). Unfortunately we don't have 
the trait machinery to enforce this yet, as this is associated types. We 
could just enforce this in an ad hoc way, or we could not enforce it. I 
don't care too much either way.


# Use cases

There are several use cases that this enables:

## Custom smart pointers

For custom smart pointers it is highly desirable to support autoderef 
and to have the `*` operator enable access to fields. For example, 
suppose `@T` becomes `Gc`. We would like to avoid something like:


let p: Gc = ...;
do p.read |x| {
printfln!("Your lucky number is %d", *x)
}

With overloadable deref it would look like:

let p: Gc = ...;
printfln!("Your lucky number is %d", *p)

I *believe* that this does not cause liveness issues for GC and RC 
because the lifetime of the resulting reference is tied to the lifetime 
of the GC/RC box itself, so the reference piggybacks off the pointer's 
reference count and everything is OK. However, I could be mistaken here; 
here I'd like others to check my reasoning. In particular I'm also 
interested in legitimate use cases that this might forbid.


## Controllable newtype autoderef

Currently, newtype structs automatically dereference to the value they 
contain; for example:


struct MyInt(int);
fn main() {
let x = MyInt(3);
printfln("1 + 2 = " + x.to_str()); // prints "1 + 2 = 3"
}

This behavior is sometimes undesirable, as Brian often points out. 
Haskell allows behavior similar to this to be controlled on an opt-in 
basis with `GeneralizedNewtypeDeriving`. We could support something 
similar by turning off autoderef for newtype structs and leaning on 
overloadable dereferencing when it is desirable. In this new world, to 
get the behavior above one would write:


struct MyInt(int);
impl Deref for MyInt {
fn deref(&'self self) -> &'self int {
let MyInt(ref inner) = *self;
inner
}
}

We could imagine something like this to make it simpler:

#[deriving(Deref)]
struct MyInt(int);

## Anonymous fields

In Go (and in C with Plan 9 extensions) it is possible to place one 
struct inside another struct and inherit its fields:


type Foo struct {
X int
Y int
}

type Bar struct {
Foo
Z int
}

x = Bar {
Foo {
X: 1,
Y: 2,
}
Z: 3,
}
fmt.Println("%d", x.Y)  // prints 2

This is almost multiple inheritance, except that the type of the `this` 
pointer will be different when invoking `Foo` methods on a `Bar` instance.


With overloadable deref this would be possible in Rust as well:

struct Bar {
base: Foo,
z: int,
}

impl Deref for Bar {
fn deref(&'self self) -> &'self Foo {
&self.base
}
}

One could imagine macro sugar for this use case, for example:

#[deriving(Deref(base))]
struct Bar {
base: Foo,
z: int,
}

## Common fields

It is a common pattern, for example in Servo, to simulate inheritance in 
Rust with something like:


struct Bar {
base: FooCommon,
...
}

struct Baz {
base: FooCommon,
...
}

struct Boo {
base: FooCommon,
...
}

enum Foo {
BarClass(~Bar),
BazClass(~Baz),
BooClass(~Boo),
}

The problem here is that if you have a `Foo` instance there is no 
convenient way to access the common fields short of a `match`. Again, 
overloadable deref comes to the rescue here. We could imagine an 
overloaded `Deref` as follows:


impl Deref for Foo {
fn deref(&'self self) -> &'self FooCommon {
match *self {
BarClass(ref bar) => &bar.base,
BazClass(ref baz) => &baz.base,
BooClass(ref boo) => &boo.base,
}
}
}

And once again we co

Re: [rust-dev] Function definition syntax

[Benjamin Striegel]

This would make deeply-nested HOF easier to read, but I'm not a fan of the
way that `fn foo(->int) {` looks for functions with no arguments.

Because I forgot to register my opinion previously, I do like the way that
the current syntax reads in the common case, including the use of the
otherwise-idiosyncratic arrow symbol. "Call this function with these
parameters, this type pops out." Coming from C-family languages and dynamic
languages, I never gave the syntax for this a second thought.


On Tue, Jul 30, 2013 at 12:50 AM, Uther  wrote:

> I didn't raise the subject since it seems late for a huge syntax change
> but if I had to change something about the function syntax I would change
> it to:
>
> fn function (var: type, ... -> returnType) {...}
>
> I really think it would be more readable especially in the case of Brendan
> Zabarauskas exemple :
>
> fn hof(x: T, f: fn(T->T) -> fn(T->T))  { … }
>
>
> Le 30/07/13 04:08, Brendan Zabarauskas a écrit :
>
>  This would make function signatures harder to read in some instances,
>> particularly when using closures and higher-order functions:
>>
>>  let f: fn(T): T = …;
>>
>>  fn hof(x: T, f: fn(T): T): fn(T): T { … }
>>
>> Compare to the current syntax:
>>
>>  let f: fn(T) -> T = …;
>>
>>  fn hof(x: T, f: fn(T) -> T) -> fn(T) -> T { … }
>>
>> ~Brendan
>>
>> On 30/07/2013, at 9:29 AM, Wojciech Miłkowski 
>> wrote:
>>
>>  Hi,
>>>
>>> I'm observing rust development for some time, and I must say it slowly
>>> encourages me to use it. Especially the progress from Perl-like syntax
>>> to more sane and quiet form is enjoyable.
>>> That said I wonder why the function definition has form:
>>> fn name(var: type, ...) -> return_type {...}
>>> instead of more unified:
>>> fn name(var: type, ...): return_type {...}
>>>
>>> Is it constructed to mimic mathematical form f(x)->y or is there other
>>> reason i.e. syntax ambiguity?
>>>
>>>
>>> Cheers,
>>> W.
>>> __**_
>>> 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] Function definition syntax

[Uther]

I didn't raise the subject since it seems late for a huge syntax change 
but if I had to change something about the function syntax I would 
change it to:


fn function (var: type, ... -> returnType) {...}

I really think it would be more readable especially in the case of 
Brendan Zabarauskas exemple :


fn hof(x: T, f: fn(T->T) -> fn(T->T))  { … }


Le 30/07/13 04:08, Brendan Zabarauskas a écrit :

This would make function signatures harder to read in some instances, 
particularly when using closures and higher-order functions:

 let f: fn(T): T = …;

 fn hof(x: T, f: fn(T): T): fn(T): T { … }

Compare to the current syntax:

 let f: fn(T) -> T = …;

 fn hof(x: T, f: fn(T) -> T) -> fn(T) -> T { … }

~Brendan

On 30/07/2013, at 9:29 AM, Wojciech Miłkowski  wrote:


Hi,

I'm observing rust development for some time, and I must say it slowly
encourages me to use it. Especially the progress from Perl-like syntax
to more sane and quiet form is enjoyable.
That said I wonder why the function definition has form:
fn name(var: type, ...) -> return_type {...}
instead of more unified:
fn name(var: type, ...): return_type {...}

Is it constructed to mimic mathematical form f(x)->y or is there other
reason i.e. syntax ambiguity?


Cheers,
W.
___
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] MPS investigation for Rust GC

[I.T. Daniher]

If the licensing terms aren't suitable for you (for example, you're
developing a closed-source commercial product or a *compiler run-time*
*system*) you can easily license the MPS under different terms from
Ravenbrook.  Please write to us at `<*mps-questi...@ravenbrook.com*>`_
for more information.

from https://github.com/Ravenbrook/mps-temporary/blob/master/license.txt

If there's serious interest in this, we could reach out. I don't know the
state of the gc library project.

On Mon, Jul 29, 2013 at 10:59 PM, Kevin Cantu  wrote:

> I'm personally not very familiar with the Sleepycat license (as MPS seems
> to use: https://github.com/Ravenbrook/mps-temporary).
> Would proprietary code have to be shipped in separate binaries than the
> Rust runtime, or would commercial licensing be required?
>
>
> Kevin
>
>
>
>
> --
> Kevin Cantu
>
>
> On Mon, Jul 29, 2013 at 10:41 AM, Thad Guidry wrote:
>
>> REGARDING:
>> - Graydon wants to investigate using the Memory Pool System as the Rust
>> GC,
>>   rather than a bespoke one. The
>> [MPS](http://www.ravenbrook.com/project/mps/) is
>>   a very mature and robust memory management library.
>>
>> Reading through and seeing one of the MPS creators initial design goals :
>>
>> "The MPS was not designed for C++, but as a memory manager for dynamic
>> language run-time systems. In fact, it was specifically designed not to
>> require C++."
>>
>> ...instantly gained my respect for this system and its potential.
>>
>> --
>> -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
>
>
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] MPS investigation for Rust GC

[Kevin Cantu]

I'm personally not very familiar with the Sleepycat license (as MPS seems
to use: https://github.com/Ravenbrook/mps-temporary).
Would proprietary code have to be shipped in separate binaries than the
Rust runtime, or would commercial licensing be required?


Kevin




-- 
Kevin Cantu


On Mon, Jul 29, 2013 at 10:41 AM, Thad Guidry  wrote:

> REGARDING:
> - Graydon wants to investigate using the Memory Pool System as the Rust GC,
>   rather than a bespoke one. The
> [MPS](http://www.ravenbrook.com/project/mps/) is
>   a very mature and robust memory management library.
>
> Reading through and seeing one of the MPS creators initial design goals :
>
> "The MPS was not designed for C++, but as a memory manager for dynamic
> language run-time systems. In fact, it was specifically designed not to
> require C++."
>
> ...instantly gained my respect for this system and its potential.
>
> --
> -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] Redesigning fmt!

[Alex Crichton]

Thanks for all the comments everyone! I'll see if I can address a good
number of them here:

> - I don't see how the example {:date} is generated from the grammar.
>   Though I do think custom (especially culture-specific) formatter
>   functions do need some support. Money and dates are the big two.

At the end of the format spec a `type` could be any identifier. I
wanted to make multi-char identifiers possible because `:date` makes a
lot of sense just reading it to see what it does. I also believe that
because the formatting is trait-based, it should be easy to implement
something like `idate` and `imoney` for the internationalized versions
in a library. I believe though that this is definitely possible!

> - I agree with others that the formatting of decimal has wiggle room in
>   the design; python's choice is ... so-so?

I agree, I think that the way I want to go now is to implement the
formatting specifiers in whatever syntax seems natural at first, and
then before we start converting everything over to the new formatting
system take some time to bikeshed the syntax of this. The syntax
itself will be pretty easy to change along with the formatting
routines at the beginning. I'm going to try to get most other stuff
working first before tackling the specific syntax though (if that's
ok).

> - I also agree with Brian that _generalizing_ format modifiers somewhat
>   (so that formatting options can pass from format-string through to
>   formatter) might be worth thinking about some more.

One cool thing that python does is allow `{:%d/%m%y}` for formatting
dates. I agree that it's an awesome ability and has some really cool
potential. The downsides to this are that the format string can't be
checked at compile-time, and you may still want to specify alignment
and things like that. Good news is that this is probably pretty easy
to deal with (like the decimal format syntax) once all the rest of the
infrastructure is in place.

> - Your implementation is extremely clever and appears to be low
>   overhead, which is _great_. I am a little saddened, though, that
>   it rests not just on something that can dynamically fail but that
>   can (presumably) fail _badly_ (memory unsafe?)

I think there might be some cleverness that could happy with TyDesc
objects, but that would result is something like a static array in
each executable with a mapping from "string format name" to TyDesc
object. I do agree that this would be nice to have, though, because I
was similarly saddened when I realized that I would have to flag the
function as unsafe.

> keyword/named selection is *really* great for longer/more busy patterns

I agree that this would be nice to have, and I think that Huon's
suggestion is a fantastic one! I'll try to target the `fmt!("{foo}",
foo=bar)` syntax to start out with.

> Can we have both?  Parse at compile time if the string is constant but parse
> at compile time if the string comes from something like a gettext-ish
> function that loads the string from a message catalog.

I can imagine a system where we do have both. One difficult part of
this is that I wanted the runtime cost at the callsites to be as small
as possible (with the goal of reducing codegen size). Precompiling
this into something which doesn't result in massive codegen is a
difficult problem that I was having a lot of trouble figuring out how
to do. One thing I wanted to do in the long term was to implement
purely runtime-based parsing, benchmark it, and then toy around with
various precompiled versions to see how much the actual speedup is. If
there's a noticeable 3x speedup, then it's probably worth the extra
code overhead, but if it's like 10% it may not be as worth it.
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Function definition syntax

[Josh Leverette]

Neither is perfect. There is definitely room for improvement in both
options.
On Jul 29, 2013 9:08 PM, "Brendan Zabarauskas"  wrote:

> This would make function signatures harder to read in some instances,
> particularly when using closures and higher-order functions:
>
> let f: fn(T): T = …;
>
> fn hof(x: T, f: fn(T): T): fn(T): T { … }
>
> Compare to the current syntax:
>
> let f: fn(T) -> T = …;
>
> fn hof(x: T, f: fn(T) -> T) -> fn(T) -> T { … }
>
> ~Brendan
>
> On 30/07/2013, at 9:29 AM, Wojciech Miłkowski  wrote:
>
> > Hi,
> >
> > I'm observing rust development for some time, and I must say it slowly
> > encourages me to use it. Especially the progress from Perl-like syntax
> > to more sane and quiet form is enjoyable.
> > That said I wonder why the function definition has form:
> > fn name(var: type, ...) -> return_type {...}
> > instead of more unified:
> > fn name(var: type, ...): return_type {...}
> >
> > Is it constructed to mimic mathematical form f(x)->y or is there other
> > reason i.e. syntax ambiguity?
> >
> >
> > Cheers,
> > W.
> > ___
> > 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] Function definition syntax

[Brendan Zabarauskas]

This would make function signatures harder to read in some instances, 
particularly when using closures and higher-order functions:

let f: fn(T): T = …;

fn hof(x: T, f: fn(T): T): fn(T): T { … }

Compare to the current syntax:

let f: fn(T) -> T = …;

fn hof(x: T, f: fn(T) -> T) -> fn(T) -> T { … }

~Brendan

On 30/07/2013, at 9:29 AM, Wojciech Miłkowski  wrote:

> Hi,
> 
> I'm observing rust development for some time, and I must say it slowly
> encourages me to use it. Especially the progress from Perl-like syntax
> to more sane and quiet form is enjoyable.
> That said I wonder why the function definition has form:
> fn name(var: type, ...) -> return_type {...}
> instead of more unified:
> fn name(var: type, ...): return_type {...}
> 
> Is it constructed to mimic mathematical form f(x)->y or is there other
> reason i.e. syntax ambiguity?
> 
> 
> Cheers,
> W.
> ___
> 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] Function definition syntax

[Benjamin Striegel]

Come to think of it, it might also make the grammar for function signatures
ambiguous, given that we allow null return types to be omitted.


On Mon, Jul 29, 2013 at 9:18 PM, Benjamin Striegel
wrote:

> I don't agree that the type of a function and the return type of a
> function are the same thing (specifically, the type of the function
> contains the return type). :) If nothing else, this would make the function
> signatures of higher-order functions much harder to read IMO.
>
>
> On Mon, Jul 29, 2013 at 8:29 PM, Patrick Walton wrote:
>
>> On 7/29/13 4:29 PM, Wojciech Miłkowski wrote:
>>
>>> Hi,
>>>
>>> I'm observing rust development for some time, and I must say it slowly
>>> encourages me to use it. Especially the progress from Perl-like syntax
>>> to more sane and quiet form is enjoyable.
>>> That said I wonder why the function definition has form:
>>> fn name(var: type, ...) -> return_type {...}
>>> instead of more unified:
>>> fn name(var: type, ...): return_type {...}
>>>
>>> Is it constructed to mimic mathematical form f(x)->y or is there other
>>> reason i.e. syntax ambiguity?
>>>
>>
>> Personal preference of Graydon, I believe. This is one of the few
>> decisions that has survived from Rust 0.1 :)
>>
>> I slightly prefer `:` to `->` but never enough to bring it up.
>>
>> Patrick
>>
>>
>> __**_
>> 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] Function definition syntax

[Benjamin Striegel]

I don't agree that the type of a function and the return type of a function
are the same thing (specifically, the type of the function contains the
return type). :) If nothing else, this would make the function signatures
of higher-order functions much harder to read IMO.


On Mon, Jul 29, 2013 at 8:29 PM, Patrick Walton  wrote:

> On 7/29/13 4:29 PM, Wojciech Miłkowski wrote:
>
>> Hi,
>>
>> I'm observing rust development for some time, and I must say it slowly
>> encourages me to use it. Especially the progress from Perl-like syntax
>> to more sane and quiet form is enjoyable.
>> That said I wonder why the function definition has form:
>> fn name(var: type, ...) -> return_type {...}
>> instead of more unified:
>> fn name(var: type, ...): return_type {...}
>>
>> Is it constructed to mimic mathematical form f(x)->y or is there other
>> reason i.e. syntax ambiguity?
>>
>
> Personal preference of Graydon, I believe. This is one of the few
> decisions that has survived from Rust 0.1 :)
>
> I slightly prefer `:` to `->` but never enough to bring it up.
>
> Patrick
>
>
> __**_
> 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] Function definition syntax

[Wojciech Miłkowski]

Patrick Walton wrote:
> I slightly prefer `:` to `->` but never enough to bring it up.

Josh Leverette wrote:
> That modification could be subtle, yet powerful. It would make the language 
> more
> consistent, at the very least.

Strong +1 if it could be considered, but I can live with that.

Regards,
W.

On Tue, Jul 30, 2013 at 2:32 AM, Josh Leverette  wrote:
> That modification could be subtle, yet powerful. It would make the language
> more consistent, at the very least.
>
> Sincerely,
> Josh
>
> On Jul 29, 2013 7:29 PM, "Patrick Walton"  wrote:
>>
>> On 7/29/13 4:29 PM, Wojciech Miłkowski wrote:
>>>
>>> Hi,
>>>
>>> I'm observing rust development for some time, and I must say it slowly
>>> encourages me to use it. Especially the progress from Perl-like syntax
>>> to more sane and quiet form is enjoyable.
>>> That said I wonder why the function definition has form:
>>> fn name(var: type, ...) -> return_type {...}
>>> instead of more unified:
>>> fn name(var: type, ...): return_type {...}
>>>
>>> Is it constructed to mimic mathematical form f(x)->y or is there other
>>> reason i.e. syntax ambiguity?
>>
>>
>> Personal preference of Graydon, I believe. This is one of the few
>> decisions that has survived from Rust 0.1 :)
>>
>> I slightly prefer `:` to `->` but never enough to bring it up.
>>
>> Patrick
>>
>> ___
>> 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] Function definition syntax

[Josh Leverette]

That modification could be subtle, yet powerful. It would make the language
more consistent, at the very least.

Sincerely,
Josh
On Jul 29, 2013 7:29 PM, "Patrick Walton"  wrote:

> On 7/29/13 4:29 PM, Wojciech Miłkowski wrote:
>
>> Hi,
>>
>> I'm observing rust development for some time, and I must say it slowly
>> encourages me to use it. Especially the progress from Perl-like syntax
>> to more sane and quiet form is enjoyable.
>> That said I wonder why the function definition has form:
>> fn name(var: type, ...) -> return_type {...}
>> instead of more unified:
>> fn name(var: type, ...): return_type {...}
>>
>> Is it constructed to mimic mathematical form f(x)->y or is there other
>> reason i.e. syntax ambiguity?
>>
>
> Personal preference of Graydon, I believe. This is one of the few
> decisions that has survived from Rust 0.1 :)
>
> I slightly prefer `:` to `->` but never enough to bring it up.
>
> Patrick
>
> __**_
> 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] Function definition syntax

[Patrick Walton]

On 7/29/13 4:29 PM, Wojciech Miłkowski wrote:

Hi,

I'm observing rust development for some time, and I must say it slowly
encourages me to use it. Especially the progress from Perl-like syntax
to more sane and quiet form is enjoyable.
That said I wonder why the function definition has form:
fn name(var: type, ...) -> return_type {...}
instead of more unified:
fn name(var: type, ...): return_type {...}

Is it constructed to mimic mathematical form f(x)->y or is there other
reason i.e. syntax ambiguity?


Personal preference of Graydon, I believe. This is one of the few 
decisions that has survived from Rust 0.1 :)


I slightly prefer `:` to `->` but never enough to bring it up.

Patrick

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

[rust-dev] Function definition syntax

[Wojciech Miłkowski]

Hi,

I'm observing rust development for some time, and I must say it slowly
encourages me to use it. Especially the progress from Perl-like syntax
to more sane and quiet form is enjoyable.
That said I wonder why the function definition has form:
fn name(var: type, ...) -> return_type {...}
instead of more unified:
fn name(var: type, ...): return_type {...}

Is it constructed to mimic mathematical form f(x)->y or is there other
reason i.e. syntax ambiguity?


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

Re: [rust-dev] RFC: Removing *T

[Gábor Lehel]

On Mon, Jul 29, 2013 at 7:21 PM, Thiez  wrote:
> This would make for some interesting/confusing calling conventions. It would
> also mean &T and &mut T would no longer share a representation; &int would
> simply be int, but &mut int would still have to be a pointer.

Yes.

> Borrowing &mut T to &T would be a dereference if T is pointer size or smaller?

Yes. I would expect borrowing and never dereferencing is uncommon, but
of course possible.

> The only
> reliable way of taking an address would be taking &mut because & would fail
> for some types.

If by "taking an address" you mean transmute::<&T, *T>(&foo), then
yes. But that's the same as the next point.

You could have an addressof() which returns *T directly, instead of
going through &T.

> Transmuting *something to &something or back would fail for
> some types, unless we make transmute smarter.

Yes. That's what decoupling the semantics of a type from its
representation means.

Unsafe code would have to be more careful. Maybe there would be
special functions to deal with some things.

It would mean there would be no way /at all/, for some T, to go from
an &T to a *T pointing at the object it was borrowed from. You could
point it at the &T, but that might have a shorter lifetime. Not clear
if this would be problematic anywhere. (It would have be something
like calling a C function with a pointer, where the C function not
only accesses the pointer but returns or stores it (but doesn't mutate
through it), for a lifetime that's shorter than the original T's
lifetime but longer than the &T's.)

>
> I think for our sanity it would be best to let LLVM perform this kind of
> magic when it figures out we won't notice the difference.

(Can it?)

Anyway, this wasn't meant to be a proposal. Just exploring an idea.
It's fun to think about. Obviously there would be both complications
and benefits. But it definitely seems like a good idea to think
through what representation details should be specified on top of the
observable semantics, and what should be left up to the
implementation. *Reserving the right* to do this kind of thing might
be worthwhile (like we already do for enums).

> On Mon, Jul 29, 2013 at 4:47 PM, Gábor Lehel  wrote:
>>
>> On Sun, Jul 28, 2013 at 11:54 PM, Daniel Micay 
>> wrote:
>> > On Sun, Jul 28, 2013 at 4:54 PM, Brian Anderson 
>> > wrote:
>> >> FWIW I prefer the terms box and reference. I don't really understand
>> >> the
>> >> idea that only * is 'semantically a pointer' though.
>> >
>> > Unique boxes can be implemented without a pointer as long as the type
>> > is no larger than the slot needed to contain a pointer-size object.
>> > The pointer itself just isn't part of the type's contract, since
>> > there's no pointer arithmetic.
>>
>> Hmm. Given immutability, in the absence of Cell or destructors, ditto
>> for &T and @T? Do we even specify that it will be pointer-sized?
>>
>> Kind of amusing: you could have @@~~@@~~int with the same
>> representation as int, and "dereferencing" at each level just
>> transmute(self).
>>
>> It may look like this is only of theoretical interest, because no one
>> in their right mind would pass int by pointer, but it would be a
>> useful optimization for generic code - for the same reason.
>>
>> --
>> Your ship was destroyed in a monadic eruption.
>> ___
>> 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
>



-- 
Your ship was destroyed in a monadic eruption.
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Preview of the new rustdoc_web frontend

[Graydon Hoare]

On 29/07/2013 12:00 PM, Jordi Boggiano wrote:

Heya,

Crossposting from Reddit [1], just so more people see it and we can get
feedback:

It's a node project (sources [2]) feeding on the json output that cmr's
rustdoc_ng [3] generates to build a static site.

See http://seld.be/rustdoc/std/index.html for a preview of the std docs.


Very nice.

A few things I notice browsing-around:

- Many type refs appear as raw IDs. I know you mentioned this.

- Markdown isn't being formatted. `, *, _, ~~~ etc. show up in the
  docstrings. See: 
http://seld.be/rustdoc/std/rand/distributions/struct.StandardNormal.html


- //! isn't being stripped / interpreted correctly. See
  http://seld.be/rustdoc/std/task/fn.get_task.html

- Likewise leading * when digesting a block comment full of
  /* ...
   *
   */
  is not being stripped properly. See
  http://seld.be/rustdoc/std/run/struct.Process.html

- The use of color is interesting but I find it a little distracting
  since red is visited-link-color on my browser.
  In general the formatting seems a little too-large / too-bold also.
  These are just aesthetic bits though.

Overall it seems like a big improvement though. Thanks so much for the 
work! I'm excited to see it having come so far.


-Graydon

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

Re: [rust-dev] Preview of the new rustdoc_web frontend

[Jordi Boggiano]

> Wow, this is looking pretty great! I'm definitely looking forward to the
> search functionality; it'll save me loads of time. Will it just search
> function/module names, or also descriptions? 

We'll need to see what's feasible since this needs to be a plain js
solution, but I guess we can do at least names and short descriptions. I
guess parsing through the entire descriptions will be rather slow and
will yield tons of false positives. In any case this is not my specialty
so if anyone has a clue or wants to help ping me on #rustdoc-wg

> What about having the
> documentation link the the appropriate source files on Github (or
> embedding them within the page)? If it's tied into the Github API, could
> it also show open issues relating to certain modules, or perhaps
> TODOS/XXX within them?

It isn't tied to the GH API no, though I suppose if we see #\d+ in
comments we could infer that they are issue numbers and link to that.

Regarding the source, there is a "[src]" link (icon pending) on every
page that brings you to the definition in the libstd source.

Cheers

-- 
Jordi Boggiano
@seldaek - http://nelm.io/jordi
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Text encoding

[Thad Guidry]

Incidentally, Simon, to get the Rust community to help a bit more with
needed libraries, etc..that Servo will need...

Where are the current "needs" of Servo listed at ?  are they on the Roadmap
? https://github.com/mozilla/servo/wiki/Roadmap  or somewhere else ?


On Mon, Jul 29, 2013 at 1:18 PM, Simon Sapin  wrote:

> Le 29/07/2013 18:58, Fredrik Håård a écrit :
>
>  I wrote an implementation of text encoding/decoding for ISO*<->Unicode
>> in Rust, available 
>> here:https://github.com/haard/**rust-codecs
>>
>> I use approximately the same technique as the cpython implementation,
>> and it works by parsing unicode.org specifications and generating Rust
>> source; a charmap for each encoding and a codecs.rs which can be used
>> to encode/decode text.
>>
>> The implementation depends on std::unicode being public, which it is
>> not right now.
>>
>> Although it is in need of cleanup, more than the single naive
>> testcase, and adding stream handling etc to the API, since I got a
>> working version (aka the fun part), I thought it best to ask if an
>> implementation along those lines could be considered for inclusion? If
>> so I'll dedicate some time to clean it up, otherwise I'll find
>> something else to work on instead.
>>
>
> Hi,
>
> This looks great, thanks a lot for sharing!
>
> Please choose a software license (preferably an open-source one ;)) and
> add a LICENSE file to the repository.
>
> Servo will eventually need an implementation (ideally in Rust) of
> http://encoding.spec.whatwg.**org/  ,
> which has a lot in common with what you’re doing.
>
> Cheers,
> --
> Simon Sapin
>
> __**_
> Rust-dev mailing list
> Rust-dev@mozilla.org
> https://mail.mozilla.org/**listinfo/rust-dev
>



-- 
-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] Preview of the new rustdoc_web frontend

[Jeaye]

On 2013-07-29 13:00, Jordi Boggiano wrote:

Heya,

Crossposting from Reddit [1], just so more people see it and we can 
get

feedback:

It's a node project (sources [2]) feeding on the json output that 
cmr's

rustdoc_ng [3] generates to build a static site.

See http://seld.be/rustdoc/std/index.html for a preview of the std 
docs.





Wow, this is looking pretty great! I'm definitely looking forward to 
the search functionality; it'll save me loads of time. Will it just 
search function/module names, or also descriptions? What about having 
the documentation link the the appropriate source files on Github (or 
embedding them within the page)? If it's tied into the Github API, could 
it also show open issues relating to certain modules, or perhaps 
TODOS/XXX within them?


Cheers,
Jeaye

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

Re: [rust-dev] Text encoding

[Fredrik Håård]

Added a MIT license.

2013/7/29 Simon Sapin :
> Le 29/07/2013 18:58, Fredrik Håård a écrit :
>
>> I wrote an implementation of text encoding/decoding for ISO*<->Unicode
>> in Rust, available here:https://github.com/haard/rust-codecs
>>
>> I use approximately the same technique as the cpython implementation,
>> and it works by parsing unicode.org specifications and generating Rust
>> source; a charmap for each encoding and a codecs.rs which can be used
>> to encode/decode text.
>>
>> The implementation depends on std::unicode being public, which it is
>> not right now.
>>
>> Although it is in need of cleanup, more than the single naive
>> testcase, and adding stream handling etc to the API, since I got a
>> working version (aka the fun part), I thought it best to ask if an
>> implementation along those lines could be considered for inclusion? If
>> so I'll dedicate some time to clean it up, otherwise I'll find
>> something else to work on instead.
>
>
> Hi,
>
> This looks great, thanks a lot for sharing!
>
> Please choose a software license (preferably an open-source one ;)) and add
> a LICENSE file to the repository.
>
> Servo will eventually need an implementation (ideally in Rust) of
> http://encoding.spec.whatwg.org/ , which has a lot in common with what
> you’re doing.
>
> Cheers,
> --
> Simon Sapin
>
> ___
> Rust-dev mailing list
> Rust-dev@mozilla.org
> https://mail.mozilla.org/listinfo/rust-dev



-- 
/f

I reject your reality and substitute my own.
http://courteous.ly/yp3Zgd
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

[rust-dev] Preview of the new rustdoc_web frontend

[Jordi Boggiano]

Heya,

Crossposting from Reddit [1], just so more people see it and we can get
feedback:

It's a node project (sources [2]) feeding on the json output that cmr's
rustdoc_ng [3] generates to build a static site.

See http://seld.be/rustdoc/std/index.html for a preview of the std docs.

TODOs:
- follow new features in rustdoc_ng (impls are missing, closures
incomplete, some ids are buggy still)
- implement search
- parameterization/customizability
- design tweaks

[1]
http://www.reddit.com/r/rust/comments/1jalfe/rustdoc_web_preview_of_a_new_doc_frontend/
[2] https://github.com/Seldaek/rustdoc_web
[3] https://github.com/cmr/rustdoc_ng

Cheers

-- 
Jordi Boggiano
@seldaek - http://nelm.io/jordi
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] RFC: Removing *T

[Daniel Micay]

On Mon, Jul 29, 2013 at 1:21 PM, Thiez  wrote:
> This would make for some interesting/confusing calling conventions. It would
> also mean &T and &mut T would no longer share a representation; &int would
> simply be int, but &mut int would still have to be a pointer. Borrowing &mut
> T to &T would be a dereference if T is pointer size or smaller? The only
> reliable way of taking an address would be taking &mut because & would fail
> for some types. Transmuting *something to &something or back would fail for
> some types, unless we make transmute smarter.
>
> I think for our sanity it would be best to let LLVM perform this kind of
> magic when it figures out we won't notice the difference.

It will only do this for internal functions and only at --opt-level=3.
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Text encoding

[Simon Sapin]

Le 29/07/2013 18:58, Fredrik Håård a écrit :

I wrote an implementation of text encoding/decoding for ISO*<->Unicode
in Rust, available here:https://github.com/haard/rust-codecs

I use approximately the same technique as the cpython implementation,
and it works by parsing unicode.org specifications and generating Rust
source; a charmap for each encoding and a codecs.rs which can be used
to encode/decode text.

The implementation depends on std::unicode being public, which it is
not right now.

Although it is in need of cleanup, more than the single naive
testcase, and adding stream handling etc to the API, since I got a
working version (aka the fun part), I thought it best to ask if an
implementation along those lines could be considered for inclusion? If
so I'll dedicate some time to clean it up, otherwise I'll find
something else to work on instead.


Hi,

This looks great, thanks a lot for sharing!

Please choose a software license (preferably an open-source one ;)) and 
add a LICENSE file to the repository.


Servo will eventually need an implementation (ideally in Rust) of 
http://encoding.spec.whatwg.org/ , which has a lot in common with what 
you’re doing.


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

Re: [rust-dev] Text encoding

[Kang Seonghoon]

Wow, it *is* indeed a coincidence: I'm also working on the character
encoding library.

https://github.com/lifthrasiir/rust-encoding

Although this one is much more sophiscated that it supports an API for
error detection and recovery. I'm not sure the whole library merits
the inclusion however, as CJK needs several hundreds of kilobytes of
data which is certainly duplicated with the system library. I would
prefer the character encoding interface (`src/types.rs`) included in
`std` however.

2013/7/30 Fredrik Håård :
> I wrote an implementation of text encoding/decoding for ISO*<->Unicode
> in Rust, available here: https://github.com/haard/rust-codecs
>
> I use approximately the same technique as the cpython implementation,
> and it works by parsing unicode.org specifications and generating Rust
> source; a charmap for each encoding and a codecs.rs which can be used
> to encode/decode text.
>
> The implementation depends on std::unicode being public, which it is
> not right now.
>
> Although it is in need of cleanup, more than the single naive
> testcase, and adding stream handling etc to the API, since I got a
> working version (aka the fun part), I thought it best to ask if an
> implementation along those lines could be considered for inclusion? If
> so I'll dedicate some time to clean it up, otherwise I'll find
> something else to work on instead.
>
> Regards,
> fredrik
> ___
> Rust-dev mailing list
> Rust-dev@mozilla.org
> https://mail.mozilla.org/listinfo/rust-dev



-- 
-- Kang Seonghoon | Software Engineer, iPlateia Inc. | http://mearie.org/
-- Opinions expressed in this email do not necessarily represent the
views of my employer.
--
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

[rust-dev] Text encoding

[Fredrik Håård]

I wrote an implementation of text encoding/decoding for ISO*<->Unicode
in Rust, available here: https://github.com/haard/rust-codecs

I use approximately the same technique as the cpython implementation,
and it works by parsing unicode.org specifications and generating Rust
source; a charmap for each encoding and a codecs.rs which can be used
to encode/decode text.

The implementation depends on std::unicode being public, which it is
not right now.

Although it is in need of cleanup, more than the single naive
testcase, and adding stream handling etc to the API, since I got a
working version (aka the fun part), I thought it best to ask if an
implementation along those lines could be considered for inclusion? If
so I'll dedicate some time to clean it up, otherwise I'll find
something else to work on instead.

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

[rust-dev] MPS investigation for Rust GC

[Thad Guidry]

REGARDING:
- Graydon wants to investigate using the Memory Pool System as the Rust GC,
  rather than a bespoke one. The
[MPS](http://www.ravenbrook.com/project/mps/) is
  a very mature and robust memory management library.

Reading through and seeing one of the MPS creators initial design goals :

"The MPS was not designed for C++, but as a memory manager for dynamic
language run-time systems. In fact, it was specifically designed not to
require C++."

...instantly gained my respect for this system and its potential.

-- 
-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] RFC: Removing *T

[Thiez]

This would make for some interesting/confusing calling conventions. It
would also mean &T and &mut T would no longer share a representation; &int
would simply be int, but &mut int would still have to be a pointer.
Borrowing &mut T to &T would be a dereference if T is pointer size or
smaller? The only reliable way of taking an address would be taking &mut
because & would fail for some types. Transmuting *something to &something
or back would fail for some types, unless we make transmute smarter.

I think for our sanity it would be best to let LLVM perform this kind of
magic when it figures out we won't notice the difference.

On Mon, Jul 29, 2013 at 4:47 PM, Gábor Lehel  wrote:

> On Sun, Jul 28, 2013 at 11:54 PM, Daniel Micay 
> wrote:
> > On Sun, Jul 28, 2013 at 4:54 PM, Brian Anderson 
> wrote:
> >> FWIW I prefer the terms box and reference. I don't really understand the
> >> idea that only * is 'semantically a pointer' though.
> >
> > Unique boxes can be implemented without a pointer as long as the type
> > is no larger than the slot needed to contain a pointer-size object.
> > The pointer itself just isn't part of the type's contract, since
> > there's no pointer arithmetic.
>
> Hmm. Given immutability, in the absence of Cell or destructors, ditto
> for &T and @T? Do we even specify that it will be pointer-sized?
>
> Kind of amusing: you could have @@~~@@~~int with the same
> representation as int, and "dereferencing" at each level just
> transmute(self).
>
> It may look like this is only of theoretical interest, because no one
> in their right mind would pass int by pointer, but it would be a
> useful optimization for generic code - for the same reason.
>
> --
> Your ship was destroyed in a monadic eruption.
> ___
> 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] Last Week in Rust

[Corey Richardson]

Hello and welcome to the eighth issue of *This Week in Rust*. Due to me being
busy and forgetful over the weekend, this is a special issue, *Last Week in
Rust*.



# What's cooking on `master`?

Issue churn continues to be negative, -15 this week. A total of 63 PRs were
merged.

## Breaking Changes

There were impressively few breaking changes last week.

- **You now need to pass `--cfg debug` to `rustc` to emit debug logging.**
- [**`mod.rs` is now "blessed".**](https://github.com/mozilla/rust/pull/7926).
  When loading `mod foo;`, rustc will now look for `foo.rs`, then
  `foo/mod.rs`, and will generate an error when both are present.
- [A bunch of `str` functions](https://github.com/mozilla/rust/pull/7996) were
  renamed or shuffled around to be more consistent.
- [`SmallIntSet` was removed](https://github.com/mozilla/rust/pull/7934) in
  favor for the more efficient, equivalent `BitvSet`.
- [`Bitv` and `Bitvset` have switched to external
  iterators](https://github.com/mozilla/rust/pull/7703).
- [`extra::net` and a bunch of other obsolete
  features](https://github.com/mozilla/rust/pull/7883) have been removed.

## Notable library additions, bugfixes, and cleanup

- Various [TCP/UDP additions](https://github.com/mozilla/rust/pull/8040) have
  been made in the new rt.
- Some more [atomic operations](https://github.com/mozilla/rust/pull/8039)
  have been added.
- A [`chain_mut_ref` method](https://github.com/mozilla/rust/pull/7931) was
  added to `Option`.
- [Random access iterators](https://github.com/mozilla/rust/pull/7982) have
  been implemented.
- Some missing [memory orderings on atomic
  types](https://github.com/mozilla/rust/pull/7993) have been added.
- [workcache has seen a bunch of
  attention](https://github.com/mozilla/rust/pull/7885).
- [DList has seen some more cleanup
  too](https://github.com/mozilla/rust/pull/7944).
- [Timers have been added to the new
  rt](https://github.com/mozilla/rust/pull/7916).
- [Vectors now implement `slice_from` and
  `slice_to`](https://github.com/mozilla/rust/pull/7943).

## Notable compiler additions, bugfixes, and cleanup

- [debuginfo for destructured locals and function
  args](https://github.com/mozilla/rust/pull/8045) is now implemented.
- [Raw representations are now
  consolidated](https://github.com/mozilla/rust/pull/7986).
- [Impossible branches on
  constants](https://github.com/mozilla/rust/pull/8041) are now omitted.
- [It is now possible to link against crates with
  `#[no_std]`](https://github.com/mozilla/rust/pull/7924).
- [There is now a warning when matching against
  NaN](https://github.com/mozilla/rust/pull/8029), since it is impossible to
  match against NaN (NaN != NaN).
- A lot of [default method and trait inheritance
  bugs](https://github.com/mozilla/rust/pull/8015) have been fixed.
- [`uint` enum discriminants are now
  allowed](https://github.com/mozilla/rust/pull/8000).
- The [section placement of static and fn items is now
  configurable](https://github.com/mozilla/rust/pull/7958).
- Some [trans naming modernization has
  occured](https://github.com/mozilla/rust/pull/7848).
- Some unnecessary branches and blocks [have been
  removed](https://github.com/mozilla/rust/pull/7941), resulting in a 10%
  speedup of unoptimized rustc.

## Documentation, tools, and other stuff

- [Some benchmarks](https://github.com/mozilla/rust/pull/7912), and [some more
  benchmarks](https://github.com/mozilla/rust/pull/7980).
- Crnobog has [fixed](https://github.com/mozilla/rust/pull/8001)
  [some](https://github.com/mozilla/rust/pull/7979) Windows testsuite issues.
- [`Makefile` dependencies](https://github.com/mozilla/rust/pull/7820) have
  been fixed. `rustc` will never be invoked without its dependencies being
  built.
- [`rust-mode` has been rewritten](https://github.com/mozilla/rust/pull/8031).
- [There are some build system changes surrounding the `--cfg debug`
  changes](https://github.com/mozilla/rust/pull/8020).

# Meetings

The [Tuesday
meeting](https://github.com/mozilla/rust/wiki/Meeting-weekly-2013-07-23) was
quite productive. A quick summary:

- Graydon wants to investigate using the Memory Pool System as the Rust GC,
  rather than a bespoke one. The
[MPS](http://www.ravenbrook.com/project/mps/) is
  a very mature and robust memory management library.
- The buildbots now collect and report some metrics as JSON. Take a poke in
  
`http://static.rust-lang.org/build-metrics.json`
  if you're interested.
- pcwalton proposes allowing `Self` in impls, like in trait definitions.
- There was some discussion of destructors taking `self` by value.
- There was a proposal to remove `*mut`, but it can be useful. There was no
  consensus.
- There was also some discussion on closures and mutable captures. I don't
  really have enough context to understand the conversation, something to do
  with "thunks".
- Removing `&const` was discussed as well. The "plan is that we add a lint
  flag but document it as a reserved word", as it doesn't really seem t

Re: [rust-dev] Redesigning fmt!

[Graydon Hoare]

On 13-07-29 02:41 AM, Steven Ashley wrote:


Apologies. This was exactly the use case  I was trying to convey.
Unfortunately I was writing the email from my phone while on the run and
couldn't recall the specifics of the syntax. I should have indicated it
was pseudo code of sorts.


Oh, no worries! Just re-reading what I wrote, it sounds a bit snippish. 
Didn't mean to sound that way at all. I just wanted to point out that 
it's been covered (and I guess try to head off a bikeshed on this 
subgrammar; or for that matter the common refrain that this is a 
bottomless problem to which no reasonable solution can be found).



In any case I really like the direction this is heading and I'm really
looking forward to playing with it. Thanks again Alex for kicking this off.


Likewise. Fmt (like log) is quite old and in need of some love.

-Graydon


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

Re: [rust-dev] RFC: Removing *T

[Gábor Lehel]

On Sun, Jul 28, 2013 at 11:54 PM, Daniel Micay  wrote:
> On Sun, Jul 28, 2013 at 4:54 PM, Brian Anderson  wrote:
>> FWIW I prefer the terms box and reference. I don't really understand the
>> idea that only * is 'semantically a pointer' though.
>
> Unique boxes can be implemented without a pointer as long as the type
> is no larger than the slot needed to contain a pointer-size object.
> The pointer itself just isn't part of the type's contract, since
> there's no pointer arithmetic.

Hmm. Given immutability, in the absence of Cell or destructors, ditto
for &T and @T? Do we even specify that it will be pointer-sized?

Kind of amusing: you could have @@~~@@~~int with the same
representation as int, and "dereferencing" at each level just
transmute(self).

It may look like this is only of theoretical interest, because no one
in their right mind would pass int by pointer, but it would be a
useful optimization for generic code - for the same reason.

-- 
Your ship was destroyed in a monadic eruption.
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Redesigning fmt!

[Steven Ashley]

On 29/07/2013 6:36 AM, "Graydon Hoare"  wrote:
>
> On 13-07-28 04:06 PM, Steven Ashley wrote:
>
>> {0:(
>>if count == 0 then (You have no messages.)
>>else (You have {count:#} messages.)
>> )}
>
>
> That's exactly the case that the nested pluralization forms are for. Read
the docs on MessageFormat. They've been working on this problem space for
quite a long time and have reasonable mechanisms mapped out for the most
common value-driven grammar alteration cases (plural, gender, selects).
>
> -Graydon

Apologies. This was exactly the use case  I was trying to convey.
Unfortunately I was writing the email from my phone while on the run and
couldn't recall the specifics of the syntax. I should have indicated it was
pseudo code of sorts.

In any case I really like the direction this is heading and I'm really
looking forward to playing with it. Thanks again Alex for kicking this off.

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

Re: [rust-dev] Redesigning fmt!

[Masklinn]

On 2013-07-29, at 11:04 , Huon Wilson wrote:

> On 29/07/13 18:26, Masklinn wrote:
>> I don't have much to say, but
>> 
>> On 2013-07-29, at 06:24 , Alex Crichton wrote:
>>>  * Any argument can be selected (0-indexed from the start)
>> keyword/named selection is *really* great for longer/more busy patterns,
>> it makes format string much more readable both in-code and for
>> translators (who usually lack part of the context, even with comments,
>> especially if they are non-technical). I think this is one of the great
>> strengths of Python's string formatting (both C-style and C#-style) or
>> Ruby's string interpolation, and if the formatting language is going
>> to be reworked away from C-style formats it would be nice to include
>> it if possible.
>> 
>> I don't think it can be integrated directly into the current grammar
>> though, as there'd be ambiguity with the function spec.
>> ___
>> Rust-dev mailing list
>> Rust-dev@mozilla.org
>> https://mail.mozilla.org/listinfo/rust-dev
> 
> fmt! is a syntax extension (which receive their arguments as tokens, not at 
> all parsed), so it can actually "define" its own syntax for named arguments, 
> without any modifications to Rust's grammar (as long as it tokenises)

I was talking about the fmt! syntax described by Alex here, not Rust's grammar.

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

Re: [rust-dev] Redesigning fmt!

[Armin Ronacher]

Hi,

On 29/07/2013 06:24, Alex Crichton wrote:

Having thought a bit more concretely about this, using the suggestions here,
and talking to Graydon on IRC I've come up with the following design for a
string formatting library. I think that this addresses the comments in the
responses to my original email, but if not please let me know!
I love the proposal.  I have been hoping for extensible and rearrangable 
formatting for a really long time.  Just a few notes on i18n support.



A few notes:
   * I believe that parsing must occur at runtime, because otherwise i18n
 wouldn't work because it could generate any arbitrary format string at
 runtime based on the current locale.
Can we have both?  Parse at compile time if the string is constant but 
parse at compile time if the string comes from something like a 
gettext-ish function that loads the string from a message catalog.



I also wanted to touch on how this covers internationalization. The main point
of this is located within the query language, but the runtime must also support
some constructs. The format string and arguments are validated at compile-time,
but any format string could be run at runtime. For this reason an equivalence
function will be needed that takes the original format string and a translated
format string and ensures at runtime that the two are equivalent in terms of
types, position, and number of arguments.
Having done some i18n work through Babel i can tell you that people 
vastly prefer keyword based syntax over positional one.  Granted, part 
of it is because in Babel (which uses old Python printf style 
formatting) you can rearrange them.  A bit part of the reason however is 
because sometimes translations lag behind and a new argument was added 
later.  If that new argument does not show up in the new format string 
it's silently ignored.


The whole translation workflow should not be forgotten.  Very few 
projects can afford to not have translations lagging behind.  I believe 
formatting for i18n should be as lenient as possible, something that 
does not hold true for normal format strings.  Maybe some compromise can 
be added to have strictness levels on the formatting?



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

Re: [rust-dev] Redesigning fmt!

[Huon Wilson]

On 29/07/13 18:26, Masklinn wrote:

I don't have much to say, but

On 2013-07-29, at 06:24 , Alex Crichton wrote:

  * Any argument can be selected (0-indexed from the start)

keyword/named selection is *really* great for longer/more busy patterns,
it makes format string much more readable both in-code and for
translators (who usually lack part of the context, even with comments,
especially if they are non-technical). I think this is one of the great
strengths of Python's string formatting (both C-style and C#-style) or
Ruby's string interpolation, and if the formatting language is going
to be reworked away from C-style formats it would be nice to include
it if possible.

I don't think it can be integrated directly into the current grammar
though, as there'd be ambiguity with the function spec.
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev


fmt! is a syntax extension (which receive their arguments as tokens, not 
at all parsed), so it can actually "define" its own syntax for named 
arguments, without any modifications to Rust's grammar (as long as it 
tokenises), so some or all of


   fmt!("{foo}", foo)
   fmt!("{foo}", foo=bar)
   fmt!("{foo} {bar}", let (foo, bar) = baz)

could be made to work; although, `foo = bar` is a valid expression (with 
return type ()), so it might be suboptimal to change its behaviour here. 
The `let` form allows for pattern matching in fmt! args, and still 
allows the fmt! implementation to have a simple parser.


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

Re: [rust-dev] Implement Digest trait for MD4 and MD5

[Alexei Sholik]

I mentioned checksum algorithms because I have a motivation to work on them
and thought Rust could have the most popular ones in stdlib. I wasn't
suggesting to put them into the same category as digests.

For the record, I'm looking at Go's crypto[1] and hash[2] packages as an
indicator of what could find its way into the standard lib.

  [1]: http://golang.org/pkg/crypto/  (scroll to the bottom to see
subpackages)
  [2]: http://golang.org/pkg/hash/


On Mon, Jul 29, 2013 at 9:53 AM, Graydon Hoare  wrote:

> On 13-07-28 05:27 PM, Kevin Cantu wrote:
>
>> AFAIK new algorithms using MD4 (and probably MD5) would also be simply
>> wrong, too.
>>
>
> They were designed as CHFs; they are now weak-or-broken but code that's
> interoperating with old cryptosystems do need them from time to time.
>
> CRCs and Checksums aren't CHFs and shouldn't be put anywhere near them.
> I'd be somewhat cautious even calling them hash functions, but I guess it's
> a short enough name.
>
> I suggest (humbly and willing to listen to counterarguments) that we have
> a trait std::crypto::Digest and a trait std::hash::Hash, with default
> implementations of each that we consider state of the art, in std; and then
> a bucket of "extra" named algorithms that satisfy the same trait in
> extra::crypto and extra::hash.
>
> In general I _think_ I'd like important / widely-used traits to be
> specified in std, even if "most" implementations don't live in std. There's
> value to getting the interface widely standardized.
>
> The same issue comes up with a lot of other interfaces: the container
> types (hashtables and balanced trees), random number generators,
> serialization schemes, compressors and such are all like this: there are 95
> different known, named variants someone _might_ want to use for some
> particular interoperability or taste reason, but I suggest that the
> interface and a promise of at least 1 "reasonably good" implementation --
> hidden behind &Trait or a non-specified typedef or something -- ought to be
> standardized.
>
> -Graydon
>
>
> __**_
> Rust-dev mailing list
> Rust-dev@mozilla.org
> https://mail.mozilla.org/**listinfo/rust-dev
>



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

Re: [rust-dev] Redesigning fmt!

[Masklinn]

I don't have much to say, but

On 2013-07-29, at 06:24 , Alex Crichton wrote:
> 
>  * Any argument can be selected (0-indexed from the start)

keyword/named selection is *really* great for longer/more busy patterns,
it makes format string much more readable both in-code and for
translators (who usually lack part of the context, even with comments,
especially if they are non-technical). I think this is one of the great
strengths of Python's string formatting (both C-style and C#-style) or
Ruby's string interpolation, and if the formatting language is going
to be reworked away from C-style formats it would be nice to include
it if possible.

I don't think it can be integrated directly into the current grammar
though, as there'd be ambiguity with the function spec.
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Implement Digest trait for MD4 and MD5

[Kevin Cantu]

I almost think we shouldn't try.  Any code running with one default
implementation will have to change when we update the default to something
more secure, or else we'll have to version everything, and at that point
rather than worry about what it was, we'll wish we'd just named Rust 0.X's
std::crypto::Digest as std::crypto::SHA2::Digest256 or whatever name
everyone else knows it by.

But I like the idea.  Is there a way to provide even a little bit of that
value of perpetually sane defaults?


Kevin




-- 
Kevin Cantu


On Sun, Jul 28, 2013 at 11:53 PM, Graydon Hoare  wrote:

> On 13-07-28 05:27 PM, Kevin Cantu wrote:
>
>> AFAIK new algorithms using MD4 (and probably MD5) would also be simply
>> wrong, too.
>>
>
> They were designed as CHFs; they are now weak-or-broken but code that's
> interoperating with old cryptosystems do need them from time to time.
>
> CRCs and Checksums aren't CHFs and shouldn't be put anywhere near them.
> I'd be somewhat cautious even calling them hash functions, but I guess it's
> a short enough name.
>
> I suggest (humbly and willing to listen to counterarguments) that we have
> a trait std::crypto::Digest and a trait std::hash::Hash, with default
> implementations of each that we consider state of the art, in std; and then
> a bucket of "extra" named algorithms that satisfy the same trait in
> extra::crypto and extra::hash.
>
> In general I _think_ I'd like important / widely-used traits to be
> specified in std, even if "most" implementations don't live in std. There's
> value to getting the interface widely standardized.
>
> The same issue comes up with a lot of other interfaces: the container
> types (hashtables and balanced trees), random number generators,
> serialization schemes, compressors and such are all like this: there are 95
> different known, named variants someone _might_ want to use for some
> particular interoperability or taste reason, but I suggest that the
> interface and a promise of at least 1 "reasonably good" implementation --
> hidden behind &Trait or a non-specified typedef or something -- ought to be
> standardized.
>
> -Graydon
>
>
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev