Whither split base?
Vanessa McHale
vanessa.mchale at iohk.io
Sun Nov 4 15:15:14 UTC 2018
I don't think split base would make it easier to introduce newcomers to
making contributions to base.
The argument r.e. portability/backpack is that it would make it harder
to use base with other compilers.
On 11/2/18 8:09 PM, John Ky wrote:
> FWIW, I'm very much in favour of Ed's suggestion.
>
> A monolithic base creates too much friction for things like porting or
> introducing newcomers like myself to making contributions to base.
>
> I am however interested in why they believe introducing backpack to
> base should cause breaking changes.
>
> Discussions there, I believe would be illuminating.
>
> Cheers
>
> John
>
> On Sat, 3 Nov 2018 at 03:01, Tom Murphy <amindfv at gmail.com
> <mailto:amindfv at gmail.com>> wrote:
>
> I'd rather see Backpack become a lot more mainstream (many more
> packages using it, maybe seeing other Haskell compilers implement it?)
> before using it to split base.
>
> I'm also -1 on any change to our most foundational package that causes
> breakage for any category of users, unless there's a very compelling
> reason.
>
> Tom
>
> On 10/30/18, Edward Kmett <ekmett at gmail.com
> <mailto:ekmett at gmail.com>> wrote:
> > Now that we have backpack which gives us 'reexported-modules:'
> perhaps a
> > better plan for a split-base would be rather to leave base
> monolithic, with
> > its current API, but instead eyeball having it re-export most if
> not all of
> > itself from smaller split-base components?
> >
> > I'm mostly interested in foundational wins where splitting things up
> > enables us to run in more places because you have to port fewer
> parts, and
> > less about wins that we get from splintering off small but
> completely pure
> > haskell components like the 'printf', but I can well understand
> how these
> > concerns get conflated.
> >
> > Then Herbert's (valid) objection about needless breakage is
> addressed and
> > it still provides a roadmap to a finer-grained dependency set
> nonetheless.
> >
> > -Edward
> >
> > On Tue, Oct 30, 2018 at 11:32 AM Daniel Cartwright
> <chessai1996 at gmail.com <mailto:chessai1996 at gmail.com>>
> > wrote:
> >
> >> DOA seems kinda harsh at this point. If base just re-exports
> the stuff,
> >> that makes sense, but wouldn't we want to move it out eventually?
> >>
> >>
> >>
> >> On Tue, Oct 30, 2018, 11:29 AM Carter Schonwald <
> >> carter.schonwald at gmail.com <mailto:carter.schonwald at gmail.com>>
> wrote:
> >>
> >>> Yeah
> >>>
> >>> The point ofnsplit base as an idea or goal is to make base simply
> >>> reexport stuff. Not to drop it off the base/face of the earth.
> >>>
> >>> This proposal is DOA.
> >>>
> >>> On Tue, Oct 30, 2018 at 11:03 AM Vanessa McHale
> <vanessa.mchale at iohk.io <mailto:vanessa.mchale at iohk.io>>
> >>> wrote:
> >>>
> >>>> Saying "people shouldn't be using this API in library code"
> seems like
> >>>> a
> >>>> poor reason to potentially break (working?) packages downstream.
> >>>> On 10/30/18 7:42 AM, Andrew Martin wrote:
> >>>>
> >>>> The benefit is certainly small, and it probably would
> discourage using
> >>>> the API. I don't think that the migration path would be
> tricky. The new
> >>>> package would just reexport Text.Printf when built with base
> < 4.13, and
> >>>> it
> >>>> would define it when built with base >= 4.13. All that is
> required is a
> >>>> build-depends line. However, people really shouldn't be using
> this API
> >>>> in
> >>>> library code. Other modules in base provide more efficient
> and more
> >>>> type-safe ways handle most of the situations I've seen this
> used for.
> >>>>
> >>>> I've never used System.Console.GetOpt (I'm typically use
> >>>> optparse-applicative for option parsing), but yes, I think
> that would
> >>>> also
> >>>> be a good candidate. Since there are multiple competing
> approach for
> >>>> argument parsing in the haskell ecosystem, my preference
> would be to
> >>>> avoid
> >>>> blessing any of them with inclusion in base.
> >>>>
> >>>> I don't feel particularly strongly about either of these, but
> their
> >>>> position in base feels odd. They both feel like the result of
> applying
> >>>> a
> >>>> "batteries included" mindset to a standard library that has
> by and
> >>>> large
> >>>> refrained from including batteries.
> >>>>
> >>>> On Tue, Oct 30, 2018 at 8:17 AM Herbert Valerio Riedel <
> >>>> hvriedel at gmail.com <mailto:hvriedel at gmail.com>> wrote:
> >>>>
> >>>>>
> >>>>> On 2018-10-30 at 08:04:59 -0400, Andrew Martin wrote:
> >>>>> > Here's an idea for this I had last night. It's narrowly
> scoped, but
> >>>>> > I
> >>>>> think
> >>>>> > it moves us a tiny bit in the right direction. We could move
> >>>>> Text.Printf
> >>>>> > out of base and into its own library. This doesn't really
> belong in
> >>>>> base.
> >>>>> > The interface it provides it somewhat opinionated, and
> it's not even
> >>>>> > type-safe. The new library could be named `printf` and
> could live
> >>>>> under the
> >>>>> > haskell github organization. Any thoughts for or against?
> >>>>>
> >>>>> Ok, but what does this effectively achieve?
> >>>>>
> >>>>> Text.Printf is an API that has been extremely stable and doesn't
> >>>>> significant evolve anymore; I don't think it has contributed
> to major
> >>>>> ver bumps in recent times, nor is it likely to. So I don't
> see much of
> >>>>> a
> >>>>> compelling benefit in doing so. The effect I'd expect if we
> do this is
> >>>>> that `Text.Printf` will be reached for less (which some
> might argue to
> >>>>> be a desirable effect -- but you're effectively pushing this
> API to a
> >>>>> path of slow legacy death due to reduced discoverability,
> IMO), as the
> >>>>> convenience of using it is reduced by requiring adding and
> maintaining
> >>>>> an additional `build-depends` line to your package
> descriptions, as
> >>>>> well
> >>>>> as having to deal with the subtly tricky business of
> handling the
> >>>>> migration path pre/post-split (c.f. the `network-bsd` split
> currently
> >>>>> being in progress).
> >>>>>
> >>>>> Btw, a related extremely stable API in base I could think of
> which
> >>>>> people might argue doesn't belong into `base` either is maybe
> >>>>> `System.Console.GetOpt`; would you argue to split that off
> as well?
> >>>>> _______________________________________________
> >>>>> Libraries mailing list
> >>>>> Libraries at haskell.org <mailto:Libraries at haskell.org>
> >>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
> >>>>>
> >>>>
> >>>>
> >>>> --
> >>>> -Andrew Thaddeus Martin
> >>>>
> >>>> _______________________________________________
> >>>> Libraries mailing
> >>>>
> listLibraries at haskell.orghttp://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
> <http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries>
> >>>>
> >>>> _______________________________________________
> >>>> Libraries mailing list
> >>>> Libraries at haskell.org <mailto:Libraries at haskell.org>
> >>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
> >>>>
> >>> _______________________________________________
> >>> Libraries mailing list
> >>> Libraries at haskell.org <mailto:Libraries at haskell.org>
> >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
> >>>
> >> _______________________________________________
> >> Libraries mailing list
> >> Libraries at haskell.org <mailto:Libraries at haskell.org>
> >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
> >>
> >
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org <mailto:Libraries at haskell.org>
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20181104/fc617906/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20181104/fc617906/attachment.sig>
More information about the Libraries
mailing list