More platform packages

[Chris Dornan]

I am very skeptical that we could maintain this distinction for very long,
Leading quite quickly to confusion. How realistic is it to expect punters
(like me) to not make use of of these packages in the platform; they would
de facto be in the platform Within a release or two, whether we liked it
or not (presumably not).

'twould be better to sort it out up front, IMHO.

Chris

On 23/01/2013 20:18, "Roman Cheplyaka" <roma at ro-che.info> wrote:

>Another possibility worth to consider is to ship these packages together
>with the platform without advertising them as "platform" packages.
>
>For these packages we'd make no claims that their API is good or stable,
>or that these packages even will be present in the future platform
>releases.
>If we consider the platform as an abstraction, then these "internal"
>packages constitute an implementation detail.
>
>The only thing we need to check, then, is that these packages are
>relatively bug-free, which would make their inclusion much easier than
>for ordinary platform packages.
>
>Roman
>
>* Gregory Collins <greg at gregorycollins.net> [2013-01-23 18:43:22+0100]
>> Hi all,
>> 
>> Hopefully you've noticed the proposal I made this morning for
>>attoparsec to
>> join the list of platform packages. I wanted to bring up a matter for
>> discussion before I propose more packages for inclusion. I'd very much
>>like
>> for the following packages written by Bryan to make it into the
>>platform:
>> 
>>    - aeson
>>    - criterion
>>    - mwc-random
>>    - statistics
>> 
>> The question is: what do we do, in general, if we want a package but its
>> inclusion would force us to pull in other non-platform packages?
>> Specifically re: the above list, statistics depends on erf and
>> math-functions, aeson depends on hashable and unordered-containers, and
>> criterion depends on aeson, hastache, and vector-algorithms.
>> 
>> I remember that we ran into the same issue vis-a-vis vector pulling in
>>the
>> "primitive" package, but I'm not sure that the discussion was resolved
>>in a
>> way that sets a usable precedent. Here my gut feeling would be that
>> "hastache" doesn't cut it as a platform package, we probably want to
>>fold
>> unordered-containers into containers in the long term, erf and
>> math-functions are probably OK to include as they are.
>> 
>> What should we do in these cases? Asking package maintainers to shoulder
>> the burden of gutting or completely refactoring their packages to get
>>rid
>> of dependencies we don't like seems contrary to the spirit of what we
>>are
>> trying to accomplish here. Our procedures seem to be mostly geared
>>around
>> refining an individual package's API and then having up-and-down votes
>>on
>> inclusion/exclusion. I worry that this is going to disqualify libraries
>> that we really, *really* want to include because their maintainers won't
>> want to do the pointless busywork that might be required alone.
>> 
>> Should we instead establish a loose "strike force" (I hesitate to use
>>the
>> word "committee") that would work to further these kinds of long-term
>>goals
>> by helping maintainers refactor things to make them more
>>platform-friendly?
>> 
>> G
>> -- 
>> Gregory Collins <greg at gregorycollins.net>
>
>> _______________________________________________
>> Haskell-platform mailing list
>> Haskell-platform at projects.haskell.org
>> http://projects.haskell.org/cgi-bin/mailman/listinfo/haskell-platform
>
>
>_______________________________________________
>Haskell-platform mailing list
>Haskell-platform at projects.haskell.org
>http://projects.haskell.org/cgi-bin/mailman/listinfo/haskell-platform