#95: GHCi :edit command should jump to the the last error
-------------------------------+-------------------------------------------
Reporter: | Owner: lortabac
martijnislief | Status: patch
Type: feature | Milestone: ⊥
request | Version: None
Priority: normal | Keywords:
Component: GHCi | Architecture: Unknown/Multiple
Resolution: None | Difficulty: Easy (less than 1 hour)
Operating System: | Blocked By:
Unknown/Multiple | Related Tickets:
Type of failure: |
None/Unknown |
Test Case: |
Blocking: |
-------------------------------+-------------------------------------------
Comment (by nomeata):
Don’t worry about test names, `prog013` is fine; `T95` would have been
another possibility. Ideally, the test case is never looked at again,
because nobody breaks this feature.
The patch is, IMHO, good to go. I’m validating this right now and will
push if validation succeeds.
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/95#comment:21>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
#6135: Unboxed Booleans
---------------------------------------------+-----------------------------
Reporter: benl | Owner: jstolarek
Type: feature request | Status: closed
Priority: normal | Milestone: 7.8.1
Component: Compiler | Version: 7.4.1
Resolution: fixed | Keywords:
Operating System: Unknown/Multiple | Architecture:
Type of failure: None/Unknown | Unknown/Multiple
Test Case: primops/should_run/T6135 | Difficulty: Unknown
Blocking: | Blocked By: 8103,
| 8103
| Related Tickets: #605
---------------------------------------------+-----------------------------
Comment (by altaic):
Replying to [comment:91 Lemming]:
> Replying to [comment:90 carter]:
> > @lemming, Bool# is now Int# afaik, could you explain what you mean?
even if we used a i1 rep, it still needs a full register! So theres no
lost for the in register rep to be Int#, afaik
>
> `Int#` represents a large range of integers, whereas `i1` in LLVM has
only values 0 and 1. That is, LLVM can optimize based on the knowledge of
the restricted value set of `i1`, but it certainly fails to do so on `i32`
or `i64`.
Two of the advantages in representing Bool# as an i1 is that llvm can
vectorize them, and arrays of i1 can fit in an i32 or i64. Off the top of
my head, I don't know of any software that makes use of large arrays of
booleans, but in that case this sort of optimization would likely be very
effective.
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/6135#comment:92>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
#7828: RebindableSyntax and Arrow
----------------------------------------------+----------------------------
Reporter: AlessandroVermeulen | Owner:
Type: bug | jstolarek
Priority: normal | Status: new
Component: Compiler (Type checker) | Milestone: 7.10.1
Resolution: | Version: 7.6.2
Operating System: Unknown/Multiple | Keywords:
Type of failure: GHC rejects valid program | Architecture:
Test Case: | Unknown/Multiple
Blocking: | Difficulty: Unknown
| Blocked By:
| Related Tickets:
----------------------------------------------+----------------------------
Comment (by jstolarek):
In my work on the prototype I've ran into a problem I can't solve. Since
desugaring of `HsCmdTop`
[https://github.com/ghc/ghc/blob/165ac4af4a1002eff5f5a474bc21bc443c8f8c63/co…
requires calls to arr and >>>] I've added two `SyntaxExpr` to `HsCmdTop`
datatype. These two `SyntaxExpr`s
[https://github.com/ghc/ghc/blob/165ac4af4a1002eff5f5a474bc21bc443c8f8c63/co…
need to be typechecked in tcCmdTop]. I've see earlier how
[https://github.com/ghc/ghc/blob/165ac4af4a1002eff5f5a474bc21bc443c8f8c63/co…
typechecking of the do-notation bind is implemented] and decided to adopt
a similar aproach:
{{{
tcCmdTop env (L loc (HsCmdTop cmd _ _ names compose_op arr_op))
cmd_ty@(cmd_stk, res_ty)
= setSrcSpan loc $
do { cmd' <- tcCmd env cmd cmd_ty
; names' <- mapM (tcSyntaxName ProcOrigin (cmd_arr env)) names
-- VOODOO CODING based on typechecking of >>= in TcMatches
-- is it correct to use b and c variables for typechecking in both
-- arr and compose?
; a <- newFlexiTyVarTy liftedTypeKind
; b <- newFlexiTyVarTy liftedTypeKind
; c <- newFlexiTyVarTy liftedTypeKind
; arr_op' <- tcSyntaxOp DoOrigin arr_op
(mkFunTy (mkFunTy b c) (mkCmdArrTy env b
c))
; compose_op' <- tcSyntaxOp DoOrigin compose_op
(mkFunTys [mkCmdArrTy env a b, mkCmdArrTy
env b c] (mkCmdArrTy env a c))
; return (L loc $ HsCmdTop cmd' cmd_stk res_ty names' compose_op'
arr_op') }
}}}
This however ends with a panic. Using `-dcore-lint` gives me this:
{{{
*** Core Lint errors : in result of Desugar (after optimization) ***
<no location info>: Warning:
In the expression: T7828.>>>
@ GHC.Prim.Any
@ GHC.Prim.Any
@ GHC.Prim.Any
@ a_aEo
@ (a_aEo, ())
@ a_aEo
(T7828.arr
@ GHC.Prim.Any
@ GHC.Prim.Any
@ a_aEo
@ (a_aEo, ())
(\ (n_aus :: a_aEo) -> (n_aus, GHC.Tuple.())))
(T7828.>>>
@ (a_aEo, ())
@ a_aEo
@ a_aEo
(T7828.arr
@ (a_aEo, ())
@ a_aEo
(\ (ds_dGU :: (a_aEo, ())) ->
case ds_dGU of _ [Occ=Dead] { (ds_dGT, _
[Occ=Dead]) -> ds_dGT }))
(T7828.returnA @ a_aEo))
Illegal type application:
Exp type:
T7828.R GHC.Prim.Any GHC.Prim.Any
-> T7828.R GHC.Prim.Any GHC.Prim.Any
-> T7828.R GHC.Prim.Any GHC.Prim.Any :: *
Arg type: a_aEo :: *
}}}
These `GHC.Prim.Any` look wrong. Notice that there are two calls of `>>>`
and `arr` but only one of each has these extra `GHC.Prim.Any` parameters.
The incorrect `>>>` and `arr` are generated by my modified `HsCmdTop`. The
other pair of `>>>` and `arr` is generated by `HsCmdArrApp` constructor,
which has not been modified yet. Simon, help?
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7828#comment:24>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
#95: GHCi :edit command should jump to the the last error
-------------------------------+-------------------------------------------
Reporter: | Owner: lortabac
martijnislief | Status: patch
Type: feature | Milestone: ⊥
request | Version: None
Priority: normal | Keywords:
Component: GHCi | Architecture: Unknown/Multiple
Resolution: None | Difficulty: Easy (less than 1 hour)
Operating System: | Blocked By:
Unknown/Multiple | Related Tickets:
Type of failure: |
None/Unknown |
Test Case: |
Blocking: |
-------------------------------+-------------------------------------------
Comment (by lortabac):
I added a `sameFile` function to check whether two paths point to the same
file.
However I can't find any readable alternative to:
{{{
curFileErrs <- filterM (\(f, _) -> unpackFS f `sameFile` file) errs
return $ case curFileErrs of
(_, line):_ -> " +" ++ show line
_ -> ""
}}}
As far as the test is concerned, I just followed the enumeration in the
ghci directory, so I called it `prog013`. It would be nice to make it a
bit more self-descriptive but I have no idea how.
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/95#comment:20>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
#9183: GHC shouldn't expand constraint synonyms
------------------------------------+-------------------------------------
Reporter: Feuerbach | Owner:
Type: feature request | Status: new
Priority: normal | Milestone:
Component: Compiler | Version: 7.8.2
Keywords: | Operating System: Unknown/Multiple
Architecture: Unknown/Multiple | Type of failure: None/Unknown
Difficulty: Unknown | Test Case:
Blocked By: | Blocking:
Related Tickets: |
------------------------------------+-------------------------------------
{{{
{-# LANGUAGE ConstraintKinds #-}
type ShowX = Show
showX :: ShowX a => a -> String
showX = show
}}}
If I now ask for the type of showX, I get:
{{{
*Main> :t showX
showX :: Show a => a -> String
}}}
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9183>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
#9097: Change GHC.Exts.Any to a type family
------------------------------------+-------------------------------------
Reporter: goldfire | Owner:
Type: task | Status: new
Priority: normal | Milestone:
Component: Compiler | Version: 7.8.2
Keywords: | Operating System: Unknown/Multiple
Architecture: Unknown/Multiple | Type of failure: None/Unknown
Difficulty: Unknown | Test Case:
Blocked By: | Blocking:
Related Tickets: |
------------------------------------+-------------------------------------
I just had this slightly alarming interchange with GHCi:
{{{
Prelude> import Data.Type.Equality
Prelude Data.Type.Equality> import GHC.Exts
Prelude Data.Type.Equality GHC.Exts> :kind! ((Any :: Bool) == (Any ::
Bool))
((Any :: Bool) == (Any :: Bool)) :: Bool
= 'False
}}}
After staring at the result in disbelief, I figured out why. The instance
for `==` at kind `Bool` looks like this:
{{{
type family EqBool a b where
EqBool False False = True
EqBool True True = True
EqBool a b = False
type instance (a :: Bool) == (b :: Bool) = EqBool a b
}}}
Well, `Any` isn't `False`, `Any` isn't `True`, so `Any == Any` must be
`False`!
The solution to this, of course, is to make `Any` a type family, not a
datatype. Then, it wouldn't be apart from the equations in `EqBool`. I
believe this idea has been floated previously but was not implemented as
it would have disturbed !TypeLits and/or singletons. These libraries have
been updated, and it's time.
I'm happy to do this myself in due course.
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9097>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
