D538 and compiler performance spec

[Alan & Kim Zimmerman]

The problem is round-tripping cases like this, which are valid

    (     ///     ) :: Int -> Int -> Int
    a /// b = 3

    baz :: Int -> Int -> Int
    a `     baz     ` b = 4

There can be arbitrary spaces between the surrounding parens and the
operator name, and between the backquotes and the identifier in the infix
version.

In each case we simply get a RdrName, which in turn is wrapped in HsVar or
whatever.

The D538 productions are of the form

    var     :: { Located RdrName }
            : varid                 { $1 }
            | '(' varsym ')'        {% ams (sLL $1 $> (unLoc $2))
                                           [mo $1,mj AnnVal $2,mc $3] }

and

    tyvarop :: { Located RdrName }
    tyvarop : '`' tyvarid '`'       {% ams (sLL $1 $> (unLoc $2))
                                           [mj AnnBackquote $1,mj AnnVal $2
                                           ,mj AnnBackquote $3] }

So the location tracks the entire span, but we need annotations for the
three individual parts.

Note: I did not check how far close to the limit the performance was prior
to this change, it may have been the last 1% to take it over.

Alan


On Fri, Dec 12, 2014 at 11:03 PM, Simon Peyton Jones <simonpj at microsoft.com>
wrote:
>
>   I am now adding an `AnnVal` to every RdrName, to be able to separate it
> out from any decoration, such as surrounding backticks or parens.
>
>
>
> That seems like overkill to me.  (a `op` b) is an HsOpApp, and must of
> course have backticks unless op is an operator like (a + b), in which case
> it doesn’t.
>
>
>
> The corner case is something like ((`op`) a b), which will 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 “parens around backticks”).
>
>
>
> Let’s only take these overheads when there is real reason to do so.
>
>
>
> Simon
>
>
>
> *From:* ghc-devs [mailto:ghc-devs-bounces at haskell.org] *On Behalf Of *Alan
> & Kim Zimmerman
> *Sent:* 12 December 2014 14:22
> *To:* ghc-devs at haskell.org
> *Subject:* D538 and compiler performance spec
>
>
>
> 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:
>     Expected    parsing001(normal) bytes allocated: 587079016 +/-5%
>     Lower bound parsing001(normal) bytes allocated: 557725065
>     Upper bound parsing001(normal) bytes allocated: 616432967
>     Actual      parsing001(normal) bytes allocated: 704940512
>     Deviation   parsing001(normal) bytes allocated:      20.1 %
>
> I am now adding an `AnnVal` to every RdrName, to be able to separate it
> out from any decoration, such as surrounding backticks or parens.
>
> Is this a problem? The alternative would be to add a SourceText field to
> RdrName.
>
> Alan
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141212/1636b9a8/attachment-0001.html>