Feedback request for #9628 AST Annotations

[Alan & Kim Zimmerman]

Ok, I have started a discussion on haskell-cafe, will cross reference to
reddit too

Alan

On Wed, Oct 1, 2014 at 7:44 PM, Simon Peyton Jones <simonpj at microsoft.com>
wrote:

>  Let me urge you, once again, to consult users.  I really do not want to
> implement a feature that (thus far) lacks a single enthusiastic user.
> Please.
>
>
>
> Simon
>
>
>
> *From:* Alan & Kim Zimmerman [mailto:alan.zimm at gmail.com]
> *Sent:* 01 October 2014 16:13
> *To:* Simon Peyton Jones
> *Cc:* Richard Eisenberg; Edward Z. Yang; ghc-devs at haskell.org
>
> *Subject:* Re: Feedback request for #9628 AST Annotations
>
>
>
> I have put up a new diff at https://phabricator.haskell.org/D297
>
> It is just a proof of concept at this point, to check if the approach is
> acceptable.
>
> This is much less intrusive, and only affects the lexer/parser, in what
> should be a transparent way.
>
> The new module ApiAnnotation was introduced because it needs to be
> imported by Lexer.x, and I was worried about another circular import cycle.
> It does also allow the annotations to be defined in a self-contained way,
> which can then easily be used by other external projects such as ghc-parser.
>
> If there is consensus that this will not break anything else, I would like
> to go ahead and add the rest of the annotations.
>
> Regards
>
>   Alan
>
>
>
> On Tue, Sep 30, 2014 at 11:19 AM, Simon Peyton Jones <
> simonpj at microsoft.com> wrote:
>
>  I'm anxious about it being too big a change too.
>
> I'd be up for it if we had several "customers" all saying "yes, this is
> precisely what we need to make our usage of the GHC API far far easier".
> With enough detail so we can understand their use-case.
>
> Otherwise I worry that we might go to a lot of effort to solve the wrong
> problem; or to build a solution that does not, in the end, work for the
> actual use-case.
>
> Another way to tackle this would be to ensure that syntax tree nodes have
> a "node-key" (a bit like their source location) that clients could use in a
> finite map, to map node-key to values of their choice.
>
> I have not reviewed your patch in detail, but it's uncomfortable that the
> 'l' parameter gets into IfGblEnv and DsM.  That doesn't smell right.
>
> Ditto DynFlags/HscEnv, though I think here that you are right that the
> "hooks" interface is very crucial.  After all, the WHOLE POINT is too make
> the client interface more flexible. I would consult Luite and Edsko, who
> were instrumental in designing the new hooks interface
>         https://ghc.haskell.org/trac/ghc/wiki/Ghc/Hooks
> (I'm not sure if that page is up to date, but I hope so)
>
> A good way to proceed might be to identify some of the big users of the
> GHC API (I'm sure I don't know them all), discuss with them what would help
> them, and share the results on a wiki page.
>
> Simon
>
>
> |  -----Original Message-----
> |  From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of
> |  Richard Eisenberg
> |  Sent: 30 September 2014 03:04
> |  To: Edward Z. Yang
> |  Cc: ghc-devs at haskell.org
> |  Subject: Re: Feedback request for #9628 AST Annotations
> |
> |  I'm only speaking up because Alan is specifically requesting feedback:
> |  I'm really ambivalent about this. I agree with Edward that this is a
> |  big change and adds permanent noise in a lot of places. But, I also
> |  really respect the goal here -- better tool support. Is it worthwhile
> |  to do this using a dynamically typed bit (using Typeable and such),
> |  which would avoid the noise? Maybe.
> |
> |  What do other languages do? Do we know what, say, Agda does to get
> |  such tight coupling with an editor? Does, say, Eclipse have such a
> |  chummy relationship with a Java compiler to do its refactoring, or is
> |  that separately implemented? Haskell/GHC is not the first project to
> |  have this problem, and there's plenty of solutions out there. And,
> |  unlike most other times, I don't think Haskell is exceptional in this
> |  regard (there's nothing very special about Haskell's AST, maybe beyond
> |  indentation-awareness), so we can probably adopt other solutions
> |  nicely.
> |
> |  Richard
> |
> |  On Sep 29, 2014, at 8:58 PM, "Edward Z. Yang" <ezyang at mit.edu> wrote:
> |
> |  > Excerpts from Alan & Kim Zimmerman's message of 2014-09-29 13:38:45
> |  -0700:
> |  >> 1. Is this change too big, should I scale it back to just update
> |  the
> |  >>   HsSyn structures and then lock it down to Located SrcSpan for all
> |  >>   the rest?
> |  >
> |  > I don't claim to speak for the rest of the GHC developers, but I
> |  think
> |  > this change is too big.  I am almost tempted to say that we
> |  shouldn't
> |  > add the type parameter at all, and do something else (maybe Backpack
> |  > can let us extend SrcSpan in a modular way, or even use a
> |  dynamically
> |  > typed map for annotations.)
> |  >
> |  > Edward
> |  > _______________________________________________
> |  > ghc-devs mailing list
> |  > ghc-devs at haskell.org
> |  > http://www.haskell.org/mailman/listinfo/ghc-devs
> |
> |  _______________________________________________
> |  ghc-devs mailing list
> |  ghc-devs at haskell.org
> |  http://www.haskell.org/mailman/listinfo/ghc-devs
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141001/bac92f2f/attachment.html>