GHC: Ticket Query
http://ghc.haskell.org/trac/ghc/query?component=libraries+(other)&milestone=Not+GHC&group=status&order=summary
The Glasgow Haskell Compileren-USGHChttp://ghc.haskell.org/trac/ghc/chrome/site/ghc_logo.png
http://ghc.haskell.org/trac/ghc/query?component=libraries+(other)&milestone=Not+GHC&group=status&order=summary
Trac 1.0.1
http://ghc.haskell.org/trac/ghc/ticket/2029
http://ghc.haskell.org/trac/ghc/ticket/2029#2029: Add --with-libedit flag to the readline packageWed, 09 Jan 2008 18:01:10 GMTjudah<p>
It would be useful for the readline package to support compiling against the libedit library (which provides a subset of the readline APIs):
</p>
<ul><li>libedit is available by default on OS X.
</li><li>since libedit is BSD-licensed, there are no problems statically linking ghc with it. (This may be useful on Windows.)
</li></ul><p>
I propose adding a <tt>--with-libedit</tt> flag to the readline autoconf script. Without that flag, the package will behave exactly as before, refusing to link against libedit. With that flag, the following behavior occurs:
</p>
<ul><li><tt>GNUreadline.framework</tt> (OS X - only) is ignored, if present
</li><li>We try to link with -lreadline, and don't fail if readline is actually libedit.
</li><li>If it is libedit, we #ifdef out all of the functions not supported by libedit. (these are generally low-level APIs not needed by most applications, including <tt>ghci</tt>.) Otherwise, if we're linking against GNU readline, we support all the available APIs.
</li></ul><p>
Suggested deadline: Jan. 23, 2008.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/2029#changelog
http://ghc.haskell.org/trac/ghc/ticket/2316
http://ghc.haskell.org/trac/ghc/ticket/2316#2316: Add Applicative instances for all MTL MonadsThu, 29 May 2008 04:41:03 GMTsjanssen<p>
This is a proposal to add Applicative instances corresponding to each Monad instance in the MTL. Note that mtl will now depend on base >= 2.0.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/2316#changelog
http://ghc.haskell.org/trac/ghc/ticket/1953
http://ghc.haskell.org/trac/ghc/ticket/1953#1953: Add Bounded instance for IntSetSun, 02 Dec 2007 23:32:53 GMTdbenbenn<p>
I propose to add a Bounded instance to IntSet.hs.
</p>
<p>
IntSet is in Ord, and there are only finitely many instances of IntSet. Therefore there is a min IntSet and a max IntSet. It turns out these bounds are very simple:
</p>
<pre class="wiki">instance Bounded IntSet where
minBound = fromList []
maxBound = fromList [maxBound]
</pre><p>
Suggested deadline: December 16, 2007.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/1953#changelog
http://ghc.haskell.org/trac/ghc/ticket/4517
http://ghc.haskell.org/trac/ghc/ticket/4517#4517: Add Data.Functor.Backwards to transformersSat, 20 Nov 2010 22:19:52 GMTr6<p>
Data.Functor.Backwards is a wrapper for functors that allow Foldable, Traversable, and Applicative functors to be operated backwards. It is similar to Dual for Monoids. The Applicative instance runs effects in reversed order. The Foldable instance folds from right to left, The Traversable instance traverses from right to left.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/4517#changelog
http://ghc.haskell.org/trac/ghc/ticket/1274
http://ghc.haskell.org/trac/ghc/ticket/1274#1274: Add a MonadState instance for the Parsec monadFri, 13 Apr 2007 18:26:35 GMTmux<p>
This patch adds a MonadState instance for the GenParser monad of Parsec, allowing the use of the usual state handling primitives instead of the custom ones provided by Parsec.
</p>
<p>
The drawback of this is that it adds a dependency on mtl; I don't think that's much of a problem though, and we'll need it for ParsecT anyways.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/1274#changelog
http://ghc.haskell.org/trac/ghc/ticket/2133
http://ghc.haskell.org/trac/ghc/ticket/2133#2133: Add an instance for IArray (IOToDiffArray IOUArray) BoolSun, 02 Mar 2008 15:26:18 GMTDeewiant<p>
An instance for <tt>IArray (IOToDiffArray IOUArray) Bool</tt> is missing from Data.Array.Diff. There doesn't seem to be any good reason for this: all the other <tt>IArray UArray a</tt> instances defined in Data.Array.IArray have corresponding instances. <tt>Bool</tt> is the sole exception.
</p>
<p>
They cannot be added in user code without copying the entire Data.Array.Diff source, since the instances require internal functions which aren't exposed.
</p>
<p>
Since all the instances are defined in exactly the same way, only varying the second type parameter, this requires practically zero work: just copy any of the other instances and replace the type parameter with <tt>Bool</tt>. A <tt>Show</tt> instance should also be provided. Both are in the patch.
</p>
<p>
To be sure that the instances haven't been omitted because they don't work, I wrote a few QuickCheck properties (attached) and it seems that it does work without any trouble.
</p>
<p>
Suggested deadline for discussion: 17th March 2008.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/2133#changelog
http://ghc.haskell.org/trac/ghc/ticket/1941
http://ghc.haskell.org/trac/ghc/ticket/1941#1941: Add htmlAttr to Text.XHtmlWed, 28 Nov 2007 12:45:24 GMTdsf<p>
It is necessary to allow HTML primitive characters such as "&times;" in string attributes, e.g.
</p>
<blockquote>
<p>
<input type="image" src="delete.gif" alt="&times;" name=...>
</p>
</blockquote>
<p>
However, passing "&times;" to strAttr results in an encoded string "&amp;times;", which doesn't
render the nice little x we need. Attached is a patch to add an htmlAttr function so we can say
</p>
<blockquote>
<p>
input ! [strAttr "type" "image", strAttr "src" "delete.gif", htmlAttr "alt" (primHtmlChar "times")]
</p>
</blockquote>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/1941#changelog
http://ghc.haskell.org/trac/ghc/ticket/3537
http://ghc.haskell.org/trac/ghc/ticket/3537#3537: Add missing NFData instances to parallelWed, 23 Sep 2009 10:49:41 GMTRoel van Dijk<p>
<a class="ext-link" href="http://hackage.haskell.org/packages/archive/parallel/1.1.0.1/doc/html/Control-Parallel-Strategies.html"><span class="icon"></span>Control.Parallel.Strategies</a> contains many NFData instances for types defined in base, but not all. I propose adding NFData instances for all types in base where it makes sense.
</p>
<p>
Attached is a patch which adds instances for most missing types. For many of those types it would be nicer to define the instances in the module where the type is defined, but that would require a circular dependency.
</p>
<p>
Instances in patch:
</p>
<ul><li><a class="ext-link" href="http://hackage.haskell.org/packages/archive/base/4.1.0.0/doc/html/Data-Fixed.html"><span class="icon"></span>Data.Fixed</a> (E6, E12, Fixed)
</li><li><a class="ext-link" href="http://hackage.haskell.org/packages/archive/base/4.1.0.0/doc/html/Data-IORef.html"><span class="icon"></span>Data.IORef</a> (IORef)
</li><li><a class="ext-link" href="http://hackage.haskell.org/packages/archive/base/4.1.0.0/doc/html/Data-STRef.html"><span class="icon"></span>Data.STRef</a> (STRef)
</li><li><a class="ext-link" href="http://hackage.haskell.org/packages/archive/base/4.1.0.0/doc/html/Data-Unique.html"><span class="icon"></span>Data.Unique</a> (Unique)
</li><li><a class="ext-link" href="http://hackage.haskell.org/packages/archive/base/4.1.0.0/doc/html/Data-Version.html"><span class="icon"></span>Data.Version</a> (Version)
</li><li><a class="ext-link" href="http://hackage.haskell.org/packages/archive/base/4.1.0.0/doc/html/Foreign-C-Error.html"><span class="icon"></span>Foreign.C.Error</a> (Errno)
</li><li><a class="ext-link" href="http://hackage.haskell.org/packages/archive/base/4.1.0.0/doc/html/Foreign-C-Types.html"><span class="icon"></span>Foreign.C.Types</a> (all of them)
</li><li><a class="ext-link" href="http://hackage.haskell.org/packages/archive/base/4.1.0.0/doc/html/System-Exit.html"><span class="icon"></span>System.Exit</a> (ExitCode)
</li><li><a class="ext-link" href="http://hackage.haskell.org/packages/archive/base/4.1.0.0/doc/html/System-IO.html"><span class="icon"></span>System.IO</a> (IOMode, SeekMode, BufferMode)
</li><li><a class="ext-link" href="http://hackage.haskell.org/packages/archive/base/4.1.0.0/doc/html/System-IO-Error.html"><span class="icon"></span>System.IO.Error</a> (IOErrorType)
</li><li><a class="ext-link" href="http://hackage.haskell.org/packages/archive/base/4.1.0.0/doc/html/System-Mem-StableName.html"><span class="icon"></span>System.Mem.StableName</a> (StableName)
</li></ul><p>
For some types I had to resort to tricks like comparing a value with itself to force evaluation since I do not have access to all constructors.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/3537#changelog
http://ghc.haskell.org/trac/ghc/ticket/1007
http://ghc.haskell.org/trac/ghc/ticket/1007#1007: Add parsing (and some more) to the time packageThu, 16 Nov 2006 13:48:59 GMTbringert@…<p>
I propose adding parsing to the time package. I also propose some minor
other changes and bugfixes. I have implemented the changes that I considered
reasonably clear-cut. The rest I will implement after community input.
</p>
<p>
All already implemented changes are available from:
<a class="ext-link" href="http://www.cs.chalmers.se/~bringert/darcs/time/"><span class="icon"></span>http://www.cs.chalmers.se/~bringert/darcs/time/</a>
</p>
<p>
All objections, comments, etc. are welcome.
</p>
<h2 id="Executivesummary">Executive summary</h2>
<p>
(see below for more details).
</p>
<h3 id="Implementedenhancements">Implemented enhancements</h3>
<ul><li>Add time parsing to the time package, including Read instances.
</li></ul><ul><li>Add fromMondayStartWeek and fromSundayStartWeek.
</li></ul><ul><li>Add secondsToDiffTime and picosecondsToDiffTime.
</li></ul><h3 id="Unimplementedenhancements">Unimplemented enhancements</h3>
<ul><li>Change %S to: the number of whole seconds.
</li></ul><ul><li>Add %q: the number of picoseconds (including trailing zeroes).
</li></ul><ul><li>Add %Q: decimal point and second decimals, without trailing zeros.
</li></ul><ul><li>Add %f: The century part of the week date year.
</li></ul><ul><li>Change %Z to produce the time zone offset if the time zone name is "".
</li></ul><ul><li>Add Eq and Ord instances for ZonedTime?
</li></ul><ul><li>Add Typeable and Data instances for all the time package types.
</li></ul><h3 id="Fixedbugs">Fixed bugs</h3>
<ul><li>formatTime "%c" did not include the time zone when applied to ZonedTime or UTCTime.
</li></ul><ul><li>s/propleptic/proleptic/ in some Haddock comments.
</li></ul><ul><li>formatTime documentation of range of %U and %W was wrong, should include 00.
</li></ul><ul><li>The showWeekDate Haddock comment was missing the example.
</li></ul><ul><li>The taiEpoch Haddock comment was missing the epoch time.
</li></ul><h3 id="Unfixedbugs">Unfixed bugs</h3>
<ul><li>Haddock comments for toJulianYearAndDay and isJulianLeapYear talk about the Gregorian calendar.
</li></ul><h2 id="Details">Details</h2>
<h3 id="Implementedenhancements1">Implemented enhancements</h3>
<ul><li>Add time parsing to the time package.
</li></ul><p>
Rationale:
The old System.Time has had a <span class="wikiextras phrase todo">TODO</span> "* add functions to parse strings to
`CalendarTime' (some day...)" for a long time. The question about date parsing
comes up once in a while on the mailing lists
(e.g. <a class="ext-link" href="http://comments.gmane.org/gmane.comp.lang.haskell.cafe/16438"><span class="icon"></span>http://comments.gmane.org/gmane.comp.lang.haskell.cafe/16438</a>).
</p>
<ul><li>Add fromMondayStartWeek and fromSundayStartWeek to Data.Time.Calendar.OrdinalDate.
</li></ul><p>
Rationale:
I can't find any duals of mondayStartWeek and sundayStartWeek. They
are useful when implementing parsing for %W and %U.
</p>
<ul><li>Add secondsToDiffTime and picosecondsToDiffTime.
</li></ul><p>
Rationale:
As has come up on haskell-cafe
(<a class="ext-link" href="http://comments.gmane.org/gmane.comp.lang.haskell.cafe/15653"><span class="icon"></span>http://comments.gmane.org/gmane.comp.lang.haskell.cafe/15653</a>), it
takes a while to figure out how to make DiffTime values.
</p>
<p>
secondsToDiffTime is not that important since it is just another name
for fromInteger, but I suspect that it would be used a lot. Using
fromRational to create a DiffTime from a number of picoseconds is a
bit of a hassle, so having a picosecondsToDiffTime would be useful.
</p>
<h3 id="Unimplementedenhancements1">Unimplemented enhancements</h3>
<ul><li>formatTime: Change %S to: the number of whole seconds.
</li><li>formatTime: Add %q: the number of picoseconds (including trailing zeroes).
</li><li>formatTime: Add %Q: decimal point and second decimals, without trailing zeros. If the number of picoseconds is zero, nothing is produced (not even the decimal point).
</li></ul><p>
Rationale:
Currently %S includes decimals if there are any. This is different
from strftime, and there is no format specifier for just the integer
part of the seconds. It would be nice to have such a specifier to
implement many standard date formats (e.g. RFC 822). Also a specifier
for second decimals would also help when using %s. Currently there is
no reasonable way to get more than integer second precision with
since-epoch timestamps. Thus the current %S would be equivalent to
%S%Q under this proposal.
</p>
<ul><li>Add %f: The century part of the week date year.
</li></ul><p>
Rationale:
There is a %g specifier for the last two digits of the week date year, but no specifier
for the century. %C cannot be used, since the normal century and the week date
century can differ:
</p>
<pre class="wiki">> formatTime defaultTimeLocale "%Y %G" (fromGregorian 2000 1 1)
"2000 1999"
</pre><ul><li>Change %Z to produce the time zone offset if the time zone name is "".
</li></ul><p>
Rationale:
Without this, if you format a ZonedTime which contains an unnamed timezone,
%Z produces the empty string. This is invalid in many formats. It would be better
to output the offset when there is no timezone name.
</p>
<ul><li>Add Eq and Ord instances for ZonedTime?
</li></ul><p>
Rationale:
It's useful at least for the QuickCheck properties, but probably also
elsewhere. There are lots of standard functions that want Eq and Ord.
</p>
<p>
Problems:
</p>
<p>
Should ZonedTimes be converted to UTC and compared, or should times in
different timezones never be equal? I would argue for the latter, but
I suspect that this problem is the reason why it never got included in
the first place.
</p>
<p>
Interestingly, there is a derived instance of Eq for TimeZone, which
means that timezones with the same offset but different names are
considered different. Following this logic, I think that ZonedTimes
with different timezones should also be different. This should be
noted in the documentation.
</p>
<ul><li>Add Typeable and Data instances for all the time package types.
</li></ul><p>
Rationale:
It's useful and doesn't hurt anyone.
</p>
<h3 id="Fixedbugs1">Fixed bugs</h3>
<ul><li>formatTime "%c" does not include the time zone even when applied to ZonedTime or UTCTime, since "%c" is handled by the FormatTime LocalTime instance:
</li></ul><pre class="wiki">> fmap (formatTime System.Locale.defaultTimeLocale "%c") getZonedTime
"Sat Nov 11 19:12:45.395568 2006"
> fmap (formatTime System.Locale.defaultTimeLocale "%c") getCurrentTime
"Sat Nov 11 18:13:52.010944 2006"
</pre><ul><li>s/propleptic/proleptic/ in Data/Time/Calendar/JulianYearDay.hs and Data/Time/Calendar/OrdinalDate.hs
</li></ul><ul><li>formatTime documentation of range of %U and %W was wrong, should include 00.
</li></ul><ul><li>The showWeekDate haddock comment is: "show in ISO 8601 Week Date format as yyyy-Www-dd (e.g."
</li></ul><ul><li>The taiEpoch haddock comment is just "The epoch of TAI, which is"
</li></ul><h3 id="Unfixedbugs1">Unfixed bugs</h3>
<ul><li>The haddock comments for toJulianYearAndDay and isJulianLeapYear in Data.Time.Calendar.JulianYearDay talk about the proleptic Gregorian calendar. This looks like a copy-and-paste problem. What is the calendar called? Proleptic Julian?
</li></ul>Resultshttp://ghc.haskell.org/trac/ghc/ticket/1007#changelog
http://ghc.haskell.org/trac/ghc/ticket/2053
http://ghc.haskell.org/trac/ghc/ticket/2053#2053: Add read_history and write_history bindings to readlineSat, 19 Jan 2008 07:03:54 GMTajd<p>
Add Haskell bindings for the GNU Readline functions read_history and write_history to the readline package. See <a class="closed ticket" href="http://ghc.haskell.org/trac/ghc/ticket/2050" title="feature request: GHCi should keep a persistent history file (closed: fixed)">#2050</a>.
</p>
<p>
Please send feedback to libraries@… by Saturday 26 January 2007.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/2053#changelog
http://ghc.haskell.org/trac/ghc/ticket/1222
http://ghc.haskell.org/trac/ghc/ticket/1222#1222: Add the "optionMaybe" combinator to ParsecTue, 13 Mar 2007 20:55:44 GMTMaxime Henrion <mux@…><p>
This patch adds a new combinator named 'optionMaybe' that is just a specialized version of the existing 'option' combinator: it wraps the result into a Maybe type with the expected semantics. That is, intuitively, if the parser fails, 'Nothing' is returned, and if the parser succeeds, 'Just a' is returned (with 'a' being the type of the parser).
</p>
<p>
It seems generally useful, and has received positive feedback from the haskell-cafe mailing list and on the #haskell IRC channel, where several people have already written something similar a few times.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/1222#changelog
http://ghc.haskell.org/trac/ghc/ticket/1594
http://ghc.haskell.org/trac/ghc/ticket/1594#1594: Better QuickCheck/HUnit integrationTue, 07 Aug 2007 17:58:38 GMTigloo<p>
Daniel Burrows <dburrows@…> in
<a class="ext-link" href="http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=355215"><span class="icon"></span>http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=355215</a>
requests:
</p>
<p>
Quickcheck and HUnit are both great tools for testing software, but it
seems to be rather difficult to make them work together. In particular,
since the signature of all the quickCheck interface functions is some
variant on
</p>
<pre class="wiki">Testable a => a -> IO ()
</pre><p>
the only way to find out whether a test succeeded or failed is to read
the terminal output. It would be ideal if QuickCheck could generate HUnit
assertion failures when a test failed (maybe by expanding the Config
structure with "failure hooks"), but even just changing its signature
to either
</p>
<pre class="wiki">Testable a => a -> IO Bool
</pre><p>
returning True for success, or (slightly more ambitiously)
</p>
<pre class="wiki">Testable a => a -> IO (Maybe String)
</pre><p>
returning Nothing for success and an error message otherwise would be
enough to get basic integration working.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/1594#changelog
http://ghc.haskell.org/trac/ghc/ticket/2535
http://ghc.haskell.org/trac/ghc/ticket/2535#2535: Bug fix for QuickCheck 1.1.0.0Fri, 22 Aug 2008 04:18:13 GMTpatperry<p>
There is currently a bug in "variant" that manifests itself in the coarbitrary function for Double and Float. It has been previously reported here:
</p>
<p>
<a class="ext-link" href="http://hackage.haskell.org/trac/ghc/ticket/2065"><span class="icon"></span>http://hackage.haskell.org/trac/ghc/ticket/2065</a>
</p>
<p>
The attached patch fixes the problem.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/2535#changelog
http://ghc.haskell.org/trac/ghc/ticket/1169
http://ghc.haskell.org/trac/ghc/ticket/1169#1169: Control.Monad.Cont documentationSat, 24 Feb 2007 02:44:15 GMTAndriy<p>
Currently this important monad module does not have any haddock comment.
</p>
<p>
Per Jeff Newbern's gracious permission included relevant information from his cool tutorial "All About Monads" <a class="ext-link" href="http://www.nomaware.com/monads/"><span class="icon"></span>http://www.nomaware.com/monads/</a>, created a couple of examples.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/1169#changelog
http://ghc.haskell.org/trac/ghc/ticket/1410
http://ghc.haskell.org/trac/ghc/ticket/1410#1410: Control.Monad.Reader documentationTue, 05 Jun 2007 04:04:15 GMTguest<p>
Added Haddock documentation. Converted the existing module documentation to Haddock format. Created examples. Per Jeff Newberns permission included parts his tutorial "All About Monads" <a class="ext-link" href="http://haskell.org/all_about_monads/"><span class="icon"></span>http://haskell.org/all_about_monads/</a>.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/1410#changelog
http://ghc.haskell.org/trac/ghc/ticket/1598
http://ghc.haskell.org/trac/ghc/ticket/1598#1598: Could instances of Typeable, Data be added?Tue, 07 Aug 2007 20:34:37 GMTigloo<p>
In <a class="ext-link" href="http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=426612"><span class="icon"></span>http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=426612</a>
Mark Carroll <mark@…> writes:
</p>
<p>
Could some of the data structures, such as Data.Time.Calendar.Day and
Data.Time.LocalTime.TimeOfDay, be made instances of Typeable and Data
so that they can be used with Data.Generics, etc.?
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/1598#changelog
http://ghc.haskell.org/trac/ghc/ticket/2324
http://ghc.haskell.org/trac/ghc/ticket/2324#2324: Data.Tree.Zipper in containers packageSat, 31 May 2008 08:32:53 GMTkr.angelov<p>
The proposal is to add Data.Tree.Zipper implementation in the containers package. The current implementation with QuickCheck properties is attached. The dead line for considerations is one week after the ticket submissions.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/2324#changelog
http://ghc.haskell.org/trac/ghc/ticket/3973
http://ghc.haskell.org/trac/ghc/ticket/3973#3973: Derive Typeable and Eq instances for TMVar, TChan (and TArray)Sat, 10 Apr 2010 13:47:26 GMTbasvandijk<p>
I would like to propose deriving <tt>Typeable</tt> and <tt>Eq</tt> instances for <tt>TMVar</tt> and <tt>TChan</tt> because their <tt>MVar</tt> counterparts have them also.
</p>
<p>
The included patch bundle adds them using the <tt>DeriveDataTypeable</tt> language extension.
</p>
<p>
There are two extra patches in the bundle that derive a <tt>Typeable</tt> instance for <tt>TArray</tt> and derive an <tt>Eq</tt> instance for <tt>TArray</tt>. These are separate patches because I'm not sure about the latter.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/3973#changelog
http://ghc.haskell.org/trac/ghc/ticket/2646
http://ghc.haskell.org/trac/ghc/ticket/2646#2646: Expand folding options for Sets and MapsThu, 02 Oct 2008 19:19:26 GMTsedillard<p>
xref <a class="closed ticket" href="http://ghc.haskell.org/trac/ghc/ticket/2580" title="proposal: export Data.Map.toDescList (closed: fixed)">#2580</a> ,
<a class="ext-link" href="http://www.haskell.org/pipermail/libraries/2008-September/010653.html"><span class="icon"></span>http://www.haskell.org/pipermail/libraries/2008-September/010653.html</a> , <a class="ext-link" href="http://www.haskell.org/pipermail/libraries/2008-October/010782.html"><span class="icon"></span>http://www.haskell.org/pipermail/libraries/2008-October/010782.html</a>
</p>
<p>
I've attached a patch which expands on Evan's changes and propagates them to <tt>IntSet</tt> and <tt>IntMap</tt>.
</p>
<p>
Some (possibly controversial) changes of note :
</p>
<ul><li>Added foldr and foldl functions for the map types. This is redundant, but so is much of the interface. The argument to foldlWithKey has a strange type, (a -> key -> value -> a), that does not play nicely with flip and const. So I think its convenient to have foldl as well, and since we've got that why not throw foldr in too.
</li></ul><ul><li>Specialized default implementations of foldl and foldr for Foldable class. This is perhaps better than exporting then from the map libraries. Data.Sequence does it this way, but the map libraries do not. If the API clutter is found to be unbearable then perhaps a major cleanup is in order, hiding all folds in the map/set modules and exporting them via Foldable.
</li></ul><p>
Shall I also add strict versions?
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/2646#changelog
http://ghc.haskell.org/trac/ghc/ticket/2769
http://ghc.haskell.org/trac/ghc/ticket/2769#2769: Export mapAccumR from Data.Map, Data.IntMapTue, 11 Nov 2008 21:01:43 GMTDeewiant<p>
For some reason, the <tt>mapAccumR</tt> function isn't exported from <tt>Data.Map</tt> or <tt>Data.IntMap</tt>: it's just commented out. Attached is a patch which corrects that.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/2769#changelog
http://ghc.haskell.org/trac/ghc/ticket/2998
http://ghc.haskell.org/trac/ghc/ticket/2998#2998: Expose the internals of the network library to make it more extensibleSun, 01 Feb 2009 23:12:59 GMTtibbe<p>
When creating new libraries on top of the network library it would be convenient if the library exposed some functions that hide platform variations so that the new libraries can be written in a portable manner.
</p>
<p>
Take for example the currently un-exported <tt>pokeSockAddr</tt> function which marshalls a <tt>SockAddr</tt> into a <tt>sockaddr</tt> struct. This function would be useful when e.g. writing a binding for the <tt>sendmsg</tt> system call. However, it's not exported so libraries are forced to define their own version.
</p>
<p>
This is unfortunate. I propose we add a new module, <tt>Network.Socket.Internal</tt>, to the network library, that exposes these portable marshalling functions. It might also be a good idea to expose some internal data representations in the same way bytestring currently does. People who write code that uses this internal do so knowing that there is a risk that the interface and data representations might change.
</p>
<p>
I've written a patch that exposes some of the library's internal functions. There are still some documentation to write and perhaps a few more functions to expose but I think we should reach consensus on whether this is a good idea to begin with before continuing.
</p>
<p>
Since this change isn't disruptive I propose a two week consideration deadline.
</p>
<p>
Cabal package:
</p>
<p>
<a class="ext-link" href="http://johantibell.com/network-2.2.1.tar.gz"><span class="icon"></span>http://johantibell.com/network-2.2.1.tar.gz</a>
</p>
<p>
Haddock:
</p>
<p>
<a class="ext-link" href="http://johantibell.com/network/doc/html/network/"><span class="icon"></span>http://johantibell.com/network/doc/html/network/</a>
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/2998#changelog
http://ghc.haskell.org/trac/ghc/ticket/2430
http://ghc.haskell.org/trac/ghc/ticket/2430#2430: Fix bug 1985Thu, 10 Jul 2008 05:53:38 GMTdbenbenn<p>
Proposal: fix bug 1985 (<a class="ext-link" href="http://hackage.haskell.org/trac/ghc/ticket/1985"><span class="icon"></span>http://hackage.haskell.org/trac/ghc/ticket/1985</a>)
</p>
<p>
Time scale: Well, it's already been 6 months, so why not 6 more months?
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/2430#changelog
http://ghc.haskell.org/trac/ghc/ticket/4251
http://ghc.haskell.org/trac/ghc/ticket/4251#4251: GHC hangs during Network.HTTP.simpleHTTP on Windows XP SP3, Windows 7Wed, 11 Aug 2010 14:53:39 GMTbalta2ar<p>
After executing:
</p>
<p>
<tt>simpleHTTP (getRequest "http://maps.google.com/maps/api/geocode/json?address=London&sensor=false")</tt>
</p>
<p>
GHC hangs and consumes all the CPU resources (CPU load rises to 100%).
</p>
<p>
Sample log:
</p>
<pre class="wiki">C:\>ghci -v -dcore-lint
GHCi, version 6.12.3: http://www.haskell.org/ghc/ :? for help
Glasgow Haskell Compiler, Version 6.12.3, for Haskell 98, stage 2 booted by GHC version 6.10.4
Using binary package database: C:\PROGRA~1\HASKEL~1\201020~1.0\lib\package.conf.d\package.cache
Using binary package database: C:\Documents and Settings\User\Application Data\ghc\i386-mingw32-6.12.3\package.conf.d\package.cache
hiding package regex-posix-0.94.2 to avoid conflict with later version regex-posix-0.94.4
hiding package base-3.0.3.2 to avoid conflict with later version base-4.2.0.2
wired-in package ghc-prim mapped to ghc-prim-0.2.0.0-2feb0cb38f65a4827135ada88c34f3ef
wired-in package integer-gmp mapped to integer-gmp-0.2.0.1-72436e28c79d056c87cc0d2d2f9f3773
wired-in package base mapped to base-4.2.0.2-0d1804f62045e52b2e806996d84f5318
wired-in package rts mapped to builtin_rts
wired-in package haskell98 mapped to haskell98-1.0.1.1-b5196101fd7a8c42a8d53bd8033d6765
wired-in package template-haskell mapped to template-haskell-2.4.0.1-401621dedd4a5f07bfd8630247358bf5
wired-in package dph-seq mapped to dph-seq-0.4.0-be069f0bb710922a6ddd4ed2b91e3a6c
wired-in package dph-par mapped to dph-par-0.4.0-b31a0ce10b7c92126978fcc929077ad6
Hsc static flags: -static
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Loading package ffi-1.0 ... linking ... done.
Prelude> :module +Network.HTTP
Prelude Network.HTTP> simpleHTTP (getRequest "http://maps.google.com/maps/api/geocode/json?address=London&sensor=false")
*** Parser:
*** Desugar:
*** Simplify:
*** CorePrep:
*** ByteCodeGen:
Loading package syb-0.1.0.2 ... linking ... done.
Loading package base-3.0.3.2 ... linking ... done.
Loading package parsec-2.1.0.1 ... linking ... done.
Loading package network-2.2.1.7 ... linking ... done.
Loading package mtl-1.1.0.2 ... linking ... done.
Loading package bytestring-0.9.1.7 ... linking ... done.
Loading package Win32-2.2.0.2 ... linking ... done.
Loading package array-0.3.0.1 ... linking ... done.
Loading package old-locale-1.0.0.2 ... linking ... done.
Loading package old-time-1.0.0.5 ... linking ... done.
Loading package HTTP-4000.0.9 ... linking ... done.
*GHC hangs here*
</pre><p>
I'm using Windows XP SP3, Haskell Platform 2010.2.0.0. No firewall or proxy restrictions.
</p>
<p>
The bug was also reported here:
<a class="ext-link" href="http://groups.google.com/group/haskell-cafe/browse_thread/thread/4e4a7e5eb92d1b81/48300428c7c10a57?lnk=gst&q=HTTP+package#48300428c7c10a57"><span class="icon"></span>http://groups.google.com/group/haskell-cafe/browse_thread/thread/4e4a7e5eb92d1b81/48300428c7c10a57?lnk=gst&q=HTTP+package#48300428c7c10a57</a>
</p>
<p>
There's a file in attachment with Wireshark's capture during the sample execution.
</p>
<p>
Note the same sample on ghc 6.12.1, haskell-network 2.2.1.7-3 on ArchLinux works just fine.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/4251#changelog
http://ghc.haskell.org/trac/ghc/ticket/1692
http://ghc.haskell.org/trac/ghc/ticket/1692#1692: GLUT timedCallback fires twiceThu, 13 Sep 2007 20:22:37 GMTrichardg@…<p>
The Graphics.UI.GLUT.Callbacks.Global.addTimerCallback doesn't function as expected when called from a timed callback.
</p>
<p>
Expected Behavior:
When a timed callback is registered, it fires at the specified interval.
</p>
<p>
Observed Behavior:
If the timed callback is registered from a timed callback, the callback fires immediately every other time. The first callback is appropriately delayed and the second fires immediately.
</p>
<p>
Impact:
50% of callbacks fire prematurely.
</p>
<p>
Workaround:
Check the time between callbacks. If the callback occurs within a certain amount of time, do no work and register another callback. Repeat until a reasonable amount of time has passed.
</p>
<p>
System:
Mac OS X 10.4.10,
Macbook Pro 2.33 GHz Core 2 Duo, 2 GB of RAM, ATI X1600
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/1692#changelog
http://ghc.haskell.org/trac/ghc/ticket/476
http://ghc.haskell.org/trac/ghc/ticket/476#476: HUnit treats failures as errorsFri, 04 Nov 2005 10:03:01 GMTstefanheimann<pre class="wiki">HUnit treats a failure in a testcase as an error. I
attached a patch that fixes the problem. I tested the
patch with ghc and hugs.
</pre>Resultshttp://ghc.haskell.org/trac/ghc/ticket/476#changelog
http://ghc.haskell.org/trac/ghc/ticket/1135
http://ghc.haskell.org/trac/ghc/ticket/1135#1135: HsTime.h isn't installed by the Windows installerTue, 06 Feb 2007 15:10:15 GMTigloo<p>
[I'm not sure if this is really a bug in the Windows installer maker or if it's a problem with building the library with ghc (rather than as a standalone cabal package). I can reproduce it on my Windows install, but not with the Debian packages]
</p>
<p>
Alistair Bayley reports in <a class="ext-link" href="http://www.haskell.org/pipermail/libraries/2007-February/006864.html"><span class="icon"></span>http://www.haskell.org/pipermail/libraries/2007-February/006864.html</a>
</p>
<p>
If I try to compile this Main.hs:
</p>
<pre class="wiki">module Main where
import Data.Time
main = getCurrentTime >>= print
</pre><p>
with this ghc-6.6 command:
</p>
<pre class="wiki">ghc --make Main -o test -O
</pre><p>
... I get this error:
</p>
<pre class="wiki">C:\DOCUME~1\bayleya\LOCALS~1\Temp\ghc728_0\ghc728_0.hc:8:20: HsTime.h:
No such file or directory
</pre>Resultshttp://ghc.haskell.org/trac/ghc/ticket/1135#changelog
http://ghc.haskell.org/trac/ghc/ticket/3999
http://ghc.haskell.org/trac/ghc/ticket/3999#3999: Improved folds for Data.Map and Data.IntMapWed, 21 Apr 2010 22:39:57 GMTLouisWasserman<p>
This proposal aims to make the following improvements:
</p>
<p>
Previously, Data.Map's Foldable instance consisted of
</p>
<pre class="wiki">instance Foldable (Map k) where
foldMap ...
</pre><p>
Even though there were implementations for foldrWithKey and foldlWithKey, these weren't being used in the Foldable instance -- instead, the slower version derived from foldMap was in use. This is silly, since foldr and foldl can be easily derived from foldrWithKey and foldlWithKey.
</p>
<p>
Additionally, it takes relatively little effort to ensure that keys, elems, toList, etc. deforest under folds. Therefore, we add the following rewrite rules:
</p>
<p>
{-# RULES
</p>
<blockquote>
<p>
"foldr/Data.Map.elems" forall f z m . foldr f z (elems m) = foldr f z m;
"foldl/Data.Map.elems" forall f z m . foldl f z (elems m) = foldl f z m;
"foldr/Data.Map.keys" forall f z m . foldr f z (keys m) = foldrWithKey (\ k _ -> f k) z m;
"foldl/Data.Map.keys" forall f z m . foldl f z (keys m) = foldlWithKey (\ z k _ -> f z k) z m;
"foldr/Data.Map.toAscList" forall f z m . foldr f z (toAscList m) = foldrWithKey (curry f) z m;
"foldl/Data.Map.toAscList" forall f z m . foldl f z (toAscList m) = foldlWithKey (curry . f) z m;
#-}
</p>
</blockquote>
<p>
Finally, we implement foldrWithKey and foldlWithKey for Data.IntMap, and make the same adjustments to Data.IntMap as to Data.Map, adding specialized foldr and foldl definitions in the Foldable instance and adding the corresponding rewrite rules.
</p>
<p>
The only API change is the addition of foldrWithKey and foldlWithKey to Data.IntMap, but folds over Maps and IntMaps are exposed to optimization.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/3999#changelog
http://ghc.haskell.org/trac/ghc/ticket/2034
http://ghc.haskell.org/trac/ghc/ticket/2034#2034: In FilePath, current directory should be ".", not ""Sat, 12 Jan 2008 17:37:18 GMTigloo<p>
FilePath's "current directory" should be ".", not "". This affects a number of commands, e.g.
</p>
<pre class="wiki">normalise "." should be "." not ""
"." </> "foo" should be "foo" not "./foo"
splitFileName "foo" should be (".","foo") not ("","foo")
</pre><p>
Some discussion is in this thread:
<a class="ext-link" href="http://www.haskell.org/pipermail/libraries/2007-December/008743.html"><span class="icon"></span>http://www.haskell.org/pipermail/libraries/2007-December/008743.html</a>
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/2034#changelog
http://ghc.haskell.org/trac/ghc/ticket/1985
http://ghc.haskell.org/trac/ghc/ticket/1985#1985: IntSet.deleteMin doesn't agree with Set.deleteMinMon, 17 Dec 2007 12:04:15 GMTdbenbenn<p>
(IntSet.deleteMin IntSet.empty) is error, while (Set.deleteMin Set.empty == Set.empty). Set and IntSet should have identical behavior whenever possible (so that Set Int can be replaced by IntSet without introducing bugs).
</p>
<p>
Since IntSet.deleteMin is newer, presumably it should be changed to agree with Set.deleteMin.
</p>
<p>
The same issue applies to IntSet.deleteMax, (snd . IntSet.deleteFindMin), and (snd . IntSet.deleteFindMax). Also Data.IntMap.
</p>
<p>
This behavior was introduced in ticket 1229.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/1985#changelog
http://ghc.haskell.org/trac/ghc/ticket/1243
http://ghc.haskell.org/trac/ghc/ticket/1243#1243: Linking error of ALUTSun, 25 Mar 2007 03:44:40 GMTguest<p>
ALUT bindings in <a class="ext-link" href="http://hackage.haskell.org/packages/archive/pkg-list.html"><span class="icon"></span>http://hackage.haskell.org/packages/archive/pkg-list.html</a>
does not work in Windows.
</p>
<hr />
<p>
"ghc -package ALUT HelloWorld.hs" returns the following error.
</p>
<p>
C:\Program Files\Haskell\ALUT-2.0\ghc-6.6/libHSALUT-2.0.a(Config.o):fake:(.text+
0x18): undefined reference to `alutInit@8'
</p>
<p>
C:\Program Files\Haskell\ALUT-2.0\ghc-6.6/libHSALUT-2.0.a(Config.o):fake:(.text+
0xdc): undefined reference to `alutInitWithoutContext@8'
</p>
<p>
C:\Program Files\Haskell\ALUT-2.0\ghc-6.6/libHSALUT-2.0.a(Config.o):fake:(.text+
0x19d): undefined reference to `alutExit@0'
</p>
<p>
C:\Program Files\Haskell\ALUT-2.0\ghc-6.6/libHSALUT-2.0.a(Config.o):fake:(.text+
0x1d9): undefined reference to `alutGetError@0'
</p>
<p>
C:\Program Files\Haskell\ALUT-2.0\ghc-6.6/libHSALUT-2.0.a(Config.o):fake:(.text+
0x210): undefined reference to `alutCreateBufferFromFile@4'
</p>
<p>
C:\Program Files\Haskell\ALUT-2.0\ghc-6.6/libHSALUT-2.0.a(Config.o):fake:(.text+
0x2b0): undefined reference to `alutCreateBufferFromFileImage@8'
</p>
<p>
C:\Program Files\Haskell\ALUT-2.0\ghc-6.6/libHSALUT-2.0.a(Config.o):fake:(.text+
0x36d): undefined reference to `alutCreateBufferHelloWorld@0'
</p>
<p>
C:\Program Files\Haskell\ALUT-2.0\ghc-6.6/libHSALUT-2.0.a(Config.o):fake:(.text+
0x3f7): undefined reference to `alutCreateBufferWaveform@16'
</p>
<p>
C:\Program Files\Haskell\ALUT-2.0\ghc-6.6/libHSALUT-2.0.a(Config.o):fake:(.text+
0x584): undefined reference to `alutLoadMemoryFromFile@16'
</p>
<p>
C:\Program Files\Haskell\ALUT-2.0\ghc-6.6/libHSALUT-2.0.a(Config.o):fake:(.text+
0x6b8): undefined reference to `alutLoadMemoryFromFileImage@20'
</p>
<p>
C:\Program Files\Haskell\ALUT-2.0\ghc-6.6/libHSALUT-2.0.a(Config.o):fake:(.text+
0x7e8): undefined reference to `alutLoadMemoryHelloWorld@12'
</p>
<p>
C:\Program Files\Haskell\ALUT-2.0\ghc-6.6/libHSALUT-2.0.a(Config.o):fake:(.text+
0x92f): undefined reference to `alutLoadMemoryWaveform@28'
</p>
<p>
C:\Program Files\Haskell\ALUT-2.0\ghc-6.6/libHSALUT-2.0.a(Config.o):fake:(.text+
0xb2c): undefined reference to `alutGetMIMETypes@4'
</p>
<p>
C:\Program Files\Haskell\ALUT-2.0\ghc-6.6/libHSALUT-2.0.a(Config.o):fake:(.text+
0xbc9): undefined reference to `alutGetMajorVersion@0'
</p>
<p>
C:\Program Files\Haskell\ALUT-2.0\ghc-6.6/libHSALUT-2.0.a(Config.o):fake:(.text+
0xc01): undefined reference to `alutGetMinorVersion@0'
</p>
<p>
C:\Program Files\Haskell\ALUT-2.0\ghc-6.6/libHSALUT-2.0.a(Config.o):fake:(.text+
0xc55): undefined reference to `alutSleep@4'
</p>
<p>
C:\Program Files\Haskell\ALUT-2.0\ghc-6.6/libHSALUT-2.0.a(Config.o):fake:(.text+
0xd89): undefined reference to `alutGetErrorString@4'
</p>
<p>
collect2: ld returned 1 exit status
</p>
<hr />
<p>
libHSALUT-2.0.a has a symbol "??@..", but alut.lib does not have "@.." of "??@..". I think this omitting "@.." is a cause of these errors.
</p>
<p>
environment: Windows XP SP2, MinGW/MSYS, GHC6.6
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/1243#changelog
http://ghc.haskell.org/trac/ghc/ticket/1266
http://ghc.haskell.org/trac/ghc/ticket/1266#1266: Make Data.Graph.Inductive.NodeMap handle slightly messy input without crashingWed, 04 Apr 2007 06:29:40 GMTjyasskin@…<p>
Using the current version of Data.Graph.Inductive casually is unnecessarily difficult because if you insert a node that's already present in the graph, or try to insert an edge with an endpoint that's not already in the graph, the library crashes. For the raw graph operations that's somewhat reasonable since it wouldn't know what labels to use. NodeMap, on the other hand, has plenty of information, so this patch makes it safer in these cases.
</p>
<p>
I've also added the beginning of a test suite runnable with <tt>runhaskell Setup.hs test</tt>.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/1266#changelog
http://ghc.haskell.org/trac/ghc/ticket/4109
http://ghc.haskell.org/trac/ghc/ticket/4109#4109: Make Data.Map.insertWith' and friends consistently force the value insertedSun, 30 May 2010 22:31:19 GMTigloo<p>
Currently, <tt>Data.Map.insertWith'</tt> (and friends) only force the value inserted when the combining function creates it:
</p>
<pre class="wiki">Prelude Data.Map> insertWith' (+) "foo" undefined empty `seq` ()
()
Prelude Data.Map> insertWith' (+) "foo" undefined (singleton "foo" 1) `seq` ()
*** Exception: Prelude.undefined
</pre><p>
I think it would be more consistent for it to always force it:
</p>
<pre class="wiki">Prelude Data.Map> insertWith' (+) "foo" undefined empty `seq` ()
*** Exception: Prelude.undefined
Prelude Data.Map> insertWith' (+) "foo" undefined (singleton "foo" 1) `seq` ()
*** Exception: Prelude.undefined
</pre><p>
Patch:
</p>
<pre class="wiki">hunk ./Data/Map.hs 460
insertWithKey' :: Ord k => (k -> a -> a -> a) -> k -> a -> Map k a -> Map k a
insertWithKey' f kx x t
= case t of
- Tip -> singleton kx x
+ Tip -> singleton kx $! x
Bin sy ky y l r
-> case compare kx ky of
LT -> balance ky y (insertWithKey' f kx x l) r
</pre><p>
Suggested discussion deadline: 14 June 2010.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/4109#changelog
http://ghc.haskell.org/trac/ghc/ticket/1127
http://ghc.haskell.org/trac/ghc/ticket/1127#1127: Make mtl lazierTue, 30 Jan 2007 16:51:53 GMTigloo<p>
I propose making mtl lazier. Currently the transformers force tuples to WHNF as they put them on the left of <- in do blocks. I suspect this was unintentional, and makes them less lazy than their non-transformer counterparts.
</p>
<p>
For example, the StateT monad gives every impression of intending to be lazy, but the absence of a ~ means that it isn't fully lazy. This bit me in the compression library, meaning I currently bundle a LazyStateT module that provides essentially StateT with this change. There was also a recent discussion about it on one of the mailing lists: <a class="ext-link" href="http://www.haskell.org/pipermail/haskell-cafe/2007-January/021244.html"><span class="icon"></span>http://www.haskell.org/pipermail/haskell-cafe/2007-January/021244.html</a>
</p>
<p>
Deadline: 28 February 2007.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/1127#changelog
http://ghc.haskell.org/trac/ghc/ticket/1452
http://ghc.haskell.org/trac/ghc/ticket/1452#1452: Modules omitted from a .cabal file are not reported, but result in a non-functional libraryFri, 22 Jun 2007 11:41:08 GMTguest<p>
<a class="ext-link" href="http://www.botik.ru/pub/local/Mechveliani/ghcBugs/importCycleBug.zip"><span class="icon"></span>http://www.botik.ru/pub/local/Mechveliani/ghcBugs/importCycleBug.zip</a>
</p>
<p>
Unzip and see install.txt.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/1452#changelog
http://ghc.haskell.org/trac/ghc/ticket/3271
http://ghc.haskell.org/trac/ghc/ticket/3271#3271: New methods for Data.SequenceTue, 02 Jun 2009 21:36:33 GMTLouisWasserman<p>
<tt>Data.Sequence</tt> is meant as a general-purpose implementation of finite sequences. The range of methods it offers, however, is considerably more constrained than <tt>Data.List</tt>, even allowing for the constraint that sequences are finite.
</p>
<p>
The following methods cannot be efficiently implemented based on currently exported methods from <tt>Data.Sequence</tt>.
</p>
<ul><li><tt>zipWith</tt> and its variants. Note: it suffices to define <tt>zipWith</tt> alone.
</li><li><tt>replicate</tt>. (This can be implemented in <tt>O(log n)</tt> time with node sharing.)
</li></ul><p>
The following methods are relatively simple extensions of already-exported methods. It may be more appropriate to allow library users to reimplement them themselves.
</p>
<ul><li><tt>scanl</tt>, <tt>scanr</tt>, and variants. This is relatively straightforward using methods borrowed from the <tt>Traversable</tt> instance.
</li><li><tt>tails</tt> and <tt>inits</tt>. <tt>tails</tt> is equivalent to <tt>scanr (<|) empty</tt>; <tt>inits</tt> is similar.
</li><li><tt>takeWhile</tt>, <tt>dropWhile</tt>, <tt>span</tt>, <tt>break</tt> (and perhaps from-the-end variations). Finding a breakpoint index can be done as efficiently on lists as on sequences; find the appropriate breakpoint index after converting to a list and use <tt>splitAt</tt>.
</li><li><tt>unfoldr</tt> and <tt>iterate</tt>, though the latter would require a finite number of iterations to perform.
</li><li><tt>partition</tt>. I can conceive of a slightly more efficient implementation than the trivial one, but the gains may be minimal.
</li></ul>Resultshttp://ghc.haskell.org/trac/ghc/ticket/3271#changelog
http://ghc.haskell.org/trac/ghc/ticket/309
http://ghc.haskell.org/trac/ghc/ticket/309#309: ObjectIO-Lib: Problem scrolling compund controlMon, 21 Feb 2005 10:20:12 GMTbrassel<pre class="wiki">Problem 1:
When using the ObjectIO library, setting the view
domain of a compund control does not correctly adjust
the min/max settings of the corresponding scroll-sliders.
Problem 2:
When trying to work around this bug, it turns out that
you can only set the scroll function for Horizontal
scrolling but not for Vertical scrolling.
Do you need an example programs for the bugs?
</pre>Resultshttp://ghc.haskell.org/trac/ghc/ticket/309#changelog
http://ghc.haskell.org/trac/ghc/ticket/408
http://ghc.haskell.org/trac/ghc/ticket/408#408: OpenAL needs -pthreadMon, 27 Jun 2005 08:04:50 GMTvolkersf<pre class="wiki">On FreeBSD (and maybe NetBSD as well), OpenAL needs -pthread in
CFLAGS/LDFLAGS:
configure:2352: gcc -o conftest -I/usr/local/include -L/usr/local/lib
conftest.c -lopenal >&5
/usr/local/lib/libopenal.so: undefined reference to `pthread_create'
/usr/local/lib/libopenal.so: undefined reference to `pthread_attr_init'
/usr/local/lib/libopenal.so: undefined reference to `pthread_exit'
This should best be solved during configure instead of setting this
globally. Also, this probably needs to be propagated into OpenAL.
cabal for linking a resulting application (although already the RTS
should pull in -pthread).
</pre>Resultshttp://ghc.haskell.org/trac/ghc/ticket/408#changelog
http://ghc.haskell.org/trac/ghc/ticket/1597
http://ghc.haskell.org/trac/ghc/ticket/1597#1597: OpenGL: Bindings for GLE library?Tue, 07 Aug 2007 20:28:34 GMTigloo<p>
In <a class="ext-link" href="http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=419125"><span class="icon"></span>http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=419125</a>
Josh Triplett <josh@…> writes:
</p>
<p>
In addition to the GL and GLU bindings currently provided, I'd really like
bindings to the OpenGL Tubing and Extrusion library, GLE.
<a class="ext-link" href="http://linas.org/gle/"><span class="icon"></span>http://linas.org/gle/</a> , packages libgle3 and libgle3-dev.
</p>
<p>
A GLE binding would need to make use of some of the internal Haskell modules
of haskell-opengl that don't ship in the binary package in order to provide a
compatible interface, so unless haskell-opengl changed to supply these, a GLE
binding would need to build as part of haskell-opengl.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/1597#changelog
http://ghc.haskell.org/trac/ghc/ticket/2643
http://ghc.haskell.org/trac/ghc/ticket/2643#2643: Optimized IntMap / IntSet construction from sorted inputThu, 02 Oct 2008 15:35:56 GMTsedillard<p>
Currently the "fromAscList" functions for building <tt>IntMap</tt>s and <tt>IntSet</tt>s are aliases for <tt>fromList</tt>. Building a trie in linear time from sorted input is not magic, and results in a considerable performance increase. See this post:
</p>
<p>
<a class="ext-link" href="http://www.haskell.org/pipermail/libraries/2008-May/009685.html"><span class="icon"></span>http://www.haskell.org/pipermail/libraries/2008-May/009685.html</a>
</p>
<p>
My impression was that the list generally approved of the patch, but for some reason its never been applied so I'm creating a ticket for it here. Tests are included in the patch. Really it just modifies an existing test (which was <tt>fromAscList xs == fromList xs</tt>) so that it's no longer vacuous.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/2643#changelog
http://ghc.haskell.org/trac/ghc/ticket/1521
http://ghc.haskell.org/trac/ghc/ticket/1521#1521: Problems building the time library with Cabal / Setup.hsTue, 10 Jul 2007 15:27:23 GMTOlivier Boudry<p>
I get the following error when building the time library using ghc-6.6.1 and Cabal-1.1.6.2.
</p>
<pre class="wiki">C:\Temp\time>runhaskell Setup.hs configure
Setup.hs:17:29:
Couldn't match expected type `GHC.IOBase.ExitCode'
against inferred type `()'
Expected type: Args
-> Bool
-> PackageDescription
-> LocalBuildInfo
-> IO GHC.IOBase.ExitCode
Inferred type: Args
-> Bool
-> PackageDescription
-> LocalBuildInfo
-> IO ()
In the `runTests' field of a record
In the expression:
defaultUserHooks
{confHook = add_Win32_dep $ (confHook defaultUserHooks),
runTests = runTestScript}
</pre><p>
I solved it by changing the type signature of runTestScript and removing the maybeExit function call from the body:
</p>
<pre class="wiki">import GHC.IOBase
...
runTestScript :: Args -> Bool -> PackageDescription -> LocalBuildInfo -> IO GHC.IOBase.ExitCode
runTestScript _args _flag _pd _lbi
= withCurrentDirectory "test" $ system "make"
</pre><p>
Then, the Setup.hs script compiles but I get a dependency problem
</p>
<pre class="wiki">C:\Temp\time>runhaskell Setup.hs configure
Configuring time-1.1.1...
configure: Dependency Win32-any: using Win32-2.1.1
configure: Dependency base-any: using base-2.1.1
Setup.hs: cannot satisfy dependency old-locale-any
</pre><p>
I solved it with removing that dependency from the time.cabal file.
</p>
<p>
Last issue: at installation HsTimeConfig.h is missing (copied it from ghc-6.6.1 source).
</p>
<p>
I don't know to which extent those problems are related to my specific installation. Looks like the user hooks signature has changed in the latest versions of Cabal.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/1521#changelog
http://ghc.haskell.org/trac/ghc/ticket/4313
http://ghc.haskell.org/trac/ghc/ticket/4313#4313: Proposal: Add left, right and strict folds to Data.Set, Data.IntMap and Data.IntSet to mimic Data.Map.Tue, 14 Sep 2010 16:21:28 GMTmilan<p>
This proposal depends on <a class="closed ticket" href="http://ghc.haskell.org/trac/ghc/ticket/4278" title="proposal: Proposal: Add strict versions of foldlWithKey and insertLookupWithKey to ... (closed: fixed)">#4278</a> and <a class="closed ticket" href="http://ghc.haskell.org/trac/ghc/ticket/4280" title="proposal: Proposal: Performance improvements for Data.Set (closed: fixed)">#4280</a>.
</p>
<p>
In accordance with a poll on libraries@… (see point 3 of <a class="ext-link" href="http://article.gmane.org/gmane.comp.lang.haskell.libraries/13273"><span class="icon"></span>http://article.gmane.org/gmane.comp.lang.haskell.libraries/13273</a>) I propose to add strict folds to the containers.
</p>
<p>
The Data.Map is getting left, right and strict folds in <a class="closed ticket" href="http://ghc.haskell.org/trac/ghc/ticket/4278" title="proposal: Proposal: Add strict versions of foldlWithKey and insertLookupWithKey to ... (closed: fixed)">#4278</a>. This proposal adds left, right and strict folds for Set, IntMap and IntSet.
</p>
<p>
The naming is a bit tricky. The folds in IntMap mimics Map (ie. foldrWithKey, foldlWithKey, foldlWithKey'; fold and foldWithKey are deprecated in favor of foldrWithKey). The folds in Set and IntSet are classic (foldr, foldl, foldl'; the old fold is deprecated in favor of foldr).
</p>
<p>
The repository of the containers package with these patches (and also several others) is at <a class="ext-link" href="http://fox.auryn.cz/darcs/containers/"><span class="icon"></span>http://fox.auryn.cz/darcs/containers/</a>.
</p>
<p>
The patches are also attached (including <a class="closed ticket" href="http://ghc.haskell.org/trac/ghc/ticket/4280" title="proposal: Proposal: Performance improvements for Data.Set (closed: fixed)">#4280</a>).
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/4313#changelog
http://ghc.haskell.org/trac/ghc/ticket/4278
http://ghc.haskell.org/trac/ghc/ticket/4278#4278: Proposal: Add strict versions of foldlWithKey and insertLookupWithKey to Data.MapSun, 29 Aug 2010 13:26:08 GMTtibbe<p>
This proposal depends on <a class="closed ticket" href="http://ghc.haskell.org/trac/ghc/ticket/4277" title="proposal: Proposal: Significant performance improvements for Data.Map (closed: fixed)">#4277</a>.
</p>
<p>
The current Data.Map API lacks two important functions:
</p>
<ul><li>A strict left (pre-order) fold -- needed to e.g. sum all the values in a map efficiently.
</li></ul><ul><li>A strict <tt>insertLookupWithKey'</tt> -- needed to e.g. update an integer counter and retrieve the previous value in a single traversal.
</li></ul><p>
The benchmark we ran indicates that <tt>foldlWithKey'</tt> is 95% faster than its lazy counter part. <tt>insertLookupWithKey'</tt> is only 6% faster, but the speedup is highly dependent on how many times each element is update. Each element was only updated once in our benchmark so real speedups should be larger.
</p>
<p>
The consideration period is 3 weeks.
</p>
<p>
Note that the attached patch includes the dependent patches in the above linked ticket.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/4278#changelog
http://ghc.haskell.org/trac/ghc/ticket/3777
http://ghc.haskell.org/trac/ghc/ticket/3777#3777: Split MonaIO class from mtlMon, 21 Dec 2009 05:43:12 GMTAntoineLatter<p>
I propose that the MonadIO class be split from the mtl package.
</p>
<p>
The class would live in a new package, titled monad-io, in a new module titled Control.Monad.IO. This class would then be re-exported by Control.Monad.Trans. This would add a dependency on the new package to mtl.
</p>
<p>
This would result in no change to the use or haddocks of mtl.
</p>
<p>
A package implementing the new package half of this proposal may be found at <a class="ext-link" href="http://community.haskell.org/~aslatter/code/mond-io"><span class="icon"></span>http://community.haskell.org/~aslatter/code/mond-io</a>
</p>
<p>
Discussion deadline: 2 weeks (Dec 13 2010)
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/3777#changelog
http://ghc.haskell.org/trac/ghc/ticket/1632
http://ghc.haskell.org/trac/ghc/ticket/1632#1632: Test.HUnit documentationThu, 23 Aug 2007 19:59:37 GMTguest<p>
I'd like to contribute Haddock documentation for HUnit.
</p>
<p>
Where there was documentation in comments in the original source code, I have generally used that - but it was mostly for the implementation of the text-based test runner, not the stuff that a typical library user would need for making assertions, constructing test cases etc. I've focused on the latter.
</p>
<p>
Afaik Haddock doesn't work with literate Haskell files, so I have converted to non-literate files. No code changes - just comments/docs.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/1632#changelog
http://ghc.haskell.org/trac/ghc/ticket/2003
http://ghc.haskell.org/trac/ghc/ticket/2003#2003: The Data.Time.Format parser should be more liberalThu, 27 Dec 2007 01:32:50 GMTBjornBuckwalter<p>
I (Björn Buckwalter) wrote to the libraries list:
</p>
<blockquote>
<p>
Is there a compelling reason to not make the formats in Data.Time.Format case-insensitive when parsing? This would apply to the months, weekdays, time zone. (I see there are already two formats %p and %P corresponding (confusingly) to AM/PM and am/pm respectively.)
</p>
</blockquote>
<blockquote>
<p>
What got me thinking about this is that I'm being supplied with dates on the format "26 DEC" which will not parse without munging. I suspect such situations are fairly common?
</p>
</blockquote>
<p>
To which Björn Bringert replied:
</p>
<blockquote>
<p>
I agree. The parser should be more liberal. I originally implemented rather faithful inverses of the formatting directives, but I don't really see any point in being very strict when parsing.
</p>
</blockquote>
<blockquote>
<p>
You are welcome to submit a patch for this, or at least a feature request in Trac to keep it from being forgotten.
</p>
</blockquote>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/2003#changelog
http://ghc.haskell.org/trac/ghc/ticket/1071
http://ghc.haskell.org/trac/ghc/ticket/1071#1071: The Graphics.X11 library for windows using Cygwin/XFri, 29 Dec 2006 00:54:06 GMTguest<p>
The X11 binding that exists does not follow together with the windows GHC installation.
There is an X Server for windows, see <a class="ext-link" href="http://x.cygwin.com/"><span class="icon"></span>http://x.cygwin.com/</a>.
</p>
<p>
This could follow with GHC regardless of if the user actually has a Server or not, since one could connect to a server on another computer.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/1071#changelog
http://ghc.haskell.org/trac/ghc/ticket/1140
http://ghc.haskell.org/trac/ghc/ticket/1140#1140: Use ccall for OpenAL on Windows (was part of #918)Sun, 11 Feb 2007 13:02:41 GMTthorkilnaur<p>
The patch attached to this ticket is part of a patch originally attached to <a class="closed ticket" href="http://ghc.haskell.org/trac/ghc/ticket/918" title="task: Fix HOpenAL's configure.ac bug that can't find OpenAL framework under Mac ... (closed: fixed)">#918</a> by shelarcy <shelarcy@…>. This original patch (file <tt>openal-mac-os-x.patch</tt>) corrected a Mac OS X OpenAL build problem and a Windows OpenAL build problem. The part of the patch attached here is the part that corrects a Windows OpenAL build problem. The file name (<tt>openal-mac-os-x-part-2.patch</tt>) contains the name of the original patch, but it is a Windows-related patch in spite of its name. Please refer to <a class="closed ticket" href="http://ghc.haskell.org/trac/ghc/ticket/918" title="task: Fix HOpenAL's configure.ac bug that can't find OpenAL framework under Mac ... (closed: fixed)">#918</a> for additional details.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/1140#changelog
http://ghc.haskell.org/trac/ghc/ticket/1019
http://ghc.haskell.org/trac/ghc/ticket/1019#1019: X11 package puts path to X libraries in ld-options rather than library-dirs, so ghci can't find itTue, 21 Nov 2006 01:17:12 GMTwolfgang<p>
The configure script for the X11 package puts the detected library path in a -L option in the ld-options field of the package.conf file. Instead, it should go into the library-dirs field.
</p>
<p>
On systems where X11 is not on the default path (such as Mac OS X), this means that the X11 package works only when compiling code, not from ghci, which only looks at the library-dirs field.
</p>
<p>
Workaround: On Mac OS X, people have to set DYLD_LIBRARY_PATH=/usr/X11R6/lib before running GHCi.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/1019#changelog
http://ghc.haskell.org/trac/ghc/ticket/987
http://ghc.haskell.org/trac/ghc/ticket/987#987: X11: foreign declarations use Haskell types instead of C onesMon, 06 Nov 2006 00:47:24 GMTross<p>
Sven Panne writes: Strictly speaking, the majority of types are wrong: an <tt>Int</tt> is not a <tt>CInt</tt>, and the binding will fail on platforms where the actual representation is different. There should be a general code review of all the types in the <tt>foreign import</tt>s.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/987#changelog
http://ghc.haskell.org/trac/ghc/ticket/988
http://ghc.haskell.org/trac/ghc/ticket/988#988: X11: refine types for improved type safetyMon, 06 Nov 2006 00:51:14 GMTross<p>
The library interface uses integral types all over the place instead of enumerations and <tt>newtype</tt>s, which would give greater type safety.
</p>
<p>
Fixing this would be an incompatible change, of course.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/988#changelog
http://ghc.haskell.org/trac/ghc/ticket/2540
http://ghc.haskell.org/trac/ghc/ticket/2540#2540: [Text.Regex] incorrect word boundary ("\\b") substitutions. Bug in regex-compat's subRegex handling of BOL flags.Sun, 24 Aug 2008 20:54:15 GMTEelis-<p>
Consider:
</p>
<pre class="wiki"> import Text.Regex
main = putStrLn $ subRegex (mkRegex "\\b(.)") "abcdef" "|\\1"
</pre><p>
This outputs "|a|b|c|d|e|f", while it really should output "|abcdef" (at least according to Perl and Ruby).
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/2540#changelog
http://ghc.haskell.org/trac/ghc/ticket/4887
http://ghc.haskell.org/trac/ghc/ticket/4887#4887: add a Location interface for element-wise operations on Data.MapFri, 07 Jan 2011 17:35:42 GMTross<p>
This is a variant of a suggestion by apfelmus:
</p>
<blockquote>
<p>
<a class="ext-link" href="http://www.haskell.org/pipermail/libraries/2010-September/014510.html"><span class="icon"></span>http://www.haskell.org/pipermail/libraries/2010-September/014510.html</a>
</p>
</blockquote>
<p>
To avoid proliferation of variants of element-wise operations, the idea is to split these operations into two phases mediated by a new Location type, so that users can do whatever they like between these phases. Documentation is here:
</p>
<blockquote>
<p>
<a class="ext-link" href="http://code.haskell.org/~ross/containers_doc/Data-Map.html#3"><span class="icon"></span>http://code.haskell.org/~ross/containers_doc/Data-Map.html#3</a>
</p>
</blockquote>
<p>
This adds a type and 9 functions to the interface, but makes possible monadic updates and much more. As an illustration, the file <tt>MapOps.hs</tt> attached to the ticket gives definitions of 30 of the public functions of Data.Map in terms of the new interface. <del>At least in the case of insert, this definition is slightly faster than the current one.</del>
</p>
<p>
Discussion period: 4 weeks (to 4 February)
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/4887#changelog
http://ghc.haskell.org/trac/ghc/ticket/1026
http://ghc.haskell.org/trac/ghc/ticket/1026#1026: coarbitrary for Double and FloatFri, 24 Nov 2006 11:54:46 GMTSusumu Katayama <skata@…><p>
@coarbitrary@ methods for Double and Float defined in Test.QuickCheck are not usable.
</p>
<p>
With GHC 6.6 they either consume unrealistically great amount of time and space, or cause:
<strong>* Exception: Prelude.(!!): negative index
</strong></p>
<p>
With the HEAD compiler, it soon causes great heap consumption and soon fails with stack overflow.
</p>
<h2 id="Example:">Example:</h2>
<p>
The following code gobbles the heap space quickly, so please set the maximum heap size limit, or be prepared to press CTRL-C when trying it.
</p>
<pre class="wiki">\begin{code}
import Test.QuickCheck
import Control.Monad.Fix(fix)
instance Show (a->b) where
showsPrec _ f = ("fun"++)
cata (x,f) 0 = x
cata (x,f) i = f (cata (x,f) (i-1))
kata c (x,f) 0 = x
kata c (x,f) i = f (c (x,f) (i-1))
prop_cata :: (Eq a, Show a) => Int -> a -> (a->a) -> Property
prop_cata = \i x f -> i>=0 ==> cata (x,f) i == fix kata (x,f) i
main = do verboseCheck (prop_cata :: Int -> Int -> (Int ->Int) -> Property)
verboseCheck (prop_cata :: Int -> Float -> (Float->Float) -> Property)
\end{code}
</pre><p>
(There can be a simpler example, but I do not think that is necessary because I have already tracked down the problem.)
</p>
<h2 id="Reason:">Reason:</h2>
<p>
The coarbitrary methods for Float and Double are defined as:
</p>
<pre class="wiki"> coarbitrary x = coarbitrary (decodeFloat x)
</pre><p>
where the first return value (:: Integer) of @decodeFloat :: a -> (Integer,Int)@ usually exceeds @maxBound::Int@.
It will eventually be converted into Int while computing the coarbitrary method for Integer, defined as:
</p>
<pre class="wiki"> coarbitrary n = variant (fromInteger (if n >= 0 then 2*n else 2*(-n) + 1))
</pre><p>
Because @(if n >= 0 then 2*n else 2*(-n) + 1)@ exceeds @maxBound::Int@, either of the following usually happens:
</p>
<p>
1) @variant m@ for large m is computed. Because the cost is O(m), it requests great time and space.
</p>
<p>
2) @variant m@ for negative m is requested, and that causes the "(!!): negative index" error.
</p>
<h2 id="Solution:">Solution:</h2>
<p>
@variant m@ could be computed in O(log m), for example,
</p>
<pre class="wiki">logvariant :: Integral i => i -> Gen a -> Gen a
logvariant 0 = variant 0
logvariant n | n > 0 = logvariant (n `div` 2) . variant (fromIntegral (n `mod` 2)) . variant 1
| otherwise = error "logvariant: negative argument"
</pre><p>
Also, negative arguments should be dealt with correctly, thus:
</p>
<pre class="wiki">newvariant :: Integral i => i -> Gen a -> Gen a
newvariant n | n >= 0 = logvariant n . variant 0
| otherwise = logvariant (-1-n) . variant 1
instance Arbitrary Integer where
arbitrary = ...
coarbitrary = newvariant
</pre><p>
I enclose a patch for doing the above. I minimized the affected parts, but coarbitrary for Int could also be replaced with @newvariant@. (Or even the definition of @variant@ could be replaced.)
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/1026#changelog
http://ghc.haskell.org/trac/ghc/ticket/2309
http://ghc.haskell.org/trac/ghc/ticket/2309#2309: containers: specialize functions that fail in a Monad to MaybeSat, 24 May 2008 23:56:43 GMTross<p>
Several functions on containers used to have types like
</p>
<pre class="wiki">lookup :: (Ord k) => k -> Map k a -> Maybe a
</pre><p>
but these were generalized to
</p>
<pre class="wiki">lookup :: (Monad m, Ord k) => k -> Map k a -> m a
</pre><p>
The only methods of <tt>Monad</tt> used are <tt>return</tt> and <tt>fail</tt>. The problem is that, depending on the monad, <tt>fail</tt> can be an ordinary value or a runtime error: this device makes it harder to check whether a program is safe, because it hides possible runtime errors among testable conditions.
</p>
<p>
The proposal is to change these signatures back, specializing them to <tt>Maybe</tt>.
</p>
<p>
The functions involved are:
</p>
<pre class="wiki">lookup :: Ord k => k -> Map k a -> Maybe a
lookupIndex :: Ord k => k -> Map k a -> Maybe Int
minViewWithKey :: Map k a -> Maybe ((k,a), Map k a)
maxViewWithKey :: Map k a -> Maybe ((k,a), Map k a)
minView :: Map k a -> Maybe (a, Map k a)
maxView :: Map k a -> Maybe (a, Map k a)
lookup :: Key -> IntMap a -> Maybe a
maxViewWithKey :: IntMap a -> Maybe ((Key, a), IntMap a)
minViewWithKey :: IntMap a -> Maybe ((Key, a), IntMap a)
maxView :: IntMap a -> Maybe (a, IntMap a)
minView :: IntMap a -> Maybe (a, IntMap a)
minView :: Set a -> Maybe (a, Set a)
maxView :: Set a -> Maybe (a, Set a)
maxView :: IntSet -> Maybe (Int, IntSet)
minView :: IntSet -> Maybe (Int, IntSet)
</pre><p>
No information is lost, because in each case there is a single failure mode.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/2309#changelog
http://ghc.haskell.org/trac/ghc/ticket/4868
http://ghc.haskell.org/trac/ghc/ticket/4868#4868: deepseq should not depend on containersTue, 28 Dec 2010 18:00:53 GMTtibbe<p>
The <a class="ext-link" href="http://hackage.haskell.org/package/deepseq"><span class="icon"></span>deepseq</a> package depends on the <a class="ext-link" href="http://hackage.haskell.org/package/containers"><span class="icon"></span>containers</a> package. This forces all packages that want to depend on <tt>deepseq</tt> in order to provide a <tt>NFData</tt> instance for exported types, to also depend on <tt>containers</tt>.
</p>
<p>
Proposal, have <tt>containers</tt> depend on <tt>deepseq</tt>, not the other way around, and define the <tt>NFData</tt> instances for the types in the <tt>containers</tt> package, in the <tt>containers</tt> package.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/4868#changelog
http://ghc.haskell.org/trac/ghc/ticket/3975
http://ghc.haskell.org/trac/ghc/ticket/3975#3975: filepath: normalise trailing dotSun, 11 Apr 2010 01:04:00 GMTconrad<p>
This darcs patch modifies the behaviour of normalise to handle
trailing dots in a path. The previous behaviour yielded this:
</p>
<pre class="wiki">Prelude System.FilePath> normalise "../."
"../."
Prelude System.FilePath> normalise ".././"
".././"
Prelude System.FilePath> normalise ".././.."
"../.."
</pre><p>
This patch modifies dropDots such that the check for (".":[]) only
occurs once for the path, after which a driver function dropDots' is
used which skips this check. Hence "." can be removed from the end of
a longer path, but a path of just "." is unchanged.
</p>
<p>
<a class="ext-link" href="http://www.haskell.org/pipermail/libraries/2010-February/013030.html"><span class="icon"></span>http://www.haskell.org/pipermail/libraries/2010-February/013030.html</a>
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/3975#changelog
http://ghc.haskell.org/trac/ghc/ticket/2645
http://ghc.haskell.org/trac/ghc/ticket/2645#2645: fix type, performance of IntMap(Set).findMin(Max)Thu, 02 Oct 2008 16:03:02 GMTsedillard<p>
The findMin / findMax functions for Data.IntMap currently return only the bound value, not the key, as is the case for Data.Map.findMin.
</p>
<p>
These read-only queries are implemented using <tt>maxView</tt> which modifies the tree along the path from the root to the leaf, burning heap unnecessarily. I've provided a patch to implement these as simple recursive loops, as is done with Data.Map.
</p>
<p>
Both of these issues impact the performance and usability of IntMaps when employed as purely functional arrays, maps from arbitrary ints to values. In this use case, I need to know what the range of used "addresses" is, so I can assign new ones for quickly appending items onto the front or back of the array, or offsetting the keys of one array before unioning it with another.
</p>
<p>
See list post : <a class="ext-link" href="http://www.haskell.org/pipermail/libraries/2008-May/009687.html"><span class="icon"></span>http://www.haskell.org/pipermail/libraries/2008-May/009687.html</a>
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/2645#changelog
http://ghc.haskell.org/trac/ghc/ticket/4842
http://ghc.haskell.org/trac/ghc/ticket/4842#4842: keep Data.Map.foldWithKeyTue, 14 Dec 2010 12:20:48 GMTmaeder<p>
Remove the recently introduced deprecation warning for <tt>Data.Map.foldWithKey</tt> as the aim to finally remove this function is bad as long as <tt>Data.IntMap.foldWithKey</tt> is the primary folding function for the specialized maps.
</p>
<p>
The deprecation was introduced by <a class="ext-link" href="http://hackage.haskell.org/trac/ghc/ticket/4277"><span class="icon"></span>http://hackage.haskell.org/trac/ghc/ticket/4277</a> that also added <tt>foldlWithKey</tt> and <tt>foldrWithKey</tt>.
</p>
<p>
But at least as long as these functions are not exported also by <tt>Data.IntMap</tt>, as proposed by <a class="ext-link" href="http://hackage.haskell.org/trac/ghc/ticket/3999"><span class="icon"></span>http://hackage.haskell.org/trac/ghc/ticket/3999</a>, the common name <tt>foldWithKey</tt> should be kept. Such a common name is also used for the simple "fold" functions over maps and sets.
</p>
<p>
There was already some disagreement on this point in the thread <a class="ext-link" href="http://www.haskell.org/pipermail/libraries/2010-December/015274.html"><span class="icon"></span>http://www.haskell.org/pipermail/libraries/2010-December/015274.html</a> which convinced me to create this proposal.
</p>
<p>
I think two weeks of discussion should be enough, but I'll be happy about a decision by mid January 2011.
</p>
<p>
The change is almost only cosmetic, delete:
</p>
<pre class="wiki">{-# DEPRECATED foldWithKey "Use foldrWithKey instead" #-}
</pre><p>
and change "should" to "may" in the documentation:
</p>
<pre class="wiki">-- This is identical to 'foldrWithKey', and you should use that one instead of
-- this one. This name is kept for backward compatibility.
</pre>Resultshttp://ghc.haskell.org/trac/ghc/ticket/4842#changelog
http://ghc.haskell.org/trac/ghc/ticket/3050
http://ghc.haskell.org/trac/ghc/ticket/3050#3050: parsec: bug in caret escape parsingWed, 25 Feb 2009 18:50:55 GMTsof<p>
The parsing of escape carets in character literals isn't quite right:
</p>
<ul><li>off-by-one (i.e., \<sup>A == \NUL; ought to be \</sup>A=\001)
</li><li>only A-Z carets are supported.
</li></ul><p>
The following minor mod takes care of the problem:
</p>
<pre class="wiki">--- Text/ParserCombinators/Parsec/Token.hs 2009-02-20 10:49:32.115500000 -0800
+++ Text/ParserCombinators/Parsec/Token.hs.~1~ 2009-02-20 10:02:45.896750000 -0800
@@ -193,8 +193,8 @@
-- charControl :: CharParser st Char
charControl = do{ char '^'
- ; code <- (oneOf ['@'..'_']) <|> char '?'
- ; return (if code == '?' then '\DEL' else toEnum (fromEnum code - fromEnum '@'))
+ ; code <- upper
+ ; return (toEnum (fromEnum code - fromEnum 'A'))
}
</pre>Resultshttp://ghc.haskell.org/trac/ghc/ticket/3050#changelog
http://ghc.haskell.org/trac/ghc/ticket/3121
http://ghc.haskell.org/trac/ghc/ticket/3121#3121: readline package does not respect Cabal --extra-{include,lib}-dirs flagsTue, 24 Mar 2009 11:01:23 GMTduncan<p>
The readline package still uses a <tt>./configure</tt> script. It has flags to set extra library and include dirs to search. These are needed by OSX users.
</p>
<p>
The <tt>./configure</tt> script takes the flags:
</p>
<pre class="wiki">--with-readline-includes=
--with-readline-libraries=
</pre><p>
However when an end user installs the package via Cabal, (either <tt>runghc Setup</tt> or <tt>cabal</tt>) they use the Cabal flags:
</p>
<pre class="wiki">--extra-include-dirs=
--extra-lib-dirs=
</pre><p>
The problem is that the two sets of flags are not connected at all. If the configure script needs to know these directories then the Setup.hs for the package should pass them through. Users are not expected to know the per-package configure flags, especially when we already have suitable generic flags for the same purpose.
</p>
<p>
The end result is that OSX users cannot install readline. Eg, today someone complained:
</p>
<pre class="wiki">hm, I have installed libreadline from mac ports and I have
told cabal to look for it in --extra-include-dirs
--extra-lib-dirs I also have installed the GNU.framework for
mac but it still fails...any suggestions?
</pre><p>
This problem actually applies to most bindings packages that use configure scripts. See also <a class="ext-link" href="http://hackage.haskell.org/trac/hackage/ticket/458"><span class="icon"></span>this Cabal ticket</a> about similar mismatches with configure scripts.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/3121#changelog
http://ghc.haskell.org/trac/ghc/ticket/4025
http://ghc.haskell.org/trac/ghc/ticket/4025#4025: template-haskell Use named fields in InfoWed, 28 Apr 2010 00:43:23 GMTaavogt<h2 id="Problem">Problem</h2>
<p>
The meaning of the fields for constructors of Language.Haskell.TH.Syntax.Info must be guessed.
</p>
<p>
See <a class="closed ticket" href="http://ghc.haskell.org/trac/ghc/ticket/1576" title="feature request: Document Template Haskell API (closed: fixed)">#1576</a>
</p>
<h2 id="ProposedChange">Proposed Change</h2>
<p>
Naming the fields for each constructor helps reduce this confusion. Compare documentations:
</p>
<p>
<strong>New</strong>
</p>
<p>
<a class="ext-link" href="http://code.haskell.org/~aavogt/libraries/template-haskell/Language-Haskell-TH-Syntax.html#t%3AInfo"><span class="icon"></span>http://code.haskell.org/~aavogt/libraries/template-haskell/Language-Haskell-TH-Syntax.html#t%3AInfo</a>
</p>
<p>
<strong>Old</strong>
</p>
<p>
<a href="http://www.haskell.org/ghc/docs/latest/html/libraries/template-haskell-2.4.0.1/Language-Haskell-TH-Syntax.html#t%3AInfo">http://www.haskell.org/ghc/docs/latest/html/libraries/template-haskell-2.4.0.1/Language-Haskell-TH-Syntax.html#t%3AInfo</a>
</p>
<h2 id="Issues">Issues</h2>
<p>
The Show instance changes (no Read).
</p>
<p>
Namespace conflicts.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/4025#changelog
http://ghc.haskell.org/trac/ghc/ticket/2644
http://ghc.haskell.org/trac/ghc/ticket/2644#2644: type of IntMap.intersection[WithKey] is incorrectThu, 02 Oct 2008 15:42:16 GMTsedillard<p>
<tt>IntMap.intersectionWith</tt> has declared type <tt>(a -> b -> a) -> IntMap a -> IntMap b -> IntMap a</tt> but the true type, correctly inferred by the compiler, is <tt>(a -> b -> c) -> IntMap a -> IntMap b -> IntMap c</tt>. This is also the type of the analogous function in the Data.Map library. This broader type signature is necessary for "zipping" maps, i.e. <tt>intersectionWith (,)</tt>.
</p>
<p>
See list post : <a class="ext-link" href="http://www.haskell.org/pipermail/libraries/2008-May/009677.html"><span class="icon"></span>http://www.haskell.org/pipermail/libraries/2008-May/009677.html</a>
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/2644#changelog
http://ghc.haskell.org/trac/ghc/ticket/1486
http://ghc.haskell.org/trac/ghc/ticket/1486#1486: utcToLocalTime converting in the wrong direction on WindowsMon, 02 Jul 2007 20:54:08 GMTOlivier Boudry<p>
I found a strange UTC to Local Time conversion bug on the Windows version of GHC 6.6.1.
</p>
<p>
Code to reproduce it:
</p>
<pre class="wiki"> import Monad
import Data.Time
import Locale
main = do
t <- (liftM2 utcToLocalTime) getCurrentTimeZone getCurrentTime
let s = formatTime defaultTimeLocale "%r" t
putStrLn s
z <- (liftM timeZoneName) getCurrentTimeZone
putStrLn z
</pre><p>
Running this program around 04:35 PM I get the following results
</p>
<p>
On Linux (a recent Ubuntu with GHC 6.6.1 compiled from source)
</p>
<pre class="wiki">04:35:48 PM
EDT
</pre><p>
On Windows (GHC 6.6.1 from installer) I get
</p>
<pre class="wiki">12:36:04 AM
Eastern Daylight Time
</pre><p>
Looks like the Windows version is counting in the wrong direction. I made some tests in GHCi on both machines an get this:
</p>
<p>
On Windows:
</p>
<pre class="wiki">Prelude> :m Monad Data.Time Locale
Prelude Locale Data.Time Monad> z <- getCurrentTimeZone
Eastern Daylight Time
Prelude Locale Data.Time Monad> timeZoneMinutes z
240
</pre><p>
On Linux: (same commands)
</p>
<pre class="wiki">Prelude Locale Data.Time Monad> timeZoneMinutes z
-240
</pre><p>
Cheers,
</p>
<p>
Olivier.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/1486#changelog