Re: Proposal process status

[Adam Foltzer]

I really appreciate you putting so much work into this. It is very
important, and I believe could do much to increase awareness of and
participation in these processes.

I've left most of my thoughts as line comments on the proposal document,
but since discussion of platform choice is taking place here, I'll quote
the Motivations section:

   1. Higher than necessary barrier-to-entry.

For the purposes of this proposal, whether we would prefer a competing
alternative is secondary to the fact that a Github account has become a
very low common denominator for people wishing to participate in the
development of open source projects. If we decide to proceed with a
non-Github platform, we need to make a compelling case that the alternate
choice does not raise the barrier to entry, or else we need to decide that
we have different priorities for this effort.

Thanks,
Adam

On Wed, Jul 20, 2016 at 12:56 PM, Ben Gamari  wrote:

> Alexander Berntsen  writes:
>
> > On 20/07/16 19:04, Ben Gamari wrote:
> >> I know, it's rather frustrating. I also have fairly strong feelings
> >>  about open-source purity, but in this case I just don't see any
> >> way to improve the current situation under this constraint.
> >
> > I don't think that starting to rely on proprietary software *is* an
> > improvement, but the opposite.
> >
> This is a bit of a judgement call. I know this is a long-contested
> issue, but personally for me it puts me at ease if,
>
>  * the proprietary code is running on someone else's machine
>
>  * I can use the application with open tools (a web browser of your
>choice, git, and an email client)
>
>  * I can get my data out if needed
>
>
> >> It does look like Gitlab is an impressive option but really then
> >> we are back to the problem of fragmented development tools. Using
> >> Trac, Phabricator, Gitlab, and mailing lists all in one project
> >> seems a bit silly.
> >
> > I don't understand why using GitLab is more silly than using GitHub,
> > when considering fragmentation.
>
> When put this way my argument does indeed sound a bit silly. :-)
>
> Perhaps it's not. I think the difference is that we would
> be consolidating on a platform which much of the Haskell community
> already uses in their non-GHC development.
>
> Cheers,
>
> - Ben
>
> ___
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
>
>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Feedback on -Wredundant-constraints

[Adam Foltzer]

With 8.0.1 freshly arrived, I'm taking on the task of updating a number of
our larger projects here at Galois. I made a couple of these comments
briefly on a relevant Trac ticket[1], but I wanted to open this discussion
to a wider audience.

We tend to use -Wall (and -Werror, in CI environments), and so I've had to
make decisions about how to handle the new -Wredundant-constraints
warnings. So far, I've come to think of it as two different warnings that
happen to be combined:

Warning 1: a warning for constraints made redundant by superclass
relationships, and
Warning 2: a warning for unused constraints

Overall I'm a fan of Warning 1. It seems very much in the spirit of other
warnings such as unused imports. The only stumbling block is how it affects
the 3-release compatibility plan with respect to, e.g., the AMP. Most of
our code targets a 2-release window, though, so in every such case it has
been fine for us to simply remove the offending constraint.

Warning 2 on the other hand is far more dubious to me. In the best case, it
finds constraints that through oversight or non-local changes are truly no
longer necessary in the codebase. This is nice, but the much more common
case in our code is that we've made a deliberate decision to include that
constraint as part of our API design.

The most painful example of this I've hit so far is in an API of related
functions, where we've put the same constraint on each function even when
the implementation of that particular function might not need that
constraint. This is good for consistency and forward-looking compatibility
(what if we need that constraint in the next version?). The warning's
advice in this case makes the API harder to understand, and less abstract
(the client shouldn't care or know that f needs Functor, but g doesn't, if
both will always be used in a Functor context).

On another level, Warning 2 is a warning that we could have given a more
general type to a definition. We quite rightly don't do this for the
non-constraint parts of the type signatures, so why are we doing it for the
constraints?

I'm happy that Warning 1 is now around, but Warning 2 feels much more like
an opinionated lint check, and I really wish it wasn't part of -Wall.

[1]: https://ghc.haskell.org/trac/ghc/ticket/10635#comment:15
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users