<div><div dir="auto">Indeed. It’d make it easier for experienced folks to improve / experiment with base. One hopes !</div></div><div dir="auto"><br></div><div dir="auto">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. </div><div><br><div class="gmail_quote"><div dir="ltr">On Sun, Nov 4, 2018 at 10:15 AM Vanessa McHale <<a href="mailto:vanessa.mchale@iohk.io">vanessa.mchale@iohk.io</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div 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><div text="#000000" bgcolor="#FFFFFF">
<div class="m_7387677205260478544moz-cite-prefix">On 11/2/18 8:09 PM, John Ky wrote:<br>
</div>
<blockquote type="cite">
<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" target="_blank">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">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">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">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">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">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">Libraries@haskell.org</a><br>
>>>>> <a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" rel="noreferrer" target="_blank">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="m_7387677205260478544moz-txt-link-abbreviated" href="mailto:listLibraries@haskell.orghttp://" target="_blank">listLibraries@haskell.orghttp://</a><a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" rel="noreferrer" target="_blank">mail.haskell.org/cgi-bin/mailman/listinfo/libraries</a><br>
>>>><br>
>>>>
_______________________________________________<br>
>>>> Libraries mailing list<br>
>>>> <a href="mailto:Libraries@haskell.org" target="_blank">Libraries@haskell.org</a><br>
>>>> <a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" rel="noreferrer" target="_blank">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">Libraries@haskell.org</a><br>
>>> <a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" rel="noreferrer" target="_blank">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">Libraries@haskell.org</a><br>
>> <a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" rel="noreferrer" target="_blank">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">Libraries@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries</a><br>
</blockquote>
</div>
</div>
</div>
</div>
<br>
<fieldset class="m_7387677205260478544mimeAttachmentHeader"></fieldset>
<pre class="m_7387677205260478544moz-quote-pre">_______________________________________________
Libraries mailing list
<a class="m_7387677205260478544moz-txt-link-abbreviated" href="mailto:Libraries@haskell.org" target="_blank">Libraries@haskell.org</a>
<a class="m_7387677205260478544moz-txt-link-freetext" href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries</a>
</pre>
</blockquote>
</div>
_______________________________________________<br>
Libraries mailing list<br>
<a href="mailto:Libraries@haskell.org" target="_blank">Libraries@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries</a><br>
</blockquote></div></div>