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
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- | bounces@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