#10377: Remove double negative of ("Unregisterised", "NO")
-------------------------------------+-------------------------------------
Reporter: erikd | Owner: erikd
Type: bug | Status: new
Priority: normal | Milestone: 7.12.1
Component: Compiler | Version: 7.11
Keywords: | Operating System: Unknown/Multiple
Architecture: | Type of failure: None/Unknown
Unknown/Multiple | Blocked By:
Test Case: | Related Tickets:
Blocking: |
Differential Revisions: |
-------------------------------------+-------------------------------------
The `settings` file has variable named `Unregisterised` which on most
arches is sed to `NO`.
I propose that the variable be renamed to `Registered` (dropping the
"ised" part as well) so that:
{{{
Old New
("Unregisterised", "NO") -> ("Registered", "YES")
("Unregisterised", "YES") -> ("Registered", "NO")
}}}
Unless someone can come up with a good reason why it should stay as it is,
I will submit a patch for this to phabricator.
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10377>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
#10782: Existential variables not scoped?
-------------------------------------+-------------------------------------
Reporter: goldfire | Owner:
Type: bug | Status: new
Priority: normal | Milestone:
Component: Compiler | Version: 7.11
(Type checker) |
Keywords: | Operating System: Unknown/Multiple
Architecture: | Type of failure: None/Unknown
Unknown/Multiple |
Test Case: | Blocked By:
Blocking: | Related Tickets:
Differential Revisions: |
-------------------------------------+-------------------------------------
I was looking into scoping of type variables, and it looks to me that
type-checking the introduction of existentials (that is, checking a GADT
pattern-match) doesn't extend the type environment. I doubt there's any
way to tickle this bug. But the existential skolems don't seem to be added
to the `tcl_tyvars` field of the `TcLclEnv`, which means that inner
quantification, should uniques collide(!), might do the wrong thing in
`quantifyTyVars`.
To be clear, I don't wish the variables actually to scope in Haskell
source, just for GHC to remember that the internal variables are in scope,
to return from `tcGetGlobalTyVars`.
Is my analysis wrong somewhere? Do we just assume that uniques being
unique will take care of this?
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10782>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
#1830: Automatic derivation of Lift
-------------------------------------+-------------------------------------
Reporter: guest | Owner:
| RyanGlScott
Type: feature request | Status: new
Priority: normal | Milestone: ⊥
Component: Template Haskell | Version: 6.8.1
Resolution: | Keywords:
Operating System: Unknown/Multiple | Architecture:
| Unknown/Multiple
Type of failure: None/Unknown | Test Case:
Blocked By: | Blocking:
Related Tickets: | Differential Revisions: Phab:D1168
-------------------------------------+-------------------------------------
Comment (by RyanGlScott):
Replying to [comment:12 mpickering]:
> Is it possible to derive these instances using GHC.Generics?
I believe so, although with `GHC.Generics` you cannot have special cases
for unlifted types like `Int#` (currently, the Phab differential uses the
[http://hackage.haskell.org/package/template-haskell-2.10.0.0/docs
/Language-Haskell-TH-Syntax.html#t:Lit Lit] type from `template-haskell`
to deal with them).
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1830#comment:13>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
#1830: Automatic derivation of Lift
-------------------------------------+-------------------------------------
Reporter: guest | Owner:
| RyanGlScott
Type: feature request | Status: new
Priority: normal | Milestone: ⊥
Component: Template Haskell | Version: 6.8.1
Resolution: | Keywords:
Operating System: Unknown/Multiple | Architecture:
| Unknown/Multiple
Type of failure: None/Unknown | Test Case:
Blocked By: | Blocking:
Related Tickets: | Differential Revisions: Phab:D1168
-------------------------------------+-------------------------------------
Comment (by mpickering):
Is it possible to derive these instances using GHC.Generics? Then the
DeriveAnyClass extension could be used for the same syntactic effect
without modifying the compiler.
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1830#comment:12>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
#8330: Remove ExtsCompat46 module once we bootstrap with GHC 7.8
-------------------------------------------+-------------------------------
Reporter: jstolarek | Owner:
Type: task | Status: new
Priority: low | Milestone: 7.10.1
Component: Compiler | Version: 7.7
Keywords: | Operating System:
Architecture: Unknown/Multiple | Unknown/Multiple
Difficulty: Easy (less than 1 hour) | Type of failure:
Blocked By: | None/Unknown
Related Tickets: | Test Case:
| Blocking:
-------------------------------------------+-------------------------------
Changing type signature of comparison primops from `Bool` to `Int#` in GHC
7.8 (see #6135) caused a problem: type signatures of functions might be
different for the bootstrapping compiler (if it is older than 7.8) than
they are for the stage1 compiler. In order to solve this problem I
introduced a compatibility module [[GhcFile(compiler/utils/ExtsCompat46)]]
that provides different definition of primops for older versions of GHC
(`__GLASGOW_HASKELL__ <= 706`) and different for newer versions
(`__GLASGOW_HASKELL__ > 706`). However, once we set minimal version of GHC
required for bootstrapping to be 7.8, we can (and should!) remove that
compatibility module and go back to using GHC.Exts. This ticket is a
reminder that we should do this after we release GHC 7.10 or 7.12.
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8330>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
#3379: GHC should use the standard binary package
-------------------------------------+-------------------------------------
Reporter: igloo | Owner:
Type: task | Status: new
Priority: normal | Milestone: 7.12.1
Component: Compiler | Version: 6.10.4
Resolution: | Keywords:
Operating System: Unknown/Multiple | Architecture:
| Unknown/Multiple
Type of failure: None/Unknown | Test Case:
Blocked By: | Blocking:
Related Tickets: | Differential Revisions:
-------------------------------------+-------------------------------------
Changes (by thomie):
* cc: kolmodin, jstolarek (added)
Comment:
The binary package received a portable implementation of `instance Binary
Integer` in the following commit:
https://github.com/kolmodin/binary/commit/2109b28f4d3919dbedcf42c97e5147116…
GHC's version looks like this:
{{{
instance Binary Integer where
-- XXX This is hideous
put_ bh i = put_ bh (show i)
get bh = do str <- get bh
case reads str of
[(i, "")] -> return i
_ -> fail ("Binary Integer: got " ++ show str)
}}}
As mentioned in Phab:D1165, `compiler/utils/Binary.hs` contains also a
commented out implementation of `instance Binary Integer`. It is
supposedly more efficient than the one in the `binary` package (but not
portable?).
This should all be cleared and cleaned up.
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/3379#comment:10>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
#1830: Automatic derivation of Lift
-------------------------------------+-------------------------------------
Reporter: guest | Owner:
| RyanGlScott
Type: feature request | Status: new
Priority: normal | Milestone: ⊥
Component: Template Haskell | Version: 6.8.1
Resolution: | Keywords:
Operating System: Unknown/Multiple | Architecture:
| Unknown/Multiple
Type of failure: None/Unknown | Test Case:
Blocked By: | Blocking:
Related Tickets: | Differential Revisions: Phab:D1168
-------------------------------------+-------------------------------------
Comment (by RyanGlScott):
Replying to [comment:10 goldfire]:
> What's wrong with using `th-lift`?
Type inference. `th-lift` is fundamentally limited in that it cannot infer
the correct instance context for complex data structures such as
{{{#!hs
data Nested f a = Nested (f a) deriving Lift
-- instance Lift (f a) => Lift (Nested f a) where ...
}}}
or
{{{#!hs
data R a = R a
instance (Show a, Lift a) => Lift (R a) where ...
data Restricted a = Restricted (R a) deriving Lift
-- instance (Show a, Lift a) => Lift (Restricted a) where ...
}}}
Granted, this could be improved if `th-lift` were changed to allow
something like this:
{{{#!hs
instance (Show a, Lift a) => Lift (Restricted a) where
lift = $(makeLift ''Restricted)
}}}
But a `deriving` statement is infinitely more aesthetically pleasing, in
my opinion.
> But that argument falls flat here, because users are clearly already
using TH!
Well, they're using the `template-haskell` library, but not necessarily
the `TemplateHaskell` extension. Users may want to define `Lift` instances
for data types without actually using the `TemplateHaskell` extension (as
doing so precludes a library from being built on a stage-1 compiler).
Having access to `DeriveLift` allows a library to be built with `Lift`
support on GHC stage 1 and 2, and then downstream packages that depend on
the library can decide if they want to actually utilize the `Lift`
instances by means of the `TemplateHaskell` extension.
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1830#comment:11>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
#1830: Automatic derivation of Lift
-------------------------------------+-------------------------------------
Reporter: guest | Owner:
| RyanGlScott
Type: feature request | Status: new
Priority: normal | Milestone: ⊥
Component: Template Haskell | Version: 6.8.1
Resolution: | Keywords:
Operating System: Unknown/Multiple | Architecture:
| Unknown/Multiple
Type of failure: None/Unknown | Test Case:
Blocked By: | Blocking:
Related Tickets: | Differential Revisions: Phab:D1168
-------------------------------------+-------------------------------------
Comment (by goldfire):
Thanks for taking this on, Ryan, but I'm unconvinced that GHC needs built-
in support here. What's wrong with using `th-lift`? I mean, I agree that
in theory, `DeriveLift` would be nice, but it's Yet Another Thing. If
something can be done well outside of GHC, I think it should be. A common
argument here is that if a feature is built-in (as opposed to requiring
TH), then users don't have to use TH. But that argument falls flat here,
because users are clearly already using TH!
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1830#comment:10>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
#4243: Make a proper options parser for the RTS
-------------------------------------+-------------------------------------
Reporter: igloo | Owner:
Type: task | Status: new
Priority: normal | Milestone: 7.12.1
Component: Runtime System | Version: 6.13
Resolution: | Keywords:
Operating System: Unknown/Multiple | Architecture:
| Unknown/Multiple
Type of failure: None/Unknown | Test Case:
Blocked By: | Blocking: 7535
Related Tickets: #9839 | Differential Revisions:
-------------------------------------+-------------------------------------
Comment (by bgamari):
osa1, I think for the sake of simplicity it would be best to avoid going
down that road. The RTS really just needs to work, even if Haskell-land is
broken (e.g. as is often the case when debugging RTS bugs or bringing up
new platforms).
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4243#comment:17>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
#1830: Automatic derivation of Lift
-------------------------------------+-------------------------------------
Reporter: guest | Owner:
| RyanGlScott
Type: feature request | Status: new
Priority: normal | Milestone: ⊥
Component: Template Haskell | Version: 6.8.1
Resolution: | Keywords:
Operating System: Unknown/Multiple | Architecture:
| Unknown/Multiple
Type of failure: None/Unknown | Test Case:
Blocked By: | Blocking:
Related Tickets: | Differential Revisions: Phab:D1168
-------------------------------------+-------------------------------------
Comment (by rwbarton):
> What should we do if someone attempts to derive `Lift` on a datatype
with no constructors?
Since `lift` then has type `Void -> Q Exp`, I would be inclined to define
it as `absurd`, i.e., an empty case. I don't see the point of turning it
into a runtime error when `lift (error "foo")` is a splice-time error for
an inhabited type.
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1830#comment:9>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
