Hello everyone,
I routinely find myself having to dig through the Outputable instances
in Demand.Types to decipher our joint demand signature syntax. Tonight I
finally broke down and extracted a BNF-like grammar summarizing the
syntax. It can be found on the Wiki [1]. I hope it is helpful for othe
Hi Josh,
I don't think this addresses the points mine or Zubin's email that is
it not correct to write a HIE file with a different BinHandle. If you
do this then you will end up with a HIE file which contains Names
which don't contain any SrcSpan information.
If I am misunderstanding then please
On Thu, 23 Apr 2020 at 09:17, Ömer Sinan Ağacan
wrote:
> Thanks Simon,
>
> > We don't want to include the *definitions* of things that are
> re-exported,
> > because that would bloat interface files a lot.
>
> I think by definition you mean unfoldings, pragmas, annotations, and rules,
> right?
>
Yes, Matthew is correct, the symbol table for Names used by HIE files is
quite distinct from the usual Iface symbol table for Names. Sharing the HIE
symbol table and the Iface symbol table for names will be quite tricky.
One crucial difference is that we also save information about local names
to
Hi,
I've just noticed these spam projects on our gitlab:
- https://gitlab.haskell.org/craigonaldson/lumaslim
- https://gitlab.haskell.org/AnthonyMussen/survey-of-evianne-cream
- https://gitlab.haskell.org/RobertoHeard/robertoheard
- https://gitlab.haskell.org/salihagenter/commission-based-busine
Thanks Simon,
> We don't want to include the *definitions* of things that are re-exported,
> because that would bloat interface files a lot.
I think by definition you mean unfoldings, pragmas, annotations, and rules,
right?
I'm a bit surprised by this, because this would require tracking transit
I also looked at this patch briefly now and it's my understanding that
the intention is to use this for HIE files as well?
HIE files currently serialises Names differently to normal interface
files (to also include the SrcSpan) and it wasn't clear to me that the
current implementation would allow
The "extensible interface files" [1, 2] work has been discussed at GHC calls a
few times and the conclusion was we were going to document why current
annotation mechanism (ANN pragmas) are insufficient and we need yet another way
to put stuff into interfaces.
Unfortunately the MR was merged before
