<div dir="ltr">Stable perhaps, but not uncontested:<div><br></div><div><a href="http://hackage.haskell.org/package/vault-0.3.1.2/docs/Data-Unique-Really.html" target="_blank">http://hackage.haskell.org/package/vault-0.3.1.2/docs/Data-Unique-Really.html</a></div><div><br></div><div>(Apologies for off-list duplicate. Why does gmail have different reply defaults for desktop vs. mobile...)</div></div><br><div class="gmail_quote"><div dir="ltr">On Tue, Oct 30, 2018 at 7:59 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 think this would raise the same objection that Herbert raised
before, namely: what does this accomplish when <tt>Data.Unique</tt>
is already stable? All I see happening is that this breaks
libraries downstream. <br>
</p>
<div class="m_4818096442545776509moz-cite-prefix">On 10/30/18 9:03 AM, Daniel Cartwright
wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">Data.Unique could probably be split off.
<div><br>
</div>
<div>A few modules that depend on the event manager might have
to be split off (e.g. System.Timeout)</div>
<div><br>
</div>
<div>Control.Concurrent is weird because it also has the 'Fd'
stuff in it, not sure how that would work - split off into the
event manager package? since there's a cyclic dependency there
while those exist in Control.Concurrent.</div>
<div><br>
</div>
<div>Weak ptrs and Stablenames are basically wrappers around
primops, so i'm unsure if those should stay or go.</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr">On Tue, Oct 30, 2018 at 9:40 AM Daniel Cartwright
<<a href="mailto:chessai1996@gmail.com" target="_blank">chessai1996@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">I agree with those.</div>
<br>
<div class="gmail_quote">
<div dir="ltr">On Tue, Oct 30, 2018 at 9:35 AM Andrew Martin
<<a href="mailto:andrew.thaddeus@gmail.com" target="_blank">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">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" target="_blank">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">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">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">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">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>
<br clear="all">
<div><br>
</div>
-- <br>
<div dir="ltr" class="m_4818096442545776509m_2484095845074977511m_3357338627103819532m_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_4818096442545776509m_2484095845074977511m_3357338627103819532m_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_4818096442545776509m_2484095845074977511m_3357338627103819532m_5728837890627266443gmail_signature" data-smartmail="gmail_signature">-Andrew Thaddeus
Martin</div>
</blockquote>
</div>
<br clear="all">
<div><br>
</div>
-- <br>
<div dir="ltr" class="m_4818096442545776509m_2484095845074977511m_3357338627103819532gmail_signature" data-smartmail="gmail_signature">-Andrew Thaddeus Martin</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>
</blockquote>
</div>
<br>
<fieldset class="m_4818096442545776509mimeAttachmentHeader"></fieldset>
<pre class="m_4818096442545776509moz-quote-pre">_______________________________________________
Libraries mailing list
<a class="m_4818096442545776509moz-txt-link-abbreviated" href="mailto:Libraries@haskell.org" target="_blank">Libraries@haskell.org</a>
<a class="m_4818096442545776509moz-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>