Arguably, what should happen is we redo the format for machine-parseability
and use that in future versions of GHC.
Edward
Excerpts from Johan Tibell's message of Wed Mar 07 23:38:06 -0500 2012:
> Thanks Edward. I'll try to summarize this in human readable form and
> publish it on the wiki.
>
>
Thanks Edward. I'll try to summarize this in human readable form and
publish it on the wiki.
-- Johan
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
This is the important bit of code in the file:
instance Outputable Demand where
ppr Top = char 'T'
ppr Abs = char 'A'
ppr Bot = char 'B'
ppr (Defer ds) = char 'D' <> ppr ds
ppr (Eval ds) = char 'U' <> ppr ds
ppr (Box (Eval ds)) =
On Wed, Mar 7, 2012 at 5:40 PM, Brandon Allbery wrote:
>> Data F = F Int
>
> would give you something that could produce U(L), the U for the F
> constructor, the L for the contained Int.
Some experimentation suggests U is for unboxed. For example,
module Test where
f :: Int -> Int
f
On Wed, Mar 7, 2012 at 20:01, Johan Tibell wrote:
> On Wed, Mar 7, 2012 at 4:38 PM, Brandon Allbery
> wrote:
> > I think the original type signature is needed to figure it out. In the
> > earlier example it indicated ghc drilling down into the type (a tuple)
> and
> > determining the strictness
On Wed, Mar 7, 2012 at 5:01 PM, Johan Tibell wrote:
> On Wed, Mar 7, 2012 at 4:38 PM, Brandon Allbery wrote:
>> I think the original type signature is needed to figure it out. In the
>> earlier example it indicated ghc drilling down into the type (a tuple) and
>> determining the strictness of th
On Wed, Mar 7, 2012 at 4:38 PM, Brandon Allbery wrote:
> I think the original type signature is needed to figure it out. In the
> earlier example it indicated ghc drilling down into the type (a tuple) and
> determining the strictness of the constituents.
I parenthesis were for tuples I would nev
On Wed, Mar 7, 2012 at 18:41, Johan Tibell wrote:
> Edward, I have looked at that file before and it didn't make me much
> wiser, because I cannot map it to the output.
>
> I find it's the parenthesis that confuses me the most. What does this mean?
>
> C(U(LU(L)))
>
I think the original type sig
Edward, I have looked at that file before and it didn't make me much
wiser, because I cannot map it to the output.
I find it's the parenthesis that confuses me the most. What does this mean?
C(U(LU(L)))
what about this?
U(SLLAA)LL
-- Johan
___
Glasg
Ah, looks like it got a bit more complicated since I looked at it
last... time to update jhc :)
Actually. not sure if the Eval/Box split is relevant to my core. hmm
John
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
ht
Check out compiler/basicTypes/Demand.lhs
Cheers,
Edward
Excerpts from Johan Tibell's message of Wed Mar 07 18:21:56 -0500 2012:
> Hi,
>
> If someone could clearly specify the exact interpretation of these
> LLSL(ULL) strictness/demand annotations shown by ghc --show-iface I'd
> like to try to wr
On Wed, Mar 7, 2012 at 3:26 PM, John Meacham wrote:
> L = lazy
> S = strict
> A = absent
>
> f :: Int -> (Char,Char) -> Int -> Char
>
> LS(S,L)A
>
> means that it is lazy in the first int, strict in the tuple, strict in
> the first argument of the tuple but lazy in the second and the third
> argum
L = lazy
S = strict
A = absent
f :: Int -> (Char,Char) -> Int -> Char
LS(S,L)A
means that it is lazy in the first int, strict in the tuple, strict in
the first argument of the tuple but lazy in the second and the third
argument is not used at all. I have a paper that describes it
somewhere. I mo
Hi,
If someone could clearly specify the exact interpretation of these
LLSL(ULL) strictness/demand annotations shown by ghc --show-iface I'd
like to try to write a little tool that highlights the function
argument binding in an IDE (e.g. Emacs) with this information. Anyone
care to explain the syn
On Wed, 7 Mar 2012 17:07:06 +0400
Paul Graphov wrote:
> Hello GHC-users!
>
> I'm trying to compile GHC-7.4.1 under OpenIndiana and get the
> following error all the time:
>
> ghc.mk:85: *** Make has restarted itself 2 times; is there a makefile
> bug?. Stop.
>
> I googled a bit and found that
Hello GHC-users!
I'm trying to compile GHC-7.4.1 under OpenIndiana and get the
following error all the time:
ghc.mk:85: *** Make has restarted itself 2 times; is there a makefile
bug?. Stop.
I googled a bit and found that this can be a result of touching some
files during build. But actually no
16 matches
Mail list logo
