#8931: The type defaulting in GHCi with Typeable
-------------------------------------+-------------------------------------
Reporter: skata | Owner:
Type: bug | Status: new
Priority: normal | Milestone:
Component: Compiler (Type | Version: 7.8.1-rc2
checker) | Operating System: Unknown/Multiple
Keywords: type defaulting, | Type of failure: GHC rejects
Typeable | valid program
Architecture: Unknown/Multiple | Test Case:
Difficulty: Unknown | Blocking:
Blocked By: |
Related Tickets: |
-------------------------------------+-------------------------------------
The type defaulting in GHCi works in less cases with GHC 7.8.1-rc2 than
with older versions, though there is no change in the related part of the
documentation (i.e., "2.4.7 Type defaulting in GHCi").
{{{
skata@kata58:~$ ghc --version
The Glorious Glasgow Haskell Compilation System, version 7.8.0.20140228
skata@kata58:~$ ghci
GHCi, version 7.8.0.20140228: http://www.haskell.org/ghc/ :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Prelude> :m +Data.Typeable
Prelude Data.Typeable> let {f :: Read a => (a->Bool) -> Char; f =
undefined}
Prelude Data.Typeable> f (\x -> (x == 3))
*** Exception: Prelude.undefined
<== This is the expected result.
Prelude Data.Typeable> let {f :: Typeable a => (a->Bool) -> Char; f =
undefined}
Prelude Data.Typeable> f (\x -> (x == 3))
<== Type defaulting does not work in this case.
<interactive>:6:1:
No instance for (Typeable a0) arising from a use of ‘f’
The type variable ‘a0’ is ambiguous
Note: there are several potential instances:
instance [overlap ok] Typeable ()
-- Defined in ‘Data.Typeable.Internal’
instance [overlap ok] Typeable Bool
-- Defined in ‘Data.Typeable.Internal’
instance [overlap ok] Typeable Char
-- Defined in ‘Data.Typeable.Internal’
...plus 14 others
In the expression: f (\ x -> (x == 3))
In an equation for ‘it’: it = f (\ x -> (x == 3))
<interactive>:6:13:
No instance for (Eq a0) arising from a use of ‘==’
The type variable ‘a0’ is ambiguous
Relevant bindings include x :: a0 (bound at <interactive>:6:5)
Note: there are several potential instances:
instance Eq a => Eq (GHC.Real.Ratio a) -- Defined in ‘GHC.Real’
instance Eq Integer -- Defined in ‘integer-gmp:GHC.Integer.Type’
instance Eq () -- Defined in ‘GHC.Classes’
...plus 33 others
In the expression: (x == 3)
In the first argument of ‘f’, namely ‘(\ x -> (x == 3))’
In the expression: f (\ x -> (x == 3))
<interactive>:6:16:
No instance for (Num a0) arising from the literal ‘3’
The type variable ‘a0’ is ambiguous
Relevant bindings include x :: a0 (bound at <interactive>:6:5)
Note: there are several potential instances:
instance Num Double -- Defined in ‘GHC.Float’
instance Num Float -- Defined in ‘GHC.Float’
instance Integral a => Num (GHC.Real.Ratio a)
-- Defined in ‘GHC.Real’
...plus 7 others
In the second argument of ‘(==)’, namely ‘3’
In the expression: (x == 3)
In the first argument of ‘f’, namely ‘(\ x -> (x == 3))’
}}}
On the other hand,
{{{
skata@kata58:~$ ghc --version
The Glorious Glasgow Haskell Compilation System, version 7.4.1
skata@kata58:~$ ghci
GHCi, version 7.4.1: http://www.haskell.org/ghc/ :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Prelude> :m +Data.Typeable
Prelude Data.Typeable> let {f :: Read a => (a->Bool) -> Char; f =
undefined}
Prelude Data.Typeable> f (\x -> (x == 3))
*** Exception: Prelude.undefined
Prelude Data.Typeable> let {f :: Typeable a => (a->Bool) -> Char; f =
undefined}
Prelude Data.Typeable> f (\x -> (x == 3))
*** Exception: Prelude.undefined
}}}
I think the old behavior is compliant with the documentation.
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8931>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
#7730: :info and polykinds
--------------------------------------------+------------------------------
Reporter: monoidal | Owner: archblob
Type: bug | Status: new
Priority: normal | Milestone: 7.8.1
Component: Compiler (Type checker) | Version: 7.6.2
Resolution: | Keywords:
Operating System: Unknown/Multiple | Architecture:
Type of failure: None/Unknown | Unknown/Multiple
Test Case: | Difficulty: Unknown
Blocking: | Blocked By:
| Related Tickets: #8776
--------------------------------------------+------------------------------
Comment (by archblob):
I do think you know what's best and I will look into exactly how much
information needs to be added and write a patch. The reason I considered
the other aproach was because I didn't really think modifying the iface
implementation would be something you were willing to do just because of
pretty printing purposes.
Also there will not really be that much code duplication when doing
separate tidying so I will try and have a patch with both aproaches next
week and I'll also try to understand exactly how the iface interface
should be extended and maybe start a discussion about that as I make
progress.
Andrei
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7730#comment:12>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
#7730: :info and polykinds
--------------------------------------------+------------------------------
Reporter: monoidal | Owner: archblob
Type: bug | Status: new
Priority: normal | Milestone: 7.8.1
Component: Compiler (Type checker) | Version: 7.6.2
Resolution: | Keywords:
Operating System: Unknown/Multiple | Architecture:
Type of failure: None/Unknown | Unknown/Multiple
Test Case: | Difficulty: Unknown
Blocking: | Blocked By:
| Related Tickets: #8776
--------------------------------------------+------------------------------
Comment (by simonpj):
I'm quite reluctant to duplicate all that tidying machinery. Moreover, we
need to pretty-print `IfaceDecl`s anyway, so this is just duplicating
that. If there isn't enough information in `IfaceSyn`, maybe we should add
a little more. For Gergo's point I was going to add an extra constructor
to `IfaceType`, corresponding to `=>`, for example. Easy; and will
improve the output from `--show-iface`.
So by all means go ahead, and I will look, but I'm advertising that my
instinct is still to take the approach I outlined.
Simon
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7730#comment:11>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
#7730: :info and polykinds
--------------------------------------------+------------------------------
Reporter: monoidal | Owner: archblob
Type: bug | Status: new
Priority: normal | Milestone: 7.8.1
Component: Compiler (Type checker) | Version: 7.6.2
Resolution: | Keywords:
Operating System: Unknown/Multiple | Architecture:
Type of failure: None/Unknown | Unknown/Multiple
Test Case: | Difficulty: Unknown
Blocking: | Blocked By:
| Related Tickets: #8776
--------------------------------------------+------------------------------
Comment (by archblob):
I have managed to fix this (not yet for kind!) using the tidying machinery
from {{{ MkIface}}}.
I first tried going through {{{IfaceDecl}}} as Simon suggested here and in
#8776, but this gets really messy because as Gergo observed
{{{tyThingToIfaceDecl}}} doesn't work for {{{RealDataCon}}}, and I also
observed the same story for {{{ClassOpId}}} and this will require us keep
{{{TyThing}}} in certain cases. I thing this will lead to code that is
more complex and harder to understand in the long run.
I also haven't looked into how this relates to #8776 but I thing we can
also go without conversion to {{{IfaceDecl}}} in that case.
I will have a patch ready in a couple of days(some other things came up)
and after we further discuss the right aproach.
Andrei
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7730#comment:10>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
#7942: aarch64 support in ghc
--------------------------------------------+------------------------------
Reporter: jcapik | Owner:
Type: feature request | Status: patch
Priority: normal | Milestone: 7.10.1
Component: Compiler | Version: 7.6.3
Resolution: | Keywords:
Operating System: Linux | Architecture: arm
Type of failure: GHC doesn't work at all | Difficulty: Unknown
Test Case: | Blocked By: 7623, 8664
Blocking: | Related Tickets:
--------------------------------------------+------------------------------
Comment (by cjwatson):
Right. I thought that was probably the case, but I didn't really want to
do yet another build that omitted them in order to make sure, since it all
takes a while as it is!
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7942#comment:27>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
#7942: aarch64 support in ghc
--------------------------------------------+------------------------------
Reporter: jcapik | Owner:
Type: feature request | Status: patch
Priority: normal | Milestone: 7.10.1
Component: Compiler | Version: 7.6.3
Resolution: | Keywords:
Operating System: Linux | Architecture: arm
Type of failure: GHC doesn't work at all | Difficulty: Unknown
Test Case: | Blocked By: 7623, 8664
Blocking: | Related Tickets:
--------------------------------------------+------------------------------
Comment (by kgardas):
Colin, thanks for submitting this. Indeed, I think for basic
unregisterised build to work changes done in includes/stg/ and rts/ may be
omitted for now. Those are my experimental bits kind of start of a work on
registerised support...
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7942#comment:26>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
#7942: aarch64 support in ghc
--------------------------------------------+------------------------------
Reporter: jcapik | Owner:
Type: feature request | Status: new
Priority: normal | Milestone: 7.10.1
Component: Compiler | Version: 7.6.3
Resolution: | Keywords:
Operating System: Linux | Architecture: arm
Type of failure: GHC doesn't work at all | Difficulty: Unknown
Test Case: | Blocked By: 7623, 8664
Blocking: | Related Tickets:
--------------------------------------------+------------------------------
Comment (by cjwatson):
I've been working with Karel Gardas (kgardas) to get this going, and I've
now completed an unregisterised GHC bootstrap on Ubuntu arm64. I started
by cross-building GHC 7.8 using variations on Karel's patch set, and then
bodged together a GHC 7.6 build (since that's what we're shipping on other
architectures) bootstrapping off that. This all now appears to be working
fine and I should be able to get binaries into our archive in the next few
days.
I'm attaching a patch (made against the ghc-7.8 branch); most of it is
Karel's from https://ghcarm.wordpress.com/2014/01/18/unregisterised-ghc-
head-build-for-arm64-platform/, I've just tweaked it a bit given that I
had the advantage of access to real hardware. Some of this may be
unnecessary for an unregisterised build, but it doesn't hurt. It would be
great if somebody could review and apply it, since it's a lot easier to
get started on more advanced things like LLVM or NCG support if you don't
have to do the time-consuming bootstrap yourself. Please note that you
also need to update the embedded copy of libffi in `libffi-tarballs/` to
at least version 3.0.12.
Karel's initial patch caused `GHC_CONVERT_CPU` to return `arm64`. I
changed this to `aarch64`, since the return value of `GHC_CONVERT_CPU` is
used to construct the `--host` option for configure scripts and thus it
needs to be valid as the first part of a GNU config triplet. I left the
Haskell-level architecture name as `ArchARM64`, since that style is more
common as a user-facing name for the architecture: for example, the Linux
kernel returns `arm64` in its `uname` output.
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7942#comment:24>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
#8834: 64-bit windows cabal.exe segfaults in GC
----------------------------------+---------------------------------
Reporter: awson | Owner:
Type: bug | Status: new
Priority: highest | Milestone: 7.8.1
Component: None | Version: 7.8.1-rc2
Keywords: | Operating System: Windows
Architecture: x86_64 (amd64) | Type of failure: None/Unknown
Difficulty: Unknown | Test Case:
Blocked By: | Blocking:
Related Tickets: |
----------------------------------+---------------------------------
`cabal.exe` built with 64-bit windows GHC segfaults doing `cabal
configure` or `cabal install` or probably something else.
This occurs *both* for cabal-install 1.18.0.2 built against Cabal 1.18.1.2
and for cabal-install 1.18.0.3 built against Cabal 1.18.1.3.
This occurs only for 64-bit build, 32-bit build is fine.
64-bit GHC-7.6.3 build is also fine.
During debugging I see segfault occurs inside `evacuate` somewhere near
`get_itbl` call I guess.
If I make `cabal.exe` to not trigger some presumably bad GC compiling it
with `-rtsopts` and running it as (for example) {{{cabal +RTS -H256m -m50
-RTS ...}}} the problem disappears.
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8834>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
#8956: Confusing error message due to ` #`-lines
-------------------------+-------------------------------------------------
Reporter: hvr | Owner:
Type: bug | Status: new
Priority: | Milestone:
normal | Version: 7.8.1-rc2
Component: | Operating System: Unknown/Multiple
Compiler | Type of failure: Incorrect warning at
Keywords: | compile-time
Architecture: | Test Case:
Unknown/Multiple | Blocking:
Difficulty: |
Unknown |
Blocked By: |
Related Tickets: |
-------------------------+-------------------------------------------------
Consider the following two (invalid) modules `M1` and `M2`:
{{{#!hs
# 1 "<built-in>" 1
module M1 where
}}}
and
{{{#!hs
# 1 "<built-in>" 1
module M2 where
}}}
When those are compiled separately by GHC, they result in the following
error:
{{{
$ ghc -c -Wall M1.hs
M1.hs:1:2: parse error on input ‘#’
ghc -c -Wall M2.hs
M2.hs:1:2: parse error on input ‘#’
}}}
However, when compiled simultaneously, the modules get seemingly parsed as
`Main`-modules (which then conflict with each others):
{{{
ghc --make -Wall M1.hs M2.hs
<no location info>:
module ‘main:Main’ is defined in multiple files: M1.hs M2.hs
}}}
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8956>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
