I think this would raise the same objection that Herbert raised before,
All I see happening is that this breaks libraries downstream.
Post by Daniel CartwrightData.Unique could probably be split off.
A few modules that depend on the event manager might have to be split
off (e.g. System.Timeout)
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.
Weak ptrs and Stablenames are basically wrappers around primops, so
i'm unsure if those should stay or go.
On Tue, Oct 30, 2018 at 9:40 AM Daniel Cartwright
I agree with those.
On Tue, Oct 30, 2018 at 9:35 AM Andrew Martin
* base: everything not removed by the libraries below
* concurrency: all Control.Concurrent.* modules (depends on base)
* foreign: all Foreign.* modules (depends on base)
* event-manager: all GHC.IO.* modules, System.Timeout (depends
on base, foreign, concurrency)
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.
On Tue, Oct 30, 2018 at 8:54 AM Andrew Martin
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.
On Tue, Oct 30, 2018 at 8:47 AM Andrew Martin
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.
On Tue, Oct 30, 2018 at 8:42 AM Andrew Martin
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
On 2018-10-30 at 08:04:59 -0400, Andrew Martin
Post by Andrew MartinHere's an idea for this I had last night.
It's narrowly scoped, but I think
Post by Andrew Martinit moves us a tiny bit in the right
direction. We could move Text.Printf
Post by Andrew Martinout of base and into its own library. This
doesn't really belong in base.
Post by Andrew MartinThe interface it provides it somewhat
opinionated, and it's not even
Post by Andrew Martintype-safe. The new library could be named
`printf` and could live under the
Post by Andrew Martinhaskell 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
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
--
-Andrew Thaddeus Martin
--
-Andrew Thaddeus Martin
--
-Andrew Thaddeus Martin
--
-Andrew Thaddeus Martin
_______________________________________________
Libraries mailing list
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries