I tend to agree that this change is much too intrusive for what it attempts to do.
I think the concept of a node key could be workable, and ties in to the approach I am taking in ghc-exactprint [1], which uses a SrcSpan together with node type as the annotation key. [1] https://github.com/alanz/ghc-exactprint On Tue, Sep 30, 2014 at 11:19 AM, Simon Peyton Jones <[email protected]> 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:[email protected]] On Behalf Of > | Richard Eisenberg > | Sent: 30 September 2014 03:04 > | To: Edward Z. Yang > | Cc: [email protected] > | 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" <[email protected]> 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 > | > [email protected] > | > http://www.haskell.org/mailman/listinfo/ghc-devs > | > | _______________________________________________ > | ghc-devs mailing list > | [email protected] > | http://www.haskell.org/mailman/listinfo/ghc-devs > _______________________________________________ > ghc-devs mailing list > [email protected] > http://www.haskell.org/mailman/listinfo/ghc-devs >
_______________________________________________ ghc-devs mailing list [email protected] http://www.haskell.org/mailman/listinfo/ghc-devs
