Re: [rust-dev] Removing some autoref magic

[Tommi]

On 2013-11-20, at 7:13, Tommi  wrote:

> Yeah, my claim that it "doesn't buy us anything" stemmed from a misconception 
> that arg.foo() could move arg, given let arg: ~A; and fn foo(x: ~A) {...}. I 
> had already forgotten that Rust UFCS was specified differently from D's. To 
> anyone not following, in D it would be a simple re-write to foo(arg) and, in 
> Rust, to foo(&arg).

Scratch that. I seem to have different things mixed up now. I found this ticket 
https://github.com/mozilla/rust/issues/6974 again and it seems I should stand 
by my initial argument. Let me explain my argument again:

Our problem is that, given let arg: ~A;, seeing only foo(arg) in code doesn't 
tell us whether arg is moved or borrowed. The proposed solution is that 
auto-borrowing in that context would be deprecated and thus would require an 
explicit borrowing: foo(&*arg). Now, given that it seems that the upcoming UFCS 
would simply re-write arg.foo() to foo(arg), it would mean that seeing only 
arg.foo() in code doesn't tell us whether arg is moved or borrowed. Thus, the 
proposed solution would fix only half of the problem.___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Removing some autoref magic

[Tommi]

On 2013-11-20, at 6:24, Patrick Walton  wrote:

> On 11/19/13 7:43 PM, Tommi wrote:
>> I like how your argument nudges this whole discussion a few inches to
>> the left. Now we see that disallowing auto-borrowing from regular
>> function arguments doesn't buy us anything unless we also disallow it
>> from the target of method invocation syntax (dot notation). And
>> that's obviously assuming the upcoming UFCS feature. I doubt that
>> anyone would like to be writing (&*foo).call_method() all day long.
> 
> Magic in one part of the language isn't equivalent to magic everywhere in the 
> language. The dot operator is already magical in several ways: it autoderefs 
> for fields and searches through all traits in scope. This proposal would 
> confine the magic to that operator and that operator alone, preventing it 
> from leaking out into other parts of the language.
> 
> Patrick
> 

Yeah, my claim that it "doesn't buy us anything" stemmed from a misconception 
that arg.foo() could move arg, given let arg: ~A; and fn foo(x: ~A) {...}. I 
had already forgotten that Rust UFCS was specified differently from D's. To 
anyone not following, in D it would be a simple re-write to foo(arg) and, in 
Rust, to foo(&arg).___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Removing some autoref magic

[Patrick Walton]

On 11/19/13 7:43 PM, Tommi wrote:

I like how your argument nudges this whole discussion a few inches to
the left. Now we see that disallowing auto-borrowing from regular
function arguments doesn't buy us anything unless we also disallow it
from the target of method invocation syntax (dot notation). And
that's obviously assuming the upcoming UFCS feature. I doubt that
anyone would

like to be writing (&*foo).call_method() all day long.

Magic in one part of the language isn't equivalent to magic everywhere 
in the language. The dot operator is already magical in several ways: it 
autoderefs for fields and searches through all traits in scope. This 
proposal would confine the magic to that operator and that operator 
alone, preventing it from leaking out into other parts of the language.


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

Re: [rust-dev] Removing some autoref magic

[Tommi]

On 2013-11-20, at 1:40, Benjamin Striegel  wrote:

> If autoref still happens on methods, does this mean that you'd be able to get 
> around the need to do:
> 
> sort(&mut *foo);
> 
> ...by turning it into a method?
> 
> foo.sort();

I like how your argument nudges this whole discussion a few inches to the left. 
Now we see that disallowing auto-borrowing from regular function arguments 
doesn't buy us anything unless we also disallow it from the target of method 
invocation syntax (dot notation). And that's obviously assuming the upcoming 
UFCS feature. I doubt that anyone would like to be writing 
(&*foo).call_method() all day long.
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] autocomplete engine for rust

[Val Markovic]

On Tue, Nov 19, 2013 at 1:12 PM, Gokcehan Kara wrote:

> I will be speculating a little since I haven't actually read the source.
> As far as I understand, YouCompleteMe uses python for some parts but at its
> core it has a cpp component using libclang library. libclang library itself
> is already something that provides code completion which is the thing
> missing for rust language.
>
> [libclang]: http://clang.llvm.org/doxygen/group__CINDEX.html
>

This is mostly correct. libclang is clang compiler API (the entire compiler
is in the binary and is exposed through the C API). YCM is written is
several languages: VimScript for the Vim client and Python & C++ for the
server binary. Python is the glue code between the various components and
semantic engines. Jedi is a semantic engine written in Python, OmniSharp is
written in C#. There's a C++ component that talks to libclang. There's
another C++ component that does the complex subsequence candidate string
matching and candidate ranking.


>
>
> On Tue, Nov 19, 2013 at 10:13 PM, Gaetan  wrote:
>
>> I think we can write in rust and perhaps reuse part of the compiler, but
>> we cannot allow to support only fully compiler crates.
>>
>> It may be possible to begin a draft in language such as python
>> (YouCompleteMe seems to be written mostly in python)
>>
>> -
>> Gaetan
>>
>>
>>
>> 2013/11/19 Gokcehan Kara 
>>
>>> I'm willing to help on this task, I think having a good completion
 library can help a lot smoothing the learning curve of a new language. I
 learned python in a few days with aptana, and I remember a few years ago
 how it was easy to write C++ with visual studio. Having an IDE integration
 is almost as important as having good tutorials.
>>>
>>>
>>> That's great. I agree that it would be nice for newbies and I think also
>>> for others as most people are already quite spoiled by the capabilities of
>>> modern IDE's these days.
>>>
>>> I'm also a newbe in Rust and I imagine you want to write in rust itself.
 I can help on the integration with sublime.
>>>
>>>
>>> I was hoping to write in rust because I don't want to implement/maintain
>>> a parser and typechecker from scratch. I was very pleased to see that it's
>>> possible to access everything in `librustc` and `libsyntax` with a simple
>>> `extern`, not sure if this will be removed later.
>>>
>>> rustfind (https://github.com/dobkeratops/rustfind) does this and more,
 for crates that compile.
>>>
>>>
>>> I wasn't aware of that, looks very nice indeed. I will take a look and
>>> see if I can contribute somehow when I have some time.
>>>
>>> Not very, for the general case. If you want autocompletion as you
 type, you currently need to have a fully-compilable crate. Otherwise,
 parsing or typechecking or something else will fail and you won't be
 able to get any results. rustc is currently very all-or-nothing.
>>>
>>>
>>> It's a bummer. Are there any plans to implement some error recovery to
>>> rustc?
>>>
>>> But, you can get useful information for completion out of an
 already-compiling crate, though I'm not sure how much better it would
 be than what etags already does.
>>>
>>>
>>> It has been some time since I last tried tags for autocompletion but it
>>> wasn't very accurate as far as I remember. As far as I know you also need
>>> some editor plugin for this, something like [OmniCppComplete](
>>> http://www.vim.org/scripts/script.php?script_id=1520) which is
>>> basically a cpp parser implemented in vimscript.
>>>
>>> Very, since it would require reworking most of the compiler ;)
>>>
>>>
>>> :)
>>>
>>
>>
>
> ___
> 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] autocomplete engine for rust

[Val Markovic]

On Mon, Nov 18, 2013 at 3:25 PM, Gokcehan Kara wrote:

> I have been thinking of working on an editor agnostic code helper library
> with an autocomplete engine for rust (since there isn't anything yet?) as a
> hobby project to get to know the internals of the compiler. Examples of
> similar projects in different languages include;
>

This is a great idea. Rust needs to have something like libclang. In fact,
I think the Clang project was started because GCC had such poor support for
being used as a library (well, that and the GPLv3 license making it hard
for Apple to link it into Xcode). This should teach us something.


> - [youcompleteme](https://github.com/Valloric/YouCompleteMe)
> (C/C++/Objective-C/Objective-C++) (this one is specific to vim and a more
> general solution to autocompletion in vim but it includes a clang based
> completion engine for c family languages)
>

YCM is a bit more complicated than that (and I'd know since I wrote it :)).
It provides a general framework for tying together various semantic engines
and building an awesome code completion experience on top. YCM currently
uses libclang as the semantic engine for C/C++/ObjC/ObjC++, Jedi for
Python, OmniSharp for C# etc. Plugging in a new semantic engine is very
easy. YCM can use the Vim omnifunc as the semantic source so it can tie
into other plugins that provide an omnifunc, like Eclim for Java or gocode
for Go. YCM then provides its own features on top of that.

YCM *used* to be specific to Vim, but that's slowly changing. I recently
rewrote it from scratch to have a client-server architecture where almost
all of the logic is in the server; the client is a very thin shell that
merely queries the server. Some time in the future you'll see YCM clients
for other editors like SublimeText, emacs and others. I first have to pull
out the server source code into a separate repo on GitHub.

Bottom line, if you get to a point where you have a library with an API
that can provide completions for Rust code, I'd love to hook it into YCM.
There's a similar project (DCD ) going
for D as well; when that's more stable it will be hooked up to YCM too.
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Please simplify the syntax for Great Justice

[Val Markovic]

On Tue, Nov 19, 2013 at 5:21 PM, Patrick Walton wrote:

>
> I agree that we should change this, but give us some credit: it's only an
> obvious design mistake now that we've gotten to this point.
> [...]

The current status is the product of the slow evolution of a design that
> predated the region and slicing system, and what seems obvious now was not
> obvious in retrospect.


Fair point. I give you guys a lot of credit though, Rust is a wonderful
language in general. I also admire how willing core Rust devs are to admit
"ok that was a bad idea, let's try something else." I don't see that every
day; Rust is better for it.

Please continue being awesome.


>
>
> 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] Removing some autoref magic

[Ben Kloosterman]

While i like auto magic eg you could let region analysis work out the
pointer type , borrowed pointers etc  ,however you need to be very careful
. C# uses ref  but autoboxing is a major issue , you dont know when the
struct is boxed ( there are some places besides the obvious virt call ) and
then you incur boxing costs  defeating the whole point of value types .
 The vast majority of C# developers only use structs for a few corner cases
eg a type holding a few values  ( many dont use value types at all) , they
could go further but often it will get boxed somewhere and kill the
benefits so why go through the hassle.

Ben


On Wed, Nov 20, 2013 at 9:35 AM, Vadim  wrote:

> If the function is not going to mutate it, I don't really care if it's
> by-ref or by-value.   That's why I said "const T&", not "T&".   Well,
> except for the case when a function caches a reference to something which I
> later mutate.   But borrow checking will prevent that.
>
> I would also be totally fine with letting the compiler figure out how
> immutable arguments are passed (based on data type size, existence of
> destructors, and whatnot).  This might not be the best idea for binary
> compatibility of public APIs, but I don't see why it can't be done with
> crate-private functions.
>
>
>
>
> On Tue, Nov 19, 2013 at 5:07 PM, Ziad Hatahet  wrote:
>
>> > Personally I would prefer if & in Rust worked similar to const T& in c++
>>
>> In that case, you would not be able to tell whether a function argument
>> was passed by value or by reference. I actually like this feature about
>> Rust (C# has it too with the `ref` keyword).
>>
>> --
>> Ziad
>>
>>
>> On Tue, Nov 19, 2013 at 4:54 PM, Vadim  wrote:
>>
>>> So why did Rust adopt auto-moving instead of explicit moving?   If the
>>> second example had to be written as foo(move a) there would be no
>>> confusion.   The and the third example should arguably be sort(mut
>>> a.as_mut_slice()).
>>>
>>> Personally I would prefer if & in Rust worked similar to const T& in c++
>>> (i.e. for most intents and purposes you can treat a reference as a value),
>>> otherwise half of the arguments on each function call will have to be
>>> adorned with ampersands.
>>>
>>> Can we have it such that foo(a) would be guaranteed to not mutate or
>>> move a and require "mut" or "move" prefix otherwise?
>>>
>>>
>>> ___
>>> 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] Removing some autoref magic

[Vadim]

If the function is not going to mutate it, I don't really care if it's
by-ref or by-value.   That's why I said "const T&", not "T&".   Well,
except for the case when a function caches a reference to something which I
later mutate.   But borrow checking will prevent that.

I would also be totally fine with letting the compiler figure out how
immutable arguments are passed (based on data type size, existence of
destructors, and whatnot).  This might not be the best idea for binary
compatibility of public APIs, but I don't see why it can't be done with
crate-private functions.




On Tue, Nov 19, 2013 at 5:07 PM, Ziad Hatahet  wrote:

> > Personally I would prefer if & in Rust worked similar to const T& in c++
>
> In that case, you would not be able to tell whether a function argument
> was passed by value or by reference. I actually like this feature about
> Rust (C# has it too with the `ref` keyword).
>
> --
> Ziad
>
>
> On Tue, Nov 19, 2013 at 4:54 PM, Vadim  wrote:
>
>> So why did Rust adopt auto-moving instead of explicit moving?   If the
>> second example had to be written as foo(move a) there would be no
>> confusion.   The and the third example should arguably be sort(mut
>> a.as_mut_slice()).
>>
>> Personally I would prefer if & in Rust worked similar to const T& in c++
>> (i.e. for most intents and purposes you can treat a reference as a value),
>> otherwise half of the arguments on each function call will have to be
>> adorned with ampersands.
>>
>> Can we have it such that foo(a) would be guaranteed to not mutate or move
>> a and require "mut" or "move" prefix otherwise?
>>
>>
>> ___
>> 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] Please simplify the syntax for Great Justice

[Patrick Walton]

On 11/19/13 5:12 PM, Val Markovic wrote:

I felt cheated a bit TBH. It's such an obvious design mistake IMO;
everyone's going to get this wrong because it's counter-intuitive.


I agree that we should change this, but give us some credit: it's only 
an obvious design mistake now that we've gotten to this point. For those 
joining us now, we have gone through the following changes starting 3 
years ago:


1. `[T]` is always reference counted. Pushing onto a vector was 
optimized to push in-place iff the reference count was 1. There is `[mut 
T]` as well. There is no overloading and also no slicing, because there 
was no region system.
2. `[T]` is always owned and small vector optimized with 4 elements 
in place (number arrived at through measurements). There is no `[mut 
T]`. There is no slicing because there is no region system.
3. `[T]` is always owned and not small vector optimized. There is 
no slicing.
4. We have 4 vector types, `[T, ..N]`, `[T]/&` and `[T]/~` (today 
`[T, ..N]`, `&[T]`, `~[T]` respectively), as well as `[T]/@` which is 
reference counted. Vector literals infer to the right one. Owned and 
managed vectors can be sliced.

5. We have 4 vector types, `[T, ..N]`, `&[T]`, `~[T]`, and `@[T]`.
6. We have 3 vector types, `[T, ..N]`, `&[T]` and `~[T]`.

Now we're talking about:

7. We have 1 built-in vector type: `[T, ..N]`. Slices are 
`Slice` lang items. Owned and managed vectors can be built into the 
library.


The current status is the product of the slow evolution of a design that 
predated the region and slicing system, and what seems obvious now was 
not obvious in retrospect.


Patrick

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

Re: [rust-dev] Please simplify the syntax for Great Justice

[Val Markovic]

On Tue, Nov 19, 2013 at 4:43 AM, Daniel Micay  wrote:
>
> The expression ~([1, 2, 3]) has a different type than the expression
> ~[1, 2, 3]. The former is an owned box containing a fixed size array
> (~[int, ..3]) and the latter is a dynamic array (~[int]).
>
> The ~str and ~[T] types are *not* owned boxes in the current type
> system. There has been a proposal for dynamically sized types which
> would make them owned boxes, but I only like it as the path forwards
> for traits/closures and not vectors.
>
> I don't think dynamic arrays/strings belong as built-in types
> hard-wired into the language, especially with a confusing syntax like
> this. They should be treated as other containers are.
>
> In what I think is a sane system, dynamic arrays would be a library
> `Vec` type just like we have `HashMap` and will have other
> vector types like `Rope` or `SmallVec`.


Agreed with this 100%. From a mental model perspective, you can't have ~foo
mean "foo is boxed" everywhere in the language and then go "Oh but ~str and
~[T]? Yeah those are exceptions. You're mental model is wrong".

*Everyone* is going to build this incorrect mental model of "putting ~ in
front of a thing puts that thing in a box" and it's not the user's fault,
it's Rust's fault for having this silly distinction.

~ in front of a type should mean one thing and one thing only. Otherwise
we're just making life difficult for the users for no sensible reason. I
read through all the Rust docs several times over the last few months, I
have years of experience with C++ and thought I had a rock-solid
understanding of ~T (it's just a unique_ptr) and just a few days ago I
learned that ~str and ~[T] are special. And I only learned about this by
randomly browsing through rust-dev.

I felt cheated a bit TBH. It's such an obvious design mistake IMO;
everyone's going to get this wrong because it's counter-intuitive. It's
like mutable default arguments in Python 2.x (which was thankfully fixed in
3.0). [I'm not trying to bash a different language, I know that's against
the rules of the list. I'm just trying to draw a parallel with a different
language design mistake that tripped up everyone as well.]
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Removing some autoref magic

[Ziad Hatahet]

> Personally I would prefer if & in Rust worked similar to const T& in c++

In that case, you would not be able to tell whether a function argument was
passed by value or by reference. I actually like this feature about Rust
(C# has it too with the `ref` keyword).

--
Ziad


On Tue, Nov 19, 2013 at 4:54 PM, Vadim  wrote:

> So why did Rust adopt auto-moving instead of explicit moving?   If the
> second example had to be written as foo(move a) there would be no
> confusion.   The and the third example should arguably be sort(mut
> a.as_mut_slice()).
>
> Personally I would prefer if & in Rust worked similar to const T& in c++
> (i.e. for most intents and purposes you can treat a reference as a value),
> otherwise half of the arguments on each function call will have to be
> adorned with ampersands.
>
> Can we have it such that foo(a) would be guaranteed to not mutate or move
> a and require "mut" or "move" prefix otherwise?
>
>
> ___
> 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] Removing some autoref magic

[Vadim]

So why did Rust adopt auto-moving instead of explicit moving?   If the
second example had to be written as foo(move a) there would be no
confusion.   The and the third example should arguably be sort(mut
a.as_mut_slice()).

Personally I would prefer if & in Rust worked similar to const T& in c++
(i.e. for most intents and purposes you can treat a reference as a value),
otherwise half of the arguments on each function call will have to be
adorned with ampersands.

Can we have it such that foo(a) would be guaranteed to not mutate or move a
and require "mut" or "move" prefix otherwise?
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Please simplify the syntax for Great Justice

[Liigo Zhuang]

在 2013年11月19日 下午8:44，"Daniel Micay" 写道：
>
> On Tue, Nov 19, 2013 at 7:35 AM, spir  wrote:
> >
> > If this is all true, that recursive structures are the main, "almost the
> > only use case" of ~ pointers, then the tutorial is in my view rather ok
on
> > this point. But then, why does it seem there are ~ pointers in every
corner
> > of Rust code? Including numerous cases in the tutorial itself.
> >
> > Also, how would we explain and term this meaning? "Indirection" is not
good
> > enough (for we introduce indirections for other reasons, if only to have
> > variable-size content). I'd say "self-similarity" is the right term
here,
> > and self-explaining (see wikipedia if you are not familiar with the
idea).
> > This is, in fact, the actual idea commonly termed "recursivity" in
> > programming (wrongly, in my view, but this is yet another terminological
> > issue). A rule about ~ pointers thus may be:
> >
> >Whenever one needs self-similarity, use a ~ pointer.
> >This lets the language store the element through the kind
> >of indirection that permits a self-similar structure.
> >
> > (I'm not happy of this formulation, neither, still obscure.)
> >
> > however, other comments on ~ pointers (eg comparisons with C++
unique_ptr,
> > notes that it means owned or "my") introduce ideas rather different
from the
> > one you suggest here, don't they? Say I manually create a kind of
string or
> > "fix-size" array:
> >
> > struct String {
> > n_bytes : uint,
> > bytes   : ~[u8],
> > }
> >
> > struct Array  {
> > n_items : uint,
> > items   : ~[Item],
> > }
>
> The expression ~([1, 2, 3]) has a different type than the expression
> ~[1, 2, 3]. The former is an owned box containing a fixed size array
> (~[int, ..3]) and the latter is a dynamic array (~[int]).
>
> The ~str and ~[T] types are *not* owned boxes in the current type
> system. There has been a proposal for dynamically sized types which
> would make them owned boxes, but I only like it as the path forwards
> for traits/closures and not vectors.
>

Are you telling us "~T is not ~T", just as "sun is not sun" and "moon is
not moon"?? If they do not have the same semantic, why use the same syntax?

> I don't think dynamic arrays/strings belong as built-in types
> hard-wired into the language, especially with a confusing syntax like
> this. They should be treated as other containers are.
>
> In what I think is a sane system, dynamic arrays would be a library
> `Vec` type just like we have `HashMap` and will have other
> vector types like `Rope` or `SmallVec`.
>
> > Is it wrong here to ~ point to bytes or items? that's what I'd do,
anyway...
> > If it is right, maybe the actual meaning of ~ is something like "proper
> > content". Whenever a structure actually contains content which is
actually
> > proper to it, or more generally has (pointed) data participating to its
> > description, then these contents or descriptive data should pointed
with ~:
> > because they belong / are proper to it.
> >
> > struct ComplexVisualForm {
> > shape : ~ Shape,
> > style : ~ Style,
> > }
>
> It doesn't make sense to use ~T over T without a reason to need a
> pointer-size value. It offers nothing in terms of semantics. It uses
> indirection to obtain pointer-size, and adds a destructor (a strict
> loss in terms of functionality). If you're not writing a recursive
> data structure or using dynamic dispatch via a trait object, you don't
> need it.
>
> > This matches my distinction between things and data (properly speaking).
> > Data, even when pointed (for technological rather than semantic
reasons),
> > still belong to whatever they are part of. Data are never referenced
> > (properly speaking), it makes no sense. Things instead exist by
themselves,
> > are always ref'ed, never copied (or moved), it makes no sense. If the
> > reasoning above about ~ pointers is more or less correct (i doubt it
is),
> > then we have in Rust the proper kind of pointer to point to data,
properly
> > speaking, meaning information about things. Now, to reference things
from
> > multiple points of view, we need something else, proper refs or links,
and
> > they cannot be ordinary pointers (especially not GC'ed): we need true
refs,
> > independant from the data (while pointers hold their addresses).
> >
> > Denis
> >
>
> ~T and T both have value semantics. Neither has by-reference
> semantics, as ~T is always the unique owner of the contained value.
> ___
> 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] Please simplify the syntax for Great Justice

[Liigo Zhuang]

在 2013年11月19日 下午8:41，"Gaetan" 写道：
>
> I think this is precisely one of the bigest issue, from a newbee point of
view. And I agree with spir on this point. It's not that important, but you
end up placing them everywhere "to make the compiler happy".
>
> ~str should be a ~T. If it is not, it should use another semantic.
>
+1

> However, I don't see where you explain this subtility in the tutorial,
didn't you added it recently?
>
> PS: I'm french, I know pretty well that all subtilities (other words for
"exception to the general rules") my natural language has their own reason,
BUT if I wanted to redesign french, I would get rid of all these rules,
exceptions, rules in the exceptions. And exceptions in the rules of
exceptions...
>
> -
> Gaetan
>
>
>
> 2013/11/19 Daniel Micay 
>>
>> On Tue, Nov 19, 2013 at 7:27 AM, Gaetan  wrote:
>> > "The most common use case for owned boxes is creating recursive data
>> > structures like a binary search tree."
>> >
>> > I don't think this is the most common use of owned boxes: string
management,
>> > ...
>> >
>> > I don't think it a good idea to place "binary search tree" in a
tutorial.
>> > You don't do this every day :)
>> >
>> > -
>> > Gaetan
>>
>> ~str isn't an ~T, in the existing type system
>
>
>
> ___
> 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] Removing some autoref magic

[Benjamin Striegel]

If autoref still happens on methods, does this mean that you'd be able to
get around the need to do:

sort(&mut *foo);

...by turning it into a method?

foo.sort();


On Tue, Nov 19, 2013 at 6:10 PM, Kevin Ballard  wrote:

> In general, I’m not a fan of &*, and I like auto-borrowing (autoref sounds
> like it turns T into &T, not ~T into &T). I understand the arguments to get
> rid of it though.
>
> BTW, you said that the current proposal still includes autoref for
> function invocation. That sounds to me like autoref would still apply to x
> in foo(x). Is there something else you mean by that?
>
> As I see it, the two interesting cases to consider for removing it are:
>
> 1. let x = ~Foo; foo(x); // looks like it moves x when it just borrows it
>
> 2. let mut a = ~[ … ]; sort(a); // mutates a
>
> To me, the second case seems pretty clear that it shouldn’t auto-borrow a
> ~T to a &mut T, and instead require sort(&mut *a). It’s pretty ugly, but it
> makes it clear what’s going on. This case isn’t particularly common, which
> is why losing autoref isn’t very tragic.
>
> The first case is the most common case, and it seems a shame to require
> &*x everywhere. I understand the argument that it looks like x is moved
> until you read the function signature of foo(), but I’m not convinced
> that’s important enough to uglify the code. Arguably, you already have to
> know what foo() does to understand what the code is doing.
>
> The basic argument, as I see it, is that the type signature of foo()
> shouldn’t change how the calling code treats its argument. If foo() changed
> from `fn foo(_: &T)` to `fn foo(_: ~T)` then `x` would start being moved
> instead of borrowed, which could cause errors in subsequent code in the
> caller.
>
> But the problem with this argument is that the type signature of foo()
> *already* changes how the calling code treats its argument, in a fashion
> that will surface errors in later code rather than at the call site.
> Notably, if the argument is not fully constrained to a specific type by the
> time foo(x) is called, it will further constrain the type that may not
> cause a problem until later. For example:
>
> fn foo(_: uint);
> fn bar(_: uint);
>
> let x = 1;
> foo(x);
> bar(x);
>
> This compiles just fine, but if foo() changes its argument to `int`, then
> the call to bar() will fail with a type error. More complex situations can
> be created using generic functions as well.
>
> In the case of autoref, the question is whether the value will be moved,
> rather than the type of the value, which is a slightly different issue but
> I’m not convinced it’s different enough that it needs to be specially
> addressed.
>
> The other problem with this is that, even with autoref removed, you can
> still hit the same problem of a seemingly-benign change elsewhere causing a
> compiler error in your code. Namely, if a struct has no destructor, and you
> rely on the ability to implicitly copy it (e.g. calling bar(x) where foo is
> fn bar(_: T)), then adding a destructor to the struct will cause your code
> to fail to compile, in just the same way that foo changing from `fn foo(_:
> &T)` to `fn foo(_: ~T)` will today.
>
> Overall, there just doesn’t seem to me to be a compelling reason to remove
> the ability to auto-borrow ~T into &T. Removing the ability to auto-borrow
> ~T into &mut T is more sensible though.
>
> FWIW, a lot of why I like auto-borrowing is actually due to auto-slicing
> of ~[T] into &[T] and ~str into &str. But I assume that when (if) DST
> happens, auto-slicing will just be a case of auto-borrowing. And until that
> happens I’d really like to avoiding having to say foo(v.as_slice()).
>
> -Kevin
>
> On Nov 19, 2013, at 2:08 PM, Alex Crichton  wrote:
>
> Hello rust-dev!
>
> Everyone's had their fair share of issues with autoref and autoderef,
> and it's worth considering removing certain portions of it from the
> compiler. The discussion around this has been rooted in the past, but
> has recently been brought up as part of
> https://github.com/mozilla/rust/issues/10504.
>
> The current proposal is to remove all autoref except for function
> invocations and indexing operations. The method of creating &T from ~T
> would be `let foo: &T = foo` or `&*foo`. Vectors and strings can't
> currently benefit from the `&*foo` syntax, but they will hopefully be
> able to do such once DST lands. In the meantime coercion via type
> ascription will work and they also have `as_slice` methods.
>
> There are a few reasons backing this proposal:
>
> 1. It's inconsistent to have magical autoref in some places, but not
> in other places.
> 2. The camp of "less compiler magic is better" can fly their flag over
> this change.
> 3. Code readability does not necessarily benefit from autoref on arguments:
>
>  let a = ~Foo;
>  foo(a); // reading this code looks like it moves `a`
>  fn foo(_: &Foo) {} // ah, nevermind, it doesn't move `a`!
>
>  let mut a = ~[ ... ];
>  sort(a); // not only does this n

Re: [rust-dev] Please simplify the syntax for Great Justice

[Liigo Zhuang]

在 2013年11月19日 下午8:35，"spir" 写道：
>
> On 11/19/2013 12:51 PM, Daniel Micay wrote:
>>
>> So in your opinion, what's wrong with the `Boxes` section?
>>
>> http://static.rust-lang.org/doc/master/tutorial.html#boxes
>>
>> I happen to think it does a pretty good job of explaining why `~` is
>> required for recursive types, which is almost the only use case for it
>> from a purely semantic perspective (not worrying about performance).
>
>
> If this is all true, that recursive structures are the main, "almost the
only use case" of ~ pointers, then the tutorial is in my view rather ok on
this point. But then, why does it seem there are ~ pointers in every corner
of Rust code? Including numerous cases in the tutorial itself.
>
+1

> Also, how would we explain and term this meaning? "Indirection" is not
good enough (for we introduce indirections for other reasons, if only to
have variable-size content). I'd say "self-similarity" is the right term
here, and self-explaining (see wikipedia if you are not familiar with the
idea). This is, in fact, the actual idea commonly termed "recursivity" in
programming (wrongly, in my view, but this is yet another terminological
issue). A rule about ~ pointers thus may be:
>
>Whenever one needs self-similarity, use a ~ pointer.
>This lets the language store the element through the kind
>of indirection that permits a self-similar structure.
>
> (I'm not happy of this formulation, neither, still obscure.)
>
> however, other comments on ~ pointers (eg comparisons with C++
unique_ptr, notes that it means owned or "my") introduce ideas rather
different from the one you suggest here, don't they? Say I manually create
a kind of string or "fix-size" array:
>
> struct String {
> n_bytes : uint,
> bytes   : ~[u8],
> }
>
> struct Array  {
> n_items : uint,
> items   : ~[Item],
> }
>
> Is it wrong here to ~ point to bytes or items? that's what I'd do,
anyway... If it is right, maybe the actual meaning of ~ is something like
"proper content". Whenever a structure actually contains content which is
actually proper to it, or more generally has (pointed) data participating
to its description, then these contents or descriptive data should pointed
with ~: because they belong / are proper to it.
>
> struct ComplexVisualForm {
> shape : ~ Shape,
> style : ~ Style,
> }
>
> This matches my distinction between things and data (properly speaking).
Data, even when pointed (for technological rather than semantic reasons),
still belong to whatever they are part of. Data are never referenced
(properly speaking), it makes no sense. Things instead exist by themselves,
are always ref'ed, never copied (or moved), it makes no sense. If the
reasoning above about ~ pointers is more or less correct (i doubt it is),
then we have in Rust the proper kind of pointer to point to data, properly
speaking, meaning information about things. Now, to reference things from
multiple points of view, we need something else, proper refs or links, and
they cannot be ordinary pointers (especially not GC'ed): we need true refs,
independant from the data (while pointers hold their addresses).
>
> Denis
>
>
> ___
> 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] Please simplify the syntax for Great Justice

[Liigo Zhuang]

+1
在 2013年11月19日 下午8:27，"Gaetan" 写道：

> "The most common use case for owned boxes is creating recursive data
> structures like a binary search tree."
>
> I don't think this is the most common use of owned boxes: string
> management, ...
>
> I don't think it a good idea to place "binary search tree" in a tutorial.
> You don't do this every day :)
>
> -
> Gaetan
>
>
>
> 2013/11/19 Gaetan 
>
>> In the french presentation for rust 0.8 [1], the author gives the analogy
>> with C++ semantics
>> - ~ is a bit like unique_ptr
>> - @ is an enhanced shared_ptr
>> - borrowed pointer works like C++ reference
>>
>> and I think it was very helpful to better understand them. I don't know
>> if it is true or now, but this comparison helps a lot understanding the
>> concepts.You can present them like this, and after, add more precision, and
>> difference with the C++ counter parts.
>>
>> A tutorial to make would be "Rust for C++ programmer" :)
>>
>>
>> [1] http://linuxfr.org/news/presentation-de-rust-0-8
>>
>> -
>> Gaetan
>>
>>
>>
>> 2013/11/19 Daniel Micay 
>>
>>> On Tue, Nov 19, 2013 at 4:25 AM, Gaetan  wrote:
>>> > I don't think there is any particular issue with the tutorial, but we
>>> need
>>> > more "recipes" on how to handle typical situations.
>>>
>>> I'm specifically talking about the `Boxes` section in the tutorial and
>>> not the whole picture. I keep hearing that the coverage of `~` it's
>>> confusing - so can someone elaborate?
>>>
>>> Rewriting the coverage of boxes and references by walking through the
>>> implementation of some data structures is something I'm willing to do,
>>> but in my opinion that section is now quite good, other than being dry
>>> and not presenting interesting code samples for the use cases it
>>> describes.
>>>
>>
>>
>
> ___
> 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] Removing some autoref magic

[Kevin Ballard]

In general, I’m not a fan of &*, and I like auto-borrowing (autoref sounds like 
it turns T into &T, not ~T into &T). I understand the arguments to get rid of 
it though.

BTW, you said that the current proposal still includes autoref for function 
invocation. That sounds to me like autoref would still apply to x in foo(x). Is 
there something else you mean by that?

As I see it, the two interesting cases to consider for removing it are:

1. let x = ~Foo; foo(x); // looks like it moves x when it just borrows it

2. let mut a = ~[ … ]; sort(a); // mutates a

To me, the second case seems pretty clear that it shouldn’t auto-borrow a ~T to 
a &mut T, and instead require sort(&mut *a). It’s pretty ugly, but it makes it 
clear what’s going on. This case isn’t particularly common, which is why losing 
autoref isn’t very tragic.

The first case is the most common case, and it seems a shame to require &*x 
everywhere. I understand the argument that it looks like x is moved until you 
read the function signature of foo(), but I’m not convinced that’s important 
enough to uglify the code. Arguably, you already have to know what foo() does 
to understand what the code is doing.

The basic argument, as I see it, is that the type signature of foo() shouldn’t 
change how the calling code treats its argument. If foo() changed from `fn 
foo(_: &T)` to `fn foo(_: ~T)` then `x` would start being moved instead of 
borrowed, which could cause errors in subsequent code in the caller.

But the problem with this argument is that the type signature of foo() already 
changes how the calling code treats its argument, in a fashion that will 
surface errors in later code rather than at the call site. Notably, if the 
argument is not fully constrained to a specific type by the time foo(x) is 
called, it will further constrain the type that may not cause a problem until 
later. For example:

fn foo(_: uint);
fn bar(_: uint);

let x = 1;
foo(x);
bar(x);

This compiles just fine, but if foo() changes its argument to `int`, then the 
call to bar() will fail with a type error. More complex situations can be 
created using generic functions as well.

In the case of autoref, the question is whether the value will be moved, rather 
than the type of the value, which is a slightly different issue but I’m not 
convinced it’s different enough that it needs to be specially addressed.

The other problem with this is that, even with autoref removed, you can still 
hit the same problem of a seemingly-benign change elsewhere causing a compiler 
error in your code. Namely, if a struct has no destructor, and you rely on the 
ability to implicitly copy it (e.g. calling bar(x) where foo is fn bar(_: T)), 
then adding a destructor to the struct will cause your code to fail to compile, 
in just the same way that foo changing from `fn foo(_: &T)` to `fn foo(_: ~T)` 
will today.

Overall, there just doesn’t seem to me to be a compelling reason to remove the 
ability to auto-borrow ~T into &T. Removing the ability to auto-borrow ~T into 
&mut T is more sensible though.

FWIW, a lot of why I like auto-borrowing is actually due to auto-slicing of 
~[T] into &[T] and ~str into &str. But I assume that when (if) DST happens, 
auto-slicing will just be a case of auto-borrowing. And until that happens I’d 
really like to avoiding having to say foo(v.as_slice()).

-Kevin

On Nov 19, 2013, at 2:08 PM, Alex Crichton  wrote:

> Hello rust-dev!
> 
> Everyone's had their fair share of issues with autoref and autoderef,
> and it's worth considering removing certain portions of it from the
> compiler. The discussion around this has been rooted in the past, but
> has recently been brought up as part of
> https://github.com/mozilla/rust/issues/10504.
> 
> The current proposal is to remove all autoref except for function
> invocations and indexing operations. The method of creating &T from ~T
> would be `let foo: &T = foo` or `&*foo`. Vectors and strings can't
> currently benefit from the `&*foo` syntax, but they will hopefully be
> able to do such once DST lands. In the meantime coercion via type
> ascription will work and they also have `as_slice` methods.
> 
> There are a few reasons backing this proposal:
> 
> 1. It's inconsistent to have magical autoref in some places, but not
> in other places.
> 2. The camp of "less compiler magic is better" can fly their flag over
> this change.
> 3. Code readability does not necessarily benefit from autoref on arguments:
> 
>  let a = ~Foo;
>  foo(a); // reading this code looks like it moves `a`
>  fn foo(_: &Foo) {} // ah, nevermind, it doesn't move `a`!
> 
>  let mut a = ~[ ... ];
>  sort(a); // not only does this not move `a`, but it mutates it!
> 
> The basic idea is that reasoning about code is no longer a local
> function decision, but rather you must understand all the pointer-ness
> of the called signatures to understand when a move happens or not.
> With no autoref, the code would look like
> 
>  let a = ~Foo;
>  foo(&*a); // c

Re: [rust-dev] Removing some autoref magic

[Alex Crichton]

Additionally, we discussed this today at our weekly meeting, and the
minutes can be found here:
https://github.com/mozilla/rust/wiki/Meeting-weekly-2013-11-19#autoderef
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

[rust-dev] Removing some autoref magic

[Alex Crichton]

Hello rust-dev!

Everyone's had their fair share of issues with autoref and autoderef,
and it's worth considering removing certain portions of it from the
compiler. The discussion around this has been rooted in the past, but
has recently been brought up as part of
https://github.com/mozilla/rust/issues/10504.

The current proposal is to remove all autoref except for function
invocations and indexing operations. The method of creating &T from ~T
would be `let foo: &T = foo` or `&*foo`. Vectors and strings can't
currently benefit from the `&*foo` syntax, but they will hopefully be
able to do such once DST lands. In the meantime coercion via type
ascription will work and they also have `as_slice` methods.

There are a few reasons backing this proposal:

1. It's inconsistent to have magical autoref in some places, but not
in other places.
2. The camp of "less compiler magic is better" can fly their flag over
this change.
3. Code readability does not necessarily benefit from autoref on arguments:

  let a = ~Foo;
  foo(a); // reading this code looks like it moves `a`
  fn foo(_: &Foo) {} // ah, nevermind, it doesn't move `a`!

  let mut a = ~[ ... ];
  sort(a); // not only does this not move `a`, but it mutates it!

The basic idea is that reasoning about code is no longer a local
function decision, but rather you must understand all the pointer-ness
of the called signatures to understand when a move happens or not.
With no autoref, the code would look like

  let a = ~Foo;
  foo(&*a); // clearly not passing by value

  let mut a = ~[ ... ];
  sort(a.as_mut_slice()); // clearly loaning a mutable reference


That being said, this proposal is not yet set in stone. I don't think
that there are many people that are fans of `&*foo` or `&mut *foo`;
both cases look fairly ugly. So far the general agreement is that
local small ugliness is the price we pay for local readability, and
the discussions have been unable to unearth a better system.

I'm curious if others have a better idea of how to go about doing
this, or if others just think it's a terrible idea in the first place.
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] autocomplete engine for rust

[Gokcehan Kara]

I will be speculating a little since I haven't actually read the source. As
far as I understand, YouCompleteMe uses python for some parts but at its
core it has a cpp component using libclang library. libclang library itself
is already something that provides code completion which is the thing
missing for rust language.

[libclang]: http://clang.llvm.org/doxygen/group__CINDEX.html


On Tue, Nov 19, 2013 at 10:13 PM, Gaetan  wrote:

> I think we can write in rust and perhaps reuse part of the compiler, but
> we cannot allow to support only fully compiler crates.
>
> It may be possible to begin a draft in language such as python
> (YouCompleteMe seems to be written mostly in python)
>
> -
> Gaetan
>
>
>
> 2013/11/19 Gokcehan Kara 
>
>> I'm willing to help on this task, I think having a good completion
>>> library can help a lot smoothing the learning curve of a new language. I
>>> learned python in a few days with aptana, and I remember a few years ago
>>> how it was easy to write C++ with visual studio. Having an IDE integration
>>> is almost as important as having good tutorials.
>>
>>
>> That's great. I agree that it would be nice for newbies and I think also
>> for others as most people are already quite spoiled by the capabilities of
>> modern IDE's these days.
>>
>> I'm also a newbe in Rust and I imagine you want to write in rust itself.
>>> I can help on the integration with sublime.
>>
>>
>> I was hoping to write in rust because I don't want to implement/maintain
>> a parser and typechecker from scratch. I was very pleased to see that it's
>> possible to access everything in `librustc` and `libsyntax` with a simple
>> `extern`, not sure if this will be removed later.
>>
>> rustfind (https://github.com/dobkeratops/rustfind) does this and more,
>>> for crates that compile.
>>
>>
>> I wasn't aware of that, looks very nice indeed. I will take a look and
>> see if I can contribute somehow when I have some time.
>>
>> Not very, for the general case. If you want autocompletion as you
>>> type, you currently need to have a fully-compilable crate. Otherwise,
>>> parsing or typechecking or something else will fail and you won't be
>>> able to get any results. rustc is currently very all-or-nothing.
>>
>>
>> It's a bummer. Are there any plans to implement some error recovery to
>> rustc?
>>
>> But, you can get useful information for completion out of an
>>> already-compiling crate, though I'm not sure how much better it would
>>> be than what etags already does.
>>
>>
>> It has been some time since I last tried tags for autocompletion but it
>> wasn't very accurate as far as I remember. As far as I know you also need
>> some editor plugin for this, something like [OmniCppComplete](
>> http://www.vim.org/scripts/script.php?script_id=1520) which is basically
>> a cpp parser implemented in vimscript.
>>
>> Very, since it would require reworking most of the compiler ;)
>>
>>
>> :)
>>
>
>
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] autocomplete engine for rust

[Gaetan]

I think we can write in rust and perhaps reuse part of the compiler, but we
cannot allow to support only fully compiler crates.

It may be possible to begin a draft in language such as python
(YouCompleteMe seems to be written mostly in python)

-
Gaetan



2013/11/19 Gokcehan Kara 

> I'm willing to help on this task, I think having a good completion library
>> can help a lot smoothing the learning curve of a new language. I learned
>> python in a few days with aptana, and I remember a few years ago how it was
>> easy to write C++ with visual studio. Having an IDE integration is almost
>> as important as having good tutorials.
>
>
> That's great. I agree that it would be nice for newbies and I think also
> for others as most people are already quite spoiled by the capabilities of
> modern IDE's these days.
>
> I'm also a newbe in Rust and I imagine you want to write in rust itself. I
>> can help on the integration with sublime.
>
>
> I was hoping to write in rust because I don't want to implement/maintain a
> parser and typechecker from scratch. I was very pleased to see that it's
> possible to access everything in `librustc` and `libsyntax` with a simple
> `extern`, not sure if this will be removed later.
>
> rustfind (https://github.com/dobkeratops/rustfind) does this and more,
>> for crates that compile.
>
>
> I wasn't aware of that, looks very nice indeed. I will take a look and see
> if I can contribute somehow when I have some time.
>
> Not very, for the general case. If you want autocompletion as you
>> type, you currently need to have a fully-compilable crate. Otherwise,
>> parsing or typechecking or something else will fail and you won't be
>> able to get any results. rustc is currently very all-or-nothing.
>
>
> It's a bummer. Are there any plans to implement some error recovery to
> rustc?
>
> But, you can get useful information for completion out of an
>> already-compiling crate, though I'm not sure how much better it would
>> be than what etags already does.
>
>
> It has been some time since I last tried tags for autocompletion but it
> wasn't very accurate as far as I remember. As far as I know you also need
> some editor plugin for this, something like [OmniCppComplete](
> http://www.vim.org/scripts/script.php?script_id=1520) which is basically
> a cpp parser implemented in vimscript.
>
> Very, since it would require reworking most of the compiler ;)
>
>
> :)
>
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] How to cast a @type in a @trait

[Patrick Walton]

On 11/19/13 11:48 AM, Philippe Delrieu wrote:

I still struggle with the json API. I try it using encode and decode API
and I face a problem.
I take this code in the json test case :
 let m = @mut MemWriter::new();
 f(m as @mut io::Writer);
and I have an error :
The managed box syntax will be replaced by a library type, and a garbage
collector is not yet implemented. Consider using the `std::rc::Rc` type
for reference counted pointers.


Add `#[feature(managed_boxes)];` to the top of your crate. The JSON and 
EBML APIs have not been kept well up to date with idioms used by the 
current version of Rust and will not work without this feature flag.


Patrick

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

Re: [rust-dev] autocomplete engine for rust

[Gokcehan Kara]

>
> I'm willing to help on this task, I think having a good completion library
> can help a lot smoothing the learning curve of a new language. I learned
> python in a few days with aptana, and I remember a few years ago how it was
> easy to write C++ with visual studio. Having an IDE integration is almost
> as important as having good tutorials.


That's great. I agree that it would be nice for newbies and I think also
for others as most people are already quite spoiled by the capabilities of
modern IDE's these days.

I'm also a newbe in Rust and I imagine you want to write in rust itself. I
> can help on the integration with sublime.


I was hoping to write in rust because I don't want to implement/maintain a
parser and typechecker from scratch. I was very pleased to see that it's
possible to access everything in `librustc` and `libsyntax` with a simple
`extern`, not sure if this will be removed later.

rustfind (https://github.com/dobkeratops/rustfind) does this and more,
> for crates that compile.


I wasn't aware of that, looks very nice indeed. I will take a look and see
if I can contribute somehow when I have some time.

Not very, for the general case. If you want autocompletion as you
> type, you currently need to have a fully-compilable crate. Otherwise,
> parsing or typechecking or something else will fail and you won't be
> able to get any results. rustc is currently very all-or-nothing.


It's a bummer. Are there any plans to implement some error recovery to
rustc?

But, you can get useful information for completion out of an
> already-compiling crate, though I'm not sure how much better it would
> be than what etags already does.


It has been some time since I last tried tags for autocompletion but it
wasn't very accurate as far as I remember. As far as I know you also need
some editor plugin for this, something like [OmniCppComplete](
http://www.vim.org/scripts/script.php?script_id=1520) which is basically a
cpp parser implemented in vimscript.

Very, since it would require reworking most of the compiler ;)


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

Re: [rust-dev] autocomplete engine for rust

[Gokcehan Kara]

>
> I'm willing to help on this task, I think having a good completion library
> can help a lot smoothing the learning curve of a new language. I learned
> python in a few days with aptana, and I remember a few years ago how it was
> easy to write C++ with visual studio. Having an IDE integration is almost
> as important as having good tutorials.


That's great. I agree that it would be nice for newbies and I think also
for others as most people are already quite spoiled by the capabilities of
modern IDE's these days.

I'm also a newbe in Rust and I imagine you want to write in rust itself. I
> can help on the integration with sublime.


I was hoping to write in rust because I don't want to implement/maintain a
parser and typechecker from scratch. I was very pleased to see that it's
possible to access everything in `librustc` and `libsyntax` with a simple
`extern`, not sure if this will be removed later.

rustfind (https://github.com/dobkeratops/rustfind) does this and more,
> for crates that compile.


I wasn't aware of that, looks very nice indeed. I will take a look and see
if I can contribute somehow when I have some time.

Not very, for the general case. If you want autocompletion as you
> type, you currently need to have a fully-compilable crate. Otherwise,
> parsing or typechecking or something else will fail and you won't be
> able to get any results. rustc is currently very all-or-nothing.


It's a bummer. Are there any plans to implement some error recovery to
rustc?

But, you can get useful information for completion out of an
> already-compiling crate, though I'm not sure how much better it would
> be than what etags already does.


It has been some time since I last tried tags for autocompletion but it
wasn't very accurate as far as I remember. As far as I know you also need
some editor plugin for this, something like [OmniCppComplete](
http://www.vim.org/scripts/script.php?script_id=1520) which is basically a
cpp parser implemented in vimscript.

Very, since it would require reworking most of the compiler ;)


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

[rust-dev] How to cast a @type in a @trait

[Philippe Delrieu]

I still struggle with the json API. I try it using encode and decode API 
and I face a problem.

I take this code in the json test case :
let m = @mut MemWriter::new();
f(m as @mut io::Writer);
and I have an error :
The managed box syntax will be replaced by a library type, and a garbage 
collector is not yet implemented. Consider using the `std::rc::Rc` type 
for reference counted pointers.


With this error I can't use extra::json::Encoder that expect a @mut 
io::Writer


I use the master updated on the 15/10

Any idea.

I didn't see if the json test case compile. Rust build but I don't know 
if the test are compiled by default.


Philippe


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

[rust-dev] Fwd: Rust docs

[Renato Lenzi]

Good documentation is crucial for the success of a language. Some friends
of mine simply ceased their efforts on a language due to lack of good docs
about it. There are examples: excellent languages, as Falcon, Gosu, Fantom,
probably do not have sufficient resources to produce what their value
would require ... while if you wanna learn Go you can find, web sites,
info and even books. I believe that Mozilla can find the right resources
for good docs about Rust.
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Please simplify the syntax for Great Justice

[Kevin Ballard]

On Nov 19, 2013, at 3:08 AM, Daniel Micay  wrote:

> I wouldn't mind not having `~T` in the language at all, but am not
> really opposed to including it because there's no harm. Choosing to
> special-case arbitrary non-trivial data structures like vectors and
> reference counted boxes *is* harmful because alternatives should *not*
> be second-class.

Alternatives aren’t second-class, they just aren’t special. Vectors in 
particular are used so ubiquitously that having special syntax is extremely 
convenient.

Anecdotally, Objective-C has moved in the opposite direction to the great 
happiness of all Obj-C developers. NSArray* and NSDictionary* are the 
ubiquitous vector/hashtable implementations that everybody uses, but they 
didn’t have any special language support. Recently, special language support 
was added so I can say @[@“yes”, @“no”, @“maybe”] instead of [NSArray 
arrayWithObjects:@“yes”, @“no”, @“maybe”, nil] (and similar syntax for 
dictionaries, as well as boxed NSNumbers) and it’s made programming in Obj-C 
significantly nicer. There’s nothing stopping you from using other data 
structures, but the special syntax for these particular ubiquitous ones just 
makes everyone’s life easier.

So back to Rust. &[] and its variants are extremely commonly used. Removing the 
special syntax for this will do nothing but make it more annoying to use them. 
It doesn’t do anything to make alternative data structures any easier to use. 
The one suggestion I’d make is maybe provide hooks for the &[] syntax to be 
used for a different vector implementation on a per-crate basis, although this 
would mean that &[] would actually be something like std::vector and &[] is 
just syntactic sugar. Which is generally fine, although it’s awfully nice to 
have &[T] be the actual type name in type signatures, having to use 
std::vector in type signatures and then using [a, b, c] to construct the 
value in code just feels a bit less nice than what we have in Rust today (but 
certainly better than no syntactic sugar at all).

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

Re: [rust-dev] Rethinking Linking in Rust

[Brian Anderson]

On 11/18/2013 08:01 PM, Zack Corr wrote:
On Tue, Nov 19, 2013 at 11:13 AM, Brian Anderson 
mailto:bander...@mozilla.com>> wrote:


Of course this conflicts with the `link` attribute of crates,
which I think is poorly named anyway.


Perhaps #[link] in its current usage should be renamed to #[crate]? I 
think that would make more sense.


This would be my preference.
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Rethinking Linking in Rust

[Brian Anderson]

On 11/18/2013 06:22 PM, Alex Crichton wrote:

* #[link(...)] becomes the new method of specifying linkage semantics on extern
   blocks, and it may be used similarly to link_args today

I'd kind of like for this to be available at the crate level too since most 
libraries don't use OS X two-level namespaces and it's more convient to me to 
just put all the linkage at the top of the crate. Of course this conflicts with 
the `link` attribute of crates, which I think is poorly named anyway.

What purpose did you have in mind for the #[link] attribute at the top of the 
crate? Is the crate saying how it should be linked to other crates?


It would be the same purpose as putting them on extern blocks - to tell 
the linker what other libraries to link to. It would function exactly 
the same. The only reason link attributes ever *need* to be specifically 
on an extern block is to support OS X two-level namespaces (which I 
don't know anything about and haven't actually seen).





I don't really understand what 'once' implies in `link(once)` and how it 
relates to statics. If a static library *must* be linked, then dynamic 
libraries may not be linked? Why is that? If 'once' implies 'static', can we 
just say 'link(static)'? I assume some argument propagation is going to come 
into play here ...

Will also need to accomodate some other common features like, e.g. `link(framework = 
"foo")` or something for OS X frameworks.

What this ended up turning out as is #[link(name = “foo”, kind = “static”)]. I 
think that a “framework” kind would fit quite well for this use case.


.rlib files also need the crate metadata.

I agree


What happens when two upstream crates link to the same native static library? 
In the final link step they are both going to be linked in, and I presume 
there's some kind of conflict?

Right now they’re both linked in. I didn’t envision this as a use case for 
rustc to complain about, but it would be simple enough to iterate over all 
upstream crates and see if the same static library were linked twice. My 
implementation requires metadata about the linkage regardless.


How does one opt into linking to dynamic libraries? Without some further 
mechanism everybody will be linking to the static libstd.

I’ve reserved another -Z flag for ‘-Z prefer-dynamic'


I took this to mean that we would just be packaging up the static libraries to 
save them for the final link step (since the rlib is just a .o file, not 
pre-linked to it's static lib dependencies). The effect of this though may be 
that all downstream crates implicitly have access to all the static library's 
symbols.

This actually what currently happens. The resulting rlib file already contains 
all of the static native libraries bundled inside of it. This is achieved via 
ld’s -r option. It is true that all of the symbols leak through, however, and 
this is unfortunate. I’d like to explore methods of preventing this, but I only 
know of one way currently. We’d create a list of all symbols in the rust 
library (an actual file on the filesystem), and then pass that to the linker 
saying “here are all the exported symbols, discard everything else.”




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

Re: [rust-dev] Rust docs

[Laxmi Narayan NIT DGP]

I am a student and thinking to write tutorial for it .





*  Laxmi Narayan Patel*

*   MCA NIT Durgapur ( Final year)*

*  Mob:-8345847473*


On Tue, Nov 19, 2013 at 10:33 AM, Thad Guidry  wrote:

>
>> I tend to agree with this, think that a collaborative approach is
>> unlikely to produce a consistent and high quality tutorial. I don't want to
>> discourage anybody but my current opinion is that we should hire an
>> experienced technical writer to do this piece especially, with input from
>> the wider community. Where I think collaboration is more likely to produce
>> something nice is in a 'cookbook' style document, of which several people
>> have already worked on seperately. Also of course API docs and the
>> reference manual are places where individuals can plug in their own
>> sections without impacting the overall narrative flow.
>>
>>
> So I spent this evening going through the tutorial (.08).  As an outsider
> to Rust, I can tell you it does not fit any model of a tutorial, but
> instead is an elongated language reference broken down into feature
> sections.  Which is highly useful in its design, and does say "This
> tutorial assumes that the reader is already familiar with one or more
> languages in the C family. Understanding of pointers and general memory
> management techniques will help."  BUT...
>
> It was not until section 17, that I finally met with a simple program that
> could compile.  That was 2 1/2 hours later before I was able to DO
> SOMETHING.
>
> I would encourage the Mozilla team to hire a technical writer as Brian
> suggests, that would turn the tutorial upside down...
>
> Start with something fun and entertaining in under 10 or 20 lines of Rust,
> that would amuse and provide "hackability" to tweak and play with values,
> mutability, and seeing the stack pop itself (half the developers in the
> world, do not know or have to worry about "a stack"..but of course "should"
> in any decent systems language :-) ), and then introduce garbage
> collecting, etc.   Introduce compile-able examples from the start, and
> continue with working examples that actually produce errors and let the
> user come to grips with the syntax & compiler error output, while coaching
> them through fixing the errors, and learning the do's and don'ts of Rust's
> current best practices.  That would be a mighty fine tutorial and the
> makings of a book for Rust itself.
>
> 2 cents and a haircut and I wish the team tremendous success on finding a
> talented writer,
>
> --
> -Thad
> +ThadGuidry 
> 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] list of all reserved keywords of the language

[Patrick Walton]

On 11/19/13 3:09 AM, Daniel Micay wrote:

The `loop` keyword still exists for the moment, but only for infinite
loops. I'd prefer removing it and just using `while true { ... }`.


The liveness analysis uses the infinite nature of `loop`, and it was 
felt that special-casing the `true` boolean like Java does is a hack.


Patrick

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

Re: [rust-dev] Rust docs

[Philippe Delrieu]

I'am ok to add sample code in json.rs.
how can I do?
I think I will have other sample code for other lib in a few days. I'll 
wait that the lib is open to doc enhancement or I put it as it come and 
how can it be managed.


Philippe

Le 19/11/2013 14:48, Gaetan a écrit :
Also, what we set up in our scrum team is "targetted" doc stories 
inside each sprint.


Let's say that over the next month, the objective is to improve a set 
of module doc, ie, a list of very useful std or extra lib that is not 
properly documented.
For instance, the next month we target on improving json or 
extra::path, and enhance them until they become golden star level. And 
the next month or sprint, we focus on other modules


It's easier to focus people like this that just telling "you can take 
whichever module you want and improve them". It just work better, we 
discovered.


-
Gaetan



2013/11/19 Gaetan mailto:gae...@xeberon.net>>

I think it's better to enhance the extra::json lib itself and
write proper module documentation, with samples, use case etc.
My reference is the QT documentation. You never open and samples
or even the QT source code, everything is in the module documentation.

-
Gaetan



2013/11/19 Philippe Delrieu mailto:philippe.delr...@free.fr>>

Hello,

I would like to share my experience about the Rust doc and the
tutorial. I've just started to learn Rust and I've decided to
use it on a project I work on. Like everybody I read the Rust
tutorial. It's not a really a tutorial for beginner but it do
a good job in presenting Rust and its mains concept. I found
other tutorial on the web and in my opinion what is missing
the more is sample code. The Rust lib is huge and there is no
code. In my project I have to use Json serialization. So I
wanted to use the json lib in extra lib and I really spend
some time to make a simple code works. I was very near to
write my own lib. json.rs  is a little
complicated for a newbie. There are some test case at the end
but it tests the lib and not what I want to do with it. For
example there is no serialization of an object. I search the
web and I found some old example (not compatible with the
master lib) and no object serialization.

So what I think is that it would be great is to construct a
repository of sample code of the Rust lib that show how to use
the lib. I'm ok to write and maintain some sample like one on
json. I think it would be great to host all these sample in
the same repository and to have the same organization for all
sample. The second reason tu use a share repository is that
the sample has to be made in the spirit of Rust to help
understand it. For that the sample must be checked and
modified by more experienced rust developer. It's easier when
the code is in a common repository.

Pḧilippe

___
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] Rust docs

[Gaetan]

I am willing to help also but i find it quite hard to setup the
environnement properly. Is these a tutorial for this point?
Le 19 nov. 2013 14:58, "Philippe Delrieu"  a
écrit :

>  I'am ok to add sample code in json.rs.
> how can I do?
> I think I will have other sample code for other lib in a few days. I'll
> wait that the lib is open to doc enhancement or I put it as it come and how
> can it be managed.
>
> Philippe
>
> Le 19/11/2013 14:48, Gaetan a écrit :
>
> Also, what we set up in our scrum team is "targetted" doc stories inside
> each sprint.
>
>  Let's say that over the next month, the objective is to improve a set of
> module doc, ie, a list of very useful std or extra lib that is not properly
> documented.
> For instance, the next month we target on improving json or extra::path,
> and enhance them until they become golden star level. And the next month or
> sprint, we focus on other modules
>
>  It's easier to focus people like this that just telling "you can take
> whichever module you want and improve them". It just work better, we
> discovered.
>
> -
> Gaetan
>
>
>
> 2013/11/19 Gaetan 
>
>> I think it's better to enhance the extra::json lib itself and write
>> proper module documentation, with samples, use case etc.
>> My reference is the QT documentation. You never open and samples or even
>> the QT source code, everything is in the module documentation.
>>
>> -
>> Gaetan
>>
>>
>>
>> 2013/11/19 Philippe Delrieu 
>>
>>> Hello,
>>>
>>> I would like to share my experience about the Rust doc and the tutorial.
>>> I've just started to learn Rust and I've decided to use it on a project I
>>> work on. Like everybody I read the Rust tutorial. It's not a really a
>>> tutorial for beginner but it do a good job in presenting Rust and its mains
>>> concept. I found other tutorial on the web and in my opinion what is
>>> missing the more is sample code. The Rust lib is huge and there is no code.
>>> In my project I have to use Json serialization. So I wanted to use the json
>>> lib in extra lib and I really spend some time to make a simple code works.
>>> I was very near to write my own lib. json.rs is a little complicated
>>> for a newbie. There are some test case at the end but it tests the lib and
>>> not what I want to do with it. For example there is no serialization of an
>>> object. I search the web and I found some old example (not compatible with
>>> the master lib) and no object serialization.
>>>
>>> So what I think is that it would be great is to construct a repository
>>> of sample code of the Rust lib that show how to use the lib. I'm ok to
>>> write and maintain some sample like one on json. I think it would be great
>>> to host all these sample in the same repository and to have the same
>>> organization for all sample. The second reason tu use a share repository is
>>> that the sample has to be made in the spirit of Rust to help understand it.
>>> For that the sample must be checked and modified by more experienced rust
>>> developer. It's easier when the code is in a common repository.
>>>
>>> Pḧilippe
>>>
>>> ___
>>> 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] Rust docs

[Gaetan]

Also, what we set up in our scrum team is "targetted" doc stories inside
each sprint.

Let's say that over the next month, the objective is to improve a set of
module doc, ie, a list of very useful std or extra lib that is not properly
documented.
For instance, the next month we target on improving json or extra::path,
and enhance them until they become golden star level. And the next month or
sprint, we focus on other modules

It's easier to focus people like this that just telling "you can take
whichever module you want and improve them". It just work better, we
discovered.

-
Gaetan



2013/11/19 Gaetan 

> I think it's better to enhance the extra::json lib itself and write proper
> module documentation, with samples, use case etc.
> My reference is the QT documentation. You never open and samples or even
> the QT source code, everything is in the module documentation.
>
> -
> Gaetan
>
>
>
> 2013/11/19 Philippe Delrieu 
>
>> Hello,
>>
>> I would like to share my experience about the Rust doc and the tutorial.
>> I've just started to learn Rust and I've decided to use it on a project I
>> work on. Like everybody I read the Rust tutorial. It's not a really a
>> tutorial for beginner but it do a good job in presenting Rust and its mains
>> concept. I found other tutorial on the web and in my opinion what is
>> missing the more is sample code. The Rust lib is huge and there is no code.
>> In my project I have to use Json serialization. So I wanted to use the json
>> lib in extra lib and I really spend some time to make a simple code works.
>> I was very near to write my own lib. json.rs is a little complicated for
>> a newbie. There are some test case at the end but it tests the lib and not
>> what I want to do with it. For example there is no serialization of an
>> object. I search the web and I found some old example (not compatible with
>> the master lib) and no object serialization.
>>
>> So what I think is that it would be great is to construct a repository of
>> sample code of the Rust lib that show how to use the lib. I'm ok to write
>> and maintain some sample like one on json. I think it would be great to
>> host all these sample in the same repository and to have the same
>> organization for all sample. The second reason tu use a share repository is
>> that the sample has to be made in the spirit of Rust to help understand it.
>> For that the sample must be checked and modified by more experienced rust
>> developer. It's easier when the code is in a common repository.
>>
>> Pḧilippe
>>
>> ___
>> 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] Rust docs

[Gaetan]

I think it's better to enhance the extra::json lib itself and write proper
module documentation, with samples, use case etc.
My reference is the QT documentation. You never open and samples or even
the QT source code, everything is in the module documentation.

-
Gaetan



2013/11/19 Philippe Delrieu 

> Hello,
>
> I would like to share my experience about the Rust doc and the tutorial.
> I've just started to learn Rust and I've decided to use it on a project I
> work on. Like everybody I read the Rust tutorial. It's not a really a
> tutorial for beginner but it do a good job in presenting Rust and its mains
> concept. I found other tutorial on the web and in my opinion what is
> missing the more is sample code. The Rust lib is huge and there is no code.
> In my project I have to use Json serialization. So I wanted to use the json
> lib in extra lib and I really spend some time to make a simple code works.
> I was very near to write my own lib. json.rs is a little complicated for
> a newbie. There are some test case at the end but it tests the lib and not
> what I want to do with it. For example there is no serialization of an
> object. I search the web and I found some old example (not compatible with
> the master lib) and no object serialization.
>
> So what I think is that it would be great is to construct a repository of
> sample code of the Rust lib that show how to use the lib. I'm ok to write
> and maintain some sample like one on json. I think it would be great to
> host all these sample in the same repository and to have the same
> organization for all sample. The second reason tu use a share repository is
> that the sample has to be made in the spirit of Rust to help understand it.
> For that the sample must be checked and modified by more experienced rust
> developer. It's easier when the code is in a common repository.
>
> Pḧilippe
>
> ___
> 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] Rust docs

[Philippe Delrieu]

Hello,

I would like to share my experience about the Rust doc and the tutorial. 
I've just started to learn Rust and I've decided to use it on a project 
I work on. Like everybody I read the Rust tutorial. It's not a really a 
tutorial for beginner but it do a good job in presenting Rust and its 
mains concept. I found other tutorial on the web and in my opinion what 
is missing the more is sample code. The Rust lib is huge and there is no 
code. In my project I have to use Json serialization. So I wanted to use 
the json lib in extra lib and I really spend some time to make a simple 
code works. I was very near to write my own lib. json.rs is a little 
complicated for a newbie. There are some test case at the end but it 
tests the lib and not what I want to do with it. For example there is no 
serialization of an object. I search the web and I found some old 
example (not compatible with the master lib) and no object serialization.


So what I think is that it would be great is to construct a repository 
of sample code of the Rust lib that show how to use the lib. I'm ok to 
write and maintain some sample like one on json. I think it would be 
great to host all these sample in the same repository and to have the 
same organization for all sample. The second reason tu use a share 
repository is that the sample has to be made in the spirit of Rust to 
help understand it. For that the sample must be checked and modified by 
more experienced rust developer. It's easier when the code is in a 
common repository.


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

Re: [rust-dev] Please simplify the syntax for Great Justice

[Gaetan]

However, I want to highlight it is really appreciable that you, the rust
team, are so open to our question.

Just wanted to give you this feedback, I don't want to be held like the guy
who criticize the current work, I know very much that is could be very
annoying.

Just willing to help :)

-
Gaetan



2013/11/19 Gaetan 

> I think this is precisely one of the bigest issue, from a newbee point of
> view. And I agree with spir on this point. It's not that important, but you
> end up placing them everywhere "to make the compiler happy".
>
> ~str should be a ~T. If it is not, it should use another semantic.
>
> However, I don't see where you explain this subtility in the tutorial,
> didn't you added it recently?
>
> PS: I'm french, I know pretty well that all subtilities (other words for
> "exception to the general rules") my natural language has their own reason,
> BUT if I wanted to redesign french, I would get rid of all these rules,
> exceptions, rules in the exceptions. And exceptions in the rules of
> exceptions...
>
> -
> Gaetan
>
>
>
> 2013/11/19 Daniel Micay 
>
>> On Tue, Nov 19, 2013 at 7:27 AM, Gaetan  wrote:
>> > "The most common use case for owned boxes is creating recursive data
>> > structures like a binary search tree."
>> >
>> > I don't think this is the most common use of owned boxes: string
>> management,
>> > ...
>> >
>> > I don't think it a good idea to place "binary search tree" in a
>> tutorial.
>> > You don't do this every day :)
>> >
>> > -
>> > Gaetan
>>
>> ~str isn't an ~T, in the existing type system
>>
>
>
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Please simplify the syntax for Great Justice

[Gaetan]

Sorry, but it's not clear.

the only occurences of "~str" are in "Declaring and implementing traits"
section...
Maybe by adding more "string specific" examples would help...

And a special section one "why ~str is not a ~T" would be so useful!

-
Gaetan



2013/11/19 Daniel Micay 

> On Tue, Nov 19, 2013 at 7:52 AM, Gaetan  wrote:
> > I think it is one of the first thing to explain, actually...
> >
> > Playing with strings, using the method in std or extra requires to
> > understand it. I wanted to use (and improve) extra::url and others (like
> > std::path,...) and... I was simply lost with all of these ~str... and
> > nothing in the manual or tutorial.
> >
> > -
> > Gaetan
>
> It is covered, I rewrote the section on it recently:
>
> http://static.rust-lang.org/doc/master/tutorial.html#vectors-and-strings
>
> It doesn't go out of the way to explain that they're not owned boxes,
> but I don't think it should. It's a confusing language wart and should
> be fixed as far as I am concerned.
>
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Please simplify the syntax for Great Justice

[Daniel Micay]

On Tue, Nov 19, 2013 at 7:52 AM, Gaetan  wrote:
> I think it is one of the first thing to explain, actually...
>
> Playing with strings, using the method in std or extra requires to
> understand it. I wanted to use (and improve) extra::url and others (like
> std::path,...) and... I was simply lost with all of these ~str... and
> nothing in the manual or tutorial.
>
> -
> Gaetan

It is covered, I rewrote the section on it recently:

http://static.rust-lang.org/doc/master/tutorial.html#vectors-and-strings

It doesn't go out of the way to explain that they're not owned boxes,
but I don't think it should. It's a confusing language wart and should
be fixed as far as I am concerned.
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Please simplify the syntax for Great Justice

[Gaetan]

I think it is one of the first thing to explain, actually...

Playing with strings, using the method in std or extra requires to
understand it. I wanted to use (and improve) extra::url and others (like
std::path,...) and... I was simply lost with all of these ~str... and
nothing in the manual or tutorial.

-
Gaetan



2013/11/19 Daniel Micay 

> On Tue, Nov 19, 2013 at 7:40 AM, Gaetan  wrote:
> > I think this is precisely one of the bigest issue, from a newbee point of
> > view. And I agree with spir on this point. It's not that important, but
> you
> > end up placing them everywhere "to make the compiler happy".
> >
> > ~str should be a ~T. If it is not, it should use another semantic.
> >
> > However, I don't see where you explain this subtility in the tutorial,
> > didn't you added it recently?
> >
> > PS: I'm french, I know pretty well that all subtilities (other words for
> > "exception to the general rules") my natural language has their own
> reason,
> > BUT if I wanted to redesign french, I would get rid of all these rules,
> > exceptions, rules in the exceptions. And exceptions in the rules of
> > exceptions...
> >
> > -
> > Gaetan
>
> I don't want to have `~str` and `~[T]` in the language, so I'm not
> really motivated to spend time trying to paper over the confusion
> caused by them. I doubt most users of Rust realize that ~([1, 2, 3])
> and ~[1, 2, 3] have different types, and dynamically sized types are
> not going to fix this.
>
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] list of all reserved keywords of the language

[Daniel Micay]

On Tue, Nov 19, 2013 at 7:49 AM, Gaetan  wrote:
> Sorry, I rephrase: "Let "do" spawn high level functions like "each" or
> "spawn" and not confuse it with "loop" or "while".
>
> -
> Gaetan

Ah, my fault for taking that out of context. I should have read the
parent email :).
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] list of all reserved keywords of the language

[Gaetan]

Sorry, I rephrase: "Let "do" spawn high level functions like "each" or
"spawn" and not confuse it with "loop" or "while".

-
Gaetan



2013/11/19 Daniel Micay 

> On Tue, Nov 19, 2013 at 6:42 AM, Gaetan  wrote:
> > I d prefere letting do launch tasks and don t add confusion.
>
> Tasks are part of the standard library, and don't have any presence at
> a language level.
>
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Please simplify the syntax for Great Justice

[Daniel Micay]

On Tue, Nov 19, 2013 at 7:40 AM, Gaetan  wrote:
> I think this is precisely one of the bigest issue, from a newbee point of
> view. And I agree with spir on this point. It's not that important, but you
> end up placing them everywhere "to make the compiler happy".
>
> ~str should be a ~T. If it is not, it should use another semantic.
>
> However, I don't see where you explain this subtility in the tutorial,
> didn't you added it recently?
>
> PS: I'm french, I know pretty well that all subtilities (other words for
> "exception to the general rules") my natural language has their own reason,
> BUT if I wanted to redesign french, I would get rid of all these rules,
> exceptions, rules in the exceptions. And exceptions in the rules of
> exceptions...
>
> -
> Gaetan

I don't want to have `~str` and `~[T]` in the language, so I'm not
really motivated to spend time trying to paper over the confusion
caused by them. I doubt most users of Rust realize that ~([1, 2, 3])
and ~[1, 2, 3] have different types, and dynamically sized types are
not going to fix this.
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Please simplify the syntax for Great Justice

[Daniel Micay]

On Tue, Nov 19, 2013 at 7:35 AM, spir  wrote:
>
> If this is all true, that recursive structures are the main, "almost the
> only use case" of ~ pointers, then the tutorial is in my view rather ok on
> this point. But then, why does it seem there are ~ pointers in every corner
> of Rust code? Including numerous cases in the tutorial itself.
>
> Also, how would we explain and term this meaning? "Indirection" is not good
> enough (for we introduce indirections for other reasons, if only to have
> variable-size content). I'd say "self-similarity" is the right term here,
> and self-explaining (see wikipedia if you are not familiar with the idea).
> This is, in fact, the actual idea commonly termed "recursivity" in
> programming (wrongly, in my view, but this is yet another terminological
> issue). A rule about ~ pointers thus may be:
>
>Whenever one needs self-similarity, use a ~ pointer.
>This lets the language store the element through the kind
>of indirection that permits a self-similar structure.
>
> (I'm not happy of this formulation, neither, still obscure.)
>
> however, other comments on ~ pointers (eg comparisons with C++ unique_ptr,
> notes that it means owned or "my") introduce ideas rather different from the
> one you suggest here, don't they? Say I manually create a kind of string or
> "fix-size" array:
>
> struct String {
> n_bytes : uint,
> bytes   : ~[u8],
> }
>
> struct Array  {
> n_items : uint,
> items   : ~[Item],
> }

The expression ~([1, 2, 3]) has a different type than the expression
~[1, 2, 3]. The former is an owned box containing a fixed size array
(~[int, ..3]) and the latter is a dynamic array (~[int]).

The ~str and ~[T] types are *not* owned boxes in the current type
system. There has been a proposal for dynamically sized types which
would make them owned boxes, but I only like it as the path forwards
for traits/closures and not vectors.

I don't think dynamic arrays/strings belong as built-in types
hard-wired into the language, especially with a confusing syntax like
this. They should be treated as other containers are.

In what I think is a sane system, dynamic arrays would be a library
`Vec` type just like we have `HashMap` and will have other
vector types like `Rope` or `SmallVec`.

> Is it wrong here to ~ point to bytes or items? that's what I'd do, anyway...
> If it is right, maybe the actual meaning of ~ is something like "proper
> content". Whenever a structure actually contains content which is actually
> proper to it, or more generally has (pointed) data participating to its
> description, then these contents or descriptive data should pointed with ~:
> because they belong / are proper to it.
>
> struct ComplexVisualForm {
> shape : ~ Shape,
> style : ~ Style,
> }

It doesn't make sense to use ~T over T without a reason to need a
pointer-size value. It offers nothing in terms of semantics. It uses
indirection to obtain pointer-size, and adds a destructor (a strict
loss in terms of functionality). If you're not writing a recursive
data structure or using dynamic dispatch via a trait object, you don't
need it.

> This matches my distinction between things and data (properly speaking).
> Data, even when pointed (for technological rather than semantic reasons),
> still belong to whatever they are part of. Data are never referenced
> (properly speaking), it makes no sense. Things instead exist by themselves,
> are always ref'ed, never copied (or moved), it makes no sense. If the
> reasoning above about ~ pointers is more or less correct (i doubt it is),
> then we have in Rust the proper kind of pointer to point to data, properly
> speaking, meaning information about things. Now, to reference things from
> multiple points of view, we need something else, proper refs or links, and
> they cannot be ordinary pointers (especially not GC'ed): we need true refs,
> independant from the data (while pointers hold their addresses).
>
> Denis
>

~T and T both have value semantics. Neither has by-reference
semantics, as ~T is always the unique owner of the contained value.
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Please simplify the syntax for Great Justice

[Gaetan]

I think this is precisely one of the bigest issue, from a newbee point of
view. And I agree with spir on this point. It's not that important, but you
end up placing them everywhere "to make the compiler happy".

~str should be a ~T. If it is not, it should use another semantic.

However, I don't see where you explain this subtility in the tutorial,
didn't you added it recently?

PS: I'm french, I know pretty well that all subtilities (other words for
"exception to the general rules") my natural language has their own reason,
BUT if I wanted to redesign french, I would get rid of all these rules,
exceptions, rules in the exceptions. And exceptions in the rules of
exceptions...

-
Gaetan



2013/11/19 Daniel Micay 

> On Tue, Nov 19, 2013 at 7:27 AM, Gaetan  wrote:
> > "The most common use case for owned boxes is creating recursive data
> > structures like a binary search tree."
> >
> > I don't think this is the most common use of owned boxes: string
> management,
> > ...
> >
> > I don't think it a good idea to place "binary search tree" in a tutorial.
> > You don't do this every day :)
> >
> > -
> > Gaetan
>
> ~str isn't an ~T, in the existing type system
>
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Please simplify the syntax for Great Justice

[spir]

On 11/19/2013 12:51 PM, Daniel Micay wrote:

So in your opinion, what's wrong with the `Boxes` section?

http://static.rust-lang.org/doc/master/tutorial.html#boxes

I happen to think it does a pretty good job of explaining why `~` is
required for recursive types, which is almost the only use case for it
from a purely semantic perspective (not worrying about performance).


If this is all true, that recursive structures are the main, "almost the only 
use case" of ~ pointers, then the tutorial is in my view rather ok on this 
point. But then, why does it seem there are ~ pointers in every corner of Rust 
code? Including numerous cases in the tutorial itself.


Also, how would we explain and term this meaning? "Indirection" is not good 
enough (for we introduce indirections for other reasons, if only to have 
variable-size content). I'd say "self-similarity" is the right term here, and 
self-explaining (see wikipedia if you are not familiar with the idea). This is, 
in fact, the actual idea commonly termed "recursivity" in programming (wrongly, 
in my view, but this is yet another terminological issue). A rule about ~ 
pointers thus may be:


   Whenever one needs self-similarity, use a ~ pointer.
   This lets the language store the element through the kind
   of indirection that permits a self-similar structure.

(I'm not happy of this formulation, neither, still obscure.)

however, other comments on ~ pointers (eg comparisons with C++ unique_ptr, notes 
that it means owned or "my") introduce ideas rather different from the one you 
suggest here, don't they? Say I manually create a kind of string or "fix-size" 
array:


struct String {
n_bytes : uint,
bytes   : ~[u8],
}

struct Array  {
n_items : uint,
items   : ~[Item],
}

Is it wrong here to ~ point to bytes or items? that's what I'd do, anyway... If 
it is right, maybe the actual meaning of ~ is something like "proper content". 
Whenever a structure actually contains content which is actually proper to it, 
or more generally has (pointed) data participating to its description, then 
these contents or descriptive data should pointed with ~: because they belong / 
are proper to it.


struct ComplexVisualForm {
shape : ~ Shape,
style : ~ Style,
}

This matches my distinction between things and data (properly speaking). Data, 
even when pointed (for technological rather than semantic reasons), still belong 
to whatever they are part of. Data are never referenced (properly speaking), it 
makes no sense. Things instead exist by themselves, are always ref'ed, never 
copied (or moved), it makes no sense. If the reasoning above about ~ pointers is 
more or less correct (i doubt it is), then we have in Rust the proper kind of 
pointer to point to data, properly speaking, meaning information about things. 
Now, to reference things from multiple points of view, we need something else, 
proper refs or links, and they cannot be ordinary pointers (especially not 
GC'ed): we need true refs, independant from the data (while pointers hold their 
addresses).


Denis

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

Re: [rust-dev] Please simplify the syntax for Great Justice

[Daniel Micay]

On Tue, Nov 19, 2013 at 7:27 AM, Gaetan  wrote:
> "The most common use case for owned boxes is creating recursive data
> structures like a binary search tree."
>
> I don't think this is the most common use of owned boxes: string management,
> ...
>
> I don't think it a good idea to place "binary search tree" in a tutorial.
> You don't do this every day :)
>
> -
> Gaetan

~str isn't an ~T, in the existing type system
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Fwd: Please simplify the syntax for Great Justice

[Daniel Glazman]

On 19/11/13 02:36, Nathan Myers wrote:

> "Rust is a general purpose language designed to make programming
> more fun for the serious programmer."
>  - nobody, yet.

Honestly, I don't really care about fun. What my company needs is more
in line with:

« Rust is a powerful, clean, easy-to-learn and easy-to-read general
purpose language designed for “programming in the large” that could
replace c++ »



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

Re: [rust-dev] Please simplify the syntax for Great Justice

[Gaetan]

"The most common use case for owned boxes is creating recursive data
structures like a binary search tree."

I don't think this is the most common use of owned boxes: string
management, ...

I don't think it a good idea to place "binary search tree" in a tutorial.
You don't do this every day :)

-
Gaetan



2013/11/19 Gaetan 

> In the french presentation for rust 0.8 [1], the author gives the analogy
> with C++ semantics
> - ~ is a bit like unique_ptr
> - @ is an enhanced shared_ptr
> - borrowed pointer works like C++ reference
>
> and I think it was very helpful to better understand them. I don't know if
> it is true or now, but this comparison helps a lot understanding the
> concepts.You can present them like this, and after, add more precision, and
> difference with the C++ counter parts.
>
> A tutorial to make would be "Rust for C++ programmer" :)
>
>
> [1] http://linuxfr.org/news/presentation-de-rust-0-8
>
> -
> Gaetan
>
>
>
> 2013/11/19 Daniel Micay 
>
>> On Tue, Nov 19, 2013 at 4:25 AM, Gaetan  wrote:
>> > I don't think there is any particular issue with the tutorial, but we
>> need
>> > more "recipes" on how to handle typical situations.
>>
>> I'm specifically talking about the `Boxes` section in the tutorial and
>> not the whole picture. I keep hearing that the coverage of `~` it's
>> confusing - so can someone elaborate?
>>
>> Rewriting the coverage of boxes and references by walking through the
>> implementation of some data structures is something I'm willing to do,
>> but in my opinion that section is now quite good, other than being dry
>> and not presenting interesting code samples for the use cases it
>> describes.
>>
>
>
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Please simplify the syntax for Great Justice

[Daniel Glazman]

On 19/11/13 05:17, Patrick Walton wrote:

> I've observed a lot of beginning Rust programmers treat the language as
> "add sigils until it works". (I have specific examples but don't want to
> name people here; however, feel free to contact me privately if you're
> curious.) They end up with slow programs and frustrated with Rust,
> wondering why they had to fight the compiler if they seemingly didn't
> gain any performance from it.
> 
> I think a fair amount of it is that the sigils don't visually convey
> enough information to the programmer; they feel like something that you
> just have to add to make the compiler happy. A sigil in Rust's
> expression grammar as it stands represents an *action*, not a
> *qualifier* as it does in most other languages (e.g. `$foo` in PHP).
> Moreover, the `~` expression maps to one of the most expensive machine
> operations in the entire language semantics! It's thus important in my
> view to emphasize to newcomers that `~` *means* something; it is not
> just a qualifier you have to add to make the compiler happy. Indeed, if
> you are adding it just to make the compiler accept your code, there's
> something wrong--either the API you're using is inefficient or you're
> confused about the semantics!

I agree 1% with what was said above.


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

Re: [rust-dev] Please simplify the syntax for Great Justice

[Gaetan]

+1 semantics is so important

>
> Le 19 nov. 2013 12:22, "spir"  a écrit :
>
>> On 11/19/2013 10:12 AM, Jordi Boggiano wrote:
>>>
>>> Often there is an alternative
>>> to pooping sigils all over the code, but if you don't understand the
>>> concepts behind it it's hard to reason about what those alternatives
>>> could be.
>>
>>
>> +++
>>
>> This is what I'm asking for about pointer variety and memory management
in Rust. What does this all mean? Semantics, please ;-) (I mean human
semantics, no machine operations)
>>
>> Denis
>> ___
>> 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] list of all reserved keywords of the language

[Daniel Micay]

On Tue, Nov 19, 2013 at 6:42 AM, Gaetan  wrote:
> I d prefere letting do launch tasks and don t add confusion.

Tasks are part of the standard library, and don't have any presence at
a language level.
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Please simplify the syntax for Great Justice

[Daniel Micay]

On Tue, Nov 19, 2013 at 6:45 AM, spir  wrote:>
>
> This helped me too, even if I'm not a C++ programmer (can only read).
> However, it is still not enough to understand the meaning of each of those
> pointer varieties, imo (at least, _i_ still don't get it). What semantic
> kinds of pointed data should go to each variety? why? I would help at once
> improving the tutorial if I did understand.
>
> @Daniel: I would answer your questions if I did understand the *logic* of
> Rust's pointers and memory management. The tutorial, in my view, should
> precisely help on this. Instead, it tells us about machine-side issues
> without meaning (which are important and we need to know, but don't help in
> understanding). What is the semantic counter-part of all this? Why does it
> exist?
>
> The logic here is hidden or difficult. As a comparison, we don't need tons
> of explanations to understand the differences between a sequential
> collection (array, list) and, say, a set. The logic is nearly obvious, we
> easily get why both kinds exist. And in fact, the machine-side,
> implementation counterpart, while important, comes after, once we understand
> the meaning; then we get to know the price one has to pay for quick, direct
> access of given items, as opposed to access by index.
>
> Denis

So in your opinion, what's wrong with the `Boxes` section?

http://static.rust-lang.org/doc/master/tutorial.html#boxes

I happen to think it does a pretty good job of explaining why `~` is
required for recursive types, which is almost the only use case for it
from a purely semantic perspective (not worrying about performance).
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Please simplify the syntax for Great Justice

[spir]

On 11/19/2013 10:51 AM, Gaetan wrote:

In the french presentation for rust 0.8 [1], the author gives the analogy
with C++ semantics
- ~ is a bit like unique_ptr
- @ is an enhanced shared_ptr
- borrowed pointer works like C++ reference

and I think it was very helpful to better understand them. I don't know if
it is true or now, but this comparison helps a lot understanding the
concepts.You can present them like this, and after, add more precision, and
difference with the C++ counter parts.

A tutorial to make would be "Rust for C++ programmer" :)


[1] http://linuxfr.org/news/presentation-de-rust-0-8


This helped me too, even if I'm not a C++ programmer (can only read). However, 
it is still not enough to understand the meaning of each of those pointer 
varieties, imo (at least, _i_ still don't get it). What semantic kinds of 
pointed data should go to each variety? why? I would help at once improving the 
tutorial if I did understand.


@Daniel: I would answer your questions if I did understand the *logic* of Rust's 
pointers and memory management. The tutorial, in my view, should precisely help 
on this. Instead, it tells us about machine-side issues without meaning (which 
are important and we need to know, but don't help in understanding). What is the 
semantic counter-part of all this? Why does it exist?


The logic here is hidden or difficult. As a comparison, we don't need tons of 
explanations to understand the differences between a sequential collection 
(array, list) and, say, a set. The logic is nearly obvious, we easily get why 
both kinds exist. And in fact, the machine-side, implementation counterpart, 
while important, comes after, once we understand the meaning; then we get to 
know the price one has to pay for quick, direct access of given items, as 
opposed to access by index.


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

Re: [rust-dev] list of all reserved keywords of the language

[Gaetan]

I d prefere letting do launch tasks and don t add confusion.

Break and continue are consistent with other langages so i would keep them.
 Le 19 nov. 2013 12:19, "spir"  a écrit :

> On 11/19/2013 12:09 PM, Daniel Micay wrote:
>
>> The `loop` keyword still exists for the moment, but only for infinite
>> loops. I'd prefer removing it and just using `while true { ... }`.
>>
>
> My view on conditionned loop is something like:
>
> loop [while cond] {
> ...
> [continue if cond]
> ...
> [break if cond]
> ...
> } [until cond]
>
> An infinite loop is just when there is neither start, nore end condition.
>
> Or replace "loop" with "do" (only for brevity), "continue" with "next" or
> "up", "break" with "exit" or "out" (the latter 2 for clarity).
>
> Denis
> ___
> 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] Please simplify the syntax for Great Justice

[spir]

On 11/19/2013 10:12 AM, Jordi Boggiano wrote:

Often there is an alternative
to pooping sigils all over the code, but if you don't understand the
concepts behind it it's hard to reason about what those alternatives
could be.


+++

This is what I'm asking for about pointer variety and memory management in Rust. 
What does this all mean? Semantics, please ;-) (I mean human semantics, no 
machine operations)


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

Re: [rust-dev] list of all reserved keywords of the language

[spir]

On 11/19/2013 12:09 PM, Daniel Micay wrote:

The `loop` keyword still exists for the moment, but only for infinite
loops. I'd prefer removing it and just using `while true { ... }`.


My view on conditionned loop is something like:

loop [while cond] {
...
[continue if cond]
...
[break if cond]
...
} [until cond]

An infinite loop is just when there is neither start, nore end condition.

Or replace "loop" with "do" (only for brevity), "continue" with "next" or "up", 
"break" with "exit" or "out" (the latter 2 for clarity).


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

Re: [rust-dev] Please simplify the syntax for Great Justice

[spir]

On 11/19/2013 05:17 AM, Patrick Walton wrote:

On 11/18/13 7:41 PM, Kevin Ballard wrote:

Is that really why, or are you just  guessing? I'm assuming the real
reason is that people are used to languages where heap allocation is
common and stack allocation rare or nonexistant, and don't understand
why boxing everything is a bad idea. In other words, it's a problem that
a proper tutorial should be able to help with. I don't think changing
syntax is going to make much of a difference.


I've observed a lot of beginning Rust programmers treat the language as "add
sigils until it works". (I have specific examples but don't want to name people
here; however, feel free to contact me privately if you're curious.) They end up
with slow programs and frustrated with Rust, wondering why they had to fight the
compiler if they seemingly didn't gain any performance from it.

I think a fair amount of it is that the sigils don't visually convey enough
information to the programmer; they feel like something that you just have to
add to make the compiler happy. A sigil in Rust's expression grammar as it
stands represents an *action*, not a *qualifier* as it does in most other
languages (e.g. `$foo` in PHP). Moreover, the `~` expression maps to one of the
most expensive machine operations in the entire language semantics! It's thus
important in my view to emphasize to newcomers that `~` *means* something; it is
not just a qualifier you have to add to make the compiler happy. Indeed, if you
are adding it just to make the compiler accept your code, there's something
wrong--either the API you're using is inefficient or you're confused about the
semantics!


I share this line of reasoning. However, why not take the opporunity to find a 
proper term (or abbreviation)? "New" says nothing about the "action" or its 
cost. Semantically, every expression yields a "new" value, doesn't it?
(My take as of now would be "mem", as a shortcut for "reserve some memory on the 
heap, where the following piece of data is to be stored; but I don't find it 
great myself. "Alloc" or "store" would be pretty good, but maybe too long.)
Some may think this is just bikeshed; I don't share this view: instead, 
terminology is extremely important, it is what conveys semantics, or should; 
ditto for "key signs". And key terms & signs remain until the end of eternity ;-).


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

Re: [rust-dev] list of all reserved keywords of the language

[Daniel Micay]

On Tue, Nov 19, 2013 at 6:00 AM, spir  wrote:
> On 11/19/2013 10:30 AM, Valentin Gosu wrote:
>>
>> Also, it seems none of the docs have been updated for with the changing of
>> loop -> continue
>
>
> Oh, has this changed? (I've just updated my editor's list of keywords to
> include "loop".)
>
> Denis

The `loop` keyword still exists for the moment, but only for infinite
loops. I'd prefer removing it and just using `while true { ... }`.
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Please simplify the syntax for Great Justice

[Daniel Micay]

On Tue, Nov 19, 2013 at 5:56 AM, Gaetan  wrote:
> Can I advise to have a certain constitency in the semantics?
>
> Not having ~foo, *foo, Rc<>, Gc<>.
>
> I would rather prefere having
>
>   ~foo *foo &foo @foo
>
> of
>
>   Something<>foo, other<>foo, Rc<> foo
>
> By the way, I like pretty much your pronoums thing, this help understanding
> :)
>
> -
> Gaetan

Containers and smart pointers are plain old generic data types, they
don't deserve special construction or type syntax at all in my
opinion. If there's something wrong with Rust's syntax for generics,
lets fix that.

I wouldn't mind not having `~T` in the language at all, but am not
really opposed to including it because there's no harm. Choosing to
special-case arbitrary non-trivial data structures like vectors and
reference counted boxes *is* harmful because alternatives should *not*
be second-class.
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] list of all reserved keywords of the language

[spir]

On 11/19/2013 10:30 AM, Valentin Gosu wrote:

Also, it seems none of the docs have been updated for with the changing of
loop -> continue


Oh, has this changed? (I've just updated my editor's list of keywords to include 
"loop".)


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

Re: [rust-dev] Please simplify the syntax for Great Justice

[Gaetan]

Can I advise to have a certain constitency in the semantics?

Not having ~foo, *foo, Rc<>, Gc<>.

I would rather prefere having

  ~foo *foo &foo @foo

of

  Something<>foo, other<>foo, Rc<> foo

By the way, I like pretty much your pronoums thing, this help understanding
:)

-
Gaetan



2013/11/19 Gábor Lehel 

> In case this helps, I recently noticed that the sigils correspond to
> possessive pronouns:
>
> '~' => "my",
> '&' => "their",
> '@' => "our"
>
> Of course, `@` might be going away, but `Rc<>`, `Gc<>`, and so forth all
> (will) have the same intuitive content, only different representations
> (among other properties). Similarly `~Foo` and plain `Foo` both mean "my",
> while having differences in other areas, in which case yeah, telling you
> that `Foo` is stored in-place while `~Foo` is stored on the heap doesn't
> help you if you don't know what heap allocation is about. But maybe this is
> something.
>
>
> On Tue, Nov 19, 2013 at 10:12 AM, Jordi Boggiano wrote:
>
>> On Tue, Nov 19, 2013 at 5:17 AM, Patrick Walton 
>> wrote:
>> > I've observed a lot of beginning Rust programmers treat the language as
>> "add
>> > sigils until it works". (I have specific examples but don't want to name
>> > people here; however, feel free to contact me privately if you're
>> curious.)
>>
>> I feel like I have to out myself as one of the idiot newcomers that do
>> this, just for the sake of the discussion. I have no systems language
>> background and frankly never had to consider the difference between
>> the heap or the stack in the past 10-some years of writing code.
>>
>> I don't really think having new vs ~ would help me avoid this problem.
>> The issue I believe is that the language looks understandable enough
>> for the average joe used to higher level web languages (php, python,
>> ruby). That's a great thing of course, that I can just jump in and
>> mostly grasp what's going on, while past attempts at C++ tinkering
>> quickly ended in tears. It also means that you have lots of people
>> that come in and are capable of getting stuff to compile but won't
>> necessarily understand the small print. Often there is an alternative
>> to pooping sigils all over the code, but if you don't understand the
>> concepts behind it it's hard to reason about what those alternatives
>> could be.
>>
>> I think I'm getting better with this over time, and the rust libraries
>> also get more usable and consistent leading to less ~ insanity, but
>> one thing that would have helped early on is a good warning in the
>> docs about this, and a good explanation of what the hell is going on
>> (not one geared towards C++ devs using lingo that only low level devs
>> are familiar with).
>>
>> I realize it's no easy task, and that arguably I should probably just
>> read a book, but at the same time it's an amazing feat I think that
>> the language is so accessible while remaining at such a low level, so
>> if we manage to improve the onboarding process it would probably be
>> very beneficial. There are tons of web devs that are interested in
>> doing things faster/lower level - if only for fun. Maybe it's worth
>> having a chapter for them in the docs. I'd happily help review that
>> and point out unclear things :)
>>
>> Cheers
>>
>> --
>> Jordi Boggiano
>> @seldaek - http://nelm.io/jordi
>> ___
>> 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
>
>
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Please simplify the syntax for Great Justice

[Gábor Lehel]

In case this helps, I recently noticed that the sigils correspond to
possessive pronouns:

'~' => "my",
'&' => "their",
'@' => "our"

Of course, `@` might be going away, but `Rc<>`, `Gc<>`, and so forth all
(will) have the same intuitive content, only different representations
(among other properties). Similarly `~Foo` and plain `Foo` both mean "my",
while having differences in other areas, in which case yeah, telling you
that `Foo` is stored in-place while `~Foo` is stored on the heap doesn't
help you if you don't know what heap allocation is about. But maybe this is
something.


On Tue, Nov 19, 2013 at 10:12 AM, Jordi Boggiano  wrote:

> On Tue, Nov 19, 2013 at 5:17 AM, Patrick Walton 
> wrote:
> > I've observed a lot of beginning Rust programmers treat the language as
> "add
> > sigils until it works". (I have specific examples but don't want to name
> > people here; however, feel free to contact me privately if you're
> curious.)
>
> I feel like I have to out myself as one of the idiot newcomers that do
> this, just for the sake of the discussion. I have no systems language
> background and frankly never had to consider the difference between
> the heap or the stack in the past 10-some years of writing code.
>
> I don't really think having new vs ~ would help me avoid this problem.
> The issue I believe is that the language looks understandable enough
> for the average joe used to higher level web languages (php, python,
> ruby). That's a great thing of course, that I can just jump in and
> mostly grasp what's going on, while past attempts at C++ tinkering
> quickly ended in tears. It also means that you have lots of people
> that come in and are capable of getting stuff to compile but won't
> necessarily understand the small print. Often there is an alternative
> to pooping sigils all over the code, but if you don't understand the
> concepts behind it it's hard to reason about what those alternatives
> could be.
>
> I think I'm getting better with this over time, and the rust libraries
> also get more usable and consistent leading to less ~ insanity, but
> one thing that would have helped early on is a good warning in the
> docs about this, and a good explanation of what the hell is going on
> (not one geared towards C++ devs using lingo that only low level devs
> are familiar with).
>
> I realize it's no easy task, and that arguably I should probably just
> read a book, but at the same time it's an amazing feat I think that
> the language is so accessible while remaining at such a low level, so
> if we manage to improve the onboarding process it would probably be
> very beneficial. There are tons of web devs that are interested in
> doing things faster/lower level - if only for fun. Maybe it's worth
> having a chapter for them in the docs. I'd happily help review that
> and point out unclear things :)
>
> Cheers
>
> --
> Jordi Boggiano
> @seldaek - http://nelm.io/jordi
> ___
> 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] Please simplify the syntax for Great Justice

[Daniel Micay]

On Tue, Nov 19, 2013 at 4:51 AM, Gaetan  wrote:
> In the french presentation for rust 0.8 [1], the author gives the analogy
> with C++ semantics
> - ~ is a bit like unique_ptr
> - @ is an enhanced shared_ptr
> - borrowed pointer works like C++ reference
>
> and I think it was very helpful to better understand them. I don't know if
> it is true or now, but this comparison helps a lot understanding the
> concepts.You can present them like this, and after, add more precision, and
> difference with the C++ counter parts.
>
> A tutorial to make would be "Rust for C++ programmer" :)
>
>
> [1] http://linuxfr.org/news/presentation-de-rust-0-8
>
> -
> Gaetan

I wrote a reference for C++ programmers on the wiki some time ago.
Rust is very easy to approach as if you have a solid grasp of C++11 so
I don't think it's an important area to work on.

A C++ programmer already has a thorough understanding of the
ownership/lifetime concepts in Rust and the trait system will be
familiar because C++ has type traits + enable_if and implicit type
"concepts" that aren't formalized in the language yet.

https://github.com/mozilla/rust/wiki/Rust-for-CXX-programmers
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Please simplify the syntax for Great Justice

[Huon Wilson]

On 19/11/13 20:51, Gaetan wrote:
In the french presentation for rust 0.8 [1], the author gives the 
analogy with C++ semantics

- ~ is a bit like unique_ptr
- @ is an enhanced shared_ptr
- borrowed pointer works like C++ reference

and I think it was very helpful to better understand them. I don't 
know if it is true or now, but this comparison helps a lot 
understanding the concepts.You can present them like this, and after, 
add more precision, and difference with the C++ counter parts.


A tutorial to make would be "Rust for C++ programmer" :)


Something like that already exists: 
https://github.com/mozilla/rust/wiki/Rust-for-CXX-programmers



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

Re: [rust-dev] Please simplify the syntax for Great Justice

[Gaetan]

In the french presentation for rust 0.8 [1], the author gives the analogy
with C++ semantics
- ~ is a bit like unique_ptr
- @ is an enhanced shared_ptr
- borrowed pointer works like C++ reference

and I think it was very helpful to better understand them. I don't know if
it is true or now, but this comparison helps a lot understanding the
concepts.You can present them like this, and after, add more precision, and
difference with the C++ counter parts.

A tutorial to make would be "Rust for C++ programmer" :)


[1] http://linuxfr.org/news/presentation-de-rust-0-8

-
Gaetan



2013/11/19 Daniel Micay 

> On Tue, Nov 19, 2013 at 4:25 AM, Gaetan  wrote:
> > I don't think there is any particular issue with the tutorial, but we
> need
> > more "recipes" on how to handle typical situations.
>
> I'm specifically talking about the `Boxes` section in the tutorial and
> not the whole picture. I keep hearing that the coverage of `~` it's
> confusing - so can someone elaborate?
>
> Rewriting the coverage of boxes and references by walking through the
> implementation of some data structures is something I'm willing to do,
> but in my opinion that section is now quite good, other than being dry
> and not presenting interesting code samples for the use cases it
> describes.
>
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Type system thoughts

[Gábor Lehel]

On Sun, Nov 17, 2013 at 2:08 AM, Niko Matsakis  wrote:

> On Fri, Nov 15, 2013 at 05:05:28PM +0100, Gábor Lehel wrote:
> > I have some ideas about typey things and I'm going to write them down. It
> > will be long.
>
> I haven't read this all yet, I just want to respond to the first few
> paragraphs. :)
>


Thanks!


> > It would be nice if `Trait1 + Trait2` were itself a trait, legal in the
> > same positions as any trait. This is already partly true: in trait bounds
> > on type parameters and super-traits of traits. Where it's not true is
> trait
> > objects, e.g. `~(ToStr + Send)`. Having this could remove the need for
> the
> > current `~Trait:OtherTraits` special syntax.
>
> It's plausible to imagine, though I wouldn't phrase it that "Trait1+Trait2"
> is a trait, but rather a form of generalized object types. Today object
> types have the form `~Trait` and these generalized object types would
> have the form `~(Trait1+...+TraitN)`. Probably their size would be
> N+1 words to account for the extra vtables, which would make it trival
> to support the (natual) subtyping relation of the form
>
> ~(Trait1+Trait2) <: ~Trait1
> ~(Trait1+Trait2) <: ~Trait2
>
> You can sort of do something similar today with
>
> trait Trait3 : Trait1 + Trait 2 { }
> impl Trait3 for T { }
>

Interesting. Why would (or should) these two have different
representations? Couldn't we think of `+` as a type constructor, that takes
two traits as arguments and makes a trait?

In the same way that

type MyThing = (int, f64);

struct MyThing { a: (int, f64) }

will both have the same representation, couldn't we have `~(Trait1+Trait2)`
be represented just the same as `~Trait3` from the example above, so in a
sense `Trait3` is nothing more than a newtype of `Trait1+Trait2`?

(Couldn't/wouldn't/shouldn't `~Trait3` also be a subtype of `~Trait1` and
`~Trait2`?)

Note that my intuitions here are informed by having done much of the same
things in Haskell with `ConstraintKinds`. For instance, here is Rust's `+`,
but called `:&:`:

http://hackage.haskell.org/package/exists-0.2/docs/Control-Constraint-Combine.html

(And `Exists` in the same package is quite close to Rust's object types.)

But not everything translates directly, because for instance, Haskell
doesn't have subtyping. (Or at least, not in this way -- polymorphic types
with (sub)constraints are in effect a different form of it.)



>
> Note that the current syntax `~Trait:Bounds` is intentionally limited
> in that the traits that can appear in `Bounds` do not offer methods
> but rather give information about the kind of data that the object
> receiver consists of.
>

I know. What I'm trying to explore is whether generalizing the meaning of
`+` might not (alongside being useful generally) remove the need for this
special casing. (My wondering about lifetimes is in a similar vein.)


>
> > I wonder whether lifetimes could also be interpreted as traits, with the
> > meaning: "[object of type implementing lifetime-trait] does not outlive
> > [the given lifetime]". This is an honest wondering: I'm not sure if it
> > makes sense. If it does make sense, it would fit in perfectly with the
> fact
> > that 'static is already a trait. Together with the above, it might also
> > allow a solution for capturing borrowed data in a trait object: you could
> > write `~(Trait + 'a)`.
>
> I don't think of `'static` as a trait, though it is currently
> implemented that way for historical reasons that will hopefully soon
> be eased. Rather, type parameters can have a *lifetime bound*, which
> indicates the minimum lifetime that they can exist for. `'static` is
> just a special case of this.  This might be (for all intents and
> purposes) what you meant.


Which is a worthwhile question. :-)

I currently have two overlapping interpretations of lifetimes:

 1. The intuitive version, where lifetime parameters on borrowed pointers
and structs have the meaning "this object does not outlive the given
lifetime";

 2. By relating them to the universally quantified type variable of
Haskell's `ST` monad, which seems very close to if not precisely the same
thing: in both cases, objects whose type is tagged with a given
(lifetime/type variable) can't "escape" the given computation.

I can make sense of the "lifetime bounds" on type parameters which you
describe in terms of the first, because it makes sense intuitively, but not
the second. How does a universally quantified type variable end up behaving
in any way, shape, or form like a type class?

In particular, one should be able to do
> `~Trait:'a`, which is interpreted as:
>
> a pointer to some type T which implements the trait `Trait`
> and which contains data valid for at least the lifetime 'a
>

Again, in part I'm trying to explore whether the need for this `:` syntax
could be obviated. But for this half of it, in larger part I'm just trying
to understand things.


>
>
> Niko
>



-- 
Your ship was destroyed in a monadic eruption.

Re: [rust-dev] Please simplify the syntax for Great Justice

[Daniel Micay]

On Tue, Nov 19, 2013 at 4:25 AM, Gaetan  wrote:
> I don't think there is any particular issue with the tutorial, but we need
> more "recipes" on how to handle typical situations.

I'm specifically talking about the `Boxes` section in the tutorial and
not the whole picture. I keep hearing that the coverage of `~` it's
confusing - so can someone elaborate?

Rewriting the coverage of boxes and references by walking through the
implementation of some data structures is something I'm willing to do,
but in my opinion that section is now quite good, other than being dry
and not presenting interesting code samples for the use cases it
describes.
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] list of all reserved keywords of the language

[Gaetan]

can you give a little review?
https://github.com/Stibbons/crayon-syntax-rust

-
Gaetan



2013/11/19 Daniel Micay 

> On Tue, Nov 19, 2013 at 4:12 AM, Josh Matthews 
> wrote:
> > http://static.rust-lang.org/doc/master/rust.html#keywords
> >
> > Cheers,
> > Josh
>
> That's missing `proc`, at the very least :). Perhaps it would be best
> to look at `libsyntax/parse/token.rs`. Just ignore __LogLevel (it
> existing is a bug) and you likely don't want to bother highlighting
> non-functional reserved ones.
>
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] list of all reserved keywords of the language

[Valentin Gosu]

On 19 November 2013 11:20, Daniel Micay  wrote:

> On Tue, Nov 19, 2013 at 4:12 AM, Josh Matthews 
> wrote:
> > http://static.rust-lang.org/doc/master/rust.html#keywords
> >
> > Cheers,
> > Josh
>
> That's missing `proc`, at the very least :). Perhaps it would be best
> to look at `libsyntax/parse/token.rs`. Just ignore __LogLevel (it
> existing is a bug) and you likely don't want to bother highlighting
> non-functional reserved ones.
>

Also, it seems none of the docs have been updated for with the changing of
loop -> continue
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Please simplify the syntax for Great Justice

[Gaetan]

I don't think there is any particular issue with the tutorial, but we need
more "recipes" on how to handle typical situations.



-
Gaetan



2013/11/19 Daniel Micay 

> Is there any specific issue with the current tutorial section on
> boxes? It mentions every case where owned boxes are useful.
>
> http://static.rust-lang.org/doc/master/tutorial.html#boxes
>
> I keep hearing that it should be better, but have yet to see any hints
> on where it falls short. It's not going to change if no one can point
> out where it confuses them.
>
> I do want to rewrite it in a less boring style by having it be an
> introduction to these concepts by implementing a linked list, but I
> won't be changing the *content* (at least of Boxes).
> ___
> 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] Rust docs

[Gaetan]

That was my point on another thread. I think it's best to have a top-bottom
approach, ie, decribe everything else BUT the language first (how crates
works, how to compile, how to test,...) and then introduce the memory
concepts, etc.

I think the technical writer is a full time job, how to present things
properly is not easy to do. He may have better way of introducing the
language. I tend to agree with the assertion that its not a level of
quality we can achieve with collaborating works, sadly.

-
Gaetan



2013/11/19 Thad Guidry 

>
>> I tend to agree with this, think that a collaborative approach is
>> unlikely to produce a consistent and high quality tutorial. I don't want to
>> discourage anybody but my current opinion is that we should hire an
>> experienced technical writer to do this piece especially, with input from
>> the wider community. Where I think collaboration is more likely to produce
>> something nice is in a 'cookbook' style document, of which several people
>> have already worked on seperately. Also of course API docs and the
>> reference manual are places where individuals can plug in their own
>> sections without impacting the overall narrative flow.
>>
>>
> So I spent this evening going through the tutorial (.08).  As an outsider
> to Rust, I can tell you it does not fit any model of a tutorial, but
> instead is an elongated language reference broken down into feature
> sections.  Which is highly useful in its design, and does say "This
> tutorial assumes that the reader is already familiar with one or more
> languages in the C family. Understanding of pointers and general memory
> management techniques will help."  BUT...
>
> It was not until section 17, that I finally met with a simple program that
> could compile.  That was 2 1/2 hours later before I was able to DO
> SOMETHING.
>
> I would encourage the Mozilla team to hire a technical writer as Brian
> suggests, that would turn the tutorial upside down...
>
> Start with something fun and entertaining in under 10 or 20 lines of Rust,
> that would amuse and provide "hackability" to tweak and play with values,
> mutability, and seeing the stack pop itself (half the developers in the
> world, do not know or have to worry about "a stack"..but of course "should"
> in any decent systems language :-) ), and then introduce garbage
> collecting, etc.   Introduce compile-able examples from the start, and
> continue with working examples that actually produce errors and let the
> user come to grips with the syntax & compiler error output, while coaching
> them through fixing the errors, and learning the do's and don'ts of Rust's
> current best practices.  That would be a mighty fine tutorial and the
> makings of a book for Rust itself.
>
> 2 cents and a haircut and I wish the team tremendous success on finding a
> talented writer,
>
> --
> -Thad
> +ThadGuidry 
> 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] autocomplete engine for rust

[Corey Richardson]

On Mon, Nov 18, 2013 at 6:25 PM, Gokcehan Kara  wrote:
> 1) Implement a type under cursor functionality

rustfind (https://github.com/dobkeratops/rustfind) does this and more,
for crates that compile.

> Some more general questions are;
>
> - How feasible is this project with the current state of the compiler?
>

Not very, for the general case. If you want autocompletion as you
type, you currently need to have a fully-compilable crate. Otherwise,
parsing or typechecking or something else will fail and you won't be
able to get any results. rustc is currently very all-or-nothing.  But,
you can get useful information for completion out of an
already-compiling crate, though I'm not sure how much better it would
be than what etags already does.

> - How difficult would it be for a newbie (to both rustc and compilers)?
>

Very, since it would require reworking most of the compiler ;)
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] list of all reserved keywords of the language

[Daniel Micay]

On Tue, Nov 19, 2013 at 4:12 AM, Josh Matthews  wrote:
> http://static.rust-lang.org/doc/master/rust.html#keywords
>
> Cheers,
> Josh

That's missing `proc`, at the very least :). Perhaps it would be best
to look at `libsyntax/parse/token.rs`. Just ignore __LogLevel (it
existing is a bug) and you likely don't want to bother highlighting
non-functional reserved ones.
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Please simplify the syntax for Great Justice

[Daniel Micay]

Is there any specific issue with the current tutorial section on
boxes? It mentions every case where owned boxes are useful.

http://static.rust-lang.org/doc/master/tutorial.html#boxes

I keep hearing that it should be better, but have yet to see any hints
on where it falls short. It's not going to change if no one can point
out where it confuses them.

I do want to rewrite it in a less boring style by having it be an
introduction to these concepts by implementing a linked list, but I
won't be changing the *content* (at least of Boxes).
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Please simplify the syntax for Great Justice

[Jordi Boggiano]

On Tue, Nov 19, 2013 at 5:17 AM, Patrick Walton  wrote:
> I've observed a lot of beginning Rust programmers treat the language as "add
> sigils until it works". (I have specific examples but don't want to name
> people here; however, feel free to contact me privately if you're curious.)

I feel like I have to out myself as one of the idiot newcomers that do
this, just for the sake of the discussion. I have no systems language
background and frankly never had to consider the difference between
the heap or the stack in the past 10-some years of writing code.

I don't really think having new vs ~ would help me avoid this problem.
The issue I believe is that the language looks understandable enough
for the average joe used to higher level web languages (php, python,
ruby). That's a great thing of course, that I can just jump in and
mostly grasp what's going on, while past attempts at C++ tinkering
quickly ended in tears. It also means that you have lots of people
that come in and are capable of getting stuff to compile but won't
necessarily understand the small print. Often there is an alternative
to pooping sigils all over the code, but if you don't understand the
concepts behind it it's hard to reason about what those alternatives
could be.

I think I'm getting better with this over time, and the rust libraries
also get more usable and consistent leading to less ~ insanity, but
one thing that would have helped early on is a good warning in the
docs about this, and a good explanation of what the hell is going on
(not one geared towards C++ devs using lingo that only low level devs
are familiar with).

I realize it's no easy task, and that arguably I should probably just
read a book, but at the same time it's an amazing feat I think that
the language is so accessible while remaining at such a low level, so
if we manage to improve the onboarding process it would probably be
very beneficial. There are tons of web devs that are interested in
doing things faster/lower level - if only for fun. Maybe it's worth
having a chapter for them in the docs. I'd happily help review that
and point out unclear things :)

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] list of all reserved keywords of the language

[Josh Matthews]

http://static.rust-lang.org/doc/master/rust.html#keywords

Cheers,
Josh


On 19 November 2013 17:06, Gaetan  wrote:

> hello
>
> Where can I find an exhaustive list of the keywords defined by the
> language? I want to add basic syntax highlighting support to the rust
> language to some web editors and I don't know all of them yet.
>
> Thanks.
>
> -
> Gaetan
>
>
> ___
> 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] list of all reserved keywords of the language

[Gaetan]

hello

Where can I find an exhaustive list of the keywords defined by the
language? I want to add basic syntax highlighting support to the rust
language to some web editors and I don't know all of them yet.

Thanks.

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

Re: [rust-dev] autocomplete engine for rust

[Gaetan]

Hello

I'm willing to help on this task, I think having a good completion library
can help a lot smoothing the learning curve of a new language. I learned
python in a few days with aptana, and I remember a few years ago how it was
easy to write C++ with visual studio. Having an IDE integration is almost
as important as having good tutorials.

I'm also a newbe in Rust and I imagine you want to write in rust itself. I
can help on the integration with sublime.

-
Gaetan



2013/11/19 Gokcehan Kara 

> Hello folks,
>
> I have been thinking of working on an editor agnostic code helper library
> with an autocomplete engine for rust (since there isn't anything yet?) as a
> hobby project to get to know the internals of the compiler. Examples of
> similar projects in different languages include;
>
> - [youcompleteme](https://github.com/Valloric/YouCompleteMe)
> (C/C++/Objective-C/Objective-C++) (this one is specific to vim and a more
> general solution to autocompletion in vim but it includes a clang based
> completion engine for c family languages)
> - [merlin](https://github.com/def-lkb/merlin) (ocaml) (haven't actually
> used this but since we have many ocaml people I'm guessing some people
> might have)
> - [gocode](https://github.com/nsf/gocode) (go)
> - [jedi](https://github.com/davidhalter/jedi) (python)
>
> I have already started playing with the code but couldn't make much
> progress. What I had in mind was;
>
> 1) Implement a type under cursor functionality
> 2) Implement autocompletion functionality (i.e by looking up the methods
> and members of the type under cursor)
> 3) Wrap the whole thing with a server-client architecture (only if
> performance suffers too much otherwise)
> 4) Work on the bindings for my editor of choice as the showcase and ask
> the community for others
>
> Unfortunately I'm still at step 1. I have managed to parse a file until
> typecheck using `phase_3_run_analysis_passes` which gave me a
> `CrateAnalysis` including presumably the type context in `ty::ctxt`. From
> there I have only checked two things so far, (1) `items: ast_map::map`
> which is basically a map from `NodeId` to the enum `ast_node` and (2)
> `node_types: node_type_table` which is similarly a map from `uint` to `t`.
>
> `t` seems to represent types which is what I was looking for although I
> couldn't find anything related to type names so far. I have found a few
> id's instead that I have yet to comprehend which then made me think that it
> might be the case that types themselves might be stored only with an id
> instead of a name. If this is the case, it may still be possible to work on
> autocomplete functionality by skipping type under cursor functionality. Any
> insight?
>
> Some more general questions are;
>
> - How feasible is this project with the current state of the compiler?
> - How difficult would it be for a newbie (to both rustc and compilers)?
> - Shall I open an issue for this?
>
> Thanks,
> Gokcehan
>
> ___
> 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