Hello Simon,
Thank you for your reply, I am indeed using undecidable instances.
The type of the "offending" dictionary is: forall (n::GHC.TypeLits.Nat).
(GHC.TypeLits.<=) 1 n
Indeed, part of the context for my 'Num' instance is: 1 <= n
Where GHC.TypeLits defines: type x <= y = (x <=? y) ~ True
I don't really get why this GHC.TypeLits constraint is a bottom dictionary...
Is it because all Coercions/Constraints are bottom?
Is there perhaps a set of flags I can use so that I can see the Core term
corresponding to CLaSH.Sized.Fixed.$fNumFixed2 during compilation?
As for exposing bottom values with -fexpose-all-unfoldings, my use-case is
specific, but not too specific I guess.
What I do is use whole-program transformation to convert Core to the hardware
description language VHDL.
As such, any identifier without an unfolding must be considered a black box,
for which the compiler must have builtin knowledge.
I understand that primitive operators defined in GHC.Prim, such as '+#', don't
have an unfolding.
And indeed, for those operators I can generate equivalently behaving VHDL.
But it becomes annoying when any user code can give rise to potential
identifiers with no unfolding.
I think that any of the Haskell->Javascript projects that start from Core would
have the same issues.
Hence my believe that my use-case is not too specific.
Also, the flag is called -fexpose-all-unfoldings, not
-fexpose-all-unfoldings-except-bottom-values ;-)
-- Christiaan
On Mar 28, 2014, at 10:08 AM, Simon Peyton Jones <simo...@microsoft.com> wrote:
> From what you say, in a subsequent message, about the strictness being "b",
> that means the strictness analyser has decided that $fNumFixed2 is bottom
> (i.e. diverges). So there's no point in exposing the unfolding, because (one
> way or another) it's an infinite loop, so there's no point in optimising it.
>
> It's unusual to have a bottom dictionary; you must be using undecidable
> instances or something. ("Scrap your boilerplate with class" describes why
> recursive dictionaries are good.) Bur apparently you have.
>
> It's arguable that with -fexpose-all-unfoldings we should expose even bottom
> values. If you have a reason for wanting that, it'd be an easy change to
> make, I think.
>
> Simon
>
> | -----Original Message-----
> | From: Glasgow-haskell-users [mailto:glasgow-haskell-users-
> | boun...@haskell.org] On Behalf Of Christiaan Baaij
> | Sent: 26 March 2014 16:41
> | To: glasgow-haskell-users
> | Subject: GHC API: getting the unfolding of a "strange" Id
> |
> | Dear list,
> |
> | I'm using the GHC API to get Core Expressions from haskell interface
> | (.hi) files, and have encountered a strange kind of 'Id' for which I
> | can't seem to get the unfolding:
> |
> | The properties of this 'Id' are the following:
> | - varName: $fNumFixed2
> | - IdDetails: VannillaId
> | - Pretty print of IdInfo.inlinePragInfo: [Always]
> | - IdInfo.unfoldingInfo: NoUnfolding
> |
> | The source file which gives rise to this 'Id' is:
> | https://github.com/christiaanb/clash-
> | prelude/blob/master/src/CLaSH/Sized/Fixed.hs
> | As you can see, the file is compiled with: -fexpose-all-unfoldings
> |
> | The '$f' prefix seems to indicate that the 'Id' is a Dictionary Function,
> | so I was expecting its 'IdInfo.unfoldingInfo' to be a 'DFunUnfolding'.
> | Given that pretty printing 'inlinePragInfo' gives me '[Always]', I would
> | expect to have a usable 'Unfolding' in general.
> | How can GHC inline the body of this 'Id' if it has no unfolding?
> |
> | Also, if I compile the file with "-O0 -fno-omit-interface-pragmas", the
> | $fNumFixed2 'Id' is no longer included in the interface file.
> | At positions where "$fNumFixed2" was originally used, a equality
> | constraint can eventually be found:
> |
> | Using -O:
> | (CLaSH.Sized.Fixed.$fNumFixed2
> | @(GHC.TypeLits.+ 4 4)
> |
> | Using -O0 -fno-omit-interface-pragmas:
> | (GHC.Types.Eq#
> | @GHC.Types.Bool
> | @(GHC.TypeLits.<=? 1 (GHC.TypeLits.+ 4 4))
> | @GHC.Types.True
> | _CO_)
> |
> | So my question is, what kind of "strange" 'Id' is this $fNumFixed2?
> | And how can I get the Core expression for this 'Id' from the interface
> | file?
> | And if I can't get it from the interface file, is there a straightforward
> | way to generate it from the 'Id'?
> |
> | Cheers,
> |
> | Christiaan
> |
> |
> | _______________________________________________
> | Glasgow-haskell-users mailing list
> | Glasgow-haskell-users@haskell.org
> | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
