#15823: Incorrect link in the doc (TH API)
-------------------------------------+-------------------------------------
Reporter: hsyl20 | Owner: (none)
Type: bug | Status: new
Priority: low | Milestone:
Component: Documentation | Version: 8.6.1
Keywords: | Operating System: Unknown/Multiple
Architecture: | Type of failure: Documentation
Unknown/Multiple | bug
Test Case: | Blocked By:
Blocking: | Related Tickets:
Differential Rev(s): | Wiki Page:
-------------------------------------+-------------------------------------
The "Haddock reference documentation" link for TH in the doc is
incorrectly generated at
https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/glasgow_ext…
#template-haskell
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15823>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
#14465: Performance of Natural
-------------------------------------+-------------------------------------
Reporter: Bodigrim | Owner: (none)
Type: feature | Status: new
request |
Priority: normal | Milestone:
Component: Compiler | Version: 8.2.1
Keywords: | Operating System: Unknown/Multiple
Architecture: | Type of failure: None/Unknown
Unknown/Multiple |
Test Case: | Blocked By:
Blocking: | Related Tickets:
Differential Rev(s): | Wiki Page:
-------------------------------------+-------------------------------------
Recently I tried to use `Natural` instead of `Integer` in one of my
projects. I expected no difference or even a minor performance boost
(since `Natural` does not have to worry about a sign). But in fact it
caused a slowdown.
A constant of type `Integer` will be evaluated to a low-level
representation (`S#` / `Jp#` / `Jn#`) during `CorePrep` stage. Nothing of
this kind happens to constant values of type `Natural`:
{{{#!hs
import Numeric.Natural
one :: Natural
one = fromInteger 1
}}}
is translated to
{{{#!hs
one1 :: Integer
one1 = 1 -- will be converted by CorePrep to S# 1#
one :: Natural
one
= case one1 of {
S# i#_a2c6 ->
case tagToEnum# (>=# i#_a2c6 0#) of {
False -> underflowError;
True -> NatS# (int2Word# i#_a2c6)
};
Jp# dt_a2cg ->
case uncheckedIShiftRL# (sizeofByteArray# dt_a2cg) 3# of {
__DEFAULT ->
case sizeofByteArray# dt_a2cg of {
__DEFAULT -> NatJ# dt_a2cg;
0# -> underflowError
};
1# ->
case indexWordArray# dt_a2cg 0# of wild2_a2ck { __DEFAULT ->
NatS# wild2_a2ck
}
};
Jn# ipv_a2cn -> underflowError
}
}}}
This is not bad itself, if `one` is a top-level definition. At the end of
the day a thunk will be replaced by its value, computed exactly once. But
suppose we have written
{{{#!hs
import Numeric.Natural
plusOne :: Natural -> Natural
plusOne n = n + 1
}}}
The corresponding Core looks this way:
{{{#!hs
plusOne :: Natural -> Natural
plusOne
= \ (n_auS :: Natural) ->
case 1 of {
S# i#_a2dA ->
case tagToEnum# (>=# i#_a2dA 0#) of {
False -> case underflowError of wild2_00 { };
True -> plusNatural n_auS (NatS# (int2Word# i#_a2dA))
};
Jp# dt_a2dI ->
case uncheckedIShiftRL# (sizeofByteArray# dt_a2dI) 3# of {
__DEFAULT ->
case sizeofByteArray# dt_a2dI of {
__DEFAULT -> plusNatural n_auS (NatJ# dt_a2dI);
0# -> case underflowError of wild4_00 { }
};
1# ->
case indexWordArray# dt_a2dI 0# of wild2_a2dM { __DEFAULT ->
plusNatural n_auS (NatS# wild2_a2dM)
}
};
Jn# ipv_a2dP -> case underflowError of wild1_00 { }
}
}}}
It looks expensive to pattern match `1` repeatedly, at every call to
`plusOne`.
Another deficiency of `Natural` is that no constant folding is done. Even
`2 * 2` results in 50 lines of Core:
{{{#!hs
twoTimesTwo2 :: Integer
twoTimesTwo2 = 2
twoTimesTwo1 :: Natural
twoTimesTwo1
= case twoTimesTwo2 of {
S# i#_a2u3 ->
case tagToEnum# (>=# i#_a2u3 0#) of {
False -> underflowError;
True -> NatS# (int2Word# i#_a2u3)
};
Jp# dt_a2ub ->
case uncheckedIShiftRL# (sizeofByteArray# dt_a2ub) 3# of {
__DEFAULT ->
case sizeofByteArray# dt_a2ub of {
__DEFAULT -> NatJ# dt_a2ub;
0# -> underflowError
};
1# ->
case indexWordArray# dt_a2ub 0# of wild2_a2uf { __DEFAULT ->
NatS# wild2_a2uf
}
};
Jn# ipv_a2ui -> underflowError
}
twoTimesTwo :: Natural
twoTimesTwo
= case twoTimesTwo2 of {
S# i#_a2u3 ->
case tagToEnum# (>=# i#_a2u3 0#) of {
False -> case underflowError of wild2_00 { };
True -> $fNumNatural_$c* twoTimesTwo1 (NatS# (int2Word#
i#_a2u3))
};
Jp# dt_a2ub ->
case uncheckedIShiftRL# (sizeofByteArray# dt_a2ub) 3# of {
__DEFAULT ->
case sizeofByteArray# dt_a2ub of {
__DEFAULT -> $fNumNatural_$c* twoTimesTwo1 (NatJ# dt_a2ub);
0# -> case underflowError of wild4_00 { }
};
1# ->
case indexWordArray# dt_a2ub 0# of wild2_a2uf { __DEFAULT ->
$fNumNatural_$c* twoTimesTwo1 (NatS# wild2_a2uf)
}
};
Jn# ipv_a2ui -> case underflowError of wild1_00 { }
}
}}}
This is not surprising, since constant folding of `Integer` works only due
to a special Core literal `LitInteger` and a set of hardcoded
`PrelRules.builtinIntegerRules` (and `NOINLINE` pragmas in
`GHC.Integer.Type`).
----
Is it reasonable to make `Natural` a first-class Core citizen? I suppose a
new `LitNatural` node and decent amount of copy-paste will do. Or,
possibly, we may reuse `LitInteger Integer Type` with appropriate `Type`
to avoid some duplication of code.
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14465>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
#15822: template-haskell package lacks any real documentation
-------------------------------------+-------------------------------------
Reporter: bgamari | Owner: (none)
Type: bug | Status: new
Priority: normal | Milestone:
Component: Documentation | Version: 8.6.1
Keywords: | Operating System: Unknown/Multiple
Architecture: | Type of failure: None/Unknown
Unknown/Multiple |
Test Case: | Blocked By:
Blocking: | Related Tickets:
Differential Rev(s): | Wiki Page:
-------------------------------------+-------------------------------------
Just as it says on the tin.
Your mission, if you choose to accept it: Look at the Haddocks for
[Language.Haskell.TH.Syntax](http://hackage.haskell.org/package/template-
haskell-2.14.0.0/docs/Language-Haskell-TH-Syntax.html), choose an
undocumented declaration, and start writing.
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15822>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
#9163: Ptr should have a phantom role
------------------------------------+-------------------------------------
Reporter: simonpj | Owner:
Type: bug | 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: |
------------------------------------+-------------------------------------
In `GHC.Ptr` we see
{{{
type role Ptr representational
data Ptr a = Ptr Addr# deriving (Eq, Ord)
}}}
with no comments. Why is `Ptr` representational?
In the same module we have `castPtr`:
{{{
castPtr :: Ptr a -> Ptr b
castPtr (Ptr addr) = Ptr addr
}}}
which unpacks and repacks a `Ptr`. If `Ptr` was phantom, we could use
`coerce`. And that in turn would actually make a lot of code more
efficient – there are lots of calls to `castPtr`. Specifically, in
`nofib`, I tried implementing `castPtr` with `unsafeCoerce`. Then I
found:
* 12% less allocation in `reverse-complem`
* 7.3% less allocation in `fasta`.
* Binary sizes fell 0.1%.
Both these benchmarks are ones that do a ''lot'' of I/O, and it turns out
that `GHC.IO.Handle.Text.$wa1` has a `castPtr` that (all by itself)
accounts for 12% of `reverse-complem`'s total allocation! So making
`castPtr` free is good.
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9163>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
#2600: Bind type variables in RULES
-------------------------------------+-------------------------------------
Reporter: simonpj | Owner: simonpj
Type: feature request | Status: closed
Priority: lowest | Milestone: 8.8.1
Component: Compiler | Version: 6.8.3
Resolution: fixed | Keywords:
Operating System: Unknown/Multiple | Architecture:
| Unknown/Multiple
Type of failure: None/Unknown | Test Case:
| rename/should_compile/T2600
Blocked By: | Blocking:
Related Tickets: #2110 | Differential Rev(s): Phab:D4894
Wiki Page: |
-------------------------------------+-------------------------------------
Comment (by mayac):
It's worth mentioning that this has not been ''completely'' addressed. The
following is now accepted:
{{{
{-# RULES
"myrule" forall t a. forall f x.
from (tmap f (to x :: t a)) = map f (from (to x :: t a))
#-}
}}}
but, as per #10595, it does not behave as one would expect – the rules
`"Class op tmap"` and `"Class op to"` may fire first. See that ticket for
the appropriate workaround.
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2600#comment:27>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
#13809: TH-reified data family instances have a paucity of kinds
-------------------------------------+-------------------------------------
Reporter: RyanGlScott | Owner: (none)
Type: bug | Status: new
Priority: normal | Milestone:
Component: Template | Version: 8.0.1
Haskell |
Keywords: TypeFamilies | Operating System: Unknown/Multiple
Architecture: | Type of failure: None/Unknown
Unknown/Multiple |
Test Case: | Blocked By:
Blocking: | Related Tickets:
Differential Rev(s): | Wiki Page:
-------------------------------------+-------------------------------------
Consider this data family (and instances):
{{{#!hs
{-# LANGUAGE TypeFamilies #-}
module Foo where
data family Foo a
data instance Foo ((f :: * -> *) (a :: *))
data instance Foo ((f :: (* -> *) -> *) (a :: (* -> *)))
}}}
These are two data family instances that GHC distinguishes by the kinds of
their type parameters. However, Template Haskell does not give me the same
insight that GHC has, because if I call `Language.Haskell.TH.reify ''Foo`,
I get this:
{{{#!hs
FamilyI
(DataFamilyD
Foo.Foo [ KindedTV a_6989586621679025989 StarT ] (Just StarT))
[ DataInstD
[]
Foo.Foo
[ AppT (VarT f_6989586621679026001) (VarT a_6989586621679026000) ]
Nothing
[]
[]
, DataInstD
[]
Foo.Foo
[ AppT (VarT f_6989586621679026007) (VarT a_6989586621679026006) ]
Nothing
[]
[]
]
}}}
Note that neither `f` nor `a` have a kind signature in either instance!
This makes it completely impossible to tell which is which (aside from the
order, which is brittle). It would make my life a lot easier if TH were to
include kind signatures for each type variable in a data family instance.
I can see two ways to accomplish this:
1. Include a `[TyVarBndr]` field in `DataInstD` and `NewtypeInstD` where
each `TyVarBndr` is a `KindedTV`.
2. Walk over the `Type`s in a `DataInstD`/`NewtypeInstD` and ensure that
every occurrence of a `VarT` is surrounded with `SigT` to indicate its
kind.
While (1) is arguably the cleaner solution, since it makes the kinds easy
to discover, it is a breaking change. Therefore, I'm inclined to implement
option (2) instead.
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13809>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
#2600: Bind type variables in RULES
-------------------------------------+-------------------------------------
Reporter: simonpj | Owner: simonpj
Type: feature request | Status: new
Priority: lowest | Milestone:
Component: Compiler | Version: 6.8.3
Resolution: | Keywords:
Operating System: Unknown/Multiple | Architecture:
| Unknown/Multiple
Type of failure: None/Unknown | Test Case:
Blocked By: | Blocking:
Related Tickets: #2110 | Differential Rev(s): Phab:D4894
Wiki Page: |
-------------------------------------+-------------------------------------
Comment (by Richard Eisenberg <rae@…>):
In [changeset:"512eeb9bb9a81e915bfab25ca16bc87c62252064/ghc" 512eeb9/ghc]:
{{{
#!CommitTicketReference repository="ghc"
revision="512eeb9bb9a81e915bfab25ca16bc87c62252064"
More explicit foralls (GHC Proposal 0007)
Allow the user to explicitly bind type/kind variables in type and data
family instances (including associated instances), closed type family
equations, and RULES pragmas. Follows the specification of GHC
Proposal 0007, also fixes #2600. Advised by Richard Eisenberg.
This modifies the Template Haskell AST -- old code may break!
Other Changes:
- convert HsRule to a record
- make rnHsSigWcType more general
- add repMaybe to DsMeta
Includes submodule update for Haddock.
Test Plan: validate
Reviewers: goldfire, bgamari, alanz
Subscribers: simonpj, RyanGlScott, goldfire, rwbarton,
thomie, mpickering, carter
GHC Trac Issues: #2600, #14268
Differential Revision: https://phabricator.haskell.org/D4894
}}}
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2600#comment:25>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
#15351: QuantifiedConstraints ignore FunctionalDependencies
-------------------------------------+-------------------------------------
Reporter: aaronvargo | Owner: (none)
Type: bug | Status: new
Priority: normal | Milestone:
Component: Compiler | Version: 8.5
(Type checker) |
Keywords: | Operating System: Unknown/Multiple
QuantifiedConstraints |
Architecture: | Type of failure: GHC rejects
Unknown/Multiple | valid program
Test Case: | Blocked By:
Blocking: | Related Tickets:
Differential Rev(s): | Wiki Page:
-------------------------------------+-------------------------------------
The following code fails to compile:
{{{#!hs
{-# LANGUAGE QuantifiedConstraints #-}
{-# LANGUAGE FunctionalDependencies #-}
class C a b | a -> b where
foo :: a -> b
bar :: (forall a. C (f a) Int) => f a -> String
bar = show . foo
}}}
{{{
• Could not deduce (Show a0) arising from a use of ‘show’
...
The type variable ‘a0’ is ambiguous
}}}
Yet it ought to work, since this is perfectly fine with top-level
instances:
{{{#!hs
instance C [a] Int where ...
baz :: [a] -> String
baz = show . foo
}}}
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15351>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
