Re: Whither split base?

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 mailto:amindfv@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 mailto:ekmett@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 mailto:chessai1996@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@gmail.com mailto:carter.schonwald@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 mailto:vanessa.mchale@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@gmail.com mailto:hvriedel@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@haskell.org mailto:Libraries@haskell.org >>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >>>>> >>>> >>>> >>>> -- >>>> -Andrew Thaddeus Martin >>>> >>>> _______________________________________________ >>>> Libraries mailing >>>> listLibraries@haskell.orghttp://mail.haskell.org/cgi-bin/mailman/listinfo/libraries http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >>>> >>>> _______________________________________________ >>>> Libraries mailing list >>>> Libraries@haskell.org mailto:Libraries@haskell.org >>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >>>> >>> _______________________________________________ >>> Libraries mailing list >>> Libraries@haskell.org mailto:Libraries@haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >>> >> _______________________________________________ >> Libraries mailing list >> Libraries@haskell.org mailto:Libraries@haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >> > _______________________________________________ Libraries mailing list Libraries@haskell.org mailto:Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries