ll parse as
>>> (HsApp (HsApp (HsVar op) (HsVar a)) (HsVar b)). But it would be silly for
>>> us to get bent out of shape because of such a vanishingly rare corner
>>> case. Instead, if you really want to reflect it faithfully, add a new
>>> constructor for “par
Instead, if you really want to reflect it faithfully, add a new
>> constructor for “parens around backticks”).
>>
>>
>>
>> Let’s only take these overheads when there is real reason to do so.
>>
>>
>>
>> Simon
>>
>>
>>
>&
> Simon
>
>
>
> *From:* ghc-devs [mailto:ghc-devs-boun...@haskell.org] *On Behalf Of *Alan
> & Kim Zimmerman
> *Sent:* 12 December 2014 14:22
> *To:* ghc-devs@haskell.org
> *Subject:* D538 and compiler performance spec
>
>
>
> For API annotations I am worki
for “parens
around backticks”).
Let’s only take these overheads when there is real reason to do so.
Simon
From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Alan & Kim
Zimmerman
Sent: 12 December 2014 14:22
To: ghc-devs@haskell.org
Subject: D538 and compiler performance
For API annotations I am working in the details of RdrNames, which come in
a bewildering variety of syntactic forms.
My latest change causes perf/compiler to fail, with
bytes allocated value is too high:
Expectedparsing001(normal) bytes allocated: 587079016 +/-5%
Lower bound parsing00
