Determine instance method from class method callsite

[Robin Palotai]

Sorry, I messed up subject and mailing list. Copying to both list now after
the mistake (wanted only ghc-devs for specificity).

Thanks!

2017-09-19 7:36 GMT+02:00 Robin Palotai :

> Hello GHC devs,
>
> Before inventing the wheel, want to check if there is a GHC API way to
> look up the (fully) resolved instance method from a class method.
>
> For example, given a code
>
> data Foo Int deriving Show
>
> bar = show (Foo 3)
>
> when inspecting the Typechecked AST for bar's show call, I would like to
> get to the Name / Id of 'show' of the 'Show' typeclass.
>
> I believe I could use splitHsSigmaTy on the HsType of the function call to
> get the context, and then evaluate the HsWrapper somehow to find out what
> instance dictionary is applied to the class restriction in the context, and
> then look up the instance method from the dictionary..
>
> Two questions:
>
> 1) Is there maybe functionality for this?
>
> 2) If not, is there any guarantee about the constraint order in the
> context, at the method call? So I could more easily determine which
> constraint's application to look for..
>
> Any hints welcome && Thank you!
> Robin
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Spurious recompilations when using a compiler plugin

[Conal Elliott]

It appears that use of GHC plugins causes client code to get needlessly
recompiled. (See Trac issues 12567
 and 7414
.) It’s becoming more of a
problem for usability of the plugin
 I’ve been developing, and
I’m wondering what can be done. Some questions:

   - Is there any work in progress on fixing this situation?
   - Are there serious obstacles to fixing it?
   - Do plugin writers or users have any workarounds?

Other insights appreciated.

– Conal
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: ANN: Overlay Hackage Package Index for GHC HEAD

[Rahul Muttineni]

Hi Herbert,

This sounds like a great idea :) Glad to see ideas from Eta inspiring new
ideas in GHC.

"constantly nagging upstream maintainers to release quickfixes
for unreleased GHC HEAD snapshots which will likely break again a few
weeks later"

^ This is what motivated us to start eta-hackage in the first place. In our
case, we didn't know whether the patches were completely correct when
porting C FFI to Java FFI, at least in the corner cases, so we needed a way
to quickly deploy updates to patches without having the end user wait a
significant amount of time. Once they stabilise, we do plan on pushing the
patches upstream to the respective packages - we've already done that for a
few of them.

Thanks,
Rahul

On Mon, Sep 18, 2017 at 8:04 AM, Herbert Valerio Riedel 
wrote:

> Hi GHC devs,
>
> A long-standing common problem when testing/dogfooding GHC HEAD is that
> at some point during the development cycle more and more packages from
> Hackage will run into build failures.
>
> Obviously, constantly nagging upstream maintainers to release quickfixes
> for unreleased GHC HEAD snapshots which will likely break again a few
> weeks later (as things are generally in flux until freeze comes into
> effect) does not scale and only introduces a latency/coordination
> bottleneck, and on top of it ultimately results in spamming the primary
> Hackage Package index with releases (which has non-negligible negative
> impact/costs of its own on the Hackage infrastructure, and thus ought to
> be minimised).
>
> OTOH, we need the ability to easily test, debug, profile, and prototype
> changes to GHC HEAD while things are still in motion, and case in point,
> if you try to e.g. build `pandoc` with GHC HEAD today, you'll currently
> run into a dozen or so of packages not building with GHC HEAD.
>
> To this end, I've finally found time to work on a side-project (related
> to matrix.hackage.haskell.org) which implements a scheme tailored to
> `cabal new-build`, which is inspired by how Eta copes with a very
> related issue (they rely on it for stable versions of the compiler);
> i.e., they maintain a set of patches at
>
>   https://github.com/typelead/eta-hackage/tree/master/patches
>
> which fix up existing Hackage packages to work with the Eta compiler.
>
>
> And this gave me the idea to use a similar scheme for GHC HEAD:
>
>   https://github.com/hvr/head.hackage/tree/master/patches
>
> This folder already contains several of patches (which mostly originate
> from Ryan, Ben and myself) to packages which I needed to patch in order
> to build popular Hackage packages & tools.
>
> The main difference is how those patches are applied; Eta uses a
> modified `cabal` which they renamed to `etlas` which is checks
> availability of .patch & .cabal files in the GitHub repo linked above;
>
> Whereas for GHC HEAD with `cabal new-build` a different scheme makes
> more sense: we simply generate an add-on Hackage repo, and use the
> existing `cabal` facilities (e.g. multi-repo support or the nix-style
> package store which makes sure that unofficially patched packages don't
> contaminate "normal" install-plans, etc.) to opt into the opt-in Hackage
> repo containing fixed up packages.
>
>
>
> I've tried to describe how to use the HEAD.hackage add-on repo in the
> README at
>
>   https://github.com/hvr/head.hackage#how-to-use
>
>
> And finally, here's a practical example of how you can use it to build
> e.g. the `pandoc` executable with GHC HEAD (can easily be adapted to
> build your project of choice; please refer to
>
>   http://cabal.readthedocs.io/en/latest/nix-local-build-overview.html
>
> to learn more about how to describe your project via  `cabal.project`
> files):
>
>
> 0.) This assumes you have a recent cabal 2.1 snapshot built from Git
>
> 1.) create & `cd` into a new work-folder
>
> 2.) invoke `head.hackage.sh update` to update the HEAD.hackage index cache
>
> 3.) invoke `head.hackage.sh init` to create an initial `cabal.project`
> configuration which locally activates the HEAD.hackage overlay repo
>
> 4.) If needed, edit the cabal.project file and change where GHC
> HEAD can be found (the script currently assumes GHC HEAD is
> installed from my Ubuntu PPA), e.g.
>
>   with-compiler: /home/hvr/src/ghc-dev/inplace/bin/ghc-stage2
>
> or you can add something like `optional-packages: deps/*/*.cabal`
> to have cabal pick up package source-trees unpacked in the deps/
> folder, or you can inject ghc-options, relax upper bounds via
> `allow-newer: *:base` etc (please refer to the cabal user guide)
>
> 5.) Create a `dummy.cabal` file (in future we will have `cabal
> new-install` or other facilities, but for now we use this
> workaround):
>
>
> --8<---cut here---start->8---
> name:dummy
> version: 0
> build-type:  Simple
> cabal-version:   >=2.0
>
> library
>   default-language:Haskell2010
>
>   -- 

Re: A type checker plugin for row types

[Nicolas Frisby]

Thank you Matthew! I very much appreciate this kind of feedback.

1) I've updated the (bulk of the) wiki page to match the github repo just
now. In particular, the "Elm" example lives here
https://github.com/nfrisby/coxswain/blob/master/sculls/Elm.hs, so I just
copied its most recent version onto the wiki. (The delta was the
"off-by-one" `Short` constraints, right?)

2) I absolutely agree about -dcore-lint. I wrongly had it in my head that I
needed a DEBUG build. See
https://github.com/nfrisby/coxswain/issues/3#issuecomment-330266479

3) Awesome! I'll add a link to the README.

Thanks again. -Nick

On Mon, Sep 18, 2017 at 4:11 AM Matthew Pickering <
matthewtpicker...@gmail.com> wrote:

> Hi Nicolas, I briefly tried out the plugin this morning and have a few
> comments.
>
> 1. The example file on the wiki page fails to compile. I needed to
> modify two of the constraints on `getName` and `getPos` to get it to
> work.
>
> 2. I was inspecting how well the compiler optimises your
> representation and came across from very strange core that I didn't
> understand.
>
> https://gist.github.com/mpickering/6ec5501400e103d64284701d7537f223
>
> Notice how there is a case on a lambda which binds an unused kind
> variable. But I can't understand how this works at all as I can't see
> where the lambda is applied.
>
> 3. Running -dcore-lint on the example file quickly complains.  I think
> making sure that core-lint passes can be quite an important sanity
> check, is a fundamental reason which makes core lint work poorly with
> type checker plugins? If there is then we should perhaps fix this.
>
> I also packaged up the project for nix if that is useful to anyone else.
>
> https://gist.github.com/2a4b2fa25351bd900052d955a00ace6a
>
> Matt
>
> On Sat, Sep 16, 2017 at 11:00 PM, Nicolas Frisby
>  wrote:
> > If you'd like to see how exactly the plugin manipulates constraints, I
> > suggest using the `summarize` and `trace` options that are discussed
> here:
> >
> >
> https://ghc.haskell.org/trac/ghc/wiki/Plugins/TypeChecker/RowTypes/Coxswain#PluginDebugOptions
> >
> > Also, the `sculls/Examples.hs` and `sculls/Elm.hs` files contain my only
> > test cases involving records and variants. Also see
> `coxswain/test/README`.
> >
> > I'm kind of spent from rushing towards this "release", so I might be a
> bit
> > less productive for a while. But I'll be generally responsive about it if
> > others are spending time on it.
> >
> > In particular: any advice for how to share the generated Haddock
> > documentation without uploading to Hackage/Stackage?
> >
> > And thanks to all for responding to my questions. I'll have to think
> harder
> > about the answers given. At least for Derived constraints, in
> particular, I
> > still don't think we have all of the relevant information in one place.
> For
> > example, I recalling thinking that I was seeing some Derived constraints
> > that seemed to arise from the unifier "giving up" on a complicated
> equality
> > and emitting a Given equality instead, and nobody mentioned that in their
> > answers here. I'll try to suss out a repro of that exactly.
> >
> > Thanks. -Nick
> >
> > On Sat, Sep 16, 2017 at 2:27 PM Nicolas Frisby  >
> > wrote:
> >>
> >> I've uploaded the code to GitHub.
> >>
> >> https://github.com/nfrisby/coxswain
> >>
> >> I went with a BSD3 licence.
> >>
> >> It's still very much a work in progress, so I only recommend using it
> for
> >> experimentation for now.
> >>
> >> Thanks. -Nick
> >>
> >>
> >> On Sun, Sep 10, 2017 at 3:24 PM Nicolas Frisby <
> nicolas.fri...@gmail.com>
> >> wrote:
> >>>
> >>> Hi all. I've been spending my free time for the last couple months on a
> >>> type checker plugin for row types. The free time waxes and wanes;
> sending an
> >>> email like this one was my primary goal for the past couple weeks.
> >>>
> >>> At the very least, I hoped this project would let me finally get some
> >>> hands on experience with OutsideIn. And I definitely have. But I've
> also
> >>> made more progress than I anticipated, and I think the plugin is
> starting to
> >>> have legs!
> >>>
> >>> I haven't uploaded the code yet to github -- it's not quite ready to
> >>> share. But I did do a write up on the dev wiki.
> >>>
> >>>
> >>>
> https://ghc.haskell.org/trac/ghc/wiki/Plugins/TypeChecker/RowTypes/Coxswain
> >>>
> >>> I would really appreciate and questions, comments, and --- boy, oh boy
> >>> --- answers.
> >>>
> >>> I hope to upload within a week or so, and I'll update that wiki page
> and
> >>> reply to this email when I do.
> >>>
> >>> Thanks very much. -Nick
> >>>
> >>> P.S. -- I've CC'd and BCC'd people who I anticipate would be
> specifically
> >>> interested in this (e.g. plugins, row types, etc). Please feel free to
> >>> forward to others that come to mind; I know some inboxes abjectly can't
> >>> afford default list traffic.
> >>>
> >>> P.P.S. -- One hold up for the upload is: which license? I intend to
> >>> 

Re: ANN: Overlay Hackage Package Index for GHC HEAD

[Robin Palotai]

Sounds amazing - could you add the procedure you described to the "stock"
multi-GHC Travis example [1]?
It already has a "HEAD" env (see "env: BUILD=cabal GHCVER=head"...), but
breaks [2] due to the package problems you mentioned.

[1]:
https://raw.githubusercontent.com/commercialhaskell/stack/master/doc/travis-complex.yml
[2]: for haskell-indexer:
https://travis-ci.org/robinp/haskell-indexer/builds/276778630

2017-09-18 14:31 GMT+02:00 Matthew Pickering :

> Something like this is definitely useful for testing.
>
> When building GHC HEAD I override the ghcHEAD derivation on nixpkgs to
> the right commit I want to use and then can similarly specify which
> patches and versions of packages to use by modifying the
> 'configuration-ghc-head.nix' file.
> This is quite a bit more flexible than just patch files as I can point
> to specific commits in git repos etc.
>
> This repo will definitely be useful for me with this workflow as well.
>
> Thanks,
>
> Matt
>
> On Mon, Sep 18, 2017 at 1:04 PM, Herbert Valerio Riedel
>  wrote:
> > Hi GHC devs,
> >
> > A long-standing common problem when testing/dogfooding GHC HEAD is that
> > at some point during the development cycle more and more packages from
> > Hackage will run into build failures.
> >
> > Obviously, constantly nagging upstream maintainers to release quickfixes
> > for unreleased GHC HEAD snapshots which will likely break again a few
> > weeks later (as things are generally in flux until freeze comes into
> > effect) does not scale and only introduces a latency/coordination
> > bottleneck, and on top of it ultimately results in spamming the primary
> > Hackage Package index with releases (which has non-negligible negative
> > impact/costs of its own on the Hackage infrastructure, and thus ought to
> > be minimised).
> >
> > OTOH, we need the ability to easily test, debug, profile, and prototype
> > changes to GHC HEAD while things are still in motion, and case in point,
> > if you try to e.g. build `pandoc` with GHC HEAD today, you'll currently
> > run into a dozen or so of packages not building with GHC HEAD.
> >
> > To this end, I've finally found time to work on a side-project (related
> > to matrix.hackage.haskell.org) which implements a scheme tailored to
> > `cabal new-build`, which is inspired by how Eta copes with a very
> > related issue (they rely on it for stable versions of the compiler);
> > i.e., they maintain a set of patches at
> >
> >   https://github.com/typelead/eta-hackage/tree/master/patches
> >
> > which fix up existing Hackage packages to work with the Eta compiler.
> >
> >
> > And this gave me the idea to use a similar scheme for GHC HEAD:
> >
> >   https://github.com/hvr/head.hackage/tree/master/patches
> >
> > This folder already contains several of patches (which mostly originate
> > from Ryan, Ben and myself) to packages which I needed to patch in order
> > to build popular Hackage packages & tools.
> >
> > The main difference is how those patches are applied; Eta uses a
> > modified `cabal` which they renamed to `etlas` which is checks
> > availability of .patch & .cabal files in the GitHub repo linked above;
> >
> > Whereas for GHC HEAD with `cabal new-build` a different scheme makes
> > more sense: we simply generate an add-on Hackage repo, and use the
> > existing `cabal` facilities (e.g. multi-repo support or the nix-style
> > package store which makes sure that unofficially patched packages don't
> > contaminate "normal" install-plans, etc.) to opt into the opt-in Hackage
> > repo containing fixed up packages.
> >
> >
> >
> > I've tried to describe how to use the HEAD.hackage add-on repo in the
> > README at
> >
> >   https://github.com/hvr/head.hackage#how-to-use
> >
> >
> > And finally, here's a practical example of how you can use it to build
> > e.g. the `pandoc` executable with GHC HEAD (can easily be adapted to
> > build your project of choice; please refer to
> >
> >   http://cabal.readthedocs.io/en/latest/nix-local-build-overview.html
> >
> > to learn more about how to describe your project via  `cabal.project`
> > files):
> >
> >
> > 0.) This assumes you have a recent cabal 2.1 snapshot built from Git
> >
> > 1.) create & `cd` into a new work-folder
> >
> > 2.) invoke `head.hackage.sh update` to update the HEAD.hackage index
> cache
> >
> > 3.) invoke `head.hackage.sh init` to create an initial `cabal.project`
> > configuration which locally activates the HEAD.hackage overlay repo
> >
> > 4.) If needed, edit the cabal.project file and change where GHC
> > HEAD can be found (the script currently assumes GHC HEAD is
> > installed from my Ubuntu PPA), e.g.
> >
> >   with-compiler: /home/hvr/src/ghc-dev/inplace/bin/ghc-stage2
> >
> > or you can add something like `optional-packages: deps/*/*.cabal`
> > to have cabal pick up package source-trees unpacked in the deps/
> > folder, or you can inject ghc-options, relax upper bounds via
> > 

Re: ANN: Overlay Hackage Package Index for GHC HEAD

[Matthew Pickering]

Something like this is definitely useful for testing.

When building GHC HEAD I override the ghcHEAD derivation on nixpkgs to
the right commit I want to use and then can similarly specify which
patches and versions of packages to use by modifying the
'configuration-ghc-head.nix' file.
This is quite a bit more flexible than just patch files as I can point
to specific commits in git repos etc.

This repo will definitely be useful for me with this workflow as well.

Thanks,

Matt

On Mon, Sep 18, 2017 at 1:04 PM, Herbert Valerio Riedel
 wrote:
> Hi GHC devs,
>
> A long-standing common problem when testing/dogfooding GHC HEAD is that
> at some point during the development cycle more and more packages from
> Hackage will run into build failures.
>
> Obviously, constantly nagging upstream maintainers to release quickfixes
> for unreleased GHC HEAD snapshots which will likely break again a few
> weeks later (as things are generally in flux until freeze comes into
> effect) does not scale and only introduces a latency/coordination
> bottleneck, and on top of it ultimately results in spamming the primary
> Hackage Package index with releases (which has non-negligible negative
> impact/costs of its own on the Hackage infrastructure, and thus ought to
> be minimised).
>
> OTOH, we need the ability to easily test, debug, profile, and prototype
> changes to GHC HEAD while things are still in motion, and case in point,
> if you try to e.g. build `pandoc` with GHC HEAD today, you'll currently
> run into a dozen or so of packages not building with GHC HEAD.
>
> To this end, I've finally found time to work on a side-project (related
> to matrix.hackage.haskell.org) which implements a scheme tailored to
> `cabal new-build`, which is inspired by how Eta copes with a very
> related issue (they rely on it for stable versions of the compiler);
> i.e., they maintain a set of patches at
>
>   https://github.com/typelead/eta-hackage/tree/master/patches
>
> which fix up existing Hackage packages to work with the Eta compiler.
>
>
> And this gave me the idea to use a similar scheme for GHC HEAD:
>
>   https://github.com/hvr/head.hackage/tree/master/patches
>
> This folder already contains several of patches (which mostly originate
> from Ryan, Ben and myself) to packages which I needed to patch in order
> to build popular Hackage packages & tools.
>
> The main difference is how those patches are applied; Eta uses a
> modified `cabal` which they renamed to `etlas` which is checks
> availability of .patch & .cabal files in the GitHub repo linked above;
>
> Whereas for GHC HEAD with `cabal new-build` a different scheme makes
> more sense: we simply generate an add-on Hackage repo, and use the
> existing `cabal` facilities (e.g. multi-repo support or the nix-style
> package store which makes sure that unofficially patched packages don't
> contaminate "normal" install-plans, etc.) to opt into the opt-in Hackage
> repo containing fixed up packages.
>
>
>
> I've tried to describe how to use the HEAD.hackage add-on repo in the
> README at
>
>   https://github.com/hvr/head.hackage#how-to-use
>
>
> And finally, here's a practical example of how you can use it to build
> e.g. the `pandoc` executable with GHC HEAD (can easily be adapted to
> build your project of choice; please refer to
>
>   http://cabal.readthedocs.io/en/latest/nix-local-build-overview.html
>
> to learn more about how to describe your project via  `cabal.project`
> files):
>
>
> 0.) This assumes you have a recent cabal 2.1 snapshot built from Git
>
> 1.) create & `cd` into a new work-folder
>
> 2.) invoke `head.hackage.sh update` to update the HEAD.hackage index cache
>
> 3.) invoke `head.hackage.sh init` to create an initial `cabal.project`
> configuration which locally activates the HEAD.hackage overlay repo
>
> 4.) If needed, edit the cabal.project file and change where GHC
> HEAD can be found (the script currently assumes GHC HEAD is
> installed from my Ubuntu PPA), e.g.
>
>   with-compiler: /home/hvr/src/ghc-dev/inplace/bin/ghc-stage2
>
> or you can add something like `optional-packages: deps/*/*.cabal`
> to have cabal pick up package source-trees unpacked in the deps/
> folder, or you can inject ghc-options, relax upper bounds via
> `allow-newer: *:base` etc (please refer to the cabal user guide)
>
> 5.) Create a `dummy.cabal` file (in future we will have `cabal
> new-install` or other facilities, but for now we use this
> workaround):
>
>
> --8<---cut here---start->8---
> name:dummy
> version: 0
> build-type:  Simple
> cabal-version:   >=2.0
>
> library
>   default-language:Haskell2010
>
>   -- library components you want cabal to solve & build for
>   -- and become accessible via .ghc.environment files and/or
>   -- `cabal new-repl`
>   build-depends: base, lens
>
>   -- executable components you want cabal to build
>   

ANN: Overlay Hackage Package Index for GHC HEAD

[Herbert Valerio Riedel]

Hi GHC devs,

A long-standing common problem when testing/dogfooding GHC HEAD is that
at some point during the development cycle more and more packages from
Hackage will run into build failures.

Obviously, constantly nagging upstream maintainers to release quickfixes
for unreleased GHC HEAD snapshots which will likely break again a few
weeks later (as things are generally in flux until freeze comes into
effect) does not scale and only introduces a latency/coordination
bottleneck, and on top of it ultimately results in spamming the primary
Hackage Package index with releases (which has non-negligible negative
impact/costs of its own on the Hackage infrastructure, and thus ought to
be minimised).

OTOH, we need the ability to easily test, debug, profile, and prototype
changes to GHC HEAD while things are still in motion, and case in point,
if you try to e.g. build `pandoc` with GHC HEAD today, you'll currently
run into a dozen or so of packages not building with GHC HEAD.

To this end, I've finally found time to work on a side-project (related
to matrix.hackage.haskell.org) which implements a scheme tailored to
`cabal new-build`, which is inspired by how Eta copes with a very
related issue (they rely on it for stable versions of the compiler);
i.e., they maintain a set of patches at

  https://github.com/typelead/eta-hackage/tree/master/patches

which fix up existing Hackage packages to work with the Eta compiler.


And this gave me the idea to use a similar scheme for GHC HEAD:

  https://github.com/hvr/head.hackage/tree/master/patches

This folder already contains several of patches (which mostly originate
from Ryan, Ben and myself) to packages which I needed to patch in order
to build popular Hackage packages & tools.

The main difference is how those patches are applied; Eta uses a
modified `cabal` which they renamed to `etlas` which is checks
availability of .patch & .cabal files in the GitHub repo linked above;

Whereas for GHC HEAD with `cabal new-build` a different scheme makes
more sense: we simply generate an add-on Hackage repo, and use the
existing `cabal` facilities (e.g. multi-repo support or the nix-style
package store which makes sure that unofficially patched packages don't
contaminate "normal" install-plans, etc.) to opt into the opt-in Hackage
repo containing fixed up packages.



I've tried to describe how to use the HEAD.hackage add-on repo in the
README at

  https://github.com/hvr/head.hackage#how-to-use


And finally, here's a practical example of how you can use it to build
e.g. the `pandoc` executable with GHC HEAD (can easily be adapted to
build your project of choice; please refer to

  http://cabal.readthedocs.io/en/latest/nix-local-build-overview.html
  
to learn more about how to describe your project via  `cabal.project`
files):


0.) This assumes you have a recent cabal 2.1 snapshot built from Git 

1.) create & `cd` into a new work-folder

2.) invoke `head.hackage.sh update` to update the HEAD.hackage index cache

3.) invoke `head.hackage.sh init` to create an initial `cabal.project`
configuration which locally activates the HEAD.hackage overlay repo

4.) If needed, edit the cabal.project file and change where GHC
HEAD can be found (the script currently assumes GHC HEAD is
installed from my Ubuntu PPA), e.g.

  with-compiler: /home/hvr/src/ghc-dev/inplace/bin/ghc-stage2

or you can add something like `optional-packages: deps/*/*.cabal`
to have cabal pick up package source-trees unpacked in the deps/
folder, or you can inject ghc-options, relax upper bounds via
`allow-newer: *:base` etc (please refer to the cabal user guide)

5.) Create a `dummy.cabal` file (in future we will have `cabal
new-install` or other facilities, but for now we use this
workaround):


--8<---cut here---start->8---
name:dummy
version: 0
build-type:  Simple
cabal-version:   >=2.0
 
library
  default-language:Haskell2010

  -- library components you want cabal to solve & build for
  -- and become accessible via .ghc.environment files and/or
  -- `cabal new-repl`
  build-depends: base, lens
  
  -- executable components you want cabal to build
  build-tool-depends: pandoc:pandoc
  
--8<---cut here---end--->8---

 6.) invoke `cabal new-build`

 7.) If everything works, you'll find the `pandoc:pandoc` executable
 somewhere in your ~/.cabal/store/ghc-8.3.*/ folder
 (you can use http://hackage.haskell.org/package/cabal-plan
  to conveniently list the location via `cabal-plan list-bins`)

 8.) As for libraries, you can either use `cabal new-repl`
 or you can leverage GHC's package environment files:

 `cabal new-build` will have generated a file like

   .ghc.environment.x86_64-linux-8.3.20170913

 which brings into scope all transitive dependencies of
 `build-depends: base, lens`

 Now all you need to do is 

Re: A type checker plugin for row types

[Matthew Pickering]

Hi Nicolas, I briefly tried out the plugin this morning and have a few comments.

1. The example file on the wiki page fails to compile. I needed to
modify two of the constraints on `getName` and `getPos` to get it to
work.

2. I was inspecting how well the compiler optimises your
representation and came across from very strange core that I didn't
understand.

https://gist.github.com/mpickering/6ec5501400e103d64284701d7537f223

Notice how there is a case on a lambda which binds an unused kind
variable. But I can't understand how this works at all as I can't see
where the lambda is applied.

3. Running -dcore-lint on the example file quickly complains.  I think
making sure that core-lint passes can be quite an important sanity
check, is a fundamental reason which makes core lint work poorly with
type checker plugins? If there is then we should perhaps fix this.

I also packaged up the project for nix if that is useful to anyone else.

https://gist.github.com/2a4b2fa25351bd900052d955a00ace6a

Matt

On Sat, Sep 16, 2017 at 11:00 PM, Nicolas Frisby
 wrote:
> If you'd like to see how exactly the plugin manipulates constraints, I
> suggest using the `summarize` and `trace` options that are discussed here:
>
> https://ghc.haskell.org/trac/ghc/wiki/Plugins/TypeChecker/RowTypes/Coxswain#PluginDebugOptions
>
> Also, the `sculls/Examples.hs` and `sculls/Elm.hs` files contain my only
> test cases involving records and variants. Also see `coxswain/test/README`.
>
> I'm kind of spent from rushing towards this "release", so I might be a bit
> less productive for a while. But I'll be generally responsive about it if
> others are spending time on it.
>
> In particular: any advice for how to share the generated Haddock
> documentation without uploading to Hackage/Stackage?
>
> And thanks to all for responding to my questions. I'll have to think harder
> about the answers given. At least for Derived constraints, in particular, I
> still don't think we have all of the relevant information in one place. For
> example, I recalling thinking that I was seeing some Derived constraints
> that seemed to arise from the unifier "giving up" on a complicated equality
> and emitting a Given equality instead, and nobody mentioned that in their
> answers here. I'll try to suss out a repro of that exactly.
>
> Thanks. -Nick
>
> On Sat, Sep 16, 2017 at 2:27 PM Nicolas Frisby 
> wrote:
>>
>> I've uploaded the code to GitHub.
>>
>> https://github.com/nfrisby/coxswain
>>
>> I went with a BSD3 licence.
>>
>> It's still very much a work in progress, so I only recommend using it for
>> experimentation for now.
>>
>> Thanks. -Nick
>>
>>
>> On Sun, Sep 10, 2017 at 3:24 PM Nicolas Frisby 
>> wrote:
>>>
>>> Hi all. I've been spending my free time for the last couple months on a
>>> type checker plugin for row types. The free time waxes and wanes; sending an
>>> email like this one was my primary goal for the past couple weeks.
>>>
>>> At the very least, I hoped this project would let me finally get some
>>> hands on experience with OutsideIn. And I definitely have. But I've also
>>> made more progress than I anticipated, and I think the plugin is starting to
>>> have legs!
>>>
>>> I haven't uploaded the code yet to github -- it's not quite ready to
>>> share. But I did do a write up on the dev wiki.
>>>
>>>
>>> https://ghc.haskell.org/trac/ghc/wiki/Plugins/TypeChecker/RowTypes/Coxswain
>>>
>>> I would really appreciate and questions, comments, and --- boy, oh boy
>>> --- answers.
>>>
>>> I hope to upload within a week or so, and I'll update that wiki page and
>>> reply to this email when I do.
>>>
>>> Thanks very much. -Nick
>>>
>>> P.S. -- I've CC'd and BCC'd people who I anticipate would be specifically
>>> interested in this (e.g. plugins, row types, etc). Please feel free to
>>> forward to others that come to mind; I know some inboxes abjectly can't
>>> afford default list traffic.
>>>
>>> P.P.S. -- One hold up for the upload is: which license? I intend to
>>> release under BSD3, mainly to match GHC since one ideal scenario would
>>> involve being packaged with/integrated into GHC. But my brief recent
>>> research suggests that the Apache license might be more conducive to
>>> eventual widespread adoption. If you'd be willing to advise or even just
>>> refer me to other write ups, please feel free to email me directly or to
>>> start a separate thread on a more appropriate distribution list (CC'ing me,
>>> please). Thanks again.
>
>
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs