Three jobs, three key "words":
1) creating structure: `mod foo { ... }` is used to organise code into modules2) external references: `extern mod foo` "imports" foo, but without any name binding (e.g. Java and Python's import statements also bind names) 3) creating aliases/binding names: `use a::b::c` What would you do? Have no structure (no mod)? Or automatically create it from the file structure? Automatically make any libraries found by the compiler available for import? On Friday 13 December 2013 11:13:29 Piotr Kukiełka wrote: > If you have a submodule called `extra`, how can the compiler tell that you > want to be importing from it? > I think I covered this in my description: > If there is matching import in scope and it isn't labeled with resource > path marker then first check local mods, and if nothing is found then scan > libs (extern mod). > > But I starts to see one downside of what I proposed. > If you need to specify path to some external module then probably you don't > want to repeat this in every place you want to import it, it would look > weird. > On the other hand you still could use only one keyword (like *use*) with > the requirement that in at least one place its defined with full path (if > needed). > Even if one decide that it's better to keep *use *and *mod *distinct then I > still don't see any benefits of having separate *mod *and *extern mod.* > Probably both of them should be replace with single keyword like *crate*. > > 2013/12/13 Huon Wilson <dbau...@gmail.com> > > > On 13/12/13 20:29, Liigo Zhuang wrote: > > looks like a good idea. > > > > I always think "extern mod extra" is repetitious, because, when i "use > > > > extra::Something", the compiler always know I'm using the mod "extra". > > > > > > You only need one `extern mod extra` per program which is hardly > > repetitive, and, what if you have a submodule called `extra`, how can the > > compiler tell that you want to be importing from it, rather than the extra > > crate? > > > > (In general, one has to explicitly import external crates, because they > > can be named anything.) > > > > > > > > Huon > > > > > > > > 2013/12/13 Piotr Kukiełka <piotr.kukie...@gmail.com> > > > >> Hi all, > >> > >> I'm new to rust but I'm quite interested in learning it more deeply and > >> > >> contributing to language itself. > >> However right now I'm just studying tutorial/manual/wiki to understand it > >> better, and sometimes I have doubts about language design. > >> My biggest concern so far was connected with module system. > >> Right now rust have 3 different (if I'm counting correctly) keywords used > >> for marking which library/module should be imported and used. > >> > >> Why not just one? It would actually solve few problems at once. > >> > >> So, this is my idea: > >> Drop *mod* and *extern mod *keywords and just leave *use*. > >> Since there would be only one keyword responsible for importing left, you > >> wouldn't need to care about their order. > >> Then, when compiler see new identifiers it checks: > >> 1) If there is local definition of it available? If there is, then we are > >> done. > >> 2) Is there matching import in scope? > >> > >> a) If yes, then is it labeled with resource path marker? > >> > >> *) If yes, then check if it's: > >> +) Path to local file => it's equivalent of > >> #[path=".."] > >> > >> mod rust; > >> > >> +) Something like "http://github.com/mozilla/rust"; => > >> > >> it's equivalent of extern mod rust = "github.com/mozilla/rust"; > >> > >> +) Something like "rust:0.8" => it's equivalent of > >> > >> extern mod my_rust(name = "rust", vers = "0.8"); *) If no, > >> then first check local mods, and if nothing is found then scan libs > >> (extern > >> mod) > >> > >> b) If no, then it's unknown symbol and we got error > >> > >> What are the real benefits? > >> > >> 1) End user just need to remember and understand one syntax, *use, * > >> > >> examples: > >> use farm; > >> use my_farm(path = "farm", vers = "2.5"); > >> use my_farm(path = "http://github.com/farming/farm";, vers = "2.5"); > >> use my_farm(path = "../../farm/farm.rs"); > >> 2) You don't need 3 special keywords > >> 3) Order of use doesn't matter (and there are no doubts about shadowing > >> order). > >> 4) You don't need special cases use super and use self, you can use path > >> to replace them as well (i.e. to replace self: use some_child_module:: > >> some_item(path = ".");) > >> 5) You won't link unused modules even if they are imported with *use.* > >> 6) If I'll decide to move part of my modules to separate library it can > >> still work without code changes > >> 7) It would be easy to implement imports which works only in scope this > >> way (as it is done in scala for example) > >> 8) this way use works more like import on jvm than include in C/C++ (and > >> I think C style include should be avoided) > >> > >> Downsides? > >> > >> I probably don't know all corner cases and maybe there are good and valid > >> reasons to do it as it done right now. > >> But unless they are really good then I think simplification of imports > >> should be seriously considered. > >> > >> Best regards, > >> > >> Piotr Kukielka > >> > >> > >> > >> > >> _______________________________________________ > >> Rust-dev mailing list > >> Rust-dev@mozilla.org > >> https://mail.mozilla.org/listinfo/rust-dev > >> > > -- > > > > 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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
