Feedback request for #9628 AST Annotations
Alan & Kim Zimmerman
alan.zimm at gmail.com
Wed Oct 1 18:34:54 UTC 2014
Ok, I have started a discussion on haskell-cafe, will cross reference to
On Wed, Oct 1, 2014 at 7:44 PM, Simon Peyton Jones <simonpj at microsoft.com>
> 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.
> *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
> 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.
> 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
> (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.
> | -----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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the ghc-devs