Parser depends on DynFlags, depends on Hooks, depends on TcM, DsM, ...

Mon Sep 14 12:02:47 UTC 2020

I believe this to already be broken in HEAD. DynFlags already got quite an
overhaul/break. I'd rather we drop supporting DynFlagPlugins. And
offer alternative stable interfaces. Though to be honest, I believe our
Plugin story is rather poor so far.

Do you happen to know of DynFlagPlugins, Adam?

Cheers,
 Moritz

On Mon, Sep 14, 2020 at 7:09 PM Adam Gundry <adam at well-typed.com> wrote:

> I'm supportive of the goal, but a complication with removing hooks from
> DynFlags is that GHC currently supports "DynFlags plugins" that allow
> plugins to install custom hooks
> (
> https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/extending_ghc.html#dynflags-plugins
> ).
> I guess this can be worked around, perhaps by passing hooks separately
> to DynFlags and providing a separate plugin interface to modify hooks.
> But doing so will necessarily break existing plugins.
>
> Adam
>
>
> On 14/09/2020 11:25, Simon Peyton Jones via ghc-devs wrote:
> > I thought I’d sent a message about this DynFlags thing, but I can’t
> > trace it now.   So here’s a resend.
> >
> >
> >
> > Currently
> >
> >   * The DynFlags record includes Hooks
> >   * Hooks in contains functions, that mention TcM, DsM etc
> >
> >
> >
> > This is bad.  We should think of DynFlags as an *abstract syntax tree*.
> > That is, the result of parsing the flag strings, yes, but not much
> > more.  So for hooks we should have an algebraic data type representing
> > the hook /specification/, but it should not be the hook functions
> > themselves.  HsSyn, for example, after parsing, is just a tree with
> > strings in it.  No TyCons, Ids, etc. That comes much later.
> >
> >
> >
> > So DynFlags should be a collection of algebraic data types, but should
> > not depend on anything else.
> >
> >
> >
> > I think that may cut a bunch of awkward loops.
> >
> >
> >
> > Simon
> >
> >
> >
> > *From:*Simon Peyton Jones
> > *Sent:* 10 September 2020 14:17
> > *To:* Sebastian Graf <sgraf1337 at gmail.com>; Sylvain Henry
> > <sylvain at haskus.fr>
> > *Cc:* ghc-devs <ghc-devs at haskell.org>
> > *Subject:* RE: Parser depends on DynFlags, depends on Hooks, depends on
> > TcM, DsM, ...
> >
> >
> >
> > And for sure the **parser** should not depend on the **desugarer** and
> > **typechecker**.   (Which it does, as described below.)
> >
> >
> >
> https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/extending_ghc.html#dynflags-plugins
> > S
> >
> >
> >
> > *From:*ghc-devs <ghc-devs-bounces at haskell.org
> > <mailto:ghc-devs-bounces at haskell.org>> *On Behalf Of *Sebastian Graf
> > *Sent:* 10 September 2020 14:12
> > *To:* Sylvain Henry <sylvain at haskus.fr <mailto:sylvain at haskus.fr>>
> > *Cc:* ghc-devs <ghc-devs at haskell.org <mailto:ghc-devs at haskell.org>>
> > *Subject:* Parser depends on DynFlags, depends on Hooks, depends on TcM,
> > DsM, ...
> >
> >
> >
> > Hey Sylvain,
> >
> >
> >
> > In https://gitlab.haskell.org/ghc/ghc/-/merge_requests/3971
> > <
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.haskell.org%2Fghc%2Fghc%2F-%2Fmerge_requests%2F3971&data=02%7C01%7Csimonpj%40microsoft.com%7C0c3760e72fad4200d39408d8558b3871%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637353404753453548&sdata=fVpIzJgaqFfWaJ5ppCE5daHwdETTQF03o1h0uNtDxGA%3D&reserved=0
> >
> > I had to fight once more with the transitive dependency set of the
> > parser, the minimality of which is crucial for ghc-lib-parser
> > <
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fhackage.haskell.org%2Fpackage%2Fghc-lib-parser&data=02%7C01%7Csimonpj%40microsoft.com%7C0c3760e72fad4200d39408d8558b3871%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637353404753463506&sdata=HZMaqK6t7PLifc26wf%2BqcUef4Ko%2BQcaPRx4o7XLcVq8%3D&reserved=0
> >
> > and tested by the CountParserDeps test.
> >
> >
> >
> > I discovered that I need to make (parts of) `DsM` abstract, because it
> > is transitively imported from the Parser for example through Parser.y ->
> > Lexer.x -> DynFlags -> Hooks -> {DsM,TcM}.
> >
> > Since you are our mastermind behind the "Tame DynFlags" initiative, I'd
> > like to hear your opinion on where progress can be/is made on that front.
> >
> >
> >
> > I see there is https://gitlab.haskell.org/ghc/ghc/-/issues/10961
> > <
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.haskell.org%2Fghc%2Fghc%2F-%2Fissues%2F10961&data=02%7C01%7Csimonpj%40microsoft.com%7C0c3760e72fad4200d39408d8558b3871%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637353404753463506&sdata=sn9zv1MO8p%2FSbwsm1NDaSiUaumE%2FvTo4NkGreYOjITA%3D&reserved=0
> >
> > and https://gitlab.haskell.org/ghc/ghc/-/issues/11301
> > <
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.haskell.org%2Fghc%2Fghc%2F-%2Fissues%2F11301&data=02%7C01%7Csimonpj%40microsoft.com%7C0c3760e72fad4200d39408d8558b3871%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637353404753463506&sdata=vFTEuEzIQLJTtpu7%2BuwFnOEWMPv8eY%2B%2FvgbrrV18uss%3D&reserved=0
> >
> > which ask a related, but different question: They want a DynFlags-free
> > interface, but I even want a DynFlags-free *module*.
> >
> >
> >
> > Would you say it's reasonable to abstract the definition of `PState`
> > over the `DynFlags` type? I think it's only used for pretty-printing
> > messages, which is one of your specialties (the treatment of DynFlags in
> > there, at least).
> >
> > Anyway, can you think of or perhaps point me to an existing road map on
> > that issue?
> >
> >
> >
> > Thank you!
> >
> > Sebastian
>
>
>
> --
> Adam Gundry, Haskell Consultant
> Well-Typed LLP, https://www.well-typed.com/
>
> Registered in England & Wales, OC335890
> 118 Wymering Mansions, Wymering Road, London W9 2NF, England
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20200914/34e375ce/attachment.html>