Libraries Digest, Vol 87, Issue 16

John Lato jwlato at gmail.com
Mon Nov 8 08:00:10 EST 2010


>
>
> Message: 10
> Date: Mon, 8 Nov 2010 09:42:33 +1100
> From: Ivan Lazar Miljenovic <ivan.miljenovic at gmail.com>
> Subject: Re: Haskell Platform Proposal: HLint
> To: "Bryan O'Sullivan" <bos at serpentine.com>
> Cc: libraries <libraries at haskell.org>
> Message-ID:
>        <AANLkTimOMxX2TjxnO0a+20=NgJW2iGym46yrNO8iX7Y3 at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> On 8 November 2010 08:35, Bryan O'Sullivan <bos at serpentine.com> wrote:
> > Hlint isn't a library, right? And as an application, it presumably
> doesn't for any practical reason need its dependencies in the platform in
> order to itself be included?
>
> As I stated earlier, the policy seems to state that they do need to be
> there (to be able to build the platform if nothing else):
>
> http://trac.haskell.org/haskell-platform/wiki/AddingPackages#PackageRequirements


Well, the policy can be changed if necessary (not that I'm proposing that
here).

While packages may need to be present to build an application in the
platform, they don't necessarily need to be exposed as part of the platform.
 Rationale-8.5 seems to be targeted at libraries specifically.  That is, it
claims there's no technical means to differentiate between blessed and
non-blessed packages, which is why non-blessed packages can't be included.
 But since an application doesn't expose libraries, there is a simple means
to make this distinction.

If you think of an application in the HP as maintaining a private fork of
non-HP libraries, it makes sense.  Of course, this also brings up one of my
concerns.  That is, the potential for future maintenance of depended-upon
libraries should be considered as part of potential for maintenance of the
application as a whole.  If the libraries are already part of HP this is
simpler.

For HLint specifically, my personal opinion is that library dependencies
shouldn't prevent hlint's inclusion in the HP.  I'm confident that
haskell-src-exts will continue to be well-maintained (and I'm glad to see
that it's working towards HP inclusion as well), and since Neil maintains
both uniplate and hlint I don't have any concern there.

John Lato
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/libraries/attachments/20101108/a5c54a10/attachment.html


More information about the Libraries mailing list