From mail at joachim-breitner.de  Sat Nov  4 15:33:01 2017
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Sat, 04 Nov 2017 11:33:01 -0400
Subject: Annotations with names
Message-ID: <1509809581.1873.10.camel@joachim-breitner.de>

Hi,

I’d like to use Annotations to transport some meta-information from the
Haskell source to GHC Plugins (as they are meant to be, right?).

But I am struggling expressing annotations that relate different
symbols. Here are some hypthetical examples what I want to express:


    foo :: String -> String
    foo = …

    bar :: [(String,String), (String, String)]
    {-# ANN bar (TestCasesFor 'foo) #-}

    rec :: Natural -> (a -> a) -> a -> a
    {-# ANN rec (RecurserFor 'Natural) $-}


This code actually works (with TemplateHaskell). It will put a TH.Name
into the annotations, but when I am in Core, I need a core Name.

Is there a good way of transporting such references in Annotations so
that the desugarer (or the renamer) will do the necessary name changes
for me?


And slightly related: Do Annotations keep bindings alive? (It seems so,
but then it should be documented in
https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/extending_ghc.html#source-annotations


Thanks,
Joachim


-- 
Joachim “nomeata” Breitner
  mail at joachim-breitner.de
  https://www.joachim-breitner.de/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <http://mail.haskell.org/pipermail/glasgow-haskell-users/attachments/20171104/96532078/attachment.sig>

From svenpanne at gmail.com  Sun Nov  5 12:56:53 2017
From: svenpanne at gmail.com (Sven Panne)
Date: Sun, 5 Nov 2017 13:56:53 +0100
Subject: [ANNOUNCE] GHC 8.2.2 release candidate 2
In-Reply-To: <877evbuqtf.fsf@ben-laptop.smart-cactus.org>
References: <877evbuqtf.fsf@ben-laptop.smart-cactus.org>
Message-ID: <CANBN=mvMqwOiH4vmy_B+rfdZqz4P3aZ-F76ZOiJVDc5VUzU1Ew@mail.gmail.com>

This is not an issue about 8.2.2 per se, but 8.2 changes in general: Recent
discussions on Haskell Cafe showed serious problems with Emacs'
haskell-mode due to some ad hoc changes like
https://phabricator.haskell.org/D3651. Related GitHub issues:

   https://github.com/haskell/haskell-mode/issues/1553
   https://github.com/haskell/haskell-mode/issues/1496

It should be noted that the output of GHC(i) is actually part of GHC's
interface, so in this light, there have been some breaking changes,
probably unintended, but nevertheless. So my question is: Is there a chance
to revert some of these ad hoc changes and/or add some flags to get the old
behavior back? I guess that Emacs + haskell-mode is one of the most
important IDEs, so it would be a pity to worsen the situation there.

I'm quite aware that it is very late in the release cycle, but it would be
extremely nice if there was something which can be done. In the future it
might make sense to co-operate with the haskell-mode team a bit more,
perhaps adding some tests regarding the required output format etc. to
GHC's test suite.

Cheers,
   S.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/glasgow-haskell-users/attachments/20171105/f58b6b88/attachment.html>

From svenpanne at gmail.com  Sun Nov  5 20:52:11 2017
From: svenpanne at gmail.com (Sven Panne)
Date: Sun, 5 Nov 2017 21:52:11 +0100
Subject: [Haskell-cafe] [ANNOUNCE] GHC 8.2.2 release candidate 2
In-Reply-To: <83961DD2-1115-44A0-9E34-B553526B2CE2@gmx.com>
References: <877evbuqtf.fsf@ben-laptop.smart-cactus.org>
 <CANBN=mvMqwOiH4vmy_B+rfdZqz4P3aZ-F76ZOiJVDc5VUzU1Ew@mail.gmail.com>
 <83961DD2-1115-44A0-9E34-B553526B2CE2@gmx.com>
Message-ID: <CANBN=mtTichqVMOzK9d9TweP6+gv7=uOXRTu6NVaT2oFv1595w@mail.gmail.com>

2017-11-05 15:37 GMT+01:00 <jpaugh at gmx.com>:

> A better approach might be to develop a "machine-readable" output format
> which then is kept stable, and can be enabled with a flag. Git has a
> similar solution.
>

Without doubt, this is definitely the better approach, but this is hardly
what can be achieved for 8.2.2. Adding some flag to get the old behavior
back when wanted *is* achievable.


> It would be a shame to avoid changes which make the user experience better
> simply because other projects cannot sync their development cycle,
>

Don't get me wrong: I'm all for improving user experience, but making ad
hoc changes without enough thought or even a chance to get the old behavior
back is probably not the right way to proceed. All SW lives in some kind of
ecosystem, so it should behave well in that. And for Emacs users, the user
experience has been made much worse.


> especially if those projects are not universally used or required.
>

This is highly a matter of personal taste: No project is "universally
used", so this is tautological statement. The question is: Is a minor
cosmetic change really worth breaking things in one of the major IDEs?

Cheers,
   S.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/glasgow-haskell-users/attachments/20171105/64d7625f/attachment.html>

From qdunkan at gmail.com  Sun Nov  5 21:12:39 2017
From: qdunkan at gmail.com (Evan Laforge)
Date: Sun, 5 Nov 2017 13:12:39 -0800
Subject: [ANNOUNCE] GHC 8.2.2 release candidate 2
In-Reply-To: <CANBN=mvMqwOiH4vmy_B+rfdZqz4P3aZ-F76ZOiJVDc5VUzU1Ew@mail.gmail.com>
References: <877evbuqtf.fsf@ben-laptop.smart-cactus.org>
 <CANBN=mvMqwOiH4vmy_B+rfdZqz4P3aZ-F76ZOiJVDc5VUzU1Ew@mail.gmail.com>
Message-ID: <CACbaDy5bq5iRLsFPbq7D3W5zRSBbqw-+SROug+dL5fWbBuOjcA@mail.gmail.com>

On Sun, Nov 5, 2017 at 4:56 AM, Sven Panne <svenpanne at gmail.com> wrote:
> This is not an issue about 8.2.2 per se, but 8.2 changes in general: Recent
> discussions on Haskell Cafe showed serious problems with Emacs' haskell-mode
> due to some ad hoc changes like https://phabricator.haskell.org/D3651.

I've long used ghci -v0 to achieve the same effect.  When you have a
couple hundred modules the "loaded X Y Z" is worse than useless.  But
it's better to just add -v0, and maybe add more flags for finer
control, than change the default and break tools.

From ben at well-typed.com  Mon Nov  6 16:54:37 2017
From: ben at well-typed.com (Ben Gamari)
Date: Mon, 06 Nov 2017 11:54:37 -0500
Subject: [Haskell-cafe] [ANNOUNCE] GHC 8.2.2 release candidate 2
In-Reply-To: <CANBN=mtTichqVMOzK9d9TweP6+gv7=uOXRTu6NVaT2oFv1595w@mail.gmail.com>
References: <877evbuqtf.fsf@ben-laptop.smart-cactus.org>
 <CANBN=mvMqwOiH4vmy_B+rfdZqz4P3aZ-F76ZOiJVDc5VUzU1Ew@mail.gmail.com>
 <83961DD2-1115-44A0-9E34-B553526B2CE2@gmx.com>
 <CANBN=mtTichqVMOzK9d9TweP6+gv7=uOXRTu6NVaT2oFv1595w@mail.gmail.com>
Message-ID: <87y3njl54i.fsf@ben-laptop.smart-cactus.org>


Next time something like this arises please do open a ticket.


Sven Panne <svenpanne at gmail.com> writes:

> 2017-11-05 15:37 GMT+01:00 <jpaugh at gmx.com>:
>
>> A better approach might be to develop a "machine-readable" output format
>> which then is kept stable, and can be enabled with a flag. Git has a
>> similar solution.
>>
>
> Without doubt, this is definitely the better approach, but this is hardly
> what can be achieved for 8.2.2. Adding some flag to get the old behavior
> back when wanted *is* achievable.
>
Yes, I have opened a differential adding such a flag. See D4164 [1].
Please bikeshed to taste.

In general I would really prefer that we *not* consider GHCi's REPL to be
a stable programmatic interface. If haskell-mode needs access to some
bit of information from GHC, then please let's discuss how to provide it
in a more robust manner. This shouldn't be hard; we just need to have
feedback on what the interfaces required should look like.

[1] https://phabricator.haskell.org/D4164

>
>> It would be a shame to avoid changes which make the user experience better
>> simply because other projects cannot sync their development cycle,
>>
>
> Don't get me wrong: I'm all for improving user experience, but making ad
> hoc changes without enough thought or even a chance to get the old behavior
> back is probably not the right way to proceed. All SW lives in some kind of
> ecosystem, so it should behave well in that. And for Emacs users, the user
> experience has been made much worse.
>
The trouble is that GHC has an extremely large surface area, any bit of
which might have mechanical consumers. Those who reviewed the patch
indeed considered making this change behind a flag (as Francesco's
original patch did) but we concluded that this would be pointless as it
didn't seem likely that anyone relied on this behavior. It seems that in
this case we were wrong

That being said, we cannot always preemptively add complexity to the
project out of fear that a given change might break a hypothetical
mechanical consumer. GHCi is first-and-foremost a REPL for users. 
When evaluating a change, if we feel it is likely that we will break a
mechanical user then we will likely guard the change with a flag.
However, if not, we won't.

Cheers,

- Ben
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/glasgow-haskell-users/attachments/20171106/0ebf0550/attachment.sig>

From svenpanne at gmail.com  Mon Nov  6 17:46:24 2017
From: svenpanne at gmail.com (Sven Panne)
Date: Mon, 6 Nov 2017 18:46:24 +0100
Subject: [Haskell-cafe] [ANNOUNCE] GHC 8.2.2 release candidate 2
In-Reply-To: <87y3njl54i.fsf@ben-laptop.smart-cactus.org>
References: <877evbuqtf.fsf@ben-laptop.smart-cactus.org>
 <CANBN=mvMqwOiH4vmy_B+rfdZqz4P3aZ-F76ZOiJVDc5VUzU1Ew@mail.gmail.com>
 <83961DD2-1115-44A0-9E34-B553526B2CE2@gmx.com>
 <CANBN=mtTichqVMOzK9d9TweP6+gv7=uOXRTu6NVaT2oFv1595w@mail.gmail.com>
 <87y3njl54i.fsf@ben-laptop.smart-cactus.org>
Message-ID: <CANBN=mu_uZb-Js8Gezd7SzjNHmhn7qpoXEU7a+=WL+LQy9uiWg@mail.gmail.com>

2017-11-06 17:54 GMT+01:00 Ben Gamari <ben at well-typed.com>:

> Next time something like this arises please do open a ticket.
>

Yep, will do...


> Yes, I have opened a differential adding such a flag. See D4164 [1].
> Please bikeshed to taste.
>

Thanks for the quick fix!


> In general I would really prefer that we *not* consider GHCi's REPL to be
> a stable programmatic interface.


I fully understand that, and that's definitely the way to go. Nevertheless,
parsing tool/compiler output is still one of the most used hacks^H^H^H
techniques for lots of Emacs modes (and probably other IDEs). Not every
project is as open to suggestions and changes as GHC is, so this is often
the only way out.


> That being said, we cannot always preemptively add complexity to the
> project out of fear that a given change might break a hypothetical
> mechanical consumer.


That's of course not what was proposed. :-)


> GHCi is first-and-foremost a REPL for users.
> When evaluating a change, if we feel it is likely that we will break a
> mechanical user then we will likely guard the change with a flag.
> However, if not, we won't.
>

I think the main problem here was communication. I can't speak for the
haskell-mode maintainers, but for my part I didn't notice the problems
because I mainly use LTS Stackage and that is still(!) at 8.0.2 (Why? This
is definitely part of the whole problem.). I tried the 8.2 series only
sparingly and only via the command line, so this is perhaps what others
did, too, so the interaction bug went unnoticed for such a long time.

Cheers,
   Sven
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/glasgow-haskell-users/attachments/20171106/35f3194d/attachment.html>

From anthony_clayden at clear.net.nz  Wed Nov  8 09:29:57 2017
From: anthony_clayden at clear.net.nz (Anthony Clayden)
Date: Wed, 08 Nov 2017 22:29:57 +1300
Subject: Proposal: Instance apartness guards
Message-ID: <5a02ce95.397.384.19041@clear.net.nz>

Surprisinlgy little comment on this proposal.
Perhaps it landed when yous were busy elsewhere.
I'd like to push it to the committee soon;
this is an invitation for more feedback.

Richard E wrote a nice brief summary
https://github.com/ghc-proposals/ghc-proposals/pull/56#issuecomment-311421457

Thank you
AntC


----- Original Message Follows -----
> After years of pondering this idea (in various forms), 
> and several rounds of discussion on several forums, 
> I've written it up.
> 
> "This proposal tackles the thorny topic of Overlapping
> instances,
>  for both type classes and Type Families/Associated types,
>  by annotating instance heads with type-level apartness
> Guards.
>  Type-level disequality predicates appear in Sulzmann &
> Stuckey 2002;
>  in the type-level ‘case selection’ in HList 2004;
>  and in various guises in Haskell cafe discussions in
> following years.
>  This proposal builds on the apartness testing implemented
>  as part of the Closed Type Families work."
> 
> All feedback welcome.
> 
>
https://github.com/AntC2/ghc-proposals/blob/instance-apartness-guards/proposals/0000-instance-apartness-guards.rst
> 
> AntC

From Geraint.Jones at wolfson.ox.ac.uk  Thu Nov  9 16:04:44 2017
From: Geraint.Jones at wolfson.ox.ac.uk (Geraint Jones)
Date: Thu, 9 Nov 2017 16:04:44 GMT
Subject: Why is scanr strict in its third argument?
Message-ID: <201711091604.vA9G4ijZ025097@clpc24.cs.ox.ac.uk>

There are two things you might think of when you think of scanr;
or rather, there are two things I think of: a specification

	scanr f e = map (foldr f e) . tails

and an implementation

	scanr f e = foldr g [e] where g x yss@(ys:_) = f x ys : yss

Of course these two differ, because the one I called an implemntation
is strict wheras the specification isn't.

I wouldn't mind, but scanl goes to the trouble of not being strict,
as does Data.List.tails, which means inter alia that scanr (:) [] is
not an implementation of Data.List.tails as you might have expected.
(Well, as I did.)


In the context of

> arb = error "not used in demo"
> bot = error "bottom"

you get

*Main> (null . map (foldr arb arb) . Data.List.tails) bot
False
*Main> (null . scanr arb arb) bot
*** Exception: bottom
*Main> (null . scanl arb arb) bot
False

From david.feuer at gmail.com  Thu Nov  9 16:06:59 2017
From: david.feuer at gmail.com (David Feuer)
Date: Thu, 9 Nov 2017 11:06:59 -0500
Subject: Why is scanr strict in its third argument?
In-Reply-To: <201711091604.vA9G4ijZ025097@clpc24.cs.ox.ac.uk>
References: <201711091604.vA9G4ijZ025097@clpc24.cs.ox.ac.uk>
Message-ID: <CAMgWh9to2-s7yQmtbR4mNnujYJ11W0E114=_17fbciEYXK=16w@mail.gmail.com>

I think this discussion would be more appropriate to the libraries list.

On Nov 9, 2017 11:05 AM, "Geraint Jones" <Geraint.Jones at wolfson.ox.ac.uk>
wrote:

> There are two things you might think of when you think of scanr;
> or rather, there are two things I think of: a specification
>
>         scanr f e = map (foldr f e) . tails
>
> and an implementation
>
>         scanr f e = foldr g [e] where g x yss@(ys:_) = f x ys : yss
>
> Of course these two differ, because the one I called an implemntation
> is strict wheras the specification isn't.
>
> I wouldn't mind, but scanl goes to the trouble of not being strict,
> as does Data.List.tails, which means inter alia that scanr (:) [] is
> not an implementation of Data.List.tails as you might have expected.
> (Well, as I did.)
>
>
> In the context of
>
> > arb = error "not used in demo"
> > bot = error "bottom"
>
> you get
>
> *Main> (null . map (foldr arb arb) . Data.List.tails) bot
> False
> *Main> (null . scanr arb arb) bot
> *** Exception: bottom
> *Main> (null . scanl arb arb) bot
> False
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/glasgow-haskell-users/attachments/20171109/9e2111ba/attachment.html>

From qdunkan at gmail.com  Mon Nov 13 03:53:40 2017
From: qdunkan at gmail.com (Evan Laforge)
Date: Sun, 12 Nov 2017 19:53:40 -0800
Subject: uninstalling libraries
Message-ID: <CACbaDy6EjAEcyvPA4C-YaMJomynWrYmD51jqAbr-ZCkFT0f1SA@mail.gmail.com>

For a very long time, I've used a local script to uninstall libraries.
Initially it was very simple: use ghc-pkg field to find and remove
library-dirs, import-dirs, and haddock-html, and call ghc-pkg
unregister.

It served well for a long time, but eventually I got tired of copy
paste games and extended it to be able to recursively delete
dependents too.  Unfortunately now it's no longer so simple.  The main
problem is that the only way I know to find dependents is to ghc-pkg
unregister, and see what the error message complains about.  That's
obviously pretty bad, since by that time you've already unregistered,
so it's too late to back out.  The non-atomic nature of unregister+rm
has always caused problems anyway, since if unregister succeeds, but
the remove fails, we are stuck with a partial install.  Recursive
delete is too error prone, so I reverted that.

And then I discovered that hmatrix helpfully includes /opt/local/lib
and /usr/local/lib in its library-dirs, so clearly just deleting
whatever the package tells me is not very safe.  All this has led me
to believe uninstalling packages is not so simple, and maybe there
should be an actual real way to do it, not everyone hacking up their
own dangerous shell scripts.

So... is there?  Should there be one?  Is there interest in one?  How
do other people uninstall libraries?  Is there a better interface to
the pkg db than ghc-pkg?  Is there a better way to find dependents
than ghc-pkg unregister?

From allbery.b at gmail.com  Mon Nov 13 04:14:59 2017
From: allbery.b at gmail.com (Brandon Allbery)
Date: Sun, 12 Nov 2017 23:14:59 -0500
Subject: uninstalling libraries
In-Reply-To: <CACbaDy6EjAEcyvPA4C-YaMJomynWrYmD51jqAbr-ZCkFT0f1SA@mail.gmail.com>
References: <CACbaDy6EjAEcyvPA4C-YaMJomynWrYmD51jqAbr-ZCkFT0f1SA@mail.gmail.com>
Message-ID: <CAKFCL4VHVWWMrcPWML15rS4k+vEd4Xgv+-709EZB=y5=Oe8LTg@mail.gmail.com>

The problem is that the package db contains only what ghc needs to be able
to use the library; not the additional information needed to safely remove
it. (There are other package systems with this problem, notably Apple's.
Apple decided that instead of solving it, they would only support
applications that are complete bundles in and of themselves.) And arguably
it doesn't actually belong in ghc-pkg insofar as it's not intended to do
anything but store the information needed for ghc to link against packages.

This is something of a nasty problem, considering that storing uninstall
information separately is not particularly robust. Perhaps ghc-pkg should,
if it doesn't already, support extension fields that e.g. cabal can use to
store uninstall information. (But even that potentially has problems, given
that people are known to copy package registration information between
package databases. If there is uninstall information in there, what happens
if someone uninstalls via one or the other copy?)

On Sun, Nov 12, 2017 at 10:53 PM, Evan Laforge <qdunkan at gmail.com> wrote:

> For a very long time, I've used a local script to uninstall libraries.
> Initially it was very simple: use ghc-pkg field to find and remove
> library-dirs, import-dirs, and haddock-html, and call ghc-pkg
> unregister.
>
> It served well for a long time, but eventually I got tired of copy
> paste games and extended it to be able to recursively delete
> dependents too.  Unfortunately now it's no longer so simple.  The main
> problem is that the only way I know to find dependents is to ghc-pkg
> unregister, and see what the error message complains about.  That's
> obviously pretty bad, since by that time you've already unregistered,
> so it's too late to back out.  The non-atomic nature of unregister+rm
> has always caused problems anyway, since if unregister succeeds, but
> the remove fails, we are stuck with a partial install.  Recursive
> delete is too error prone, so I reverted that.
>
> And then I discovered that hmatrix helpfully includes /opt/local/lib
> and /usr/local/lib in its library-dirs, so clearly just deleting
> whatever the package tells me is not very safe.  All this has led me
> to believe uninstalling packages is not so simple, and maybe there
> should be an actual real way to do it, not everyone hacking up their
> own dangerous shell scripts.
>
> So... is there?  Should there be one?  Is there interest in one?  How
> do other people uninstall libraries?  Is there a better interface to
> the pkg db than ghc-pkg?  Is there a better way to find dependents
> than ghc-pkg unregister?
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
>



-- 
brandon s allbery kf8nh                               sine nomine associates
allbery.b at gmail.com                                  ballbery at sinenomine.net
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/glasgow-haskell-users/attachments/20171112/963e8aa4/attachment.html>

From qdunkan at gmail.com  Mon Nov 13 04:45:19 2017
From: qdunkan at gmail.com (Evan Laforge)
Date: Sun, 12 Nov 2017 20:45:19 -0800
Subject: uninstalling libraries
In-Reply-To: <CAKFCL4VHVWWMrcPWML15rS4k+vEd4Xgv+-709EZB=y5=Oe8LTg@mail.gmail.com>
References: <CACbaDy6EjAEcyvPA4C-YaMJomynWrYmD51jqAbr-ZCkFT0f1SA@mail.gmail.com>
 <CAKFCL4VHVWWMrcPWML15rS4k+vEd4Xgv+-709EZB=y5=Oe8LTg@mail.gmail.com>
Message-ID: <CACbaDy67Xz6PzEQq-WetOHCoBC9xF6UsDs+2NueAwY37=kGH8w@mail.gmail.com>

On Sun, Nov 12, 2017 at 8:14 PM, Brandon Allbery <allbery.b at gmail.com> wrote:
> This is something of a nasty problem, considering that storing uninstall
> information separately is not particularly robust. Perhaps ghc-pkg should,
> if it doesn't already, support extension fields that e.g. cabal can use to
> store uninstall information. (But even that potentially has problems, given
> that people are known to copy package registration information between
> package databases. If there is uninstall information in there, what happens
> if someone uninstalls via one or the other copy?)

Aren't packages only allowed to install a restricted set of things
into a restricted set of places?  We have the code (.hi, .a, .so,
etc., in import-dirs / library-dirs), possibly library-specific data
(I assume that's data-dir), and haddock (haddock-html and
haddock-interfaces, awkwardly in separate places).

One problem is that I don't fully understand what those fields mean,
is there documentation somewhere?  And then the fact that these are
all plural so presumably you could have a lot of them, what is that
for?

I'm guessing library-dirs means something like "put this on your -L
line" so it's clearly a mistake to interpret that as "here's where I
put the library", and you'll have things like /usr/local/lib if you
need to link external libraries.

Is there any more complicated install plan than put *.a, *.so, *.hi in
$root/lib/$ghc/$package-$id, put haddock in
$root/share/doc/$ghc/$package, put ad-hoc junk in
$root/share/$ghc/$package?  I assume there must be, but who's doing
that and why?  If it's OS packages, then they have their own uninstall
mechanisms, presumably not ghc's problem.

From allbery.b at gmail.com  Mon Nov 13 04:51:17 2017
From: allbery.b at gmail.com (Brandon Allbery)
Date: Sun, 12 Nov 2017 23:51:17 -0500
Subject: uninstalling libraries
In-Reply-To: <CACbaDy67Xz6PzEQq-WetOHCoBC9xF6UsDs+2NueAwY37=kGH8w@mail.gmail.com>
References: <CACbaDy6EjAEcyvPA4C-YaMJomynWrYmD51jqAbr-ZCkFT0f1SA@mail.gmail.com>
 <CAKFCL4VHVWWMrcPWML15rS4k+vEd4Xgv+-709EZB=y5=Oe8LTg@mail.gmail.com>
 <CACbaDy67Xz6PzEQq-WetOHCoBC9xF6UsDs+2NueAwY37=kGH8w@mail.gmail.com>
Message-ID: <CAKFCL4XxcED7ANqpeTGwXe3AwNfAQxNe6CD00UXLewwdvXOtTw@mail.gmail.com>

cabal and stack, and in the case of stack, cabal new-build, and possibly
cabal sandboxes, you probably shouldn't be trying to uninstall.

And yes, the data lines are telling ghc what to compile / link with, not
files but command line inclusions. And this will be especially messy on OS
X because of the need to group .dylibs together to avoid making the link
commands section too large with multiple RPATH entries. (Which will also
complicate uninstallation there.)

On Sun, Nov 12, 2017 at 11:45 PM, Evan Laforge <qdunkan at gmail.com> wrote:

> On Sun, Nov 12, 2017 at 8:14 PM, Brandon Allbery <allbery.b at gmail.com>
> wrote:
> > This is something of a nasty problem, considering that storing uninstall
> > information separately is not particularly robust. Perhaps ghc-pkg
> should,
> > if it doesn't already, support extension fields that e.g. cabal can use
> to
> > store uninstall information. (But even that potentially has problems,
> given
> > that people are known to copy package registration information between
> > package databases. If there is uninstall information in there, what
> happens
> > if someone uninstalls via one or the other copy?)
>
> Aren't packages only allowed to install a restricted set of things
> into a restricted set of places?  We have the code (.hi, .a, .so,
> etc., in import-dirs / library-dirs), possibly library-specific data
> (I assume that's data-dir), and haddock (haddock-html and
> haddock-interfaces, awkwardly in separate places).
>
> One problem is that I don't fully understand what those fields mean,
> is there documentation somewhere?  And then the fact that these are
> all plural so presumably you could have a lot of them, what is that
> for?
>
> I'm guessing library-dirs means something like "put this on your -L
> line" so it's clearly a mistake to interpret that as "here's where I
> put the library", and you'll have things like /usr/local/lib if you
> need to link external libraries.
>
> Is there any more complicated install plan than put *.a, *.so, *.hi in
> $root/lib/$ghc/$package-$id, put haddock in
> $root/share/doc/$ghc/$package, put ad-hoc junk in
> $root/share/$ghc/$package?  I assume there must be, but who's doing
> that and why?  If it's OS packages, then they have their own uninstall
> mechanisms, presumably not ghc's problem.
>



-- 
brandon s allbery kf8nh                               sine nomine associates
allbery.b at gmail.com                                  ballbery at sinenomine.net
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/glasgow-haskell-users/attachments/20171112/76dd00dd/attachment-0001.html>

From danburton.email at gmail.com  Mon Nov 13 20:27:07 2017
From: danburton.email at gmail.com (Dan Burton)
Date: Mon, 13 Nov 2017 12:27:07 -0800
Subject: [Haskell-cafe] uninstalling libraries
In-Reply-To: <CAKFCL4XxcED7ANqpeTGwXe3AwNfAQxNe6CD00UXLewwdvXOtTw@mail.gmail.com>
References: <CACbaDy6EjAEcyvPA4C-YaMJomynWrYmD51jqAbr-ZCkFT0f1SA@mail.gmail.com>
 <CAKFCL4VHVWWMrcPWML15rS4k+vEd4Xgv+-709EZB=y5=Oe8LTg@mail.gmail.com>
 <CACbaDy67Xz6PzEQq-WetOHCoBC9xF6UsDs+2NueAwY37=kGH8w@mail.gmail.com>
 <CAKFCL4XxcED7ANqpeTGwXe3AwNfAQxNe6CD00UXLewwdvXOtTw@mail.gmail.com>
Message-ID: <CALSygweo1QOVw0WAhv43tuygeB603++OGm_+0sXGsQDTMPpt=w@mail.gmail.com>

I also lean towards the "you shouldn't be trying to uninstall" mentality.
But it's worth discussing.

What is the motive for uninstalling? Is it to upgrade to a new version? To
narrow hoogle search results?  For these, our sandbox tooling should allow
for upgrades or selective querying without having to manually uninstall. If
it's just because you want the hard drive space back, then I don't really
have anything for that.


On Nov 12, 2017 20:55, "Brandon Allbery" <allbery.b at gmail.com> wrote:

cabal and stack, and in the case of stack, cabal new-build, and possibly
cabal sandboxes, you probably shouldn't be trying to uninstall.

And yes, the data lines are telling ghc what to compile / link with, not
files but command line inclusions. And this will be especially messy on OS
X because of the need to group .dylibs together to avoid making the link
commands section too large with multiple RPATH entries. (Which will also
complicate uninstallation there.)

On Sun, Nov 12, 2017 at 11:45 PM, Evan Laforge <qdunkan at gmail.com> wrote:

> On Sun, Nov 12, 2017 at 8:14 PM, Brandon Allbery <allbery.b at gmail.com>
> wrote:
> > This is something of a nasty problem, considering that storing uninstall
> > information separately is not particularly robust. Perhaps ghc-pkg
> should,
> > if it doesn't already, support extension fields that e.g. cabal can use
> to
> > store uninstall information. (But even that potentially has problems,
> given
> > that people are known to copy package registration information between
> > package databases. If there is uninstall information in there, what
> happens
> > if someone uninstalls via one or the other copy?)
>
> Aren't packages only allowed to install a restricted set of things
> into a restricted set of places?  We have the code (.hi, .a, .so,
> etc., in import-dirs / library-dirs), possibly library-specific data
> (I assume that's data-dir), and haddock (haddock-html and
> haddock-interfaces, awkwardly in separate places).
>
> One problem is that I don't fully understand what those fields mean,
> is there documentation somewhere?  And then the fact that these are
> all plural so presumably you could have a lot of them, what is that
> for?
>
> I'm guessing library-dirs means something like "put this on your -L
> line" so it's clearly a mistake to interpret that as "here's where I
> put the library", and you'll have things like /usr/local/lib if you
> need to link external libraries.
>
> Is there any more complicated install plan than put *.a, *.so, *.hi in
> $root/lib/$ghc/$package-$id, put haddock in
> $root/share/doc/$ghc/$package, put ad-hoc junk in
> $root/share/$ghc/$package?  I assume there must be, but who's doing
> that and why?  If it's OS packages, then they have their own uninstall
> mechanisms, presumably not ghc's problem.
>



-- 
brandon s allbery kf8nh                               sine nomine associates
allbery.b at gmail.com                                  ballbery at sinenomine.net
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net

_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/glasgow-haskell-users/attachments/20171113/80c9c4b0/attachment.html>

From qdunkan at gmail.com  Mon Nov 13 22:45:33 2017
From: qdunkan at gmail.com (Evan Laforge)
Date: Mon, 13 Nov 2017 14:45:33 -0800
Subject: [Haskell-cafe] uninstalling libraries
In-Reply-To: <CALSygweo1QOVw0WAhv43tuygeB603++OGm_+0sXGsQDTMPpt=w@mail.gmail.com>
References: <CACbaDy6EjAEcyvPA4C-YaMJomynWrYmD51jqAbr-ZCkFT0f1SA@mail.gmail.com>
 <CAKFCL4VHVWWMrcPWML15rS4k+vEd4Xgv+-709EZB=y5=Oe8LTg@mail.gmail.com>
 <CACbaDy67Xz6PzEQq-WetOHCoBC9xF6UsDs+2NueAwY37=kGH8w@mail.gmail.com>
 <CAKFCL4XxcED7ANqpeTGwXe3AwNfAQxNe6CD00UXLewwdvXOtTw@mail.gmail.com>
 <CALSygweo1QOVw0WAhv43tuygeB603++OGm_+0sXGsQDTMPpt=w@mail.gmail.com>
Message-ID: <CACbaDy7CtzLo5FQZRUd+ya_UQdTrPTXmzqEfVzE=MRz0NzUwfA@mail.gmail.com>

On Mon, Nov 13, 2017 at 12:27 PM, Dan Burton <danburton.email at gmail.com> wrote:
> I also lean towards the "you shouldn't be trying to uninstall" mentality.
> But it's worth discussing.
>
> What is the motive for uninstalling? Is it to upgrade to a new version? To
> narrow hoogle search results?  For these, our sandbox tooling should allow
> for upgrades or selective querying without having to manually uninstall. If
> it's just because you want the hard drive space back, then I don't really
> have anything for that.

I'm usually backing out of a version so I can install something else.
I always keep just one version of each library installed.  It's less
clutter, and I never have any question about what package is linked to
what version of what other package.

Maybe it's not the official way to do things, but it's probably the
reason I've never encountered cabal hell.  Back in the day, of course,
it was the only option.  Nowadays we have cabal sandbox, but global
packages are still simpler and more convenient.  Maybe the new cabal
install will improve on the situation, but it seems hard to beat the
convenience, and doesn't provide the guarantee that there's no version
skew anywhere.  But, I'm not the only one with a single version
policy, Google does too.

Anyway, if there's no interest in robust uninstallation, I'll just
continue using my script, with a few extra hacks to avoid deleting
/usr/local/lib.  Except that one hiccup it's actually worked fine for
the last 15 years or so.  For me, making a better API to the package
db than ghc-pkg would probably do well enough.

From danburton.email at gmail.com  Tue Nov 14 00:56:33 2017
From: danburton.email at gmail.com (Dan Burton)
Date: Mon, 13 Nov 2017 16:56:33 -0800
Subject: [Haskell-cafe] uninstalling libraries
In-Reply-To: <CACbaDy7CtzLo5FQZRUd+ya_UQdTrPTXmzqEfVzE=MRz0NzUwfA@mail.gmail.com>
References: <CACbaDy6EjAEcyvPA4C-YaMJomynWrYmD51jqAbr-ZCkFT0f1SA@mail.gmail.com>
 <CAKFCL4VHVWWMrcPWML15rS4k+vEd4Xgv+-709EZB=y5=Oe8LTg@mail.gmail.com>
 <CACbaDy67Xz6PzEQq-WetOHCoBC9xF6UsDs+2NueAwY37=kGH8w@mail.gmail.com>
 <CAKFCL4XxcED7ANqpeTGwXe3AwNfAQxNe6CD00UXLewwdvXOtTw@mail.gmail.com>
 <CALSygweo1QOVw0WAhv43tuygeB603++OGm_+0sXGsQDTMPpt=w@mail.gmail.com>
 <CACbaDy7CtzLo5FQZRUd+ya_UQdTrPTXmzqEfVzE=MRz0NzUwfA@mail.gmail.com>
Message-ID: <CALSygwc6wLM5_wBUg-=kLaFCqcAKQvUYUYXq8ptuy5FEmc3+-w@mail.gmail.com>

The point at which I find a "single version policy" difficult is when I'm
trying to contribute to disparate packages or projects, with differing
maintainers and version requirements. One person wants to use the latest,
while another hasn't upgraded yet. Sandboxing is the only sane way to work
on two such projects simultaneously.

But if you, like Google, have enough control over all the projects worked
on in order to dictate a single version policy, then that approach can
certainly have its benefits. I'm not sure many people consider themselves
in such a position, hence the pervasive assumption that sandboxing will be
involved.


On Nov 13, 2017 14:45, "Evan Laforge" <qdunkan at gmail.com> wrote:

On Mon, Nov 13, 2017 at 12:27 PM, Dan Burton <danburton.email at gmail.com>
wrote:
> I also lean towards the "you shouldn't be trying to uninstall" mentality.
> But it's worth discussing.
>
> What is the motive for uninstalling? Is it to upgrade to a new version? To
> narrow hoogle search results?  For these, our sandbox tooling should allow
> for upgrades or selective querying without having to manually uninstall.
If
> it's just because you want the hard drive space back, then I don't really
> have anything for that.

I'm usually backing out of a version so I can install something else.
I always keep just one version of each library installed.  It's less
clutter, and I never have any question about what package is linked to
what version of what other package.

Maybe it's not the official way to do things, but it's probably the
reason I've never encountered cabal hell.  Back in the day, of course,
it was the only option.  Nowadays we have cabal sandbox, but global
packages are still simpler and more convenient.  Maybe the new cabal
install will improve on the situation, but it seems hard to beat the
convenience, and doesn't provide the guarantee that there's no version
skew anywhere.  But, I'm not the only one with a single version
policy, Google does too.

Anyway, if there's no interest in robust uninstallation, I'll just
continue using my script, with a few extra hacks to avoid deleting
/usr/local/lib.  Except that one hiccup it's actually worked fine for
the last 15 years or so.  For me, making a better API to the package
db than ghc-pkg would probably do well enough.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/glasgow-haskell-users/attachments/20171113/199daa73/attachment.html>

From qdunkan at gmail.com  Tue Nov 14 01:39:01 2017
From: qdunkan at gmail.com (Evan Laforge)
Date: Mon, 13 Nov 2017 17:39:01 -0800
Subject: [Haskell-cafe] uninstalling libraries
In-Reply-To: <CALSygwc6wLM5_wBUg-=kLaFCqcAKQvUYUYXq8ptuy5FEmc3+-w@mail.gmail.com>
References: <CACbaDy6EjAEcyvPA4C-YaMJomynWrYmD51jqAbr-ZCkFT0f1SA@mail.gmail.com>
 <CAKFCL4VHVWWMrcPWML15rS4k+vEd4Xgv+-709EZB=y5=Oe8LTg@mail.gmail.com>
 <CACbaDy67Xz6PzEQq-WetOHCoBC9xF6UsDs+2NueAwY37=kGH8w@mail.gmail.com>
 <CAKFCL4XxcED7ANqpeTGwXe3AwNfAQxNe6CD00UXLewwdvXOtTw@mail.gmail.com>
 <CALSygweo1QOVw0WAhv43tuygeB603++OGm_+0sXGsQDTMPpt=w@mail.gmail.com>
 <CACbaDy7CtzLo5FQZRUd+ya_UQdTrPTXmzqEfVzE=MRz0NzUwfA@mail.gmail.com>
 <CALSygwc6wLM5_wBUg-=kLaFCqcAKQvUYUYXq8ptuy5FEmc3+-w@mail.gmail.com>
Message-ID: <CACbaDy5eJjKZNMOq5PmWXvB17Zp9n0tpEFPjq6EEmCOU=hPtYw@mail.gmail.com>

To be fair, it's not absolute.  I have found cabal sandbox useful to
compile things thing tons of dependencies, like pandoc.  And if I
wanted to contribute to something with out of date version
requirements (and the first step is not helping them upgrade, for
whatever reason), then surely I'd go ahead and make a sandbox for
that.  It hasn't really come up though.  I'm certainly not trying to
push this as The Solution, that's a bigger windmill than just
uninstalls :)

On Mon, Nov 13, 2017 at 4:56 PM, Dan Burton <danburton.email at gmail.com> wrote:
> The point at which I find a "single version policy" difficult is when I'm
> trying to contribute to disparate packages or projects, with differing
> maintainers and version requirements. One person wants to use the latest,
> while another hasn't upgraded yet. Sandboxing is the only sane way to work
> on two such projects simultaneously.
>
> But if you, like Google, have enough control over all the projects worked on
> in order to dictate a single version policy, then that approach can
> certainly have its benefits. I'm not sure many people consider themselves in
> such a position, hence the pervasive assumption that sandboxing will be
> involved.
>
>
> On Nov 13, 2017 14:45, "Evan Laforge" <qdunkan at gmail.com> wrote:
>
> On Mon, Nov 13, 2017 at 12:27 PM, Dan Burton <danburton.email at gmail.com>
> wrote:
>> I also lean towards the "you shouldn't be trying to uninstall" mentality.
>> But it's worth discussing.
>>
>> What is the motive for uninstalling? Is it to upgrade to a new version? To
>> narrow hoogle search results?  For these, our sandbox tooling should allow
>> for upgrades or selective querying without having to manually uninstall.
>> If
>> it's just because you want the hard drive space back, then I don't really
>> have anything for that.
>
> I'm usually backing out of a version so I can install something else.
> I always keep just one version of each library installed.  It's less
> clutter, and I never have any question about what package is linked to
> what version of what other package.
>
> Maybe it's not the official way to do things, but it's probably the
> reason I've never encountered cabal hell.  Back in the day, of course,
> it was the only option.  Nowadays we have cabal sandbox, but global
> packages are still simpler and more convenient.  Maybe the new cabal
> install will improve on the situation, but it seems hard to beat the
> convenience, and doesn't provide the guarantee that there's no version
> skew anywhere.  But, I'm not the only one with a single version
> policy, Google does too.
>
> Anyway, if there's no interest in robust uninstallation, I'll just
> continue using my script, with a few extra hacks to avoid deleting
> /usr/local/lib.  Except that one hiccup it's actually worked fine for
> the last 15 years or so.  For me, making a better API to the package
> db than ghc-pkg would probably do well enough.
>
>

From twhitehead at gmail.com  Tue Nov 14 03:38:24 2017
From: twhitehead at gmail.com (Tyson Whitehead)
Date: Tue, 14 Nov 2017 03:38:24 +0000
Subject: uninstalling libraries
In-Reply-To: <CAKFCL4XxcED7ANqpeTGwXe3AwNfAQxNe6CD00UXLewwdvXOtTw@mail.gmail.com>
References: <CACbaDy6EjAEcyvPA4C-YaMJomynWrYmD51jqAbr-ZCkFT0f1SA@mail.gmail.com>
 <CAKFCL4VHVWWMrcPWML15rS4k+vEd4Xgv+-709EZB=y5=Oe8LTg@mail.gmail.com>
 <CACbaDy67Xz6PzEQq-WetOHCoBC9xF6UsDs+2NueAwY37=kGH8w@mail.gmail.com>
 <CAKFCL4XxcED7ANqpeTGwXe3AwNfAQxNe6CD00UXLewwdvXOtTw@mail.gmail.com>
Message-ID: <CAJbx2R6+_GFuROByMe5kjOGm_ap4nd+pZU5s09drOHuRm5=EqA@mail.gmail.com>

I used to fight with a combination of system and cabal installed packages
under debian testing.

Then, about a year ago, the frustration became too much and I switched to
using nix, intero in emacs, and stack with the nix resolver, all installed
with nix on my debian machine.  Couldn't be happier.

If I want a new dependency, I just add it to my cabal file, rerun
cabal2nix, restart intero and it all just works. Talk about a vastly
improved experience over what I used to have.

As a major bonus I now also run the exact same setup on our HPC cluster,
which runs centos 6, and I can switch between them seamlessly.

Cheers -Tyson

PS: The only gotcha I ran into so far is that stack/intero installs a
ghcpaths package outside of nix on first startup that can causes conflicts
with some packages. Turns out you can just manually remove it though to
resolve this, so no big deal.

On Sun, Nov 12, 2017, 23:52 Brandon Allbery, <allbery.b at gmail.com> wrote:

> cabal and stack, and in the case of stack, cabal new-build, and possibly
> cabal sandboxes, you probably shouldn't be trying to uninstall.
>
> And yes, the data lines are telling ghc what to compile / link with, not
> files but command line inclusions. And this will be especially messy on OS
> X because of the need to group .dylibs together to avoid making the link
> commands section too large with multiple RPATH entries. (Which will also
> complicate uninstallation there.)
>
> On Sun, Nov 12, 2017 at 11:45 PM, Evan Laforge <qdunkan at gmail.com> wrote:
>
>> On Sun, Nov 12, 2017 at 8:14 PM, Brandon Allbery <allbery.b at gmail.com>
>> wrote:
>> > This is something of a nasty problem, considering that storing uninstall
>> > information separately is not particularly robust. Perhaps ghc-pkg
>> should,
>> > if it doesn't already, support extension fields that e.g. cabal can use
>> to
>> > store uninstall information. (But even that potentially has problems,
>> given
>> > that people are known to copy package registration information between
>> > package databases. If there is uninstall information in there, what
>> happens
>> > if someone uninstalls via one or the other copy?)
>>
>> Aren't packages only allowed to install a restricted set of things
>> into a restricted set of places?  We have the code (.hi, .a, .so,
>> etc., in import-dirs / library-dirs), possibly library-specific data
>> (I assume that's data-dir), and haddock (haddock-html and
>> haddock-interfaces, awkwardly in separate places).
>>
>> One problem is that I don't fully understand what those fields mean,
>> is there documentation somewhere?  And then the fact that these are
>> all plural so presumably you could have a lot of them, what is that
>> for?
>>
>> I'm guessing library-dirs means something like "put this on your -L
>> line" so it's clearly a mistake to interpret that as "here's where I
>> put the library", and you'll have things like /usr/local/lib if you
>> need to link external libraries.
>>
>> Is there any more complicated install plan than put *.a, *.so, *.hi in
>> $root/lib/$ghc/$package-$id, put haddock in
>> $root/share/doc/$ghc/$package, put ad-hoc junk in
>> $root/share/$ghc/$package?  I assume there must be, but who's doing
>> that and why?  If it's OS packages, then they have their own uninstall
>> mechanisms, presumably not ghc's problem.
>>
>
>
>
> --
> brandon s allbery kf8nh                               sine nomine
> associates
> allbery.b at gmail.com
> ballbery at sinenomine.net
> unix, openafs, kerberos, infrastructure, xmonad
> http://sinenomine.net
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/glasgow-haskell-users/attachments/20171114/db7bfa96/attachment.html>

From anthony_clayden at clear.net.nz  Mon Nov 20 08:43:29 2017
From: anthony_clayden at clear.net.nz (Anthony Clayden)
Date: Mon, 20 Nov 2017 21:43:29 +1300
Subject: [was ghc-devs] Reasoning backwards with type families
Message-ID: <5a1295b1.33d.372a.15211@clear.net.nz>

> On Thu Nov 16 01:31:55 UTC 2017, David Feuer wrote:

(Moving to ghc-users, there's nothing particularly dev-y.)

> Sometimes it woulld be useful to be able to reason
backwards
> about type families.

Hi David, this is a well-known issue/bit of a sore.
Discussed much in the debate between type families
compared to FunDeps.

> For example, we have
>
> type family a && b where
>   'False && b      = 'False
>   'True  && b      = b
>   a      && 'False = 'False
>   a      && 'True  = a
>   a      && a      = a

> ... if we know something about the *result*,
> GHC doesn't give us any way to learn anything about the
arguments.

You can achieve the improvement you want today.

You'll probably find Oleg has a solution
With FunDeps and superclass constraints, it'll go like this

class (OnResult r a b, OnResult r b a) => And a b r | a b ->
r

instance And 'False b 'False
-- etc, as you'd expect following the tf equations
-- the instances are overlapping but confluent

class OnResult r a b | r a -> b
instance OnResult 'True a 'True
instance OnResult 'False 'True 'False

You could equally make `OnResult` a type family.

If you can trace backwards to where `&&` is used,
you might be able to add suitable constraints there.

So there's a couple of futures:
* typechecker plugins, using an SMT solver
* injective type families
   the next phase is supposed to allow

type family a && b = r | r a -> b, r b -> a where ...

That will help with some type families
(such as addition of Nats),
plug1
https://github.com/AntC2/ghc-proposals/blob/instance-apartness-guards/proposals/0000-instance-apartness-guards.rst#injective-type-families

but I don't see it helping here.
plug2 (this example)
https://github.com/AntC2/ghc-proposals/blob/instance-apartness-guards/proposals/0000-instance-apartness-guards.rst#type-family-coincident-overlap

Because (for example) if you unify the first two equations,
(that is, looking for coincident overlap)

    'False && 'False = 'False
    'True && 'False = 'False

That's inconsistent on dependency ` r b -> a`.

And you can't fix it by re-ordering the closed equations.

> For (&&), the obvious things you'd want are ...
>
> There's nothing inherently impossible about this sort of
reasoning.

No-ish but. It relies on knowing kind `Bool` is closed.
And GHC doesn't pay attention to that.
So you need to bring type family `Not`
into the reasoning; hence a SMT solver.

> ...
> I wouldn't necessarily expect GHC
> to be able to work something like this out on its own.

That's a relief ;-)

> But it seems like there should be some way to allow the
user
> to guide it to a proof.

Yes, an SMT solver with a model for kind `Bool`.
(And a lot of hard work to teach it, by someone.)

AntC

From ben at well-typed.com  Tue Nov 21 22:00:36 2017
From: ben at well-typed.com (Ben Gamari)
Date: Tue, 21 Nov 2017 17:00:36 -0500
Subject: [ANNOUNCE] GHC 8.2.2 released
Message-ID: <878tezfg1u.fsf@ben-laptop.smart-cactus.org>


           ===============================================
            The Glasgow Haskell Compiler -- version 8.2.2
           ===============================================

The GHC Team is pleased to announce a new minor release of GHC. This release
builds on the performance and stability improvements of 8.2.1, fixing a variety
of correctness bugs, improving error messages, and making the compiler more
portable.

Notable bug-fixes include

 * A correctness issue resulting in segmentation faults in some
   FFI-users (#13707, #14346)

 * A correctness issue resulting in undefined behavior in some programs
   using STM (#14171)

 * A bug which may have manifested in segmentation faults in
   out-of-memory condition (#14329)

 * clearBit of Natural no longer bottoms (#13203)

 * A specialisation bug resulting in exponential blowup of compilation
   time in some specialisation-intensive programs (#14379)

 * ghc-pkg now works even in environments with misconfigured NFS mounts
   (#13945)

 * GHC again supports production of position-independent executables
   (#13702)

 * Better error messages around kind mismatches (#11198, #12373, #13530,
   #13610)

A thorough list of the changes in the release can be found in the release
notes,

    https://haskell.org/ghc/docs/8.2.2/html/users_guide/release-8-2-2.html


How to get it
~~~~~~~~~~~~~

This release can be downloaded from

    https://www.haskell.org/ghc/download_ghc_8_2_2.html

For older versions see

    https://www.haskell.org/ghc/

We supply binary builds in the native package format for many platforms, and the
source distribution is available from the same place.


Background
~~~~~~~~~~

Haskell is a standardized lazy functional programming language.

GHC is a state-of-the-art programming suite for Haskell. Included is an
optimising compiler generating efficient code for a variety of platforms,
together with an interactive system for convenient, quick development. The
distribution includes space and time profiling facilities, a large collection of
libraries, and support for various language extensions, including concurrency,
exceptions, and foreign language interfaces. GHC is distributed under a
BSD-style open source license.

A wide variety of Haskell related resources (tutorials, libraries,
specifications, documentation, compilers, interpreters, references, contact
information, links to research groups) are available from the Haskell home page
(see below).


On-line GHC-related resources
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Relevant URLs on the World-Wide Web:

GHC home page              https://www.haskell.org/ghc/
GHC developers' home page  https://ghc.haskell.org/trac/ghc/
Haskell home page          https://www.haskell.org/


Supported Platforms
~~~~~~~~~~~~~~~~~~~

The list of platforms we support, and the people responsible for them, is here:

    https://ghc.haskell.org/trac/ghc/wiki/Contributors

Ports to other platforms are possible with varying degrees of difficulty. The
Building Guide describes how to go about porting to a new platform:

    https://ghc.haskell.org/trac/ghc/wiki/Building


Developers
~~~~~~~~~~

We welcome new contributors. Instructions on accessing our source code
repository, and getting started with hacking on GHC, are available from the
GHC's developer's site:

    https://ghc.haskell.org/trac/ghc/


Mailing lists
~~~~~~~~~~~~~

We run mailing lists for GHC users and bug reports; to subscribe, use the web
interfaces at

    https://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
    https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-tickets

There are several other haskell and ghc-related mailing lists on
www.haskell.org; for the full list, see

    https://mail.haskell.org/cgi-bin/mailman/listinfo

Many GHC developers hang out on #haskell on IRC:

    https://www.haskell.org/haskellwiki/IRC_channel

Please report bugs using our bug tracking system. Instructions on reporting bugs
can be found here:

    https://www.haskell.org/ghc/reportabug


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/glasgow-haskell-users/attachments/20171121/ffcef898/attachment.sig>

From ben at well-typed.com  Tue Nov 21 22:31:53 2017
From: ben at well-typed.com (Ben Gamari)
Date: Tue, 21 Nov 2017 17:31:53 -0500
Subject: [ANNOUNCE] GHC 8.2.2 released
In-Reply-To: <878tezfg1u.fsf@ben-laptop.smart-cactus.org>
References: <878tezfg1u.fsf@ben-laptop.smart-cactus.org>
Message-ID: <8760a3femx.fsf@ben-laptop.smart-cactus.org>

Ben Gamari <ben at well-typed.com> writes:

> A thorough list of the changes in the release can be found in the release
> notes,
>
>     https://haskell.org/ghc/docs/8.2.2/html/users_guide/release-8-2-2.html
>
For the record this link was incorrect. It should be

    https://downloads.haskell.org/~ghc/8.2.2/docs/html/users_guide/8.2.2-notes.html

My apologies for the confusion.

Cheers,

- Ben

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/glasgow-haskell-users/attachments/20171121/8beb3379/attachment.sig>