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