Re: [rust-dev] Why we don't like glob use (use std::vec::*)?
Perhaps it's not that important that it will be able to continue after errors? I think that generally there should not be type errors even while programming is in progress. It means that if I'm referring to something I have to immediately write a stub for it, but I don't think it's that bad. Noam On Wed, Mar 12, 2014 at 10:07 PM, Daniel Micay danielmi...@gmail.comwrote: On 12/03/14 03:52 PM, Clark Gaebel wrote: There is no accurate jump-to-definition, type retrieval, docstring retrieval or semantic completion for Rust. The compiler was not built with support for this kind of tooling in mind, and I seriously doubt that anything but inaccurate hacks will exist for a *long* time. This worries me a lot. It would need to be able to perform type checking/inference even if the file can't be fully parsed, or there are type errors in other places. At the moment, each phase simply assumes all of the previous stages were fully completed, and it bails out immediately on any error by unwinding via failure. It's easy to see this from the error reporting. Rust can report multiple errors within the same phase, but it's unable to report a type error if parsing fails. `clang` was designed with this kind of thing as a central pillar and is able to continue reporting errors or giving useful results to queries from tooling even if there are problems. It's not at all an easy task, and most compilers are not able to do it. A language like Go is simple enough that tooling like completion can be done without help from a compiler. However, Rust has powerful local type inference, which presents a difficult obstacle. Another enormous obstacle is the power of traits - a type can have methods provided by traits, if the trait is in scope and the type is covered by an implementation, which may be generic. ___ 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] Why we don't like glob use (use std::vec::*)?
Hi,
coersion still can break any code depending on library really badly.
Just suppose the method implemented for Hello in the following example
was added later. After the change, different function is called. IMO,
the risks from glob imports are no worse than this.
struct Hello {
s : ~str
}
impl Hello {
// added later
fn print(self) { println!({}, self.s); }
}
trait Printable {
fn print(self);
}
impl Printable for Hello {
fn print(self) { println!(Hello world from trait); }
}
fn main() {
let h = Hello {s : ~Hello world};
h.print(); // calling different function
}
J
On 03/12/2014 08:17 PM, Bob Ippolito wrote:
Glob imports work well up front but aren't good for maintenance. In
Haskell if a popular library adds a new function it could easily break
any packages that depend on it that use glob imports. It's more work but
almost always best to explicitly import individual names. A tool could
help with this though.
On Wednesday, March 12, 2014, Huon Wilson dbau...@gmail.com
mailto:dbau...@gmail.com wrote:
Certain aspects of them dramatically complicate the name resolution
algorithm (as I understand it), and, anyway, they have various
downsides for the actual code, e.g. the equivalent in Python is
frowned upon:
http://python.net/~goodger/projects/pycon/2007/idiomatic/handout.html#importing
Maybe they aren't so bad in a compiled statically typed language?
I don't know; either way, I personally find code without glob
imports easier to read, because I can work out which function is
being called very easily, whereas glob imports require more effort.
Huon
On 12/03/14 20:44, Liigo Zhuang wrote:
glob use just make compiler loading more types, but make
programmers a lot easy (to write, to remember). perhaps I'm wrong?
thank you!
--
by *Liigo*, http://blog.csdn.net/liigo/
Google+ https://plus.google.com/105597640837742873343/
___
Rust-dev mailing list
Rust-dev@mozilla.org javascript:_e(%7B%7D,'cvml','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] Why we don't like glob use (use std::vec::*)?
Existing problems with the language aren't a reason to add new problems. signature.asc Description: OpenPGP digital signature ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Why we don't like glob use (use std::vec::*)?
On 3/13/14 11:35 AM, Daniel Micay wrote: Existing problems with the language aren't a reason to add new problems. I don't think the coercion is much of a problem; at least, not a fixable one. Dot notation for method syntax in a systems language that supports values pretty much requires some sort of coercion. (Having to write `(mut my_vector).push()` is a non-starter, sadly, as much as the compiler writer in me wants to remove all that code...) Patrick ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Why we don't like glob use (use std::vec::*)?
I am following Rust only for few month. Was the alternate syntax Trait::method(object, other parameters) discussed? It will be sometimes useful to write Clone::clone(x) instead of x.clone() or (x as Clone).clone(). J On 03/13/2014 07:36 PM, Patrick Walton wrote: On 3/13/14 11:35 AM, Daniel Micay wrote: Existing problems with the language aren't a reason to add new problems. I don't think the coercion is much of a problem; at least, not a fixable one. Dot notation for method syntax in a systems language that supports values pretty much requires some sort of coercion. (Having to write `(mut my_vector).push()` is a non-starter, sadly, as much as the compiler writer in me wants to remove all that code...) 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] Why we don't like glob use (use std::vec::*)?
On 3/13/14 11:44 AM, Jan Klesnil wrote: I am following Rust only for few month. Was the alternate syntax Trait::method(object, other parameters) discussed? It will be sometimes useful to write Clone::clone(x) instead of x.clone() or (x as Clone).clone(). Yup! That's what we call Uniform Function Call Syntax or UFCS. :) Patrick ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
[rust-dev] Why we don't like glob use (use std::vec::*)?
glob use just make compiler loading more types, but make programmers a lot easy (to write, to remember). perhaps I'm wrong? thank you! -- by *Liigo*, http://blog.csdn.net/liigo/ Google+ https://plus.google.com/105597640837742873343/ ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Why we don't like glob use (use std::vec::*)?
Certain aspects of them dramatically complicate the name resolution algorithm (as I understand it), and, anyway, they have various downsides for the actual code, e.g. the equivalent in Python is frowned upon: http://python.net/~goodger/projects/pycon/2007/idiomatic/handout.html#importing Maybe they aren't so bad in a compiled statically typed language? I don't know; either way, I personally find code without glob imports easier to read, because I can work out which function is being called very easily, whereas glob imports require more effort. Huon On 12/03/14 20:44, Liigo Zhuang wrote: glob use just make compiler loading more types, but make programmers a lot easy (to write, to remember). perhaps I'm wrong? thank you! -- by *Liigo*, http://blog.csdn.net/liigo/ Google+ https://plus.google.com/105597640837742873343/ ___ 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] Why we don't like glob use (use std::vec::*)?
On 12/03/14 06:38 AM, Huon Wilson wrote: Certain aspects of them dramatically complicate the name resolution algorithm (as I understand it), and, anyway, they have various downsides for the actual code, e.g. the equivalent in Python is frowned upon: http://python.net/~goodger/projects/pycon/2007/idiomatic/handout.html#importing Maybe they aren't so bad in a compiled statically typed language? I don't know; either way, I personally find code without glob imports easier to read, because I can work out which function is being called very easily, whereas glob imports require more effort. Huon I think it's still pretty bad. It makes it *very* hard to read the code because it's not clear where the names are coming from. signature.asc Description: OpenPGP digital signature ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Why we don't like glob use (use std::vec::*)?
That implies we need better editors. Things I need for exploring large codebases: 1. Go to definition 2. What's the type of this variable/function? With these two things, it should be relatively easy to read code with or without glob imports. On Wed, Mar 12, 2014 at 2:57 PM, Daniel Micay danielmi...@gmail.com wrote: On 12/03/14 06:38 AM, Huon Wilson wrote: Certain aspects of them dramatically complicate the name resolution algorithm (as I understand it), and, anyway, they have various downsides for the actual code, e.g. the equivalent in Python is frowned upon: http://python.net/~goodger/projects/pycon/2007/idiomatic/handout.html#importing Maybe they aren't so bad in a compiled statically typed language? I don't know; either way, I personally find code without glob imports easier to read, because I can work out which function is being called very easily, whereas glob imports require more effort. Huon I think it's still pretty bad. It makes it *very* hard to read the code because it's not clear where the names are coming from. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev -- Clark. Key ID : 0x78099922 Fingerprint: B292 493C 51AE F3AB D016 DD04 E5E3 C36F 5534 F907 ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Why we don't like glob use (use std::vec::*)?
I don’t like the glob patterns either, but I might like them more if a module
could define a “prelude” and only those symbols would be imported by a glob
pattern. For example, if you say `use std::str::*`, you would automatically
get the functions but not rarely used things like the raw module.
Maybe just a corruption of existing syntax like:
mymod.rs
```
mod * {
pub use { MyStruct, my_func, MyEnum };
}
pub struct MyStruct {
[…]
}
[…]
```
Eric
On Mar 12, 2014, at 1:57 PM, Daniel Micay danielmi...@gmail.com wrote:
On 12/03/14 06:38 AM, Huon Wilson wrote:
Certain aspects of them dramatically complicate the name resolution
algorithm (as I understand it), and, anyway, they have various downsides
for the actual code, e.g. the equivalent in Python is frowned upon:
http://python.net/~goodger/projects/pycon/2007/idiomatic/handout.html#importing
Maybe they aren't so bad in a compiled statically typed language? I
don't know; either way, I personally find code without glob imports
easier to read, because I can work out which function is being called
very easily, whereas glob imports require more effort.
Huon
I think it's still pretty bad. It makes it *very* hard to read the code
because it's not clear where the names are coming from.
___
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] Why we don't like glob use (use std::vec::*)?
Glob imports work well up front but aren't good for maintenance. In Haskell if a popular library adds a new function it could easily break any packages that depend on it that use glob imports. It's more work but almost always best to explicitly import individual names. A tool could help with this though. On Wednesday, March 12, 2014, Huon Wilson dbau...@gmail.com wrote: Certain aspects of them dramatically complicate the name resolution algorithm (as I understand it), and, anyway, they have various downsides for the actual code, e.g. the equivalent in Python is frowned upon: http://python.net/~goodger/projects/pycon/2007/idiomatic/handout.html#importing Maybe they aren't so bad in a compiled statically typed language? I don't know; either way, I personally find code without glob imports easier to read, because I can work out which function is being called very easily, whereas glob imports require more effort. Huon On 12/03/14 20:44, Liigo Zhuang wrote: glob use just make compiler loading more types, but make programmers a lot easy (to write, to remember). perhaps I'm wrong? thank you! -- by *Liigo*, http://blog.csdn.net/liigo/ Google+ https://plus.google.com/105597640837742873343/ ___ Rust-dev mailing listrust-...@mozilla.org javascript:_e(%7B%7D,'cvml','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] Why we don't like glob use (use std::vec::*)?
I think it helps that Rust allows imports in any block. You could use glob
imports like this with little risk of breaking:
```
fn foo() {
import std::str::*
[..]
}
```
Eric
On Mar 12, 2014, at 2:17 PM, Bob Ippolito b...@redivi.com wrote:
Glob imports work well up front but aren't good for maintenance. In Haskell
if a popular library adds a new function it could easily break any packages
that depend on it that use glob imports. It's more work but almost always
best to explicitly import individual names. A tool could help with this
though.
On Wednesday, March 12, 2014, Huon Wilson dbau...@gmail.com wrote:
Certain aspects of them dramatically complicate the name resolution algorithm
(as I understand it), and, anyway, they have various downsides for the actual
code, e.g. the equivalent in Python is frowned upon:
http://python.net/~goodger/projects/pycon/2007/idiomatic/handout.html#importing
Maybe they aren't so bad in a compiled statically typed language? I don't
know; either way, I personally find code without glob imports easier to read,
because I can work out which function is being called very easily, whereas
glob imports require more effort.
Huon
On 12/03/14 20:44, Liigo Zhuang wrote:
glob use just make compiler loading more types, but make programmers a lot
easy (to write, to remember). perhaps I'm wrong? thank you!
--
by Liigo, http://blog.csdn.net/liigo/
Google+ https://plus.google.com/105597640837742873343/
___
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] Why we don't like glob use (use std::vec::*)?
Fixed ;-)
On Mar 12, 2014, at 2:19 PM, Eric Summers eric.summ...@me.com wrote:
I think it helps that Rust allows imports in any block. You could use glob
imports like this with less risk of breaking:
```
fn foo() {
use std::str::*
[..]
}
```
Eric
On Mar 12, 2014, at 2:17 PM, Bob Ippolito b...@redivi.com wrote:
Glob imports work well up front but aren't good for maintenance. In Haskell
if a popular library adds a new function it could easily break any packages
that depend on it that use glob imports. It's more work but almost always
best to explicitly import individual names. A tool could help with this
though.
On Wednesday, March 12, 2014, Huon Wilson dbau...@gmail.com wrote:
Certain aspects of them dramatically complicate the name resolution
algorithm (as I understand it), and, anyway, they have various downsides for
the actual code, e.g. the equivalent in Python is frowned upon:
http://python.net/~goodger/projects/pycon/2007/idiomatic/handout.html#importing
Maybe they aren't so bad in a compiled statically typed language? I don't
know; either way, I personally find code without glob imports easier to
read, because I can work out which function is being called very easily,
whereas glob imports require more effort.
Huon
On 12/03/14 20:44, Liigo Zhuang wrote:
glob use just make compiler loading more types, but make programmers a
lot easy (to write, to remember). perhaps I'm wrong? thank you!
--
by Liigo, http://blog.csdn.net/liigo/
Google+ https://plus.google.com/105597640837742873343/
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Why we don't like glob use (use std::vec::*)?
On 12/03/14 03:12 PM, Clark Gaebel wrote: That implies we need better editors. Things I need for exploring large codebases: 1. Go to definition 2. What's the type of this variable/function? With these two things, it should be relatively easy to read code with or without glob imports. Rust is explicitly designed to work well in any editor. That's one of the reasons for caring so much about keeping the grammar simple. It's a pragmatic language ignoring arguments about a sufficiently smart compiler or editor. There is no accurate jump-to-definition, type retrieval, docstring retrieval or semantic completion for Rust. The compiler was not built with support for this kind of tooling in mind, and I seriously doubt that anything but inaccurate hacks will exist for a *long* time. Even if it did exist, there would be many editing Rust code without it. Not everyone is going to install a librustc-based emacs/vim plugin, completion daemon or whatever is required. signature.asc Description: OpenPGP digital signature ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Why we don't like glob use (use std::vec::*)?
Is that what people actually do? You still risk breakage if you glob import
from two or more modules in the same block.
On Wed, Mar 12, 2014 at 12:22 PM, Eric Summers eric.summ...@me.com wrote:
Fixed ;-)
On Mar 12, 2014, at 2:19 PM, Eric Summers eric.summ...@me.com wrote:
I think it helps that Rust allows imports in any block. You could use
glob imports like this with less risk of breaking:
```
fn foo() {
use std::str::*
[..]
}
```
Eric
On Mar 12, 2014, at 2:17 PM, Bob Ippolito b...@redivi.com wrote:
Glob imports work well up front but aren't good for maintenance. In
Haskell if a popular library adds a new function it could easily break
any packages that depend on it that use glob imports. It's more work but
almost always best to explicitly import individual names. A tool could help
with this though.
On Wednesday, March 12, 2014, Huon Wilson dbau...@gmail.com wrote:
Certain aspects of them dramatically complicate the name resolution
algorithm (as I understand it), and, anyway, they have various downsides
for the actual code, e.g. the equivalent in Python is frowned upon:
http://python.net/~goodger/projects/pycon/2007/idiomatic/handout.html#importing
Maybe they aren't so bad in a compiled statically typed language? I
don't know; either way, I personally find code without glob imports easier
to read, because I can work out which function is being called very easily,
whereas glob imports require more effort.
Huon
On 12/03/14 20:44, Liigo Zhuang wrote:
glob use just make compiler loading more types, but make programmers a
lot easy (to write, to remember). perhaps I'm wrong? thank you!
--
by *Liigo*, http://blog.csdn.net/liigo/
Google+ https://plus.google.com/105597640837742873343/
___
Rust-dev mailing
listRust-dev@mozilla.orghttps://mail.mozilla.org/listinfo/rust-dev
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Why we don't like glob use (use std::vec::*)?
Yes, but you can minimize the risk. Particularly if you are importing your own
modules. Just need to use some common sense.
If you are referring to importing at the block level, I see a lot of Rust code
doing that including in the compiler. Glob imports are not really used though.
Like most people, I’m not sure how I feel about them yet.
Eric
On Mar 12, 2014, at 2:45 PM, Bob Ippolito b...@redivi.com wrote:
Is that what people actually do? You still risk breakage if you glob import
from two or more modules in the same block.
On Wed, Mar 12, 2014 at 12:22 PM, Eric Summers eric.summ...@me.com wrote:
Fixed ;-)
On Mar 12, 2014, at 2:19 PM, Eric Summers eric.summ...@me.com wrote:
I think it helps that Rust allows imports in any block. You could use glob
imports like this with less risk of breaking:
```
fn foo() {
use std::str::*
[..]
}
```
Eric
On Mar 12, 2014, at 2:17 PM, Bob Ippolito b...@redivi.com wrote:
Glob imports work well up front but aren't good for maintenance. In Haskell
if a popular library adds a new function it could easily break any packages
that depend on it that use glob imports. It's more work but almost always
best to explicitly import individual names. A tool could help with this
though.
On Wednesday, March 12, 2014, Huon Wilson dbau...@gmail.com wrote:
Certain aspects of them dramatically complicate the name resolution
algorithm (as I understand it), and, anyway, they have various downsides
for the actual code, e.g. the equivalent in Python is frowned upon:
http://python.net/~goodger/projects/pycon/2007/idiomatic/handout.html#importing
Maybe they aren't so bad in a compiled statically typed language? I don't
know; either way, I personally find code without glob imports easier to
read, because I can work out which function is being called very easily,
whereas glob imports require more effort.
Huon
On 12/03/14 20:44, Liigo Zhuang wrote:
glob use just make compiler loading more types, but make programmers a
lot easy (to write, to remember). perhaps I'm wrong? thank you!
--
by Liigo, http://blog.csdn.net/liigo/
Google+ https://plus.google.com/105597640837742873343/
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Why we don't like glob use (use std::vec::*)?
There is no accurate jump-to-definition, type retrieval, docstring retrieval or semantic completion for Rust. The compiler was not built with support for this kind of tooling in mind, and I seriously doubt that anything but inaccurate hacks will exist for a *long* time. This worries me a lot. -- Clark. Key ID : 0x78099922 Fingerprint: B292 493C 51AE F3AB D016 DD04 E5E3 C36F 5534 F907 ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Why we don't like glob use (use std::vec::*)?
Maybe I’m wrong, but I’m not sure this is accurate. rustdoc does all of this with libsyntax including jumping to the line of the actual source code for a symbol. Maybe it isn’t perfectly ideal for some tools, but I don’t think it is anywhere near a lost cause. Eric On Mar 12, 2014, at 2:52 PM, Clark Gaebel cgae...@uwaterloo.ca wrote: There is no accurate jump-to-definition, type retrieval, docstring retrieval or semantic completion for Rust. The compiler was not built with support for this kind of tooling in mind, and I seriously doubt that anything but inaccurate hacks will exist for a *long* time. This worries me a lot. -- Clark. Key ID : 0x78099922 Fingerprint: B292 493C 51AE F3AB D016 DD04 E5E3 C36F 5534 F907 ___ 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] Why we don't like glob use (use std::vec::*)?
On 12/03/14 03:52 PM, Clark Gaebel wrote: There is no accurate jump-to-definition, type retrieval, docstring retrieval or semantic completion for Rust. The compiler was not built with support for this kind of tooling in mind, and I seriously doubt that anything but inaccurate hacks will exist for a *long* time. This worries me a lot. It would need to be able to perform type checking/inference even if the file can't be fully parsed, or there are type errors in other places. At the moment, each phase simply assumes all of the previous stages were fully completed, and it bails out immediately on any error by unwinding via failure. It's easy to see this from the error reporting. Rust can report multiple errors within the same phase, but it's unable to report a type error if parsing fails. `clang` was designed with this kind of thing as a central pillar and is able to continue reporting errors or giving useful results to queries from tooling even if there are problems. It's not at all an easy task, and most compilers are not able to do it. A language like Go is simple enough that tooling like completion can be done without help from a compiler. However, Rust has powerful local type inference, which presents a difficult obstacle. Another enormous obstacle is the power of traits - a type can have methods provided by traits, if the trait is in scope and the type is covered by an implementation, which may be generic. signature.asc Description: OpenPGP digital signature ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Why we don't like glob use (use std::vec::*)?
That makes sense. Rust is an easier language to parse then C/C++ though, so maybe it isn’t necessary. Just need to convert the source in to an AST with an alternate parser that can throw out stuff that is invalid. Then analyze it with the compiler. Eric On Mar 12, 2014, at 3:07 PM, Daniel Micay danielmi...@gmail.com wrote: On 12/03/14 03:52 PM, Clark Gaebel wrote: There is no accurate jump-to-definition, type retrieval, docstring retrieval or semantic completion for Rust. The compiler was not built with support for this kind of tooling in mind, and I seriously doubt that anything but inaccurate hacks will exist for a *long* time. This worries me a lot. It would need to be able to perform type checking/inference even if the file can't be fully parsed, or there are type errors in other places. At the moment, each phase simply assumes all of the previous stages were fully completed, and it bails out immediately on any error by unwinding via failure. It's easy to see this from the error reporting. Rust can report multiple errors within the same phase, but it's unable to report a type error if parsing fails. `clang` was designed with this kind of thing as a central pillar and is able to continue reporting errors or giving useful results to queries from tooling even if there are problems. It's not at all an easy task, and most compilers are not able to do it. A language like Go is simple enough that tooling like completion can be done without help from a compiler. However, Rust has powerful local type inference, which presents a difficult obstacle. Another enormous obstacle is the power of traits - a type can have methods provided by traits, if the trait is in scope and the type is covered by an implementation, which may be generic. ___ 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] Why we don't like glob use (use std::vec::*)?
It's not as dire as you suggest. We can just allow some further passes to continue if earlier passes fail. We have this ty_err infrastructure in place already. Parsing creating an incomplete AST is also possible. I don't really think that Go is that much easier to do completion on. Type inference in Rust is more powerful, sure, but Go has type inference too. Same with trait imports: it's all lexical in Rust, so that should work too. C++ is much worse, with its strange intertwined parsing and typechecking and template expansion, and Visual Studio does a good job with that. JetBrains offers code completion for Scala, which is more complex than Rust with implicits and such. Patrick On March 12, 2014 1:07:23 PM PDT, Daniel Micay danielmi...@gmail.com wrote: On 12/03/14 03:52 PM, Clark Gaebel wrote: There is no accurate jump-to-definition, type retrieval, docstring retrieval or semantic completion for Rust. The compiler was not built with support for this kind of tooling in mind, and I seriously doubt that anything but inaccurate hacks will exist for a *long* time. This worries me a lot. It would need to be able to perform type checking/inference even if the file can't be fully parsed, or there are type errors in other places. At the moment, each phase simply assumes all of the previous stages were fully completed, and it bails out immediately on any error by unwinding via failure. It's easy to see this from the error reporting. Rust can report multiple errors within the same phase, but it's unable to report a type error if parsing fails. `clang` was designed with this kind of thing as a central pillar and is able to continue reporting errors or giving useful results to queries from tooling even if there are problems. It's not at all an easy task, and most compilers are not able to do it. A language like Go is simple enough that tooling like completion can be done without help from a compiler. However, Rust has powerful local type inference, which presents a difficult obstacle. Another enormous obstacle is the power of traits - a type can have methods provided by traits, if the trait is in scope and the type is covered by an implementation, which may be generic. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev -- Sent from my Android phone with K-9 Mail. Please excuse my brevity.___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Why we don't like glob use (use std::vec::*)?
On Wed, Mar 12, 2014 at 03:12:16PM -0400, Clark Gaebel wrote: That implies we need better editors. Things I need for exploring large codebases: 1. Go to definition 2. What's the type of this variable/function? FWIW, ctags (with etags-select [1]) gives me both of these things today to an acceptable degree. I'm not arguing we should never have better IDE integration or anything, just saying that if you want to make your life easier TODAY, you should consider using ctags. Just run make TAGS.vi or make TAGS.emacs to index the standard libraries, and you can copy the definition file for use on your own projects. Niko [1] http://www.emacswiki.org/emacs/EtagsSelect ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Why we don't like glob use (use std::vec::*)?
On 12/03/14 04:24 PM, Patrick Walton wrote: It's not as dire as you suggest. We can just allow some further passes to continue if earlier passes fail. We have this ty_err infrastructure in place already. Parsing creating an incomplete AST is also possible. I don't really think that Go is that much easier to do completion on. Type inference in Rust is more powerful, sure, but Go has type inference too. Same with trait imports: it's all lexical in Rust, so that should work too. C++ is much worse, with its strange intertwined parsing and typechecking and template expansion, and Visual Studio does a good job with that. JetBrains offers code completion for Scala, which is more complex than Rust with implicits and such. Patrick Go doesn't really have what I would call type inference. It just takes the type from the right-hand side so it's not much different than writing foo(bar(2)) instead of `x := bar(2); foo(x)`. C++ makes it impossible to provide accurate completion without implementing most of a compiler. You don't need as much of a compiler to do it for Rust, but you still need a lot. signature.asc Description: OpenPGP digital signature ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Why we don't like glob use (use std::vec::*)?
On 12/03/14 04:35 PM, Niko Matsakis wrote: On Wed, Mar 12, 2014 at 03:12:16PM -0400, Clark Gaebel wrote: That implies we need better editors. Things I need for exploring large codebases: 1. Go to definition 2. What's the type of this variable/function? FWIW, ctags (with etags-select [1]) gives me both of these things today to an acceptable degree. I'm not arguing we should never have better IDE integration or anything, just saying that if you want to make your life easier TODAY, you should consider using ctags. Just run make TAGS.vi or make TAGS.emacs to index the standard libraries, and you can copy the definition file for use on your own projects. Niko [1] http://www.emacswiki.org/emacs/EtagsSelect It somewhat works, but ctags is pretty awful even in C when compared to something like youcompleteme, XCode or Visual Studio. In my opinion, the need to generate tags and the occasional inaccurate results (missing completions, or invalid ones) is more of a productivity loss than lack of completion will ever be :P. signature.asc Description: OpenPGP digital signature ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Why we don't like glob use (use std::vec::*)?
On Wed, Mar 12, 2014 at 12:12 PM, Clark Gaebel cgae...@uwaterloo.ca wrote: That implies we need better editors. Things I need for exploring large codebases: 1. Go to definition 2. What's the type of this variable/function? With these two things, it should be relatively easy to read code with or without glob imports. I consider those features /extremely/ useful as well. However, I would still prefer to be able to read code purely in my head, without having to actively press keys to figure out what I'm reading. If you have a fancy IDE then it should also be able to add the namespaces for you... (Sadly, type inference makes that sort of reading something of a lost cause in general - not that I'm against type inference, since it makes writing so much nicer.) ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
