Whither split base?

Sat Nov 3 01:09:26 UTC 2018

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> 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> 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>
> > 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> 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>
> >>> 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> 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
> >>>>> 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
> >>>>
> >>>> _______________________________________________
> >>>> Libraries mailing list
> >>>> 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
> >>>
> >> _______________________________________________
> >> Libraries mailing list
> >> 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/20181103/15d55ef8/attachment-0001.html>