Forgot to reply-all. d'oh!
Regards,
Paul Nathan
Sent from my iPhone
On Feb 28, 2013, at 11:01 AM, Paul Nathan <pnat...@vandals.uidaho.edu> wrote:
> I would suggest a three-ring strategy.
>
> 1. Compiler and minimal libs, much like C. This is the sacred system
> maintained by rust devs. This is just what would be needed for writing
> embedded systems and other minimal lib situations.
>
> 2. Blessed ring: moves faster and is collected periodically. C.f. Haskell
> platform. It represents common programming tasks and 'batteries'. Not
> standardized.( no iso document)
>
> 3. Rust-cpan. Free for all. Yahoos. Whatever. Popular packages might make
> into the platform.
>
> N. b. - Version locking can be problematic and a hassle; see in the case of
> Haskell/cabal.
>
> Well, those are my 2c. :)
>
> Regards,
> Paul Nathan
>
> Sent from my iPhone
>
> On Feb 28, 2013, at 10:50 AM, Graydon Hoare <gray...@mozilla.com> wrote:
>
>> On 28/02/2013 9:43 AM, Erick Tryzelaar wrote:
>>> Hello Tommy,
>>>
>>> I feel our process will ultimately be more along the lines of a small
>>> standard library that needs hooks into the compiler and runtime, and an
>>> extensive CPAN-esque repository for everything else. We'll have first
>>> party "blessed" packages for things like a web client, compression, and
>>> hashing algorithms.
>>
>> This "blessed packages" approach to libstd is appealing in some ways but
>> unappealing in others; it's something we discussed at the last weekly
>> meeting and I'm curious to hear more perspectives on it. There are a
>> bunch of tensions at work:
>>
>> - Terminology-wise, "standard library" as in "gets written into a
>> standards document" suggests a very minimal libcore-like (or
>> smaller) component. This is Stroustrup's philosophy[1] and it has
>> a credible basis. You don't want to burden ISO translators with
>> writing up the docs to your space invaders emulator[2].
>>
>> - In terms of user convenience, tracking numerous library versions
>> is a pain, as is tracking numerous "works on OS $foo" statuses.
>> A standard-ish (or "common" if we want to avoid the word "standard")
>> library is helpful in setting expectations about what a user can
>> expect to be able to get working "on all reasonable installs",
>> as well as which APIs will have long-term support and high levels
>> of QA, documentation, integration testing, porting, etc.
>>
>> - Gating releases of a language on readiness-status of libraries and
>> maintaining legacy APIs is a pain, true, but users often care much
>> more about library APIs than they do about language features. "How
>> do I write $foo in Rust" is very often an API question, not a
>> language question, and the absence of a good API is equivalent
>> to saying "go away".
>>
>> - Certain code idioms are mutually recursive. These need to be in the
>> same crate for our purposes.
>>
>> In general my tendency is towards "batteries included" from the _user
>> experience_ perspective when possible; this does leave some question
>> about whether (and how) to approach a best-of-both-worlds situation as
>> far as making the _developer experience_ also pleasant.
>>
>> I've been pushing around ideas about how to manage possibly re-exporting
>> pinned versions of particular external libraries as part of the libstd
>> namespace, as a way to mediate these tensions. Doing so would have
>> possibly-weird, possibly-ok effects:
>>
>> - We might have to teach rustpkg to handle the idea of a mod
>> directive resolving against a pkgid, the same way we're going
>> to be teaching it to resolve extern mod directives. That is, we
>> might need to be able to write 'mod foo = "github.com/user/foo";'
>> and have it imply that the package manager check out that
>> library but _build it into the referencing crate_ rather than as
>> an extern. But I think that's ... possibly ok, and might even be
>> pleasantly uniform in practice.
>>
>> - The libstd major-version might advance as the _maximum_ of advances
>> in included libraries. It might bump with nearly every release,
>> though I have a long-standing idea in mind to mitigate this: version
>> attributes on module items. This is essentially a way to turn what
>> _would_ be a major-version bump (API change) into a minor-version
>> bump (API addition), since the items wind up qualified by separate
>> version numbers. This might wind up weird or it might wind up quite
>> practical. We haven't implemented it yet. Put concretely, we might
>> get away with doing this (in libstd):
>>
>> #[vers="1.0.0"]
>> pub mod foo = "github.com/user/foo#1.0";
>>
>> #[vers="1.1.0"]
>> pub mod foo = "github.com/user/foo#2.0";
>>
>> which would "absorb" the major-version change between two versions
>> of libfoo into a minor-version change to libstd, because we're
>> "keeping the old API" of foo around qualified with std vers 1.0.0.
>> Anyone who bound to "pkg.rust-lang.org/std#1.0.0" would get the
>> old libfoo API they are expecting, but the package manager would
>> be willing to provide it by downloading 1.0.0 or 1.1.0; in semver
>> logic we literally are just "adding API" so are treated as such by
>> version-reasoning tools. Moreover if a user wants to use a mixture
>> of old and new APIs they can:
>>
>> extern mod std = "pkg.rust-lang.org/std#1.0.0";
>> std::foo::bar(1); // using foo::bar 1.0 API
>>
>> mod futuristic {
>> // This module's been upgraded.
>> extern mod std = "pkg.rust-lang.org/std#1.1.0";
>> std::foo::bar(1, true); // using foo::bar 2.0 API
>> }
>>
>> of course if we got sick of maintaining foo 1.0 in libstd, we'd
>> remove it and that would cause a major-version bump to libstd.
>> Presumably we'd clear out a bunch of old re-exports at once in
>> such a case -- anything that we're convinced is obsolete & unused,
>> or causing undue maintenance pain.
>>
>> I'm interested to hear thoughts from others, as usual. This is tricky to
>> get just right but it's important. API compatibility is the thing
>> hardest to handle over time as they'll _always_ evolve, no matter how
>> stable the language; having a strategy for thinking about backward
>> compatibility might help us avoid the version tarpit that has happened
>> to so many languages (inability to ship new APIs due to mismatches in
>> users' willingness to upgrade, essentially). How we do this will have
>> pretty major implications for how we work over time.
>>
>> -Graydon
>>
>> [1] https://en.wikipedia.org/wiki/Standard_library#Philosophies
>> [2]
>> http://docs.factorcode.org/content/article-handbook-library-reference.html
>>
>> _______________________________________________
>> 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
