GHC: Ticket Query
http://ghc.haskell.org/trac/ghc/query?status=closed&component=libraries%2Fbase&milestone=Not+GHC&group=resolution&order=priority
The Glasgow Haskell Compileren-USGHChttp://ghc.haskell.org/trac/ghc/chrome/site/ghc_logo.png
http://ghc.haskell.org/trac/ghc/query?status=closed&component=libraries%2Fbase&milestone=Not+GHC&group=resolution&order=priority
Trac 1.0.1
http://ghc.haskell.org/trac/ghc/ticket/974
http://ghc.haskell.org/trac/ghc/ticket/974#974: Add partitionEithers, lefts, rights to Data.EitherMon, 30 Oct 2006 13:34:40 GMTguest<p>
This proposal would add basic functionality to <tt>Either</tt> similar to that for <tt>Maybe</tt>. The <tt>splitEithers</tt> function of type <tt>[Either a b] -> ([a],[b])</tt> is unique; however, it seems to be a widely useful function.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/974#changelog
http://ghc.haskell.org/trac/ghc/ticket/994
http://ghc.haskell.org/trac/ghc/ticket/994#994: add 'unsafeCoerce' to a standard location in the hierarchical librariesFri, 10 Nov 2006 11:46:30 GMTmalcolm.wallace@…<p>
Currently, all implementations provide either the 'unsafeCoerce' or 'unsafeCoerce#' functions, but they live in implementation-specific locations.
</p>
<p>
This proposal is to adopt the Haskell'98-compatible name 'unsafeCoerce', and to add it to the standard base library package.
Suggested location: Data.Function.Unsafe?
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/994#changelog
http://ghc.haskell.org/trac/ghc/ticket/1126
http://ghc.haskell.org/trac/ghc/ticket/1126#1126: Add Data.String, containing IsString(fromString), to baseTue, 30 Jan 2007 13:48:38 GMTigloo<p>
Proposal to create a new module Data.String, containing IsString(fromString), to the base package. This would be used by the overloaded strings extension (-foverloaded-strings in GHC).
</p>
<p>
Deadline: 28 Feb 2007
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/1126#changelog
http://ghc.haskell.org/trac/ghc/ticket/1189
http://ghc.haskell.org/trac/ghc/ticket/1189#1189: Add First and Last wrappers around Maybe to Data.MonoidSun, 04 Mar 2007 08:59:09 GMTjyasskin<p>
First and Last <tt>mappend</tt> to the first and last non-Nothing elements of the input. These instances seem to fit with the other simple instances in this file and are useful, for example, to turn foldMap into findFirst or findLast, or to get a really trivial Writer monad.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/1189#changelog
http://ghc.haskell.org/trac/ghc/ticket/1191
http://ghc.haskell.org/trac/ghc/ticket/1191#1191: Proposal: Add ioeGetLocation, ioeSetLocation to System/IO/Error.hsSun, 04 Mar 2007 13:07:08 GMTigloo<p>
This is a proposal to add ioeGetLocation and ioeSetLocation to System/IO/Error.hs.
</p>
<p>
The functions are visible only to GHC and hugs; nhc is already missing some of this family of functions.
</p>
<p>
Deadline: About a week after discussion stops.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/1191#changelog
http://ghc.haskell.org/trac/ghc/ticket/1460
http://ghc.haskell.org/trac/ghc/ticket/1460#1460: Problem with Monoid instance of Data.MapMon, 25 Jun 2007 17:56:10 GMTahey@…<p>
See..
</p>
<p>
<a class="ext-link" href="http://www.haskell.org/pipermail/libraries/2007-May/007491.html"><span class="icon"></span>http://www.haskell.org/pipermail/libraries/2007-May/007491.html</a>
</p>
<p>
Data.Map Monoid instance is currently..
</p>
<pre class="wiki">instance (Ord k) => Monoid (Map k v) where
mempty = empty
mappend = union
mconcat = unions
</pre><p>
..but probably should be..
</p>
<pre class="wiki">instance (Ord k, Monoid v) => Monoid (Map k v) where
mempty = empty
mappend map0 map1 = unionWith mappend map0 map1
mconcat maps = foldr (unionWith mappend) empty maps
</pre><p>
Adrian Hey
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/1460#changelog
http://ghc.haskell.org/trac/ghc/ticket/1464
http://ghc.haskell.org/trac/ghc/ticket/1464#1464: Proposal: add dropPrefix to Data.ListWed, 27 Jun 2007 01:22:30 GMTigloo<p>
I seem to have a copy of this function in everything I write sooner or later, so I'd like to propose its addition to Data.List. It strips a prefix from a list and, if successful, returns the tail. I often use it with pattern guards:
</p>
<pre class="wiki">foo :: String -> IO ()
foo x
| Just y <- dropPrefix "foo=" = putStrLn ("foo is " ++ show y)
foo _ = putStrLn "Unknown"
</pre><p>
but you can of course achieve the same by using case etc.
</p>
<p>
Let's try 11 July for a discussion deadline.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/1464#changelog
http://ghc.haskell.org/trac/ghc/ticket/1535
http://ghc.haskell.org/trac/ghc/ticket/1535#1535: Proposal: expose the drive functions in the filepath packageSat, 14 Jul 2007 12:36:26 GMTigloo<p>
This comes out of <a class="closed ticket" href="http://ghc.haskell.org/trac/ghc/ticket/1490" title="bug: Install with Cabal broken on Windows (closed: fixed)">#1490</a>, where, in createDirectoryIfMissing, we use stat to determine if a directory exists.
</p>
<p>
(I don't think catching an exception is a possibility in this case, as mkdir returns EEXIST if "pathname already exists (not necessarily as a directory)", so we can't distinguish between the directory already existing and a file existing with the name that we want. Short of doing something ugly like trying to make (path ++ "/.") and seeing if we get ENOTDIR, anyway).
</p>
<p>
The problem is that mingw's stat succeeds for C:\ and C:\foo but fails for C: and C:\foo\. The current code strips a trailing \ before calling stat, and thus fails if asked to create C:\ (which we always do if "make parents" is true, and of course this path could be given explicitly by a user).
</p>
<p>
What we want is something like
</p>
<pre class="wiki">if isDrive x
then addTrailingPathSeparator x
else dropTrailingPathSeparator x
</pre><p>
except filepath currently doesn't export isDrive, for reasons I'm not entirely clear on.
</p>
<p>
Thus I propose exposing the *Drive functions from the filepath package. The patch, which I will attach, is rather trivial as the code is already written, tested etc, just not exposed.
</p>
<p>
Let's try until 21 July for a discussion period.
</p>
<p>
Please try to accompany any objections with a (clean) alternative solution to the original problem.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/1535#changelog
http://ghc.haskell.org/trac/ghc/ticket/1566
http://ghc.haskell.org/trac/ghc/ticket/1566#1566: Move the throwErrnoPath* functions from unix:System.Posix.Error to base:Foreign.C.ErrorSun, 29 Jul 2007 12:06:05 GMTigloo<p>
Currently, unix:System.Posix.Error has a number of throwErrnoPath* functions which are entirely portable, but they are not available on Windows due to being in the unix package.
</p>
<p>
In the thread beginning <a class="ext-link" href="http://www.haskell.org/pipermail/libraries/2007-July/007793.html"><span class="icon"></span>http://www.haskell.org/pipermail/libraries/2007-July/007793.html</a> Simon Marlow writes:
</p>
<pre class="wiki">When I needed to add some error-related functionality for the POSIX
library, I didn't want to add extra stuff to Foreign.C.Error beyond what
was specified in the FFI spec, so I added System.Posix.Error instead.
This was just conservative; we could probably add throwErrnoPath and
friends to Foreign.C.Error (with the usual proposal process).
</pre><p>
I propose that these functions are moved to base:Foreign.C.Error. They would still be re-exported by unix:System.Posix.Error to minimise breakage.
</p>
<p>
Suggested deadline: Sun 12 August 2007.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/1566#changelog
http://ghc.haskell.org/trac/ghc/ticket/1568
http://ghc.haskell.org/trac/ghc/ticket/1568#1568: Proposal: Move System.Posix.Signals to the unix packageSun, 29 Jul 2007 22:10:03 GMTigloo<p>
As suggested in
<a class="ext-link" href="http://hackage.haskell.org/trac/ghc/ticket/1190"><span class="icon"></span>http://hackage.haskell.org/trac/ghc/ticket/1190</a>
I propose that the System.Posix.Signals module is moved to the UNIX package.
Currently, on Windows, it is an empty module.
</p>
<p>
Suggested deadline: 12 August 2007.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/1568#changelog
http://ghc.haskell.org/trac/ghc/ticket/1611
http://ghc.haskell.org/trac/ghc/ticket/1611#1611: Data.Map, Data.IntMap documentationSat, 11 Aug 2007 02:36:57 GMTguest<p>
Improved, fixed documentation for Data.Map, Data.IntMap. Moved time complexity Big-O values to the end of function descriptions. Added examples.
</p>
<p>
For the initial review I submitted only changes for Data.Map. I'll update IntMap for the final review.
</p>
<p>
Deadline - August 7, 2007 (2 weeks).
Don't worry if I don't submit the changes on the deadline. I'm frequently late with these.
</p>
<p>
Andriy
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/1611#changelog
http://ghc.haskell.org/trac/ghc/ticket/1773
http://ghc.haskell.org/trac/ghc/ticket/1773#1773: Add Compositor class as superclass of Arrow, in Control.CompositorSat, 13 Oct 2007 08:01:15 GMTguest<p>
The Compositor class has two members:
</p>
<pre class="wiki">class Compositor comp where
identity :: comp a a
(>>>) :: comp a b -> comp b c -> comp a c
</pre><p>
with the obvious monoid. A number of useful types are Compositors but not Arrows.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/1773#changelog
http://ghc.haskell.org/trac/ghc/ticket/1841
http://ghc.haskell.org/trac/ghc/ticket/1841#1841: Data.Typeable: Instances of basic types don't provide qualified strings to mkTyConWed, 07 Nov 2007 02:00:54 GMTguest<p>
The documentation of Data.Typeable.mkTyCon reasonably states that the name of the type constructor provided to mkTyCon "should be unique in the program, so it might be wise to use the fully qualified name".
</p>
<p>
When automatically generating Typeable instances through "deriving", the aforementioned advice seems to be followed. However, all the instances of basic types defined in Data.Typeable don't provide qualified constructor names to mkTyCon.
</p>
<p>
The case of Tuple constructors is specially strange, since the constructor string lacks the surrounding parentheses (e.g "," "<sub>" ... ).
</sub></p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/1841#changelog
http://ghc.haskell.org/trac/ghc/ticket/2143
http://ghc.haskell.org/trac/ghc/ticket/2143#2143: Yhc's sort is faster than GHC'sSun, 09 Mar 2008 13:34:48 GMTNeilMitchell<p>
The sort code in the Yhc libraries is faster than GHC. In some cases its asymptotically better. Some benchmarks have shown a doubling in performance. I know why this is, but will need to make sure the code is as good as it can be, check all the benchmarks agree etc.
</p>
<p>
Original work by Ian: <a class="ext-link" href="http://www.haskell.org/pipermail/glasgow-haskell-users/2002-May/003376.html"><span class="icon"></span>http://www.haskell.org/pipermail/glasgow-haskell-users/2002-May/003376.html</a>
</p>
<p>
I will track this down and aim for a libraries proposal in a month or so.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/2143#changelog
http://ghc.haskell.org/trac/ghc/ticket/2254
http://ghc.haskell.org/trac/ghc/ticket/2254#2254: have Control.Arrow re-export (>>>) and (<<<)Wed, 30 Apr 2008 23:50:40 GMTross<p>
<a class="closed ticket" href="http://ghc.haskell.org/trac/ghc/ticket/1773" title="proposal: Add Compositor class as superclass of Arrow, in Control.Compositor (closed: fixed)">#1773</a> split the Arrow class, making (>>>) and (<<<) functions in Control.Category. This breaks programs that use Control.Arrow.
</p>
<p>
To avoid some of the breakage, the proposal is that Control.Arrow should re-export (>>>) and (<<<), imported from Control.Category.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/2254#changelog
http://ghc.haskell.org/trac/ghc/ticket/2419
http://ghc.haskell.org/trac/ghc/ticket/2419#2419: Extensible exceptionsFri, 04 Jul 2008 13:25:23 GMTigloo<p>
This is a proposal to replace the current exception mechanism in the
base library with extensible exceptions.
</p>
<p>
It also reimplements the existing exceptions on top of extensible
exceptions, for legacy applications.
</p>
<p>
Proposed deadline: 25th July.
</p>
<h1 id="Whatareextensibleexceptions">What are extensible exceptions?</h1>
<p>
Simon's extensible extensions paper is very easy to read, and describes
the problems and proposed solution very well:
</p>
<blockquote>
<p>
<a class="ext-link" href="http://www.haskell.org/~simonmar/papers/ext-exceptions.pdf"><span class="icon"></span>http://www.haskell.org/~simonmar/papers/ext-exceptions.pdf</a>
</p>
</blockquote>
<p>
I won't try to reproduce everything the paper says here, but here is the
list of what we want extracted from it:
</p>
<ul><li>A hierarchy of exception types, such that a particular catch can choose to catch only exceptions that belong to a particular subclass and re-throw all others.
</li><li>A way to add new exception types at any point in the hierarchy from library or program code.
</li><li>The boilerplate code required to add a new type to the exception hierarchy should be minimal.
</li><li>Exceptions should be thrown and caught using the same primitives, regardless of the types involved.
</li></ul><p>
I heartily recommend having a read through of the paper.
</p>
<h1 id="Patchesandexamples">Patches and examples</h1>
<p>
The patches are here:
</p>
<blockquote>
<p>
<a class="ext-link" href="http://darcs.haskell.org/ext-excep/"><span class="icon"></span>http://darcs.haskell.org/ext-excep/</a>
</p>
</blockquote>
<p>
along with <tt>Examples.hs</tt>, which gives some examples of using it.
</p>
<p>
The patches aren't polished; if this proposal is accepted then there is
some more work to do, moving things around inside the base package to
simplify the dependencies, and to maximise the amount of code that can
be shared between all the impls. There's also some GHC-specific fiddling
to be done, to make GHC.TopHandler use the new exceptions. This can all
be done without further library proposals, though.
</p>
<p>
Also, currently it derives Data.Typeable, which is unportable, but we
can easily work around that. The only extensions that I don't think that
we can do without are ExistentialQuantification and Rank2Types.
DeriveDataTypeable makes the implementation easier, and
DeriveDataTypeable and PatternSignatures make using it easier.
</p>
<h1 id="Libraryfunctiondifferences">Library function differences</h1>
<p>
As far as the library functions are concerned, here are the main
differences:
</p>
<p>
The old and new types for catch are:
</p>
<pre class="wiki"> Old: catch :: IO a -> (Exception -> IO a) -> IO a
New: catch :: Exception e => IO a -> (e -> IO a) -> IO a
</pre><p>
i.e. catch can now catch any type of exception; we don't have to force
all the different types of extension into one fixed datatype.
</p>
<p>
All the other exception functions are similarly changed to handle any
type of extension, e.g. we now have
</p>
<pre class="wiki"> try :: Exception e => IO a -> IO (Either e a)
</pre><p>
Now that you can write handlers for different exception types, you might
want to catch multiple different types at the same point. You can use
catches for this. For example, the OldException module needs to catch
all the new exception types and put them into the old Exception type, so
that the legacy handler can be run on them. It looks like this:
</p>
<pre class="wiki"> catch :: IO a -> (Exception -> IO a) -> IO a
catch io handler =
io `catches`
[Handler (\e -> handler e),
Handler (\exc -> handler (ArithException exc)),
Handler (\exc -> handler (ArrayException exc)),
...]
</pre><p>
where the first Handler deals with exceptions of type Exception, the
second those of type ArithException, and so on.
</p>
<p>
If you want to catch all exceptions, e.g. if you want to cleanup and
rethrow the exception, or just print the exception at the top-level, you
can use the new function catchAny:
</p>
<pre class="wiki"> catchAny :: IO a -> (forall e . Exception e => e -> IO a) -> IO a
</pre><p>
You can happily write
</p>
<pre class="wiki"> `catchAny` \e -> print e
</pre><p>
where
</p>
<pre class="wiki"> `catch` \e -> print e
</pre><p>
would give you an ambiguous type variable error.
</p>
<p>
There's also
</p>
<pre class="wiki"> ignoreExceptions :: IO () -> IO ()
</pre><p>
which can be used instead of try for things like
</p>
<pre class="wiki"> ignoreExceptions (hClose h)
</pre><p>
(where we don't look at the result, so the exception type would be
ambiguous if we used try). (I'm not sure if this is the best name for
this function).
</p>
<p>
All the build failures I've seen with the new exceptions library have
been cases where you need to change a "catch" to "catchAny", "try" to
"ignoreExceptions", or occassionally a different function, e.g.
"bracket" or "handle", is used to handle any extension, so adding a type
signature involving the SomeException type solves the problem.
</p>
<p>
The old interface is available in Control.OldException. Currently it
doesn't catch exceptions that don't fit into the old Exception type; we
could catch them, show them and treat them as user errors, but then the
exception has changed if it gets rethrown.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/2419#changelog
http://ghc.haskell.org/trac/ghc/ticket/2517
http://ghc.haskell.org/trac/ghc/ticket/2517#2517: remove 'pure' method from Arrow classFri, 15 Aug 2008 12:43:05 GMTross<p>
The Arrow class as originally defined by John Hughes had methods <tt>arr</tt>, <tt>>>></tt> and <tt>first</tt>. (<tt>>>></tt> has since been moved by <a class="closed ticket" href="http://ghc.haskell.org/trac/ghc/ticket/1773" title="proposal: Add Compositor class as superclass of Arrow, in Control.Compositor (closed: fixed)">#1773</a> to the <tt>Category</tt> class.) When writing the <em>Fun of Programming</em> paper, I added <tt>pure</tt> as a synonym for <tt>arr</tt>, because Richard Bird preferred it. However this name hasn't caught on, and now it clashes with a method in the <tt>Applicative</tt> class, so I propose to remove it.
</p>
<p>
The usual practice would be to deprecate the name in one release and remove it in the following one, but I propose to remove it in one step because
</p>
<ul><li>no-one seems to be using this name, and
</li><li>backward compatibility has been broken anyway by the Category split (<a class="closed ticket" href="http://ghc.haskell.org/trac/ghc/ticket/1773" title="proposal: Add Compositor class as superclass of Arrow, in Control.Compositor (closed: fixed)">#1773</a>).
</li></ul><p>
The only people who will be bitten by the change are those who import <tt>Control.Arrow</tt> hiding <tt>pure</tt>, and they wouldn't be warned by deprecation.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/2517#changelog
http://ghc.haskell.org/trac/ghc/ticket/2532
http://ghc.haskell.org/trac/ghc/ticket/2532#2532: Add Typeable instance to Data.UniqueFri, 22 Aug 2008 01:23:55 GMTjapple<p>
Data.Unique should be able to be used with Data.Dynamic.
</p>
<p>
Timescale for consideration: Until September 7, 2008.
</p>
<p>
The <a class="ext-link" href="http://www.haskell.org/haskellwiki/Library_submissions"><span class="icon"></span>library submission procedures</a> say
</p>
<blockquote>
<p>
If the changes update Haddoc [sic] documentation, also attach the resulting Haddock-generated pages.
</p>
</blockquote>
<p>
Haddock fails on the file because of existing CPP commands.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/2532#changelog
http://ghc.haskell.org/trac/ghc/ticket/2533
http://ghc.haskell.org/trac/ghc/ticket/2533#2533: Generic functions that take integral arguments should work the same way as their prelude counterpartsFri, 22 Aug 2008 02:40:06 GMTjapple<p>
The Prelude functions drop, take, and splitAt are unfailing (never call error). This patch changes the Data.List generic versions to behave the same way. At present, they call error on negative arguments.
</p>
<p>
quickCheck (\x n -> take n x == genericTake n x)
quickCheck (\x n -> drop n x == genericDrop n x)
quickCheck (\x n -> splitAt n x == genericSplitAt n x)
</p>
<p>
The library submission procedures say
</p>
<blockquote>
<p>
If the changes update Haddoc [sic] documentation, also attach the resulting Haddock-generated pages.
</p>
</blockquote>
<p>
Haddock fails on the file because of existing CPP commands.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/2533#changelog
http://ghc.haskell.org/trac/ghc/ticket/3292
http://ghc.haskell.org/trac/ghc/ticket/3292#3292: Add an 'ignore' function to Control.MonadWed, 10 Jun 2009 19:01:35 GMTguest<p>
See <a class="ext-link" href="http://www.haskell.org/pipermail/libraries/2009-June/thread.html#11880"><span class="icon"></span>http://www.haskell.org/pipermail/libraries/2009-June/thread.html#11880</a>
</p>
<p>
In short, add a 'ignore :: m a -> m ()' function to Control.Monad. This lets us do things like 'forkIO $ ignore stuff', as opposed to throwing around all sorts of '>> return ()'.
</p>
<p>
This function could be widely used by many libraries & apps, and has been repeatedly invented and suggested (see the thread). So far no one has said a word against it.
</p>
<pre class="wiki">- -- | Convenience function. This is particularly good for 'forkIO' and 'forM_',
-- as they demand return types of 'IO ()', but most interesting IO functions
-- don't return void. So one can wrap them with 'ignore' (essentially a call to 'unit').
ignore :: Functor f => f a -> f ()
ignore = fmap (const ())
</pre>Resultshttp://ghc.haskell.org/trac/ghc/ticket/3292#changelog
http://ghc.haskell.org/trac/ghc/ticket/3298
http://ghc.haskell.org/trac/ghc/ticket/3298#3298: Add swap to Data.TupleFri, 12 Jun 2009 21:07:58 GMTr6<p>
I think swap is a widely accepted name for the function. There is only the question of strictness. I suggest swap for the lazy version and swap' for the strict version
</p>
<p>
swap ~(a,b) = (b,a)
</p>
<p>
swap' (a,b) = (b,a)
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/3298#changelog
http://ghc.haskell.org/trac/ghc/ticket/3335
http://ghc.haskell.org/trac/ghc/ticket/3335#3335: make some Applicative functions into methods, and split off Data.FunctorMon, 29 Jun 2009 12:42:58 GMTross<p>
The following functions
</p>
<pre class="wiki">(<$) :: Functor f => a -> f b -> f a
(*>) :: Applicative f => f a -> f b -> f b
(<*) :: Applicative f => f a -> f b -> f a
some :: Alternative f => f a -> f [a]
many :: Alternative f => f a -> f [a]
</pre><p>
are moved into the corresponding classes, with the existing implementations as default definitions. This gives people creating instances the option of defining specialized implementations of these functions, though they should be equivalent to the default definitions.
</p>
<p>
Although (<$) is now a method of the Functor class, it is hidden in the re-export by the Prelude, Control.Monad and Monad. The new module Data.Functor exposes the full class, plus the function (<$>). These are also re-exported by Control.Applicative.
</p>
<p>
Discussion on libraries@… to 20th July 2009.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/3335#changelog
http://ghc.haskell.org/trac/ghc/ticket/3337
http://ghc.haskell.org/trac/ghc/ticket/3337#3337: Proposal: expose Unicode and newline translation from System.IOTue, 30 Jun 2009 11:57:07 GMTsimonmar<p>
For the proposed new additions, see:
</p>
<ul><li><a class="ext-link" href="http://www.haskell.org/~simonmar/base/System-IO.html#23"><span class="icon"></span>System.IO (Unicode encoding/decoding)</a>
</li><li><a class="ext-link" href="http://www.haskell.org/~simonmar/base/System-IO.html#25"><span class="icon"></span>System.IO (Newline conversion)</a>
</li></ul><p>
Patch, and Haddocks for the base package, attached.
</p>
<p>
Discussion period: 2 weeks (14 July).
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/3337#changelog
http://ghc.haskell.org/trac/ghc/ticket/3381
http://ghc.haskell.org/trac/ghc/ticket/3381#3381: PROPOSAL: Remove Control.OldExceptionSat, 18 Jul 2009 12:49:47 GMTigloo<p>
We included <tt>Control.OldException</tt> in base to help people trying to remain compatible with both GHC 6.8 and GHC 6.10. However, my impression is that most (all?) people who wanted compatibility used the <tt>extensible-exceptions</tt> package instead.
</p>
<p>
I propose that we remove <tt>Control.OldException</tt> for GHC 6.12.
</p>
<p>
If anyone does want <tt>Control.OldException</tt>, then it could be provided by a separate package.
</p>
<p>
Deadline: 2nd August (2 weeks).
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/3381#changelog
http://ghc.haskell.org/trac/ghc/ticket/3393
http://ghc.haskell.org/trac/ghc/ticket/3393#3393: Add openFileTemplate, openBinaryFileTemplate to System.IOFri, 24 Jul 2009 16:43:00 GMTigloo<p>
In <tt>System.IO</tt>, <tt>openTempFile</tt> and <tt>openBinaryTempFile</tt> mask the file permissions of the file they create with 0o600. However, we would like to use it for implementing things like <tt>writeFileAtomic</tt>, in which case we want the default file permissions to be used.
</p>
<p>
I propose that we add <tt>openFileTemplate</tt> and <tt>openBinaryFileTemplate</tt> functions, which use the default permissions.
</p>
<p>
Deadline: 8th August (2 weeks).
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/3393#changelog
http://ghc.haskell.org/trac/ghc/ticket/4095
http://ghc.haskell.org/trac/ghc/ticket/4095#4095: add Applicative instance for EitherTue, 25 May 2010 12:37:24 GMTross<p>
The proposal is to add this instance to Control.Applicative:
</p>
<pre class="wiki">instance Applicative (Either e) where
pure = Right
Left e <*> _ = Left e
Right f <*> r = fmap f r
</pre><p>
This is not the only possible instance for Either, but this one is compatible with the usual Monad instance.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/4095#changelog
http://ghc.haskell.org/trac/ghc/ticket/4257
http://ghc.haskell.org/trac/ghc/ticket/4257#4257: Add strict versions of insertWith and insertWithKey to IntMapSun, 15 Aug 2010 11:32:44 GMTtibbe<p>
A strict version of <tt>insertWith</tt> is needed when the value stored in the <tt>IntMap</tt> is e.g. an Int or some other value that's more efficiently stored in WHNF.
</p>
<p>
Deadline: 2 weeks
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/4257#changelog
http://ghc.haskell.org/trac/ghc/ticket/4282
http://ghc.haskell.org/trac/ghc/ticket/4282#4282: Proposal: make Data.List.intersperse and intercalate less strictWed, 01 Sep 2010 19:50:29 GMTdaniel.is.fischer<p>
It is proposed that <tt>intersperse</tt> and <tt>intercalate</tt> be changed to be less strict.
</p>
<p>
Period of discussion: Two weeks, until 30 Sep. 2010.
</p>
<p>
A patch is attached to this ticket. See also the <a class="ext-link" href="http://www.haskell.org/pipermail/libraries/2010-September/014293.html"><span class="icon"></span>mailing list discussion thread</a>.
</p>
<p>
This change is in keeping with the spirit of the Haskell98 List module, which is for list functions to be as lazy as possible (unless there are good reasons otherwise). There are use cases where the current overly-strict versions are problematic. In addition, the more lazy versions are slightly more efficient.
</p>
<p>
current implementation:
</p>
<pre class="wiki">intersperse :: a -> [a] -> [a]
intersperse _ [] = []
intersperse _ [x] = [x]
intersperse sep (x:xs) = x : sep : intersperse sep xs
</pre><p>
current strictness properties:
</p>
<pre class="wiki">intersperse _ _|_ = _|_
intersperse _ (x :_|_) = _|_
intersperse sep (x:y:_|_) = x : sep : _|_
</pre><p>
proposed implementation:
</p>
<pre class="wiki">intersperse :: a -> [a] -> [a]
intersperse _ [] = []
intersperse sep (x:xs) = x : go xs
where
go [] = []
go (y:ys) = sep : y : go ys
</pre><p>
strictness properties after change:
</p>
<pre class="wiki">intersperse _ _|_ = _|_
intersperse _ (x:_|_) = x : _|_
intersperse sep (x:y:_|_) = x : sep : y : _|_
</pre><p>
current and proposed implementation of <tt>intercalate</tt>:
</p>
<pre class="wiki">intercalate :: [a] -> [[a]] -> [a]
intercalate sep xss = concat (intersperse sep xss)
</pre><p>
current strictness properties:
</p>
<pre class="wiki">intercalate _ _|_ = _|_
intercalate _ (xs:_|_) = _|_
intercalate sep (xs:ys:_|_) = xs ++ sep ++ _|_
</pre><p>
strictness properties after proposed change to <tt>intersperse</tt>:
</p>
<pre class="wiki">intercalate _ _|_ = _|_
intercalate _ (xs:_|_) = xs ++ _|_
intercalate sep (xs:ys:_|_) = xs ++ sep ++ ys ++ _|_
</pre>Resultshttp://ghc.haskell.org/trac/ghc/ticket/4282#changelog
http://ghc.haskell.org/trac/ghc/ticket/4323
http://ghc.haskell.org/trac/ghc/ticket/4323#4323: Change implementation of intersectByThu, 16 Sep 2010 15:12:29 GMTdaniel.is.fischer<p>
Currently, intersectBy eq xs [] takes O(length xs) time to calculate and returns _|_ on (x : _|_). The proposed change,
</p>
<pre class="wiki">intersectBy :: (a -> a -> Bool) -> [a] -> [a] -> [a]
intersectBy _ [] _ = []
intersectBy _ _ [] = []
intersectBy eq xs ys = [x | x <- xs, any (eq x) ys]
</pre><p>
makes this an O(1) operation and returns [] for infinite or partial (... : _|_) lists xs. The first equation is necessary to retain intersectBy _ [] _|_ = [].
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/4323#changelog
http://ghc.haskell.org/trac/ghc/ticket/4334
http://ghc.haskell.org/trac/ghc/ticket/4334#4334: Make lines stricter to fix space leakFri, 24 Sep 2010 19:01:39 GMTdaniel.is.fischer<p>
I propose changing the implementation of lines to be stricter.
</p>
<p>
The current implementation causes (in GHC) a space leak, so it is better to sacrifice a little laziness to fix that leak.
</p>
<p>
Period of discussion: Three weeks, until 15<sup>th</sup> October (because of ICFP).
</p>
<p>
Current implementation:
</p>
<pre class="wiki">lines :: String -> [String]
lines "" = []
lines s = let (l, s') = break (== '\n') s
in l : case s' of
[] -> []
(_:s'') -> lines s''
</pre><p>
The relevant part of the core showing the leak (-O or -O2, similar for -O0 but without inlining <tt>break</tt>):
</p>
<pre class="wiki"> let {
ds1_sjM :: ([GHC.Types.Char], [GHC.Types.Char])
LclId
[Str: DmdType]
ds1_sjM =
case GHC.List.$wbreak @ GHC.Types.Char lvl1_rjW wild_B1
of _ { (# ww1_aj3, ww2_aj4 #) ->
(ww1_aj3, ww2_aj4)
} } in
GHC.Types.:
@ GHC.Base.String
(case ds1_sjM of _ { (l_aif, _) -> l_aif })
(case ds1_sjM of _ { (_, s'_aih) ->
case s'_aih of _ {
[] -> GHC.Types.[] @ GHC.Base.String;
: _ s''_adj -> Lines.lines s''_adj
}
})
</pre><p>
<tt>ds1_sjM</tt> keeps a reference to the first line until the second is demanded, preventing it from being GCed.
</p>
<p>
Current strictness properties:
</p>
<pre class="wiki">lines _|_ = _|_
lines (_|_:_|_) = _|_ : _|_
</pre><p>
Proposed implementation:
</p>
<pre class="wiki">lines :: String -> [String]
lines "" = []
lines s = case break (== '\n') s of
(l, s') -> l : case s' of
[] -> []
(_:s'') -> lines s''
</pre><p>
Due to the pattern matching on <tt>break</tt>'s result, the pair is never considered a single entity, allowing the first line to be GCed before the second is demanded.
</p>
<p>
Strictness properties of the proposed implementation:
</p>
<pre class="wiki">lines _|_ = _|_
lines (_|_:_|_) = _|_
</pre><p>
Generally, a <tt>_|_</tt> as the first <tt>Char</tt> of a line would produce a <tt>_|_</tt> instead of the <tt>_|_ : _|_</tt> which the current implementation produces. <tt>_|_</tt> in any other place would be treated identically.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/4334#changelog
http://ghc.haskell.org/trac/ghc/ticket/4336
http://ghc.haskell.org/trac/ghc/ticket/4336#4336: Better implementation of recip for Ratio aFri, 24 Sep 2010 21:59:28 GMTdaniel.is.fischer<p>
Proposal: A better implementation of <tt>recip</tt> for <tt>Ratio a</tt>
</p>
<p>
Discussion period: Three weeks, until 15<sup>th</sup> October 2010
</p>
<p>
Currently, in GHC.Real,
</p>
<pre class="wiki"> recip (x:%y) = y % x
</pre><p>
calculates the <tt>gcd</tt> of numerator and denominator, although they are known to
be coprime (unless the constructor has been directly [ab]used or the value has been obtained via the broken fromRational, <a class="closed ticket" href="http://ghc.haskell.org/trac/ghc/ticket/4335" title="bug: fromRational broken for Ratio a (closed: fixed)">#4335</a>).
Since integer division is slow, that is an expensive operation.
I propose changing <tt>recip</tt> to
</p>
<pre class="wiki"> recip (0:%_) = error "Ratio.%: zero denominator"
recip (x:%y)
| x < 0 = negate y :% negate x
| otherwise = y :% x
</pre><p>
For all legitimate values of <tt>Ratio a</tt> with a reasonable <tt>Integral a</tt>, both implementations yield the same result.
</p>
<p>
The attached programme shows that for Rationals with large numerators and denominators, the speedup is huge:
</p>
<pre class="wiki">$ ./benchRecip 40000 0
4011866
id took 1.420088s
4011833
frecip took 1.220077s
4011833
recip took 137.500593s
</pre><p>
(<tt>id</tt> takes longer than <tt>frecip</tt> because it incudes the time to build the <tt>fibQuots</tt> list).
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/4336#changelog
http://ghc.haskell.org/trac/ghc/ticket/4337
http://ghc.haskell.org/trac/ghc/ticket/4337#4337: Better power for RationalSat, 25 Sep 2010 00:32:07 GMTdaniel.is.fischer<p>
Proposal: A better implementation of powers for Rational
</p>
<p>
Discussion period: Three weeks, until 16<sup>th</sup> October 2010
</p>
<p>
Exponentiation by repeated squaring, as is used in <tt>(^)</tt> is bad for <tt>Rational</tt> since on each multiplication a <tt>gcd</tt> has to be calculated.
</p>
<p>
For well-formed <tt>Rational</tt>s, the numerator and denominator are known to be coprime, hence all powers of the numerator and denominator are also coprime.
</p>
<p>
To avoid superfluous work, I propose a special power function for <tt>Rational</tt>s and a rewrite rule to replace calls to <tt>(^)</tt> for <tt>Rational</tt> bases by the special function. It might also be beneficial to export the specialised function from Data.Ratio to be used if the rule doesn't fire.
</p>
<p>
Proposed function and rule:
</p>
<pre class="wiki">ratPow :: Integral a => Rational -> a -> Rational
ratPow _ e
| e < 0 = error "Negative exponent"
ratPow _ 0 = 1 :% 1
ratPow r 1 = r
ratPow (0:%y) _ = 0 :% 1
ratPow (x:%1) e = (x^e) :% 1
ratPow (x:%y) e = (x^e) :% (y^e)
{-# RULES
"power/Rational" (^) = ratPow
#-}
</pre><p>
Like the elimination of <tt>gcd</tt> from recip (<a class="closed ticket" href="http://ghc.haskell.org/trac/ghc/ticket/4336" title="proposal: Better implementation of recip for Ratio a (closed: fixed)">#4336</a>), this would yield a great performance boost.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/4337#changelog
http://ghc.haskell.org/trac/ghc/ticket/4422
http://ghc.haskell.org/trac/ghc/ticket/4422#4422: Export String from Data.StringWed, 20 Oct 2010 20:07:22 GMTbasvandijk<h2 id="Proposals">Proposals</h2>
<p>
This ticket makes three proposals, in order of importance IMHO:
</p>
<ol><li>Export <tt>String</tt> from <tt>Data.String</tt>. Most modules in <tt>base</tt> and on Hackage of the form: <tt>Data.<type></tt> also export <tt><type></tt>. I think it's surprising and confusing that <tt>Data.String</tt> doesn't conform to this pattern.
</li><li>Unexport <tt>String</tt> from <tt>Data.Char</tt>. I feel less strongly about this one, but in general I think it is good that a symbol is exported from as few modules as possible.
</li><li>Export the <tt>String</tt> operations: <tt>lines</tt>, <tt>words</tt>, <tt>unlines</tt> and <tt>unwords</tt> from <tt>Data.String</tt>. I feel even less strongly about this one. However these are operations on <tt>String</tt>s so it makes sense to export them from <tt>Data.String</tt>. As a counter argument you could say these operations either receive or produce a <em>list</em> of <tt>String</tt>s so they only belong in <tt>Data.List</tt>.
</li></ol><p>
If we accept 3 then in the spirit of <em>export a symbol from as few modules as possible</em>, you may expect a fourth proposal: Unexport the <tt>String</tt> operations: <tt>lines</tt>, <tt>words</tt>, <tt>unlines</tt> and <tt>unwords</tt> from <tt>Data.List</tt>. However I think this will break lots of programs. I have no problem also discussing this one though.
</p>
<p>
Attached is a patch bundle with three patches that implement the three proposals. We may end up deciding to apply only a few of them.
</p>
<h2 id="Discussiondeadline">Discussion deadline</h2>
<p>
3 weeks from now: Wednesday 10 November.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/4422#changelog
http://ghc.haskell.org/trac/ghc/ticket/4455
http://ghc.haskell.org/trac/ghc/ticket/4455#4455: Add Applicative instance for STFri, 29 Oct 2010 22:42:23 GMTpumpkin<p>
ST has a Functor and a Monad instance, but no Applicative instance. This patch by Bas van Dijk adds such an instance.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/4455#changelog
http://ghc.haskell.org/trac/ghc/ticket/4502
http://ghc.haskell.org/trac/ghc/ticket/4502#4502: Add a Read instance for Data.Fixed.FixedTue, 16 Nov 2010 22:33:12 GMTigloo<p>
Add a Read instance for Data.Fixed.Fixed.
</p>
<p>
Patch and test attached; the essence is:
</p>
<pre class="wiki">readsFixed :: (HasResolution a) => ReadS (Fixed a)
readsFixed = readsSigned
where readsSigned ('-' : xs) = [ (negate x, rest)
| (x, rest) <- readsUnsigned xs ]
readsSigned xs = readsUnsigned xs
readsUnsigned xs = case span isDigit xs of
([], _) -> []
(is, xs') ->
let i = fromInteger (read is)
in case xs' of
'.' : xs'' ->
case span isDigit xs'' of
([], _) -> []
(js, xs''') ->
let j = fromInteger (read js)
l = genericLength js :: Integer
in [(i + (j / (10 ^ l)), xs''')]
_ -> [(i, xs')]
</pre><p>
Suggested deadline: 1 Dec 2010.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/4502#changelog
http://ghc.haskell.org/trac/ghc/ticket/4865
http://ghc.haskell.org/trac/ghc/ticket/4865#4865: Deprecate and remove Prelude.catch and System.IO.Error.{catch,try}Mon, 27 Dec 2010 12:33:49 GMTigloo<p>
<tt>Prelude</tt> and <tt>System.IO.Error</tt> both export an old version of <tt>catch</tt>, which only catches <tt>IOError</tt>s, and <tt>System.IO.Error</tt> additionally exports <tt>try</tt> with the same problem.
</p>
<p>
These exports are annoying for people who want to use the modern exception handling functions in <tt>Control.Exception</tt>, as you need to explicitly either import the <tt>Prelude</tt> with <tt>catch</tt> hidden, or give the module of the function you want to use.
</p>
<p>
They may also be confusing for beginners, who may not expect to have to use anything other than the <tt>catch</tt> function in the default scope to catch all exceptions.
</p>
<p>
I believe these functions are only there for historical reasons, and are old cruft that we should tidy up, so I propose that in the <tt>base</tt> package that comes with GHC 7.2 we deprecate these old functions, and in 7.4 we remove them.
</p>
<p>
Suggested deadline: 24 Jan 2011.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/4865#changelog
http://ghc.haskell.org/trac/ghc/ticket/666
http://ghc.haskell.org/trac/ghc/ticket/666#666: Collection hierarchy proposalMon, 23 Jan 2006 10:02:25 GMTjpbernardy<p>
Well, i am as user of libraries just wants consistency of using
different data structures for the same tasks. for example, i want to
have one indexing operator instead of !, !! and find. so, it's my
hope-list:
</p>
<ol><li>all collections are divided into 3-4 classes: arrays/lists, maps and sets. arrays/lists have sequential indexes in some range while maps have sparse indexes. also each class have an Updatable subclass
</li><li>collections in one class can be collected to each other with one (better universal) operator, such as:
<pre class="wiki">let list = cvt array
let tree = cvt map
</pre></li><li>collections can be converted to/from Updatable subclass with help of usual freeze/thaw operators
</li><li>all operations which are currently implemented in Data.List, Array.*, Map, Set, HashTable modules must be bound to one of these classes, with duplicates (such as !/!!) removed. now i see the following class hierarchy:
<pre class="wiki">Collection (map, size, values)
SetLike (union, diff)
Set
Map
Indexed (indexes, !)
Map
Sequential (reverse, head)
Array
List (tail)
</pre></li></ol><p>
i give in parentheses examples of operations which are supported on each level of hierarchy
</p>
<p>
this will give possibility to write datastructure-independent algorithms and easily convert data to the data type which are best for each part of the program, smthg like:
</p>
<pre class="wiki">a :: Map Int String <- read str
algorithm1 a
let b :: Hash Int String <- cvt a
algorithm2 b
c :: HashTable Int String <- thaw b
algorithm3 c
</pre>Resultshttp://ghc.haskell.org/trac/ghc/ticket/666#changelog
http://ghc.haskell.org/trac/ghc/ticket/2629
http://ghc.haskell.org/trac/ghc/ticket/2629#2629: Data.List: Replace nub; add nubOrd, nubInt, nubWithSun, 28 Sep 2008 07:00:21 GMTBart Massey<p>
Everyone always complains about nub, but nobody ever does anything about it except (map head . group . sort), which isn't lazy and isn't always faster. :-)
</p>
<p>
I've implemented a new function nubWith that takes a "stop list" as an argument and filters its target list against the stop list. I've then re-implemented nub and implemented nubOrd and nubInt in terms of nubWith: the stop list is a typeclass, so these implementations are trivial and new implementations are easily added. nubBy is left alone, since there's nothing obvious to be done about it. All of the nubs are still fully lazy.
</p>
<p>
Basic QuickCheck tests are provided, and pass.
</p>
<p>
Performance benchmarking code is provided. The performance of my nub implementation is quite comparable to that of the standard one. My nubOrd and nubInt implementations are dramatically faster, since they use a Set and IntSet respectively for the stop list. In particular, they are performant on long lists with long nubs, unlike the basic nub.
</p>
<p>
My implementation is available via git at
</p>
<blockquote>
<p>
<a class="ext-link" href="git://svcs.cs.pdx.edu/git/nub.git"><span class="icon"></span>git://svcs.cs.pdx.edu/git/nub.git</a>
</p>
</blockquote>
<p>
or can be browsed at
</p>
<blockquote>
<p>
<a class="ext-link" href="http://svcs.cs.pdx.edu/gitweb?p=nub.git;a=tree"><span class="icon"></span>http://svcs.cs.pdx.edu/gitweb?p=nub.git;a=tree</a> and has a maybe-outdated tarball at
<a class="ext-link" href="http://svcs.cs.pdx.edu/haskell/nub.tar.gz"><span class="icon"></span>http://svcs.cs.pdx.edu/haskell/nub.tar.gz</a>
</p>
</blockquote>
<p>
The Nub.hs file itself is attached to this proposal. If the proposal is accepted, I will prepare a patch against current GHC library top-of-tree, but for now it seems easier for everyone to just look at the bits in their current natural habitat.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/2629#changelog
http://ghc.haskell.org/trac/ghc/ticket/2717
http://ghc.haskell.org/trac/ghc/ticket/2717#2717: Add nubWith, nubOrdTue, 21 Oct 2008 08:52:51 GMTBart Massey<p>
This is a followup to my proposal <a class="closed ticket" href="http://ghc.haskell.org/trac/ghc/ticket/2629" title="proposal: Data.List: Replace nub; add nubOrd, nubInt, nubWith (closed: invalid)">#2629</a>, which had a much more ambitious scheme. After much discussion, it was decided to put this smaller proposal on the table.
</p>
<p>
I've implemented a new function Data.List.nubWith that takes a "stop list" and "filtering function" as an argument, and filters its target list against the stop list. I've then implemented Data.Set.nubOrd in terms of nubWith. nubBy is left alone, since there's nothing obvious to be done about it. All of the nubs are still fully lazy.
</p>
<p>
Basic QuickCheck tests have been written, and pass.
Performance benchmarking shows my nubOrd implementation to be quite comparable to that of nub in cases where the latter performs well, and dramatically faster when nub performs poorly. In particular, nubOrd can work on long lists with long nubs, unlike the basic nub, which is hopeless.
</p>
<p>
Patch against current Darcs head attached.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/2717#changelog
http://ghc.haskell.org/trac/ghc/ticket/4481
http://ghc.haskell.org/trac/ghc/ticket/4481#4481: Functor, Pointed, Applicative, MonadSun, 07 Nov 2010 10:15:25 GMTgidyn<p>
As pointed out on <a class="ext-link" href="http://stackoverflow.com/questions/1634911/can-liftm-differ-from-lifta"><span class="icon"></span>StackOverflow</a>, Functor, Pointed, Applicative and Monad all belong in a hierarchy thus:
</p>
<pre class="wiki">class Functor f where
map :: (a -> b) -> f a -> f b
class Functor f => Pointed f where
pure :: a -> f a
class Pointed f => Applicative f where
(<*>) :: f (a -> b) -> f a -> f b
(*>) :: f a -> f b -> f b
(<*) :: f a -> f b -> f a
class Applicative m => Monad m where
(>>=) :: (m a) -> (a -> m b) -> m b
(>>) :: m a -> m b -> m b
return :: a -> m a
</pre><p>
As well as eliminating much duplication (where every Applicative must also be given a Monad instance), this will make it easier to eliminate such duplication as [fmap,liftM,map,liftA], [(<*>),ap], and [concat,join].
</p>
<p>
fail does not belong in Monad; it only makes sense monadically as mzero.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/4481#changelog
http://ghc.haskell.org/trac/ghc/ticket/4535
http://ghc.haskell.org/trac/ghc/ticket/4535#4535: Add tryReadChan to ChanSat, 27 Nov 2010 00:48:13 GMTmitar<p>
Now that <tt>isEmptyChan</tt> is deprecated (<a class="closed ticket" href="http://ghc.haskell.org/trac/ghc/ticket/4154" title="bug: Deadlock in Chan module (closed: fixed)">#4154</a>) it would be useful to add <tt>tryReadChan</tt>. It seems it is possible to define it so that it does not block like <tt>isEmptyChan</tt>. This is because semantics is a bit different: <tt>tryReadChan</tt> is allowed to return <tt>Nothing</tt> also when <tt>Chan</tt> is non-empty, but it would block. Contrary, <tt>isEmptyChan</tt> is expected that it would return <tt>False</tt> only if <tt>Chan</tt> is really empty.
</p>
<p>
I have defined also two new <tt>MVar</tt> functions which helped me implementing <tt>tryReadChan</tt>: <tt>tryReadMVar</tt> and <tt>tryModifyMVar</tt>. Probably it would be useful to make them public.
</p>
<p>
Please comment. I propose three weeks for discussion.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/4535#changelog
http://ghc.haskell.org/trac/ghc/ticket/4857
http://ghc.haskell.org/trac/ghc/ticket/4857#4857: Add Control.Exception.allowInterruptWed, 22 Dec 2010 10:34:00 GMTsimonmar<p>
This proposal is to add the following function to <tt>Control.Exception</tt>:
</p>
<pre class="wiki">-- | When invoked inside 'mask', this function allows a blocked
-- asynchronous exception to be raised, if one exists. It is
-- equivalent to performing an interruptible operation (see
-- #interruptible#), but does not involve any actual blocking.
--
-- When called outside 'mask', or inside 'uninterruptibleMask', this
-- function has no effect.
allowInterrupt :: IO ()
allowInterrupt = unsafeUnmask $ return ()
</pre><p>
Some discussion leading up to this can be found in <a class="closed ticket" href="http://ghc.haskell.org/trac/ghc/ticket/4810" title="proposal: Versions of bracket without masking acquire action (closed: wontfix)">#4810</a>.
</p>
<p>
Discussion period: 3 weeks (until 12 Jan 2011)
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/4857#changelog
http://ghc.haskell.org/trac/ghc/ticket/4858
http://ghc.haskell.org/trac/ghc/ticket/4858#4858: Add Control.Concurrent.forkIOWithUnmask, deprecate forkIOUnmaskedWed, 22 Dec 2010 10:46:19 GMTsimonmar<p>
We added <tt>forkIOUnmasked</tt> as part of the new asynchronous exceptions API in base 4.3.0.0 (GHC 7.0.1). Unfortunately, <tt>forkIOUnmasked</tt> isn't very useful: the computation in the child thread is executed in the unmasked state, so the child doesn't have a way to reliably set up an exception handler before an asynchronous exception is raised.
</p>
<p>
This proposal is to replace <tt>forkIOUnmasked</tt> with <tt>forkIOWithUnmask</tt>:
</p>
<pre class="wiki">-- | Like 'forkIO', but the child thread is passed a function that can
-- be used to unmask asynchronous exceptions. This function is
-- typically used in the following way
--
-- > ... mask_ $ forkIOWithUnmask $ \unmask ->
-- > catch (unmask ...) handler
--
-- so that the exception handler in the child thread is established
-- with asynchronous exceptions masked, meanwhile the main body of
-- the child thread is executed in the unmasked state.
--
-- Note that the unmask function passed to the child thread should
-- only be used in that thread; the behaviour is undefined if it is
-- invoked in a different thread.
--
forkIOWithUnmask :: ((forall a . IO a -> IO a) -> IO ()) -> IO ThreadId
forkIOWithUnmask io = forkIO (io unsafeUnmask)
</pre><p>
<tt>forkIOUnmasked</tt> will be deprecated.
</p>
<p>
Some discussion leading up to this can be found in <a class="closed ticket" href="http://ghc.haskell.org/trac/ghc/ticket/4810" title="proposal: Versions of bracket without masking acquire action (closed: wontfix)">#4810</a>.
</p>
<p>
Discussion period: 3 weeks (until 12 Jan 2011)
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/4858#changelog
http://ghc.haskell.org/trac/ghc/ticket/4859
http://ghc.haskell.org/trac/ghc/ticket/4859#4859: Add forkOnIO and friends to Control.ConcurrentWed, 22 Dec 2010 11:37:28 GMTsimonmar<p>
I think these functions are implementation-independent enough to add to the main <tt>Control.Concurrent</tt> API:
</p>
<pre class="wiki">{- |
Like 'forkIO', but lets you specify on which CPU the thread is
created. Unlike a `forkIO` thread, a thread created by `forkOnIO`
will stay on the same CPU for its entire lifetime (`forkIO` threads
can migrate between CPUs according to the scheduling policy).
`forkOnIO` is useful for overriding the scheduling policy when you
know in advance how best to distribute the threads.
The `Int` argument specifies the CPU number; it is interpreted modulo
the value returned by 'getNumCapabilities'.
-}
forkOnIO :: Int -> IO () -> IO ThreadId
-- | Like 'forkIOWithUnmask', but the child thread is pinned to the
-- given CPU, as with 'forkOnIO'.
forkOnIOWithUnmask :: Int -> ((forall a . IO a -> IO a) -> IO ()) -> IO ThreadId
{- |
Returns the number of Haskell threads that can run truly
simultaneously (on separate physical processors) at any given time.
The CPU number passed to `forkOnIO` is interpreted modulo this
value.
An implementation in which Haskell threads are mapped directly to
OS threads might return the number of physical processor cores in
the machine, and 'forkOnIO' would be implemented using the OS's
affinity facilities. An implementation that schedules Haskell
threads onto a smaller number of OS threads (like GHC) would return
the number of such OS threads that can be running simultaneously.
GHC notes: this returns the number passed as the argument to the
@+RTS -N@ flag. In current implementations, the value is fixed
when the program starts and never changes, but it is possible that
in the future the number of capabilities might vary at runtime.
-}
getNumCapabilities :: IO Int
-- | returns @Just x@ if the given thread was created with either
-- @forkOnIO x@ or @forkOnIOWithUnmask@, or @Nothing@ otherwise.
threadIsPinned :: ThreadId -> IO (Maybe Int)
</pre><p>
In base 4.3.0.0 (GHC 7.0.1) we currently have <tt>forkOnIO</tt> and <tt>forkOnIOUnmasked</tt>, available from <tt>GHC.Conc</tt>. I am about to add the other functions to <tt>GHC.Conc</tt>, and deprecate <tt>forkOnIOUnmasked</tt> (see <a class="closed ticket" href="http://ghc.haskell.org/trac/ghc/ticket/4858" title="proposal: Add Control.Concurrent.forkIOWithUnmask, deprecate forkIOUnmasked (closed: invalid)">#4858</a>). This proposal is to export the above functions from<tt>Control.Concurrent</tt> too.
</p>
<p>
A feature request for <tt>threadIsPinned</tt> was submitted as <a class="closed ticket" href="http://ghc.haskell.org/trac/ghc/ticket/4457" title="feature request: Way to determine if code is running in thread fixed on capability (closed: fixed)">#4457</a>.
</p>
<p>
Naming is up for grabs: I'm not at all sure that "capabilities" is a good word here, but I can't think of any better ideas. "processors" or "CPUs" don't seem quite right.
</p>
<p>
Discussion period: 4 weeks (until 19 Jan 2011)
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/4859#changelog
http://ghc.haskell.org/trac/ghc/ticket/667
http://ghc.haskell.org/trac/ghc/ticket/667#667: Efficient Map <-> Set conversionsMon, 23 Jan 2006 10:04:08 GMTjpbernardy<p>
We should be able to convert a Set into a Map without re-computation of the tree Shape. (initially proposed by John Meacham)
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/667#changelog
http://ghc.haskell.org/trac/ghc/ticket/720
http://ghc.haskell.org/trac/ghc/ticket/720#720: Map/Set range functionFri, 10 Mar 2006 20:38:21 GMTjpbernardy<p>
Data.Map seems to lack a way to perform range queries
like "fetch all elements between keys low and high".
The naive implementation is easy:
</p>
<pre class="wiki">range :: Ord k => k -> k -> Map.Map k v -> [(k,v)]
range low high = toList . fst . split high . snd . split low
</pre><p>
But this is not very fast for larger maps. Maybe
this operation could be provided in Data.Map?
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/720#changelog
http://ghc.haskell.org/trac/ghc/ticket/722
http://ghc.haskell.org/trac/ghc/ticket/722#722: Adrian Hey's StringMap library in the collections package.Fri, 10 Mar 2006 21:09:54 GMTjpbernardy<ul><li>Bring Adrian Hey's StringMap to a higher level of completeness, so it can be made an instance of the Map class.
</li></ul><ul><li>Add an abstraction layer, as close a possible to Data.Map, so it can be a drop-in replacement in most cases.
</li></ul>Resultshttp://ghc.haskell.org/trac/ghc/ticket/722#changelog
http://ghc.haskell.org/trac/ghc/ticket/1022
http://ghc.haskell.org/trac/ghc/ticket/1022#1022: Add System.FilePath to baseWed, 22 Nov 2006 12:28:54 GMTguest<p>
Here is the proposal to add System.FilePath to base. The System.FilePath module is located at <a class="ext-link" href="http://www-users.cs.york.ac.uk/~ndm/projects/libraries.php#filepath"><span class="icon"></span>http://www-users.cs.york.ac.uk/~ndm/projects/libraries.php#filepath</a>
</p>
<p>
In particular I propose the addition of System.FilePath (a
cross-platform FilePath manipulation library), System.FilePath.Windows
(Windows paths on all OS's) and System.FilePath.Posix (Posix paths on
all OS's). The Version_* stuff is not being proposed for addition.
</p>
<p>
<a class="ext-link" href="http://article.gmane.org/gmane.comp.lang.haskell.libraries/5751"><span class="icon"></span>http://article.gmane.org/gmane.comp.lang.haskell.libraries/5751</a>
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/1022#changelog
http://ghc.haskell.org/trac/ghc/ticket/1218
http://ghc.haskell.org/trac/ghc/ticket/1218#1218: Add sortNub and sortNubBy to Data.ListTue, 13 Mar 2007 03:08:32 GMTneil<p>
I propose the addition of sortNub and sortNubBy to Data.List
</p>
<p>
sortNub = sort . nub, but can run in O(n log n) instead of O(n<sup>2) with the implementation:
</sup></p>
<p>
sortNub = map head . group . sort
</p>
<p>
I personally have defined this function over 25 times. Debate on the libraries list.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/1218#changelog
http://ghc.haskell.org/trac/ghc/ticket/1249
http://ghc.haskell.org/trac/ghc/ticket/1249#1249: Data.Map.map should be deprecated/removedWed, 28 Mar 2007 02:34:25 GMTajb@…<p>
(Note: Every claim here referring to Data.Map.map applies equally well to Data.IntMap.map.)
</p>
<p>
I believe that Data.Map.map is a misfeature and should be deprecated or removed.
</p>
<ol><li>Its name clashes with an extremely commonly-used Prelude function. This makes the first import of Data.Map into an existing module very expensive. Either all existing instances of "map" need to be qualified, or the import of Data.Map needs to be qualified (which works, but makes (!) and (<br />) unnecessarily inelegant), or the import must hide map.
</li></ol><ol start="2"><li>There is an easy way to get at the functionality which is already implemented: use fmap.
</li></ol><p>
Data.Set.map and Data.IntSet.map have similar problems, however you can't just "use fmap" in that case. I don't have a good solution except to rename these.
</p>
<p>
Data.Map.null also clashes with the Prelude, and should be reconsidered. However, again, there isn't a simple workaround, and there are many more overloadings of null (e.g. Data.ByteString). It's also likely that null is used far less than map, so the cost of a clash is much lower.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/1249#changelog
http://ghc.haskell.org/trac/ghc/ticket/1506
http://ghc.haskell.org/trac/ghc/ticket/1506#1506: Case-insensitive char/string comparisonFri, 06 Jul 2007 16:39:55 GMTEelis<p>
Data.Char provides functions to convert case, but does not provide a function to perform case-insensitive char/string comparison. Note that such functionality cannot be obtained by simply comparing for equality after performing toUpper/toLower, because some languages have things like multiple lowercase characters corresponding to the same uppercase character.
</p>
<p>
For example, in Greek, converting either σ or ς to uppercase yields Σ, while the inverse always yields σ. Consequently, the convert-all-to-uppercase approach would produce a false positive when comparing σ to ς, and the convert-all-to-lowercase approach would produce a false negative when comparing Σ to ς.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/1506#changelog
http://ghc.haskell.org/trac/ghc/ticket/1516
http://ghc.haskell.org/trac/ghc/ticket/1516#1516: Add Data.Stream, a library for manipulating infinite lists, to baseMon, 09 Jul 2007 18:03:07 GMTWouterSwierstra<p>
I'd propose to add a Data.Stream library to base. Data.Stream should be fairly uncontroversial. The module consists largely of a reimplimentation of several functions from Data.List to create, modify, and manipulate infinite lists. There is already a package on Hackage:
</p>
<p>
<a class="ext-link" href="http://hackage.haskell.org/cgi-bin/hackage-scripts/package/Stream-0.1"><span class="icon"></span>http://hackage.haskell.org/cgi-bin/hackage-scripts/package/Stream-0.1</a>
</p>
<p>
I've tried to include Haddock-comments, very similar to those for Data.List. As working with infinite lists can be tricky, I've included warnings clearly stating which functions can diverge.
</p>
<p>
I am aware that the name may cause confusion with Data.List.Stream. I'd welcome suggestions to avoid causing confusion.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/1516#changelog
http://ghc.haskell.org/trac/ghc/ticket/1590
http://ghc.haskell.org/trac/ghc/ticket/1590#1590: Libraries proposal: Add System.Info.isWindowsMon, 06 Aug 2007 10:25:33 GMTneil<p>
Currently the recognised way to test if your application is being run on Windows is:
</p>
<pre class="wiki">import System.Info
.... = os == "mingw"
</pre><p>
This is wrong on so many levels!
</p>
<p>
# The return result of os is NOT an operating system
# The result mingw does not imply that mingw is installed
# String comparisons are not very safe, a typo stops this working
# In GHC this comparison will take place at runtime, even though its a constant
</p>
<p>
Since nearly all uses of System.Info.os are to check if the operating system is Windows, adding an explicit isWindows function would simplify things.
</p>
<p>
Proposal:
</p>
<p>
Add System.Info.isWindows :: Bool
</p>
<p>
This value should return True on all Windows systems (Win 1.0 ... Vista), and False on all other systems.
</p>
<p>
Deadline:
</p>
<p>
2 weeks from the end of discussion. Please discuss on the libraries@ mailing list.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/1590#changelog
http://ghc.haskell.org/trac/ghc/ticket/1802
http://ghc.haskell.org/trac/ghc/ticket/1802#1802: proposal: fix comparison operations for base:Data.Version.VersionThu, 25 Oct 2007 16:21:26 GMTmalcolm.wallace@…<p>
Proposal: that values of the type Data.Version.Version should compare
equal, by ignoring trailing zeros.
Thus 1.2.0 == 1.2, rather than 1.2.0 > 1.2
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/1802#changelog
http://ghc.haskell.org/trac/ghc/ticket/1902
http://ghc.haskell.org/trac/ghc/ticket/1902#1902: Restrict the type of (^), (^^), and add genericPower, genericPower'Sat, 17 Nov 2007 13:58:50 GMTigloo<p>
This got a warm reception when I mentioned it in <a class="ext-link" href="http://www.haskell.org/pipermail/haskell-cafe/2007-June/027557.html"><span class="icon"></span>http://www.haskell.org/pipermail/haskell-cafe/2007-June/027557.html</a> so I'm formally proposing it now.
</p>
<p>
Note that this is a divergence from Haskell 98 (but the libraries already have a handful of small divergences, and Haskell' is just around the corner...).
</p>
<p>
In my opinion, <tt>(^)</tt> has the wrong type. Just as we have, for example,
</p>
<pre class="wiki">(!!) :: [a] -> Int -> a
genericIndex :: (Integral b) => [a] -> b -> a
</pre><p>
we should also have
</p>
<pre class="wiki">(^) :: (Num a) => a -> Int -> a
genericPower :: (Num a, Integral b) => a -> b -> a
</pre><p>
(or some other function name). The same goes for <tt>(^^)</tt> (<tt>genericPower'</tt>).
</p>
<p>
In my experience this would remove 99.9% of all defaulting (mostly where you write things like <tt>x^12</tt> and <tt>8^12</tt>), which means it's easier to get <tt>-Wall</tt> clean without having to put <tt>:: Int</tt> annotations everywhere.
</p>
<p>
The impact to GHC's bootlibs and extralibs is minimal. In most cases we have things like <tt>2^15</tt>, where Int is clearly fine, although it happens to be defaulted to Integer currently. In <tt>Data.Complex</tt> we have 2 cases of <tt>e^(2::Int)</tt> which can now be beautified. There are several cases where the type is inferred to be <tt>Int</tt> anyway.
</p>
<p>
There are 3 files where we really do have an Integer, and it does matter. They are all for parsing numbers of the form 18e43, in <tt>base/Text/Read/Lex.hs</tt>, <tt>parsec/Text/ParserCombinators/Parsec/Token.hs</tt> and <tt>haskell-src/Language/Haskell/Lexer.hs</tt>.
</p>
<p>
Initial deadline: 1 Dec 2007.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/1902#changelog
http://ghc.haskell.org/trac/ghc/ticket/1951
http://ghc.haskell.org/trac/ghc/ticket/1951#1951: Add "writer" Monad instance (,) o to Control.Monad.InstancesSun, 02 Dec 2007 17:23:46 GMTconal<p>
I'd like to have a (,)-style writer instance alongside the (->)-based reader instance for Monad in <tt>Control.Monad.Instances</tt>.
</p>
<p>
Here's the current reader:
</p>
<pre class="wiki">instance Monad ((->) r) where
return = const
f >>= k = \ r -> k (f r) r
</pre><p>
and my proposed writer:
</p>
<pre class="wiki">instance Monoid o => Monad ((,) o) where
return = pure
(o,a) >>= f = (o `mappend` o', a') where (o',a') = f a
</pre><p>
where the <tt>return</tt> definition relies on the Applicative instance of <tt>((,) o)</tt>. Written out explicitly,
</p>
<pre class="wiki"> return a = (mempty,a)
</pre><p>
<tt>Control.Monad.Instances</tt> will also need two new imports:
</p>
<pre class="wiki">import Data.Monoid (Monoid(..))
import Control.Applicative (pure)
</pre>Resultshttp://ghc.haskell.org/trac/ghc/ticket/1951#changelog
http://ghc.haskell.org/trac/ghc/ticket/1952
http://ghc.haskell.org/trac/ghc/ticket/1952#1952: Max and Min for MonoidSun, 02 Dec 2007 17:54:40 GMTconal<p>
I'd like to add two instances to <tt>Data.Monoid</tt>, alongside of All/Any, Sum/Product, and First/Last.
</p>
<p>
Here's a current instance (as a style example):
</p>
<pre class="wiki">-- | Boolean monoid under conjunction.
newtype All = All { getAll :: Bool }
deriving (Eq, Ord, Read, Show, Bounded)
instance Monoid All where
mempty = All True
All x `mappend` All y = All (x && y)
</pre><p>
My proposed addition:
</p>
<pre class="wiki">-- | Ordered monoid under 'max'.
newtype Max a = Max { getMax :: a }
deriving (Eq, Ord, Read, Show, Bounded)
instance (Ord a, Bounded a) => Monoid (Max a) where
mempty = Max minBound
Max a `mappend` Max b = Max (a `max` b)
-- | Ordered monoid under 'min'.
newtype Min a = Min { getMin :: a }
deriving (Eq, Ord, Read, Show, Bounded)
instance (Ord a, Bounded a) => Monoid (Min a) where
mempty = Min minBound
Min a `mappend` Min b = Min (a `min` b)
</pre><p>
I have a niggling uncertainty about the Ord & Bounded instances for <tt>Min a</tt>? Is there a reason flip the <tt>a</tt> ordering instead of preserving it?
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/1952#changelog
http://ghc.haskell.org/trac/ghc/ticket/1960
http://ghc.haskell.org/trac/ghc/ticket/1960#1960: Add Applicative and Monoid instances for STMWed, 05 Dec 2007 22:57:14 GMTconal<pre class="wiki">instance Applicative STM where { pure = return; (<*>) = ap }
instance Monoid (STM a) where { mempty = retry; mappend = orElse }
</pre><p>
I don't know where these instances would go. Nor whether this is a libraries or GHC proposal.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/1960#changelog
http://ghc.haskell.org/trac/ghc/ticket/1979
http://ghc.haskell.org/trac/ghc/ticket/1979#1979: Add variants of tails and inits not returning empty listsFri, 14 Dec 2007 16:08:45 GMTmux<p>
This patch adds the tails1 and inits1 function, that behave like their counterpart except that they won't return an empty list. I've needed them several times already, so it seems to me they would be useful to have in base.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/1979#changelog
http://ghc.haskell.org/trac/ghc/ticket/2042
http://ghc.haskell.org/trac/ghc/ticket/2042#2042: Add concatMapM to Control.MonadMon, 14 Jan 2008 16:36:19 GMTtwanvl<p>
I have written this function over and over again for different projects. Time to add it to the base libraries:
</p>
<pre class="wiki">-- | The 'concatMapM' function generalizes 'concatMap' to arbitrary monads.
concatMapM :: (Monad m) => (a -> m [b]) -> [a] -> m [b]
concatMapM f xs = liftM concat (mapM f xs)
</pre>Resultshttp://ghc.haskell.org/trac/ghc/ticket/2042#changelog
http://ghc.haskell.org/trac/ghc/ticket/2048
http://ghc.haskell.org/trac/ghc/ticket/2048#2048: Add split and splitWith to Data.ListWed, 16 Jan 2008 22:55:46 GMTtwanvl<p>
An often requested function is 'split', to split a list into parts delimited by some separator. ByteString has the functions split and splitWith for this purpose. I propose we add equivalents to Data.List.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/2048#changelog
http://ghc.haskell.org/trac/ghc/ticket/2095
http://ghc.haskell.org/trac/ghc/ticket/2095#2095: add new forms of unsafePerformIO and unsafeInterleaveIOThu, 14 Feb 2008 10:52:06 GMTduncan<p>
This proposal is to add two new variations on unsafePerformIO and one new form of unsafeInterleaveIO to the System.IO.Unsafe module in the base library (which already exports unsafePerformIO and unsafeInterleaveIO).
</p>
<p>
The additions are documented and portable to non-ghc.
</p>
<p>
Summary and documentation below, see attached patch for code details.
</p>
<p>
Suggested timescale: ~2 weeks, ends Friday 29th February
</p>
<h1 id="Summary">Summary</h1>
<ul><li><tt>unsafeDupablePerformIO</tt> and <tt>unsafeDupableInterleaveIO</tt>
When GHC added SMP support the previous <tt>unsafePerform/InterleaveIO</tt> got renamed to these two functions and new <tt>unsafePerform/InterleaveIO</tt> functions were added that provide protection against duplication in a multi-threaded context. This protection comes at some cost so there are cases where it is ok to uses these weaker forms if duplicating the IO action is safe. These are already defined and documented in <tt>GHC.IOBase</tt>, this patch just exports them.
</li></ul><ul><li><tt>unsafeInlinePerformIO</tt>
This is an even less safe form of <tt>unsafePerformIO</tt>. It is used in the <tt>Data.ByteString</tt> implementation and is very occasionally needed in other projects. If it is needed it is better that it be supplied in a portable form from a standard module with a sensible name and with full documentation.
</li></ul><h1 id="HaddockDocumentation">Haddock Documentation</h1>
<p>
This version of 'unsafePerformIO' is slightly more efficient,
because it omits the check that the IO is only being
performed by a single thread. Hence, when you write 'unsafeDupablePerformIO', there is a possibility that the IO
action may be performed multiple times (on a multiprocessor),
and you should therefore ensure that it gives the same results
each time.
</p>
<p>
<tt>unsafeDupablePerformIO :: IO a -> a</tt>
</p>
<blockquote>
<p>
<span class="wikiextras phrase todo">TODO</span> Actually, unsafeDupableInterleaveIO is not yet documented, that will have to be fixed.
</p>
</blockquote>
<p>
<tt>unsafeDupableInterleaveIO :: IO a -> IO a</tt>
</p>
<p>
This variant of 'unsafePerformIO' is quite /mind-bogglingly
unsafe/. It unstitches the dependency chain that holds the IO
monad together and breaks all your ordinary intuitions about
IO, sequencing and side effects. Avoid it unless you really
know what you are doing.
</p>
<p>
It is only safe for operations which are genuinely pure (not
just externally pure) for example reading from an immutable
foreign data structure. In particular, you should do no memory
allocation inside an 'unsafeInlinePerformIO' block. This is
because an allocation is a constant and is likely to be
floated out and shared. More generally, any part of any
IO action that does not depend on a function argument is
likely to be floated to the top level and have its result
shared.
</p>
<p>
It is more efficient because in addition to the checks that
'unsafeDupablePerformIO' omits, we also inline. Additionally
we do not pretend that the body is lazy which allows the
strictness analyser to see the strictness in the body. In turn
this allows some re-ordering of operations and any
corresponding side-effects.
</p>
<p>
With GHC it compiles to essentially no code and it exposes the
body to further inlining.
</p>
<p>
<tt>unsafeInlinePerformIO :: IO a -> a</tt>
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/2095#changelog
http://ghc.haskell.org/trac/ghc/ticket/2099
http://ghc.haskell.org/trac/ghc/ticket/2099#2099: Storable instance for ComplexFri, 15 Feb 2008 13:19:45 GMTjedbrown<p>
I propose that the following instance be added to base:
</p>
<pre class="wiki">instance (RealFloat a, Storable a) => Storable (Complex a) where
sizeOf z = 2 * sizeOf (realPart z)
alignment z = sizeOf (realPart z)
peek p = do
[r,i] <- peekArray 2 (castPtr p)
return (r :+ i)
poke p (r :+ i) = pokeArray (castPtr p) [r,i]
</pre><p>
This instance is binary compatible with C99, C++ and Fortran complex types.
</p>
<p>
It is currently needed by at least two independent packages: hmatrix and fft. Since it is natural for user code to use both of these packages, we need to move the instance to a common location.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/2099#changelog
http://ghc.haskell.org/trac/ghc/ticket/2659
http://ghc.haskell.org/trac/ghc/ticket/2659#2659: Add sortOn and other *On functionsSun, 05 Oct 2008 15:27:25 GMTtwanvl<p>
Almost all uses of <tt>sortBy</tt> are of the form <tt>sortBy (comparing f)</tt>, <tt>sortBy (compare `on` f)</tt> or an equivalent construction. I propose that we add the more convenient function <tt>sortOn</tt> to Data.List:
</p>
<pre class="wiki">sortOn :: Ord b => (a -> b) -> [a] -> [a]
</pre><p>
For consistency for the other <tt>By</tt> functions we should also add an <tt>On</tt> equivalent:
</p>
<pre class="wiki">nubOn :: Eq b => (a -> b) -> [a] -> [a]
deleteOn :: Eq b => (a -> b) -> a -> [a] -> [a]
deleteFirstsOn :: Eq b => (a -> b) -> [a] -> [a] -> [a]
unionOn :: Eq b => (a -> b) -> [a] -> [a] -> [a]
intersectOn :: Eq b => (a -> b) -> [a] -> [a] -> [a]
groupOn :: Eq b => (a -> b) -> [a] -> [[a]]
sortOn :: Ord b => (a -> b) -> [a] -> [a]
insertOn :: Ord b => (a -> b) -> a -> [a] -> [a]
maximumOn :: Ord b => (a -> b) -> [a] -> a
minimumOn :: Ord b => (a -> b) -> [a] -> a
</pre>Resultshttp://ghc.haskell.org/trac/ghc/ticket/2659#changelog
http://ghc.haskell.org/trac/ghc/ticket/2660
http://ghc.haskell.org/trac/ghc/ticket/2660#2660: Add Down newtype wrapper for reversing orderingsSun, 05 Oct 2008 15:37:08 GMTtwanvl<p>
In the same spirit as the newtypes in Data.Monoid, we can also add a newtype for reversing the ordering of a type:
</p>
<pre class="wiki">newtype Down a = Down { getDown :: a }
instance Ord a => Ord (Down a) where
Down x < Down y = y < x
-- etc.
</pre><p>
This newtype is especially useful in combination with <tt>sortOn</tt> (ticket <a class="closed ticket" href="http://ghc.haskell.org/trac/ghc/ticket/2629" title="proposal: Data.List: Replace nub; add nubOrd, nubInt, nubWith (closed: invalid)">#2629</a>).
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/2660#changelog
http://ghc.haskell.org/trac/ghc/ticket/2736
http://ghc.haskell.org/trac/ghc/ticket/2736#2736: Add bool to Data.BoolMon, 03 Nov 2008 06:39:11 GMTguest<p>
The function either is in Data.Either and maybe is in Data.Maybe. The function if' is a referenced function in the point-free module, but it doesn't exist, and if is a keyword, not a function. Since Data.Bool is a library module, and it fits the form of the two modules mentioned earlier, it should have a function bool. Its exact form may need more discussion, but in keeping with the other two, I propose:
</p>
<pre class="wiki">bool :: a -> a -> Bool -> a
bool false true False = false
bool false true True = true
</pre><p>
(proposed by BMeph, 2 November 2008)
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/2736#changelog
http://ghc.haskell.org/trac/ghc/ticket/3036
http://ghc.haskell.org/trac/ghc/ticket/3036#3036: Max/Min MonoidsThu, 19 Feb 2009 10:23:23 GMTwhpearson<p>
A small patch to Data.Monoid to give Max a and Min a monoids for (Ord a, Bounded a) = > a. Very similar to Sum and Product.
</p>
<p>
Some alternatives here for unbounded Max/Mins
<a class="ext-link" href="http://hpaste.org/fastcgi/hpaste.fcgi/view?id=1528"><span class="icon"></span>http://hpaste.org/fastcgi/hpaste.fcgi/view?id=1528</a>
</p>
<p>
My current preferred one is to not to bother and perhaps put Data.AddBounds in the main branch and people can wrap Integers in that if they want. It seems conceptually purer.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/3036#changelog
http://ghc.haskell.org/trac/ghc/ticket/3058
http://ghc.haskell.org/trac/ghc/ticket/3058#3058: Add a 'hex' function to the pretty printingMon, 02 Mar 2009 05:49:43 GMTTomMD<p>
Attached is a patch for Text.PrettyPrint.HughesPJ that adds a 'hex' function to print hexidecimal numbers.
</p>
<p>
The only point that I exepect to be contended is it varies slightly from the surrounding functions in that it allows one to control the number of characters printed (see below).
</p>
<blockquote class="citation">
<p>
hex 5 31
</p>
</blockquote>
<p>
0001f
</p>
<blockquote class="citation">
<p>
hex 2 8
</p>
</blockquote>
<p>
08
</p>
<blockquote class="citation">
<p>
hex 3 7495
</p>
</blockquote>
<p>
d47
</p>
<p>
While we can argue about the consistancy issues, I almost always want to control the number of digits when I'm dealing with hex. Hence I feel this is a reasonable special case.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/3058#changelog
http://ghc.haskell.org/trac/ghc/ticket/3324
http://ghc.haskell.org/trac/ghc/ticket/3324#3324: Add Foldable and Traversable instances for ((,) a)Tue, 23 Jun 2009 11:25:56 GMTYitzGale<p>
These instances are pretty obvious, and no
more or less trivial than the existing instances
for Prelude types. I have found them to be
useful.
</p>
<p>
Since we are touching these modules anyway,
I am attaching two additional minor patches to this
proposal.
</p>
<p>
One is to add a few additional explicit method
implementations in the Foldable and Traversable
instances for Prelude types. These might sometimes
be slightly more efficient, and they better match
the strictness and style of the existing explicit method
implementations.
</p>
<p>
The other is to fix the documentation for the functions
fmapDefault and foldMapDefault in Data.Traversable.
Contrary to what is stated, these cannot be used
as methods in superclasses, since the superclasses
must already exist before these functions can be
defined. Instead, I have paraphrased what
is stated in the documentation above: that the
corresponding superclass methods should be
equivalent to these.
</p>
<p>
Discussion period: two weeks.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/3324#changelog
http://ghc.haskell.org/trac/ghc/ticket/3362
http://ghc.haskell.org/trac/ghc/ticket/3362#3362: Adding a newtype EndoCategory to Control.CategoryWed, 08 Jul 2009 03:29:48 GMTr6<p>
I suggest adding a wrapper to make <tt>(a x x)</tt> a <tt>Monoid</tt> for any <tt>Category</tt> <tt>a</tt> and type <tt>x</tt>. This would be added to <tt>Control.Category</tt>.
</p>
<pre class="wiki">newtype EndoCategory a x = EndoCategory { runEndoCategory :: a x x }
instance (Category a) => Monoid (EndoCategory a x) where
mempty = EndoCategory id
mappend (EndoCategory f) (EndoCategory g) = EndoCategory (f . g)
</pre>Resultshttp://ghc.haskell.org/trac/ghc/ticket/3362#changelog
http://ghc.haskell.org/trac/ghc/ticket/3399
http://ghc.haskell.org/trac/ghc/ticket/3399#3399: Generalize the type of Data.List.{deleteBy, deleteFirstsBy}Mon, 27 Jul 2009 17:19:05 GMTiago<p>
Better (more general) type signatures would be
</p>
<pre class="wiki">deleteBy :: (b -> a -> Bool) -> b -> [a] -> [a]
deleteFirstsBy :: (b -> a -> Bool) -> [b] -> [a] -> [a]
</pre><p>
<em>Example of why it is useful</em>:
</p>
<pre class="wiki">deleteBy ((==) . fst) 1 [(1,'a'), (2, 'b')]
</pre>Resultshttp://ghc.haskell.org/trac/ghc/ticket/3399#changelog
http://ghc.haskell.org/trac/ghc/ticket/3446
http://ghc.haskell.org/trac/ghc/ticket/3446#3446: Library enhancement request: Data.Maybe.justIfFri, 21 Aug 2009 13:28:29 GMTnomeata<p>
Hi,
</p>
<p>
I found myself often writing the idiom "if a then Just v else Nothing". It can be nicely abbreviated by the function:
</p>
<pre class="wiki">justIf :: a -> Bool -> Just a
justIf x True = Just x
justIf x False = Nothing
</pre><p>
Which would allow me to write the nicely write- and readable <tt>v `justIf` a</tt>.
</p>
<p>
Asking on #haskell, I got positive feedback about this addition:
</p>
<pre class="wiki"><endojelly> nomeata, I'm all for it. my last project was *full* of that idiom
</pre>Resultshttp://ghc.haskell.org/trac/ghc/ticket/3446#changelog
http://ghc.haskell.org/trac/ghc/ticket/3453
http://ghc.haskell.org/trac/ghc/ticket/3453#3453: Add "check" function to Control.MonadSun, 23 Aug 2009 08:56:43 GMTJonFairbairn<p>
Generalisation of "guard".
</p>
<p>
check (not . isSpace) 'c' == Just 'c'
</p>
<p>
check (not . isSpace) ' ' == Nothing
</p>
<p>
See example in attached darcs patch
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/3453#changelog
http://ghc.haskell.org/trac/ghc/ticket/3455
http://ghc.haskell.org/trac/ghc/ticket/3455#3455: Add a setting to change how Unicode encoding errors are handledSun, 23 Aug 2009 16:07:00 GMTjudahj<p>
I proposal that we augment ghc-6.12.1's support for Unicode Handles
by adding the following functions to System.IO:
</p>
<pre class="wiki">hSetOnEncodingError :: Handle -> OnEncodingError -> IO ()
hGetOnEncodingError :: Handle -> IO OnEncodingError
</pre><p>
as well as the enumeration <tt>OnEncodingError</tt> with three constructors:
</p>
<ul><li><tt>ThrowEncodingError</tt>: Throw an exception at the first encoding or decoding
error.
</li><li><tt>SkipEncodingError</tt>: Skip all invalid bytes or characters.
</li><li><tt>TranslitEncodingError</tt>: Replace undecodable bytes with u+FFFD, and unencodable characters with '?'.
</li></ul><p>
I have implemented this functionality in the attached patch. Haddock docs are here:
<a class="ext-link" href="http://code.haskell.org/~judah/new-io-docs/System-IO.html#23"><span class="icon"></span>http://code.haskell.org/~judah/new-io-docs/System-IO.html#23</a>
</p>
<p>
The choice of error handler is orthogonal to the choice of encoder.
Additionally, the same setting is used for both read and write modes. For
portability, the handlers are written in pure Haskell rather than using GNU
iconv's <em>TRANSLIT feature.
</em></p>
<p>
Note that the text package, for example, provides more sophisticated
error-handling options. However, I think the above choices are useful enough
without making the API too complicated.
</p>
<p>
Discussion deadline: September 9
</p>
<p>
Haddock docs:
<a class="ext-link" href="http://code.haskell.org/~judah/new-io-docs/System-IO.html#23"><span class="icon"></span>http://code.haskell.org/~judah/new-io-docs/System-IO.html#23</a>
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/3455#changelog
http://ghc.haskell.org/trac/ghc/ticket/3456
http://ghc.haskell.org/trac/ghc/ticket/3456#3456: Add FilePath -> String decoderSun, 23 Aug 2009 16:16:38 GMTjudahj<p>
Currently, FilePaths on POSIX systems are represented as raw
bytes in a String. When this last came up on the mailing list, the general
consensus was to make FilePath an abstract datatype representing paths as
Strings on Windows and raw bytes on POSIX systems. However, such a change is
sure to break some existing code.
</p>
<p>
As a small step towards that goal, I propose adding the following two functions
to the System.IO module:
</p>
<pre class="wiki">filePathToString :: FilePath -> IO String
getFilePathToStringFunc :: IO (FilePath -> String)
</pre><p>
This functionality is implemented in the attached patch; Haddock docs are here:
<a class="ext-link" href="http://code.haskell.org/~judah/new-io-docs/System-IO.html#v%3AfilePathToString"><span class="icon"></span>http://code.haskell.org/~judah/new-io-docs/System-IO.html#v%3AfilePathToString</a>
</p>
<p>
On POSIX those functions decode according to the current locale, so they ought to be in the IO
monad. I think that the latter function will be easier to integrate into existing pure code.
</p>
<p>
On Windows, those functions are just <tt>return</tt> and <tt>return id</tt>, respectively, since GHC already treats
FilePaths as Strings on that platform.
</p>
<p>
Discussion deadline: September 9
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/3456#changelog
http://ghc.haskell.org/trac/ghc/ticket/3474
http://ghc.haskell.org/trac/ghc/ticket/3474#3474: Add a strict variant of iterate to Data.ListSat, 29 Aug 2009 21:47:31 GMTmux<p>
I suggest adding a strict variant of the iterate function to the Data.List module, as others seem to have had a need for it too. It is useful when you want to repeatedly apply a function a large number of times and get the final result. Using the standard iterate function in this way results in the whole list being held in memory, as exemplified in the following GHCi session (code compiled with -O2 behaves similarly):
</p>
<blockquote class="citation">
<p>
let f = (+1) in iterate f 0 !! 10000000
</p>
</blockquote>
<blockquote>
<p>
<strong>* Exception: stack overflow
</strong></p>
</blockquote>
<p>
Using a strict variant of iterate seems to be sufficient for this code to run in O(1) memory:
</p>
<blockquote class="citation">
<p>
let iterate' f x = x <tt>seq</tt> x : iterate' f (f x)
let f = (+1) in iterate' f 0 !! 10000000
</p>
</blockquote>
<blockquote>
<p>
10000000
</p>
</blockquote>
<p>
I have no idea if this is something that could/should be detected by the strictness analyzer; that would obviously be preferable if it is indeed possible.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/3474#changelog
http://ghc.haskell.org/trac/ghc/ticket/3563
http://ghc.haskell.org/trac/ghc/ticket/3563#3563: A couple of additions to Data.BitsWed, 07 Oct 2009 07:40:53 GMTporges<p>
Population count is an often-needed function when bitfiddling, so I think a version should be supplied. I also have included functions for converting to and from lists of Booleans:
</p>
<pre class="wiki">-- population count
popCount :: (Bits a, Num t) => a -> t
popCount x = count' (bitSize x) x 0
where
count' 0 _ acc = acc
count' n x acc = count' (n-1) (x `shiftR` 1) (acc + if x .&. 1 == 1 then 1 else 0)
-- this weird if/else is to preserve the nice type signature :)
-- converts a list of bools to a number
fromBools :: (Bits a) => [Bool] -> a
fromBools = foldl' (\i b -> (i `shiftL` 1) .|. if b then 1 else 0) 0 -- likewise
-- converts a number to a list of bools
toBools :: (Bits a) => a -> [Bool]
toBools x = reverse (toBools' (bitSize x) x)
where
toBools' 0 _ = []
toBools' n x = (x .&. 1 == 1) : toBools' (n-1) (x `shiftR` 1)
</pre>Resultshttp://ghc.haskell.org/trac/ghc/ticket/3563#changelog
http://ghc.haskell.org/trac/ghc/ticket/3587
http://ghc.haskell.org/trac/ghc/ticket/3587#3587: provide a cross-platform way to set environment variablesWed, 14 Oct 2009 22:36:05 GMTshahn<p>
System.Environment contains cross-platform operations to query environment variables, not to modify them. System.Posix.Env (package unix) provides operations to set environment variables on Linux (and probably other unices). This ticket requests adding cross-platform operations to set env vars to the module System.Environment.
</p>
<p>
As a workaround i copied the implementation of <a class="ext-link" href="http://hackage.haskell.org/packages/archive/unix/2.3.2.0/doc/html/src/System-Posix-Env.html#putEnv"><span class="icon"></span>System.Posix.Env.putEnv</a> into a new module. That seems to work on windows and linux (for me. Maybe this is due to using mingw/msys, though).
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/3587#changelog
http://ghc.haskell.org/trac/ghc/ticket/3634
http://ghc.haskell.org/trac/ghc/ticket/3634#3634: Add traceM, traceShowM and withTraceTue, 03 Nov 2009 07:41:17 GMTMartijnVanSteenbergen<p>
On haskell-libraries we have <a class="ext-link" href="http://thread.gmane.org/gmane.comp.lang.haskell.libraries/12019"><span class="icon"></span>discussed</a> the addition of the following three functions to module Debug.Trace:
</p>
<pre class="wiki">withTrace :: Show a => String -> a -> a
withTrace msg x = trace (msg ++ show x) x
traceM :: Monad m => String -> m ()
traceM msg = trace msg (return ())
traceShowM :: (Show a, Monad m) => a -> m ()
traceShowM = traceM . show
</pre><p>
The current documentation for that module is a little terse so we have also added an example to clarify the use of trace.
</p>
<p>
The following people have participated in the discussion and all expressed interest, agreement or concerns (but always with constructive comments) in or over the new functions: Philip Hölzenspies, pepe, Lennart Augustsson, Felipe Lessa, Evan LaForge, Joachim Breitner, Twan van Laarhoven, Ben Franksen, Ian Lynagh, Sean Leather. Please see the thread for more detail.
</p>
<p>
I have attached a diff that can be applied to the module. Could one of the GHC developers check it and apply it?
</p>
<p>
Thanks,
</p>
<p>
Martijn.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/3634#changelog
http://ghc.haskell.org/trac/ghc/ticket/3671
http://ghc.haskell.org/trac/ghc/ticket/3671#3671: Add partitioning functions to Data.ListTue, 17 Nov 2009 13:45:12 GMTholzensp<p>
The functions <tt>take</tt> and <tt>span</tt> have recursive equivalents <tt>takeRec</tt> and <tt>spanRec</tt> that apply the same function to the remainder, i.e.
</p>
<pre class="wiki">takeRec i xs = let (hs,ts) = splitAt i xs in hs : takeRec i xs
spanRec p xs = let (hs,ts) = span p xs in hs : spanRec p xs
</pre><p>
and the more generic version of <tt>take</tt>:
</p>
<pre class="wiki">genericTakeRec i xs = let (hs,ts) = genericSplitAt i xs in hs : genericTakeRec i xs
</pre><p>
These functions, to me, are in the same league as <tt>partition</tt> and <tt>group</tt>, can be added with little chance of nameclashes on functions with a different meaning and are not named compositions.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/3671#changelog
http://ghc.haskell.org/trac/ghc/ticket/3962
http://ghc.haskell.org/trac/ghc/ticket/3962#3962: Add flipped fmapWed, 07 Apr 2010 09:06:45 GMTbasvandijk<p>
The Applicative apply <tt><*></tt> and Monadic bind <tt>>>=</tt> both have flipped variants: <tt><**></tt> and <tt>=<<</tt> respectively. The Functor <tt>fmap</tt> or <tt><$></tt> does not have such a flipped variant.
</p>
<p>
I would like to propose adding a flipped variant of <tt><$></tt> to <tt>Data.Functor</tt>:
</p>
<pre class="wiki">(<$$>) ∷ Functor f ⇒ f α → (α → β) → f β
(<$$>) = flip (<$>)
infixl 4 <$>, <$$>
</pre><p>
because of the following two reasons:
</p>
<ul><li>I often use <tt><$></tt> in the last expression of a do-expression to do a final transformation of the last monadic value. When the code of the transformation function is big and spans multiple lines it visually breaks the sequential nature of a do-expression:
<pre class="wiki">do m1
m2
bigPieceOfCodeThatVisuallyBreaks
theSequentialNatureOfADoExpression <$> m3
</pre></li></ul><p>
I would rather like to see:
</p>
<pre class="wiki">do m1
m2
m3 <$$> bigPieceOfCodeThatVisuallyBreaks
theSequentialNatureOfADoExpression
</pre><ul><li>Consistency. As already mentioned, Applicative and Monad have flipped variants but Functor does not. I like the consistency of:
<pre class="wiki">(<$>) ∷ Functor f ⇒ (α → β) → (f α → f β)
(<$$>) ∷ Functor f ⇒ f α → (α → β) → f β
(<*>) ∷ Applicative f ⇒ f (α → β) → (f α → f β)
(<**>) ∷ Applicative f ⇒ f α → f (α → β) → f β
(>>=) ∷ Monad f ⇒ f α → (α → f β) → f β
(=<<) ∷ Monad f ⇒ (α → f β) → (f α → f β)
</pre></li></ul><p>
With regard to naming, I don't particularly like <tt><$$></tt> because it's undirectional. However so are <tt><$></tt>, <tt><*></tt> and <tt><**></tt>. I choose <tt><$$></tt> because it's consistent with <tt><**></tt>.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/3962#changelog
http://ghc.haskell.org/trac/ghc/ticket/4189
http://ghc.haskell.org/trac/ghc/ticket/4189#4189: (<.>) operator (generalizing (.) to Functor)Wed, 14 Jul 2010 06:37:29 GMTuzytkownik<p>
Currently there are following operators:
</p>
<pre class="wiki">(<$>) :: (a -> b) -> f a -> f b
($) :: (a -> b) -> a -> b
(.) :: (b -> c) -> (a -> b) -> a -> c
</pre><p>
However defining the operator that is to <$> as . is to $ is trivial:
</p>
<pre class="wiki">(<.>) :: (b -> c) -> (a -> f b) -> a -> f c
f <.> g = fmap f . g
</pre><p>
It would help writing in pointless style using Functors (as well as Applicatives/Monads etc.)
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/4189#changelog
http://ghc.haskell.org/trac/ghc/ticket/4443
http://ghc.haskell.org/trac/ghc/ticket/4443#4443: Don't require users to use undefinedTue, 26 Oct 2010 16:02:57 GMTbasvandijk<p>
Users of the <tt>sizeOf</tt> or <tt>alignment</tt> methods (<tt>:: a -> Int</tt>) of the <tt>Storable</tt> class are pushed to use <tt>undefined</tt> in their programs. Take the following function from <tt>Foreign.Marshal.Alloc</tt> as an example:
</p>
<pre class="wiki">malloc :: Storable a => IO (Ptr a)
malloc = doMalloc undefined
where
doMalloc :: Storable b => b -> IO (Ptr b)
doMalloc dummy = mallocBytes (sizeOf dummy)
</pre><p>
I find the use of <tt>undefined</tt> ugly; its only purpose is to help the type-checker by carrying around a type variable. It also makes the job of an optimizing compiler harder because, in order to avoid generating unnecessary code, the compiler needs to find out if <tt>undefined</tt> isn't used. More importantly however, <tt>undefined</tt> is dangerous; The type-checker will never complain when you accidentally use <tt>undefined</tt> in the wrong place increasing the change that your program will crash. Also, instance writers for the <tt>Storable</tt> class need to be careful not to evaluate the argument of <tt>sizeOf</tt> because it may be <tt>undefined</tt>.
</p>
<p>
The use of <tt>undefined</tt> is not only required by the <tt>Storable</tt> class. Users of the <tt>HasResolution</tt> class from <tt>Data.Fixed</tt> also need to use <tt>undefined</tt> in order to get the resolution of a fixed value:
</p>
<pre class="wiki">class HasResolution a where
resolution :: p a -> Integer
</pre><p>
I would like to propose solving this. My proposal consists of 3 sub-proposals:
</p>
<ol><li>Add module <tt>Data.Tagged</tt>.
</li></ol><ol start="2"><li>Modify the <tt>sizeOf</tt> and <tt>alignment</tt> methods of the <tt>Storable</tt> class.
</li></ol><ol start="3"><li>Modify the <tt>HasResolution</tt> class.
</li></ol><p>
What follows are more detailed explanations of the proposals:
</p>
<h2 id="AddmoduleData.Tagged">Add module <tt>Data.Tagged</tt></h2>
<p>
My proposal is to move the <tt>Data.Tagged</tt> module from Edward A. Kmett's <a class="ext-link" href="http://hackage.haskell.org/package/tagged"><span class="icon"></span>tagged</a> package to <tt>base</tt>.
</p>
<p>
The only modification that needs to be done is to drop the <tt>Default</tt> instance for <tt>Proxy</tt> because this will otherwise require that <tt>Data.Default</tt> be moved to base as well which isn't my intention. When this proposal is accepted <tt>Data.Default</tt> can provide the instance instead.
</p>
<h2 id="ModifythesizeOfandalignmentmethodsoftheStorableclass">Modify the <tt>sizeOf</tt> and <tt>alignment</tt> methods of the <tt>Storable</tt> class</h2>
<p>
I would like to replace the following:
</p>
<pre class="wiki">class Storable a where
sizeOf :: a -> Int
alignment :: a -> Int
</pre><p>
with:
</p>
<pre class="wiki">class Storable a where
sizeOf :: SizeOf a
alignment :: Alignment a
type SizeOf a = Tagged a Int
type Alignment a = Tagged a Int
</pre><p>
To retrieve the actual size of type <tt>a</tt> use:
<tt>untag (sizeOf :: SizeOf a)</tt>
where: <tt>untag :: Tagged s b -> b</tt> from <tt>Data.Tagged</tt>.
</p>
<p>
See the following for the <a class="ext-link" href="http://code.haskell.org/~basvandijk/doc/ghc/html/libraries/base-4.3.0.0/Foreign-Storable.html"><span class="icon"></span>haddock documentation</a>.
</p>
<p>
Here's the definition of the previous <tt>malloc</tt> function to give you an impression how code looks when my proposals are accepted:
</p>
<pre class="wiki">malloc :: forall a. Storable a => IO (Ptr a)
malloc = mallocBytes (untag (sizeOf :: SizeOf a))
</pre><p>
(Note that this does require the <tt>ScopedTypeVariables</tt> language extension.)
</p>
<h2 id="ModifytheHasResolutionclass">Modify the <tt>HasResolution</tt> class</h2>
<p>
I would like to modify the <tt>HasResolution</tt> class in the same way. So replacing:
</p>
<pre class="wiki">class HasResolution a where
resolution :: p a -> Integer
</pre><p>
with:
</p>
<pre class="wiki">class HasResolution a where
resolution :: Resolution a
type Resolution a = Tagged a Integer
</pre><p>
See the following for the <a class="ext-link" href="http://code.haskell.org/~basvandijk/doc/ghc/html/libraries/base-4.3.0.0/Data-Fixed.html"><span class="icon"></span>haddock documentation</a>.
</p>
<p>
Note that <tt>Fixed</tt> also gets a <tt>HasResolution</tt> instance:
</p>
<pre class="wiki">instance HasResolution a => HasResolution (Fixed a) where
resolution = retag (resolution :: Resolution a)
</pre><p>
where: <tt>retag :: Tagged s b -> Tagged t b</tt> from <tt>Data.Tagged</tt>.
</p>
<h2 id="bitSize"><tt>bitSize</tt>?</h2>
<p>
There's a possible 4th proposal that I'm thinking about: The <tt>Bits</tt> class from <tt>Data.Bits</tt> has the <tt>bitSize :: a -> Int</tt> method. Maybe it would be a good idea to replace that as well with:
<tt>bitSize :: BitSize a; type BitSize a = Tagged a Int</tt>
However I think <tt>bitSize</tt> is more often applied to an actual value than to <tt>undefined</tt> so I need to investigate that a little further.
</p>
<h2 id="Patches">Patches</h2>
<p>
A patch for the <tt>base</tt> package is attached to the ticket. I also attached patches for the <tt>ghc</tt> compiler, <tt>bytestring</tt>, <tt>binary</tt>, <tt>vector</tt> and <tt>dph</tt>. The latter are just some packages that were inside my ghc repository.
</p>
<h2 id="Deadline">Deadline</h2>
<p>
3 weeks from now (Tuesday 16 November 2010) but I will shift it when the discussion demands it.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/4443#changelog
http://ghc.haskell.org/trac/ghc/ticket/4500
http://ghc.haskell.org/trac/ghc/ticket/4500#4500: Improve Read IntegerTue, 16 Nov 2010 20:31:06 GMTigloo<p>
Currently, according to H98, H2010, GHC and hugs,
</p>
<pre class="wiki">reads "1.2" :: [(Integer, String)]
</pre><p>
is
</p>
<pre class="wiki">[]
</pre><p>
whereas I would expect it to be
</p>
<pre class="wiki">[(1,".2")]
</pre><p>
The attached patch fixes it.
</p>
<p>
Suggested deadline: 1 Dec 2010.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/4500#changelog
http://ghc.haskell.org/trac/ghc/ticket/1097
http://ghc.haskell.org/trac/ghc/ticket/1097#1097: enumFrom on basic numeric types should be strictSat, 13 Jan 2007 05:16:29 GMTbdonlan@…<p>
The haskell report in section 6.3.4 states that "For all four of these Prelude numeric types, all of the enumFrom family of functions are strict in all their arguments.", however, with Integer, Float, and Double, this is not the case. As tests/ghc-regress/KNOWN_FAILURES notes, this may be a bug in the prelude, as the reference implementation is not strict on its arguments, however I believe the text in 6.3.4 should be accepted as normative, as this behavior has confused users in the past ( <a class="ext-link" href="http://www.haskell.org/pipermail/haskell-cafe/2007-January/021133.html"><span class="icon"></span>http://www.haskell.org/pipermail/haskell-cafe/2007-January/021133.html</a> ), and there is little legitimate usage for a list of [undefined..]::Integer.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/1097#changelog
http://ghc.haskell.org/trac/ghc/ticket/1695
http://ghc.haskell.org/trac/ghc/ticket/1695#1695: library submission: Data.Either.unzipEithers :: [Either a b] -> ([a],[b])Fri, 14 Sep 2007 20:06:08 GMTJeremyShaw<p>
This function is like unzip for a list of Eithers instead of tuples.
</p>
<p>
According to google code search, I am at least the 5th person to
implement this function:
</p>
<p>
<a class="ext-link" href="http://www.google.com/codesearch?hl=en&lr=&q=%22%5BEither+a+b%5D+-%3E+%28%5Ba%5D%2C%5Bb%5D%29%22&btnG=Search"><span class="icon"></span>http://www.google.com/codesearch?hl=en&lr=&q=%22%5BEither+a+b%5D+-%3E+%28%5Ba%5D%2C%5Bb%5D%29%22&btnG=Search</a>
</p>
<p>
I opted for the name unzipEithers because the function is similar to
two existing functions: unzip and catMaybes. It seems less similar to
partition, because partition does not desconstruct the values, it just
divides them into to two groups. I have no particular attachment to the name however.
</p>
<p>
I modeled the implementation after unzip and partition. Hopefully I
made effective use of the irrefutable patterns and laziness, but
someone else should verify.
</p>
<p>
Deadline: October 15
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/1695#changelog