Haskell Prime: Ticket Query
https://prime.haskell.org/query?status=!closed&reporter=guest&desc=1&order=id
Haskell Language Report Working Groupen-USHaskell Primehttps://prime.haskell.org/chrome/site/HaskellLogo_2.jpg
https://prime.haskell.org/query?status=!closed&reporter=guest&desc=1&order=id
Trac 1.2.2.dev0
https://prime.haskell.org/ticket/125
https://prime.haskell.org/ticket/125#125: Rename interact to iofilterThu, 02 Aug 2007 16:17:02 GMT<p>
The interact function in Prelude has an un-intuitive name.
I suggest using the name "iofilter" instead.
</p>
<ul><li>Alexander Rødseth (rodseth "@" gmail.com)
</li></ul>Resultshttps://prime.haskell.org/ticket/125#changelog
https://prime.haskell.org/ticket/115
https://prime.haskell.org/ticket/115#115: Complex arithmetic misbehaves in boundary casesTue, 02 Jan 2007 18:08:19 GMT<p>
Consider complex multiplication. If we have a number x+iy and multiply this number by i we get -y+ix.
Let us try the same thing in Haskell with IEEE floating point:
let inf = 1.0/0.0
</p>
<blockquote>
<p>
a = 1 :+ inf
i = 0 :+ 1
</p>
</blockquote>
<p>
in a * i
This comes out as (-Infinity) :+ NaN when it should have been (-Infinity) :+ 1.0.
It is not just a made up problem, see, e.g., <a class="ext-link" href="http://www.cs.berkeley.edu/~wkahan/Curmudge.pdf"><span class="icon"></span>http://www.cs.berkeley.edu/~wkahan/Curmudge.pdf</a>
</p>
<p>
We should address this problem. I have not yet determined if testing for
a real part of 0 in multiplication (and division) is sufficent, but I think
it is. I will be back with more information on the fix.
</p>
<blockquote>
<p>
— Lennart
</p>
</blockquote>
Resultshttps://prime.haskell.org/ticket/115#changelog
https://prime.haskell.org/ticket/112
https://prime.haskell.org/ticket/112#112: Break unnecessary dependencies between Haskell numeric classesWed, 20 Sep 2006 19:51:39 GMT<p>
Motivation:
</p>
<p>
The Haskell numeric classes contain some interdependencies that look rather odd to a mathematician. For example, why do you have to be Show in order to be Num, and why do you have to be Enum in order to be Integral. These dependencies are not justified by mathematical considerations, and make it hard to represent some mathematical concepts in Haskell.
</p>
<p>
For example, consider the Gaussian integers - numbers of the form a+bi, where a and b are integers, and i is the square root of -1. (Complex Integer, if you like.) There is a division with remainder algorithm for the Gaussian integers, so that we would like to declare them as an instance of Integral, and define the quotRem function. However, to do this we would have to declare them as an instance of Enum - and this makes no sense - there is no natural way to define the Enum functions on the Gaussian integers.
</p>
<p>
For similar reasons, the dependency of Integral on Real is suspect - there is no natural way to define toRational on the Gaussian integers.
</p>
<p>
The dependency of <a class="missing wiki">RealFrac?</a> on Fractional is also unnecessary - what have floor, ceiling etc got to do with recip?
</p>
<p>
Note that breaking these dependencies will not break any existing code. At present, if I declare a type T to be a Num instance, I must also declare it to be an Eq instance and a Show instance. If the dependency is broken, that is, if
</p>
<p>
class (Eq a, Show a) ⇒ Num a
</p>
<p>
is replaced by
</p>
<p>
class Num a
</p>
<p>
then existing code will still work.
</p>
<p>
What will have changed is that it will now be possible to declare a type T to be a Num instance without also declaring it to be an Eq and a Show instance.
</p>
<p>
Proposal:
</p>
<p>
Conservative version:
</p>
<p>
Replace the existing Prelude class declarations with:
</p>
<ol><li>class Eq a ⇒ Num a — remove dependency on Show
</li></ol><ol start="2"><li>class Num a ⇒ Integral a — replace dependency on Real, Enum by dependency on Num
</li></ol><ol start="3"><li>class Real a ⇒ <a class="missing wiki">RealFrac?</a> a — remove dependency on Fractional
</li></ol><p>
Radical version:
</p>
<p>
In addition to the above:
</p>
<ol start="4"><li>Split abs and signum out from Num into a new
</li></ol><p>
class Num a ⇒ Quantity a
</p>
<p>
(There are plenty of objects in mathematics for which the arithmetical operations +,-,* make sense, but the size and direction operations abs and signum do not - for example polynomials, matrices.)
</p>
<ol start="5"><li>Amalgamate classes Real and <a class="missing wiki">RealFrac?</a> - Real no longer has any purpose as a distinct class. The new class should probably be called Real.
</li></ol><p>
See also: <a class="wiki" href="https://prime.haskell.org/wiki/NumericClasses">NumericClasses</a>.
</p>
Resultshttps://prime.haskell.org/ticket/112#changelog
https://prime.haskell.org/ticket/110
https://prime.haskell.org/ticket/110#110: Generalize types of IO actionsFri, 21 Apr 2006 18:33:30 GMT<p>
One nice way to structure programs is to use monad transformers on top of IO. For example, one common technique is to use StateT or ReaderT to propagate custom state through IO code. This technique has two problems
</p>
<p>
1) It requires one to use 'liftIO' rather a lot, which is mildly irritating
</p>
<p>
2) It makes it very difficult to use higher-order IO combinators, such as try or bracket, which is highly irritating
</p>
<p>
This proposal involves generalizing the types of standard IO functions to make this use-case easier.
</p>
<p>
Conservative proposal:
</p>
<p>
Generalize higher order IO combinators to take a MonadIO context. For example, try and catch would then have types
</p>
<pre class="wiki">try :: MonadIO m => m a -> m (Either Exception a)
catch :: MonadIO m => m a -> (Exception -> m a) - > m a
</pre><p>
This allows one to use custom monads built on IO and still do correct exception handling, etc. without having to do lots of nasty monad unwrapping/rewrapping.
</p>
<p>
NOTE: This is not possible to implement. there is no way to 'rewind' a monad
in a generic way in order to implement try or catch. - <a class="missing wiki">JohnMeacham?</a>
</p>
<p>
NOTE: An alternative is to use a different version of Control.Exception that defines a typeclass as follows:
</p>
<pre class="wiki">class MonadIO m => MonadException m where
catch :: m a -> (Exception -> m a) -> m a
block, unblock :: m a -> m a
</pre><p>
This can be implemented for the common monad transformers, and all the other exception functions can be implemented just using the methods in the above typeclass, or using liftIO with the existing functions. A full implementation (not fully tested though) is attached. — Brian Hulley
</p>
<p>
NOTE: Even though not all uses of IO can be eliminated (eg when defining callback functions to use with FFI), the importance of having an Exception module which is not tied to concrete <code>IO</code> is that it would allow library writers which require <code>block</code>, <code>bracket</code> etc to use the more general <code>MonadException</code> in place of <code>IO</code>. If library writers do not do this, users of the library, which may be other libraries etc, are also tied down to concrete <code>IO</code>, so the longer we leave it, the more difficult it will be to "unconcretise" the code base. — Brian Hulley
</p>
<p>
More radical proposal:
</p>
<p>
Generalize the types of all standard library IO routines to take MonadIO contexts. For example,
</p>
<p>
putChar :: MonadIO m ⇒ Char → m ()
</p>
<p>
getChar :: MonadIO m ⇒ m Char
</p>
<p>
These could easily be defined in terms of lower level IO primitives:
</p>
<p>
putCharIO :: Char → IO ()
</p>
<p>
putCharIO = …
</p>
<p>
putChar c = liftIO (putChar c)
</p>
<p>
Now you can eliminate a bunch of noisy calls to liftIO in client code.
</p>
<p>
NOTE: This should be quite trivial to implement for all functions which just use <code>IO</code> in the return value. When <code>IO</code> is used in other positions it is unlikely to be possible to implement except by replacing the other occurrence of <code>IO</code> by <code>MonadIOU</code> defined by:
</p>
<pre class="wiki"> class MonadIO m => MonadIOU m where
getUnliftIO :: m (m a -> IO a)
</pre><p>
Unfortunately only a few of the monad transformers support this operation (eg <code>ReaderT</code> ) but at least it's better than nothing. An alternative would be to define special typeclasses for related sets of operations if this would allow more monad transformers to be supported by the particular operations, or to add first-order api functions which a library user could use to build a specialised version of the higher order function for a specific monad. — Brian Hulley
</p>
Resultshttps://prime.haskell.org/ticket/110#changelog
https://prime.haskell.org/ticket/109
https://prime.haskell.org/ticket/109#109: split Enum into two typeclassesSun, 09 Apr 2006 23:26:41 GMT<p>
The current uses of Enum are somewhat confusing — this is partially because of the name, but partially because two seperate interfaces are glued together. One provides Enumeration of all possible values and conversion to integers for binary storage, and the other provides sequences of values (usually arithmetic) (which [a..b], etc desugar to).
</p>
<pre class="wiki">class Enum a where
succ, pred :: a -> a
toEnum :: Int -> a
fromEnum :: a -> Int
instance Enum Integer
instance Enum Int
instance Enum Bool
instance Enum Ordering
instance Enum Word...
</pre><pre class="wiki">class ArithmeticSequence a where
stepFrom :: a -> [a] -- [n..]
stepFromThen :: a -> a -> [a] -- [n, n'..]
stepFromTo :: a -> a -> [a] -- [n..m]
stepFromThenTo :: a -> a -> a -> [a] -- [n,n'..m]
instance ArithmeticSequence Integer
instance ArithmeticSequence Int
instance ArithmeticSequence Bool
instance ArithmeticSequence Ordering
instance ArithmeticSequence Float
instance ArithmeticSequence Double
instance ArithmeticSequence Rational
instance ArithmeticSequence Word...
...
</pre><p>
Steppable may be a preferrable name.
</p>
<p>
pros:
</p>
<ul><li>Clearly divides two seperate uses, while keeping functionality.
</li><li>Can re-introduce relationship between Ix and Enum?
</li></ul><p>
cons:
</p>
<ul><li>Yet another typeclass.
</li><li>Slightly misleading name, as non-arithmetic structures _should_ be supported. Also a bit long.
</li><li>Automatically supporting such isn't trivial if they're not in Enum, though.
</li></ul>Resultshttps://prime.haskell.org/ticket/109#changelog
https://prime.haskell.org/ticket/108
https://prime.haskell.org/ticket/108#108: make toEnum and fromEnum take and return IntegersSun, 09 Apr 2006 23:07:00 GMT<p>
Change the signature of toEnum and fromEnum in the Enum a typeclass to
</p>
<pre class="wiki"> toEnum :: Integer -> a
fromEnum :: a -> Integer
</pre><p>
(they currently use Int)
</p>
<p>
It's possible, for example, to have Enumeratable types that are larger than Int
</p>
<p>
pros: No overflow possibilities
</p>
<p>
cons: efficiency
</p>
Resultshttps://prime.haskell.org/ticket/108#changelog
https://prime.haskell.org/ticket/107
https://prime.haskell.org/ticket/107#107: Add assertionsTue, 04 Apr 2006 20:48:26 GMT<p>
GHC currently has a nice feature for assertions, which allow the programmer to insert a condition which is asserted to be true. If the condition is in fact false, an error is raised which contains the source code line of the assertion. A compiler flag allows all assertions to be disabled.
</p>
<p>
<a class="ext-link" href="http://www.haskell.org/ghc/docs/latest/html/users_guide/sec-assertions.html"><span class="icon"></span>http://www.haskell.org/ghc/docs/latest/html/users_guide/sec-assertions.html</a>
</p>
<p>
Possible variations:
</p>
<ol><li>Have a form of 'assert' which can take an arbitrary string to which the source file location is prepended.
</li><li>assert can tie in to imprecise exceptions, if they are adopted, or a failed assertion can be bottom
</li><li>Remove the source line feature (makes the proposal simpler, but less useful because now all you get is the compiler flag to turn assertions off)
</li></ol>Resultshttps://prime.haskell.org/ticket/107#changelog
https://prime.haskell.org/ticket/101
https://prime.haskell.org/ticket/101#101: Class AliasesSun, 26 Mar 2006 00:43:25 GMT<p>
See <a class="ext-link" href="http://repetae.net/john/recent/out/classalias.html"><span class="icon"></span>http://repetae.net/john/recent/out/classalias.html</a>
</p>
<pre class="wiki">class alias Num a = (Additive a, AdditiveNegation a,
Multiplicative a, FromInteger a) where
one = fromInteger 1
zero = fromInteger 0
negate x = zero - x
</pre>Resultshttps://prime.haskell.org/ticket/101#changelog
https://prime.haskell.org/ticket/98
https://prime.haskell.org/ticket/98#98: Restricted Data Types NowWed, 22 Mar 2006 00:12:00 GMT<p>
We should adopt Oleg's "Restricted Data Types Now" approach for simpler cases, like Functor, that don't involve creating new type classes.
</p>
<pre class="wiki">class Functor f a b where
fmap :: (a -> b) -> f a -> f b
instance (Ord a, Ord b) => Functor Data.Set.Set a b where
...
</pre>Resultshttps://prime.haskell.org/ticket/98#changelog
https://prime.haskell.org/ticket/97
https://prime.haskell.org/ticket/97#97: Collection library interfaceWed, 22 Mar 2006 00:04:48 GMT<p>
We should make a collection library interface, using whatever new features end up in Haskell'. See: <a class="ext-link" href="http://hackage.haskell.org/trac/ghc/wiki/CollectionClassFramework"><span class="icon"></span>http://hackage.haskell.org/trac/ghc/wiki/CollectionClassFramework</a>
</p>
Resultshttps://prime.haskell.org/ticket/97#changelog
https://prime.haskell.org/ticket/81
https://prime.haskell.org/ticket/81#81: scoping of type variables in class instancesTue, 31 Jan 2006 10:23:17 GMT<p>
The scoping of type variables in class instances is underspecified. GHC scopes them for the entire instance, Hugs does not.
</p>
<p>
GHC's approach is more expressive, it is sometimes needed - especially in combination with multi-parameter classes.
Example:
</p>
<pre class="wiki">class Ping a b where ping:: a->b
newtype A a = A a
instance (Show b,Ping a b) => Show (A a) where
show (A x) = show (ping x)
</pre><p>
This is ambiguous and thus rejected, but we could resolve the ambiguity by annotating 'ping' with its expected type a→b, but that only works if the scoping of the class instance extends to the member definition.
</p>
<h2 id="pros">pros</h2>
<p>
: extends expressiveness, implemented in GHC anyway, was underspecified in Haskell anyway
</p>
<h2 id="cons">cons</h2>
<p>
: very minor: it could break some existing programs as it makes some local functions non-polymorphic, though these would have been badly written
</p>
<p>
See also: <a class="ext-link" href="http://hackage.haskell.org/trac/haskell-prime/wiki/ScopedTypeVariables"><span class="icon"></span>http://hackage.haskell.org/trac/haskell-prime/wiki/ScopedTypeVariables</a>
</p>
Resultshttps://prime.haskell.org/ticket/81#changelog