Why we don't like glob use (use std::vec::*)?

classic Classic list List threaded Threaded
26 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Why we don't like glob use (use std::vec::*)?

Liigo Zhuang
"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/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/rust-dev/attachments/20140312/cf3fdcb5/attachment.html>

Reply | Threaded
Open this post in threaded view
|

Why we don't like glob use (use std::vec::*)?

Huon Wilson
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 at mozilla.org
> https://mail.mozilla.org/listinfo/rust-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/rust-dev/attachments/20140312/54c08ae1/attachment.html>

Reply | Threaded
Open this post in threaded view
|

Why we don't like glob use (use std::vec::*)?

Daniel Micay
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.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: <http://mail.mozilla.org/pipermail/rust-dev/attachments/20140312/caed3a27/attachment.sig>

Reply | Threaded
Open this post in threaded view
|

Why we don't like glob use (use std::vec::*)?

Clark Gaebel
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 <danielmicay at 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 at mozilla.org
> https://mail.mozilla.org/listinfo/rust-dev
>
>


--
Clark.

Key ID     : 0x78099922
Fingerprint: B292 493C 51AE F3AB D016  DD04 E5E3 C36F 5534 F907
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/rust-dev/attachments/20140312/65eeb8f2/attachment.html>

Reply | Threaded
Open this post in threaded view
|

Why we don't like glob use (use std::vec::*)?

Eric Summers
In reply to this post by Daniel Micay
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 <danielmicay at 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 at mozilla.org
> https://mail.mozilla.org/listinfo/rust-dev


Reply | Threaded
Open this post in threaded view
|

Why we don't like glob use (use std::vec::*)?

Bob Ippolito
In reply to this post by Huon Wilson
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.pp at 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 at mozilla.org <javascript:_e(%7B%7D,'cvml','Rust-dev at mozilla.org');>https://mail.mozilla.org/listinfo/rust-dev
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/rust-dev/attachments/20140312/df281d6f/attachment.html>

Reply | Threaded
Open this post in threaded view
|

Why we don't like glob use (use std::vec::*)?

Eric Summers
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 <bob at 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.pp at 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 at mozilla.org
>> https://mail.mozilla.org/listinfo/rust-dev
>
> _______________________________________________
> Rust-dev mailing list
> Rust-dev at mozilla.org
> https://mail.mozilla.org/listinfo/rust-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/rust-dev/attachments/20140312/ea682812/attachment.html>

Reply | Threaded
Open this post in threaded view
|

Why we don't like glob use (use std::vec::*)?

Eric Summers

Fixed ;-)

On Mar 12, 2014, at 2:19 PM, Eric Summers <eric.summers at 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 <bob at 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.pp at 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 at mozilla.org
>>> https://mail.mozilla.org/listinfo/rust-dev
>>
>> _______________________________________________
>> Rust-dev mailing list
>> Rust-dev at mozilla.org
>> https://mail.mozilla.org/listinfo/rust-dev
>
> _______________________________________________
> Rust-dev mailing list
> Rust-dev at mozilla.org
> https://mail.mozilla.org/listinfo/rust-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/rust-dev/attachments/20140312/02eb4e02/attachment-0001.html>

Reply | Threaded
Open this post in threaded view
|

Why we don't like glob use (use std::vec::*)?

Daniel Micay
In reply to this post by Clark Gaebel
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.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: <http://mail.mozilla.org/pipermail/rust-dev/attachments/20140312/54cb9588/attachment.sig>

Reply | Threaded
Open this post in threaded view
|

Why we don't like glob use (use std::vec::*)?

Bob Ippolito
In reply to this post by Eric Summers
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.summers at me.com> wrote:

>
> Fixed ;-)
>
> On Mar 12, 2014, at 2:19 PM, Eric Summers <eric.summers at 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 <bob at 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.pp at 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 at mozilla.orghttps://mail.mozilla.org/listinfo/rust-dev
>>
>>
>>  _______________________________________________
> Rust-dev mailing list
> Rust-dev at mozilla.org
> https://mail.mozilla.org/listinfo/rust-dev
>
>
> _______________________________________________
> Rust-dev mailing list
> Rust-dev at mozilla.org
> https://mail.mozilla.org/listinfo/rust-dev
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/rust-dev/attachments/20140312/5cc0eab4/attachment.html>

Reply | Threaded
Open this post in threaded view
|

Why we don't like glob use (use std::vec::*)?

Eric Summers
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 <bob at 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.summers at me.com> wrote:
>
> Fixed ;-)
>
> On Mar 12, 2014, at 2:19 PM, Eric Summers <eric.summers at 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 <bob at 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.pp at 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 at mozilla.org
>>>> https://mail.mozilla.org/listinfo/rust-dev
>>>
>>> _______________________________________________
>>> Rust-dev mailing list
>>> Rust-dev at mozilla.org
>>> https://mail.mozilla.org/listinfo/rust-dev
>>
>> _______________________________________________
>> Rust-dev mailing list
>> Rust-dev at mozilla.org
>> https://mail.mozilla.org/listinfo/rust-dev
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/rust-dev/attachments/20140312/7433a98b/attachment-0001.html>

Reply | Threaded
Open this post in threaded view
|

Why we don't like glob use (use std::vec::*)?

Clark Gaebel
In reply to this post by Daniel Micay
> ?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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/rust-dev/attachments/20140312/d930fbca/attachment.html>

Reply | Threaded
Open this post in threaded view
|

Why we don't like glob use (use std::vec::*)?

Eric Summers
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 <cgaebel at 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 at mozilla.org
> https://mail.mozilla.org/listinfo/rust-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/rust-dev/attachments/20140312/a9e26586/attachment.html>

Reply | Threaded
Open this post in threaded view
|

Why we don't like glob use (use std::vec::*)?

Daniel Micay
In reply to this post by Clark Gaebel
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.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: <http://mail.mozilla.org/pipermail/rust-dev/attachments/20140312/2aedb9c8/attachment.sig>

Reply | Threaded
Open this post in threaded view
|

Why we don't like glob use (use std::vec::*)?

Eric Summers
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 <danielmicay at 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 at mozilla.org
> https://mail.mozilla.org/listinfo/rust-dev


Reply | Threaded
Open this post in threaded view
|

Why we don't like glob use (use std::vec::*)?

Patrick Walton
In reply to this post by Daniel Micay
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 <danielmicay at 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 at mozilla.org
>https://mail.mozilla.org/listinfo/rust-dev

--
Sent from my Android phone with K-9 Mail. Please excuse my brevity.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/rust-dev/attachments/20140312/a81b6ab8/attachment.html>

Reply | Threaded
Open this post in threaded view
|

Why we don't like glob use (use std::vec::*)?

Niko Matsakis
In reply to this post by Clark Gaebel
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



Reply | Threaded
Open this post in threaded view
|

Why we don't like glob use (use std::vec::*)?

Daniel Micay
In reply to this post by Patrick Walton
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.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: <http://mail.mozilla.org/pipermail/rust-dev/attachments/20140312/ea726914/attachment.sig>

Reply | Threaded
Open this post in threaded view
|

Why we don't like glob use (use std::vec::*)?

Daniel Micay
In reply to this post by Niko Matsakis
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.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: <http://mail.mozilla.org/pipermail/rust-dev/attachments/20140312/eaeb897b/attachment-0001.sig>

Reply | Threaded
Open this post in threaded view
|

Why we don't like glob use (use std::vec::*)?

comex
In reply to this post by Clark Gaebel
On Wed, Mar 12, 2014 at 12:12 PM, Clark Gaebel <cgaebel at 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.)

12