Re: [GHC] #1496: Newtypes and type families combine to produce inconsistent FC(X) axiom sets
#1496: Newtypes and type families combine to produce inconsistent FC(X) axiom
sets
+---
Reporter: sorear |Owner: simonpj
Type: bug | Status: new
Priority: high |Milestone: 6.8 branch
Component: Compiler (Type checker) | Version: 6.7
Severity: critical | Resolution:
Keywords: | Difficulty: Unknown
Os: Unknown | Testcase:
Architecture: Unknown |
+---
Comment (by Isaac Dupree):
Replying to [comment:12 toms]:
However, GADTs are definitely not functors.
...
We can attempt to fix the situation by imposing conditions on the
types involved in
a newtype deriving:
* generate the fmap code, and hence demand explicit Functor
instances.
We should be able to expect the compiler to eliminate any runtime
overhead.
From Frisby we have a data type that is a Functor and a GADT, but not a
Functor in the way you and GHC expect:
{{{
data PE a where
-- leaving out most of the constructors, but note especially PMap
Char :: IntSet.IntSet - PE Char
Failure :: PE a
Not :: PE a - PE ()
Then :: PE a - PE b - PE (a,b)
PMap :: (a - b) - PE a - PE b
instance Functor PE where
fmap = PMap
}}}
Applying the `fmap`-option would make interesting, type-correct code be
generated that could not be optimized away (so the dictionaries couldn't
be shared).
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1496#comment:14
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[GHC] #1802: proposal: fix comparison operations for base:Data.Version.Version
#1802: proposal: fix comparison operations for base:Data.Version.Version +--- Reporter: [EMAIL PROTECTED] | Owner: Type: proposal | Status: new Priority: normal | Milestone: Component: libraries/base |Version: 6.6.1 Severity: normal | Keywords: Difficulty: Unknown| Os: Unknown Testcase: | Architecture: Unknown +--- Proposal: that values of the type Data.Version.Version should compare equal, by ignoring trailing zeros. Thus 1.2.0 == 1.2, rather than 1.2.0 1.2 -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1802 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #1800: Template Haskell support for running functions defined in the same module
#1800: Template Haskell support for running functions defined in the same
module
-+--
Reporter: simonpj |Owner:
Type: feature request | Status: new
Priority: normal|Milestone: _|_
Component: Template Haskell | Version: 6.6.1
Severity: normal| Resolution:
Keywords:| Difficulty: Unknown
Os: Unknown | Testcase:
Architecture: Unknown |
-+--
Comment (by guest):
It would be interesting to note how the template-haskell end user copes
with this problem to illustrate why the proposed feature is useful.
I myself have had to face this problem when designing an embedded compiler
for system design.
Doe to the mentioned limitation I'm normally forced to push the
arguments out of the splice.
As a (simplified) example, in my System Modelling DSL I have to create
system definition. That is done by providing the function Name together
with the identifiers of its inputs and outputs.
{{{
inputs = [in1, in2]
outputs = [out1, out2]
f :: Signal Int - Signal Int - (Signal Int, Signal Int)
f = ...
}}}
Since it is not possible to do
{{{
system :: SysDef
system = $(mkSysDef 'f inputs outputs)
}}}
due to the limitation explained in this ticket. I'm forced to do:
{{{
system :: SysDef
system = $(mkSysDef 'f) inputs outputs
-- where mkSysDef :: Name - ExpQ
}}}
My solution does not solve the problem. It rather bypasses it.
Furthermore, mkSysDef unfortunately cannot do static checking (for
example, it cannot make sure that all the inputs and outputs have
different identifiers). However, that's better than asking the user to
create the system definitions and identifiers in different modules.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1800#comment:2
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
