GHC: Ticket Query
http://ghc.haskell.org/trac/ghc/query?status=!closed&reporter=diatchki&order=id
The Glasgow Haskell Compileren-USGHChttp://ghc.haskell.org/trac/ghc/chrome/site/ghc_logo.png
http://ghc.haskell.org/trac/ghc/query?status=!closed&reporter=diatchki&order=id
Trac 1.0.1
http://ghc.haskell.org/trac/ghc/ticket/4385
http://ghc.haskell.org/trac/ghc/ticket/4385#4385: Type-level natural numbersMon, 11 Oct 2010 23:22:51 GMTdiatchki<p>
Natural numbers at the type-level have many uses, especially in contexts where programmers need to manipulate data with statically known sizes. A simple form of this feature has been present in many programming languages for a long time (e.g., sub-range types in Pascal, array type in C, etc.). The feature is particularly useful when combined with polymorphism as illustrated by more recent programming languages (e.g., Cyclone, BlueSpec, Cryptol, Habit).
</p>
<p>
Existing features of Haskell's type system---such as polymorphism, kinds, and qualified types---make it particularly suitable for adding support for type level naturals in a natural way!
</p>
<p>
Indeed, there are quite a few Haskell libraries available on Hackage that implement support for type-level numbers in various forms. These libraries are being used by other packages and projects (e.g., the Kansas Lava project, and the type-safe bindings to the LLVM library).
</p>
<p>
Supporting natural number types directly in the compiler would help these projects, and others, by improving on the existing libraries in the following ways:
</p>
<ul><li>a standard implementation,
</li><li>a better notation,
</li><li>better error messages,
</li><li>a more efficient implementation,
</li><li>more complete support for numeric operations.
</li></ul><p>
I have started on an implementation of this feature, and my GHC branch is available in a darcs repository at the following URL:
</p>
<pre class="wiki">http://code.galois.com/darcs/ghc-type-naturals/
</pre>Resultshttp://ghc.haskell.org/trac/ghc/ticket/4385#changelog
http://ghc.haskell.org/trac/ghc/ticket/4894
http://ghc.haskell.org/trac/ghc/ticket/4894#4894: Missing improvement for fun. deps.Mon, 17 Jan 2011 03:16:09 GMTdiatchki<p>
The problem is illustrated by the following example:
</p>
<pre class="wiki">{-# LANGUAGE MultiParamTypeClasses, FunctionalDependencies #-}
class F a b | a -> b
f :: (F a b, F a c) => a -> b -> c
f _ = id
Results in the following error:
Could not deduce (b ~ c)
from the context (F a b, F a c)
bound by the type signature for f :: (F a b, F a c) => a -> b -> c
at bug.hs:6:1-8
`b' is a rigid type variable bound by
the type signature for f :: (F a b, F a c) => a -> b -> c
at bug.hs:6:1
`c' is a rigid type variable bound by
the type signature for f :: (F a b, F a c) => a -> b -> c
at bug.hs:6:1
Expected type: b -> c
Actual type: b -> b
In the expression: id
In an equation for `f': f _ = id
</pre><p>
The issue seems to be related to Note [When improvement happens] in module TcInteract. It states that two "givens" do not interact for the purposes of improvement.
</p>
<p>
As far as I understand, the correct behavior should be to generate a new given equality, justified by the functional dependency on the class.
</p>
<p>
This is also related to bug <a class="closed ticket" href="http://ghc.haskell.org/trac/ghc/ticket/1241" title="bug: Functional dependency Coverage Condition is lifted, and should not be (closed: fixed)">#1241</a>: in order to justify an improvement by functional dependency, we have to check that all instances are consistent with the dependency. Otherwise, the above function would turn into an "unsafe cast" function.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/4894#changelog
http://ghc.haskell.org/trac/ghc/ticket/7842
http://ghc.haskell.org/trac/ghc/ticket/7842#7842: Incorrect checking of let-bindings in recursive doWed, 17 Apr 2013 00:00:50 GMTdiatchki<p>
I have run into a problem with the type-checking of recursive do blocks, which reduces to the following example:
</p>
<pre class="wiki">{-# LANGUAGE RecursiveDo #-}
module Bug where
bug :: (Int -> IO Int) -> IO (Bool, Char)
bug m =
mdo i <- m i1 -- RECURSION
let i1 :: Int
i1 = i -- RECURSION
-- This appears to be monomorphic, despite the type signature.
f :: b -> b
f x = x
return (f True, f 'a')
</pre><p>
This program is rejected with the errors shown below. The problem appears to be that somehow <tt>f</tt> has become monomorphic, despite its type-signature. This seems to happen only when <tt>f</tt> is part of a <tt>let</tt> block that is also involved in the recursion.
</p>
<p>
Here is the error reported by GHC 7.7.20130215:
</p>
<pre class="wiki">Bug.hs:15:23:
Couldn't match expected type `Char' with actual type `Bool'
In the return type of a call of `f'
In the expression: f 'a'
In the first argument of `return', namely `(f True, f 'a')'
Bug.hs:15:25:
Couldn't match expected type `Bool' with actual type `Char'
In the first argument of `f', namely 'a'
In the expression: f 'a'
In the first argument of `return', namely `(f True, f 'a')'
</pre>Resultshttp://ghc.haskell.org/trac/ghc/ticket/7842#changelog
http://ghc.haskell.org/trac/ghc/ticket/9334
http://ghc.haskell.org/trac/ghc/ticket/9334#9334: Implement "instance chains"Sat, 19 Jul 2014 21:10:04 GMTdiatchki<p>
It would be useful to implement a version of "instance chains" <a class="missing changeset" title="No changeset 1 in the repository">[1]</a> in GHC, which would eliminate the need for OVERLAPPING_INSTANCES in most (all practcial?) programs.
</p>
<p>
The idea is that programmers can explicitly group and order instances into an "instance chain". For example:
</p>
<pre class="wiki">instance (Monad m) => StateM (StateT s m) s where ...
else (MonadTrans t, StateM m s) => StateM (t m) s where ...
</pre><p>
When GHC searches for instances, the instances in a chain are considered together and in order, starting with the first one:
</p>
<ol><li>If the goal matches the current instance's head, then this instance is selected and the rest are ignored, as if they were not there;
</li></ol><ol start="2"><li>If the goal does not match the current instance's head, AND it does not unify with the current instance's head, then we skip the instance and proceed to the next member of the chain;
</li></ol><ol start="3"><li>If the goal does not match the current instance's head, but it does unify with it, then we cannot use this chain to solve the goal.
</li></ol><p>
In summary: earlier instances in a chain "hide" later instances, and later instances can be reached only if we are sure that none of the previous instance will match.
</p>
<p>
<a class="missing changeset" title="No changeset 1 in the repository">[1]</a> <a class="ext-link" href="http://web.cecs.pdx.edu/~mpj/pubs/instancechains.pdf"><span class="icon"></span>http://web.cecs.pdx.edu/~mpj/pubs/instancechains.pdf</a>
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/9334#changelog
http://ghc.haskell.org/trac/ghc/ticket/10101
http://ghc.haskell.org/trac/ghc/ticket/10101#10101: ghci :e throws exception after type errorWed, 18 Feb 2015 21:58:40 GMTdiatchki<p>
After a type-error on the command line, :e starts throwing an exception. To reproduce:
</p>
<pre class="wiki">~/src/ghc/inplace/bin/ghc-stage2 --interactive test.hs
GHCi, version 7.11.20150128: http://www.haskell.org/ghc/ :? for help
[1 of 1] Compiling Main ( test.hs, interpreted )
Ok, modules loaded: Main.
*Main> 1 + ()
<interactive>:2:3:
No instance for (Num ()) arising from a use of ‘+’
In the expression: 1 + ()
In an equation for ‘it’: it = 1 + ()
*Main> :e
*** Exception: <interactive>: canonicalizePath: does not exist (No such file or directory)
*Main>
</pre><p>
The contents of <tt>test.hs</tt> is not important as long as there is a file to edit.
</p>
<p>
Editing works fine before the type-error on the command line.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/10101#changelog