<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p>This would break a lot of packages for the relatively small
benefit of finer grained dependencies.<br>
</p>
<div class="moz-cite-prefix">On 10/30/18 8:35 AM, Andrew Martin
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CABNC7eOD+9NmLX6s5r2MrH5yeFzxZSSosW3K7F-fsnMWP911=w@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">Here's my stab at a more aggressive split:
<div><br>
</div>
<div>* base: everything not removed by the libraries below</div>
<div>* concurrency: all Control.Concurrent.* modules (depends on
base)</div>
<div>* foreign: all Foreign.* modules (depends on base)</div>
<div>* event-manager: all GHC.IO.* modules, System.Timeout
(depends on base, foreign, concurrency)</div>
<div><br>
</div>
<div>There would be some additional trickery. The stuff in
Control.Concurrent that deals with event registration would
need to be moved somewhere else. But I think this would
more-or-less work.</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr">On Tue, Oct 30, 2018 at 8:54 AM Andrew Martin
<<a href="mailto:andrew.thaddeus@gmail.com"
moz-do-not-send="true">andrew.thaddeus@gmail.com</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">For additional clarity, I should mention that I
am looking for low-hanging fruit here. The higher and
tastier fruit would of course be splitting out the event
manager and all the file handle logic with it. But that
would be difficult, both in terms of the actual work
required and in terms of achieving a consensus.</div>
<br>
<div class="gmail_quote">
<div dir="ltr">On Tue, Oct 30, 2018 at 8:47 AM Andrew Martin
<<a href="mailto:andrew.thaddeus@gmail.com"
target="_blank" moz-do-not-send="true">andrew.thaddeus@gmail.com</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">We could also move out all the modules
underneath Control.Concurrent (but not
Control.Concurrent itself) except for the MVar module.
We would have to leave that one because there is a bunch
of other stuff in base that uses MVar. These modules
have demonstrated less stability than
System.Console.GetOpt and Text.Printf, and there are
competing implementations in other libraries.</div>
<br>
<div class="gmail_quote">
<div dir="ltr">On Tue, Oct 30, 2018 at 8:42 AM Andrew
Martin <<a href="mailto:andrew.thaddeus@gmail.com"
target="_blank" moz-do-not-send="true">andrew.thaddeus@gmail.com</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">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.
<div>
<div>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.</div>
</div>
<div><br>
</div>
<div>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.</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr">On Tue, Oct 30, 2018 at 8:17 AM
Herbert Valerio Riedel <<a
href="mailto:hvriedel@gmail.com" target="_blank"
moz-do-not-send="true">hvriedel@gmail.com</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex"><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 I think<br>
> it moves us a tiny bit in the right
direction. We could move Text.Printf<br>
> out of base and into its own library. This
doesn't really belong in 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 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 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 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>
</blockquote>
</div>
<br clear="all">
<div><br>
</div>
-- <br>
<div dir="ltr"
class="m_5728837890627266443m_7007428628053109112m_6505248671778253220gmail_signature"
data-smartmail="gmail_signature">-Andrew Thaddeus
Martin</div>
</blockquote>
</div>
<br clear="all">
<div><br>
</div>
-- <br>
<div dir="ltr"
class="m_5728837890627266443m_7007428628053109112gmail_signature"
data-smartmail="gmail_signature">-Andrew Thaddeus Martin</div>
</blockquote>
</div>
<br clear="all">
<div><br>
</div>
-- <br>
<div dir="ltr" class="m_5728837890627266443gmail_signature"
data-smartmail="gmail_signature">-Andrew Thaddeus Martin</div>
</blockquote>
</div>
<br clear="all">
<div><br>
</div>
-- <br>
<div dir="ltr" class="gmail_signature"
data-smartmail="gmail_signature">-Andrew Thaddeus Martin</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>