Whither split base?

Sun Nov 4 16:04:27 UTC 2018

Indeed.  It’d make it easier for experienced folks to improve / experiment
with base.  One hopes !

Currently even regular ghc contributors have to wrestle with avoiding
needing recursive modules sometimes when hacking on base!  There’s still
some of those in base but it’s less bad than in the past.  Though some
changes have very non intuitive realizations / factoring to avoid
introducing new recursion.

On Sun, Nov 4, 2018 at 10:15 AM Vanessa McHale <vanessa.mchale at iohk.io>
wrote:

> 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> 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
>>
>
> _______________________________________________
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20181104/05ff75a6/attachment.html>