Well suppose
data T a where
T1 :: T (Int,Int,Int)
T2 :: T (Int,Int)
f :: T a -> a -> Int
f a b = case a of
T1 -> case b of { (x,y,z) -> x+y+z }
_ -> 0
g :: T a -> a -> Int
f a b = case a of
T2 -> case b of { (x,y) -> x+y }
_ -> 0
h :: T a -> a -> Int
indication that a more general type error improvement sweep would be welcome
Absolutely yes. But it depends on someone saying “I want to do that”; and of
course on how hard or easy it turns out to be.
general UX improvements I would like to undertake.
Great! Make Trac tickets proposing
I was looking for an indication that a more general type error improvement
sweep would be welcome. I could pinpoint a particular type error if you
liked (such as the one that prompted this email), but there are general UX
improvements I would like to undertake.
On Fri, Mar 4, 2016 at 4:25 AM,
ImpredicativeTypes is indeed problematic. Perhaps you can add your example as
another Trac ticket? It's not really going to get fixed until someone pays
sustained attention to it.
Alejandro (cc'd) is working on this. We are working on a paper for ICFP...
wait a couple of weeks!
Simon
|
Simon, your GADT example clearly shows how lub sometimes needs to handle
products with different arities, but the case with bothDmd is still confuses
me. I think we need have a code like this:
f x + g x
Where f puts a S(SS) demand on x and g puts a S(SSS). This looks like a
bug/type error to
Good day!
I realise that ImpredicativeTypes is a problematic extension, but I have
found something that looks like an outright bug -- no polymorphism involved:
,
| {-# LANGUAGE ImpredicativeTypes #-}
|
| module Foo where
|
| foo :: IO (Maybe Int)
| foo = do
| pure $ case undefined ::
Identifying recursive types is an old and unsatisfactory part of GHC.
The code in TcTyDecls was an early attempt and has not received much love
since. Partly because it's not so clear exactly what it is trying to do! What
precisely does it mean for a TyCon to be "recursive" and what guarantees
Maybe you could just maintain a separate map "on the side" and push it through
to the LLVM code gen?
I hate the whole proc-point machinery. It's all caused by our inability to
take the address of a local label. So to push a return address on the stack we
have to make it a top-level
Facundo
Yes, that makes perfect sense. Moreover, it is pretty much exactly what the
tct_closed flag on `ATcId` does.
The trick will be to guarantee that all those Ids do in fact end up being
floated out.
We could have a Skype chat about this, preferably after the March 16 ICFP
deadline
Christopher
Improving error message is an excellent goal, and one that I have spent more
hours on than I care to tell you.
If you have a particular one in mind, could you open a Trac ticket with a
particular reproducible test case, the error message you get, and the error
message you’d like
| current thought is that you collect the usage demands on the fields of
| the constructor for the alternative you're analysing (let's say it's
| tag 1) and insert that into a USum where the usage demands on all the
| other constructors (all the tags except 1) is UHead.
I'm not sure you
On 03/03/2016 11:32 AM, Ben Gamari wrote:
>> Given a CmmGraph, is there a possibility to annotate information to a
>> single node within this graph? I.e. I want to annotate to certain
>> CmmCalls that they where introduced by 'proc point splitting'. I would
>> like to slightly modifiy the
12 matches
Mail list logo
