On 23/04/2013 9:44 AM, Erick Tryzelaar wrote:
There are still a couple things in std that depend on rustrt:
arena.rs <http://arena.rs>
dbg.rs <http://dbg.rs>
net_tcp.rs <http://net_tcp.rs>
rl.rs <http://rl.rs>
test.rs <http://test.rs>
time.rs <http://time.rs>
uv_ll.rs <http://uv_ll.rs>
Can we include moving these into core as part of a rename? I believe
that's the one main holdup that is keeping us from breaking std up into
external packages.
Yes. Though I'd ask that we also take a moment to revisit the original
motivation for the core/std split, and confirm that everyone's ok with
collapsing them back together:
https://mail.mozilla.org/pipermail/rust-dev/2011-December/001037.html
Namely:
- When we support static linking, will it be possible to link subsets
of "the standard library" for space constrained devices? E.g. will
we be able to compile it with section-per-function or such?
- Is it ok that "the standard library" winds up 'use'd in every
module by default? You can still shadow its definitions, but there
is some risk of confusion due to use of paths qualified by
un-mentioned modules.
- Is it ok that "packages" in "ext" cannot be mutually recursive
with one another? Will this happen often?
- Is the "large standard library" approach of python and haskell (say)
really problematic wrt. pace of library evolution? Is it wise to
even _have_ an "ext"? If so, what does it mean? Supported and
tested non-mutually-dependent selections from the package ecosystem?
The moral equivalent of boost?
Finally, wrt. naming, in the meeting someone mentioned that:
extern mod "rust-lang.org/ext";
might not really read well. Lots of "ext" in there. Any other names come
to mind?
Thanks,
-Graydon
_______________________________________________
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
