Re: Proposal process status

[Yuras Shumovich]

On Thu, 2016-07-21 at 14:38 -0400, Richard Eisenberg wrote:
> > 
> > On Jul 21, 2016, at 2:25 PM, Yuras Shumovich 
> > wrote:
> > 
> > It is hopeless. Haskell2020 will not include TemplateHaskell,
> > GADTs,
> > etc.
> 
> Why do you say this? I don't think this is a forgone conclusion. I'd
> love to see these standardized.

Because I'm a pessimist :)
We even can't agree to add `text` to the standard library.

> 
> My own 2¢ on these are that we can standardize some subset of
> TemplateHaskell quite easily. GADTs are harder because (to my
> knowledge) no one has ever written a specification of type inference
> for GADTs. (Note that the OutsideIn paper admits to failing at this.)
> Perhaps we can nail it, but perhaps not. Even so, we can perhaps
> standardize much of the behavior around GADTs (but with pattern
> matches requiring lots of type annotations) and say that an
> implementation is free to do better. Maybe we can do even better than
> this, but I doubt we'll totally ignore this issue.
> 
> > Haskell Prime committee will never catch up if GHC will continue
> > adding new extensions.
> 
> Of course not. But I believe some libraries also refrain from using
> new extensions for precisely the same reason -- that the new
> extensions have yet to fully gel.

And you are an optimist. We are lazy, so we'll use whatever is
convenient. There are three ways to force people to refrain from using
new extensions:

- mature alternative compiler exists, so nobody will use your library
unless it uses only the common subset of features;

- the standard covers all usual needs (I don't think it will be
possible in near future, and existence of this email thread proves
that.)

- new features are not first class citizens; e.g. `cabal check` issues
an error (or warning) when you are uploading a package with immature
extension used.

> 
> > In 2020 everybody will use pattern synonyms,
> > overloaded record fields and TypeInType, so the standard will be as
> > far
> > from practice as it is now.
> 
> Pattern synonyms, now with a published paper behind them, may
> actually be in good enough shape to standardize by 2020. I don't know
> anything about overloaded record fields. I'd be shocked if TypeInType
> is ready to standardize by 2020. But hopefully we'll get to it.
> 
> > 
> > The whole idea of language extensions, as it is right now, works
> > against Haskell Prime.
> 
> I heartily disagree here. Ideas that are now standard had to have
> started somewhere, and I really like (in theory) the way GHC/Haskell
> does this.

I'm not against language extensions completely. But using them should
be a real pain to prevent people from using then everywhere. Ideally
you should have to compile GHC manually to get a particular extension
enabled :)

> 
> The (in theory) parenthetical is because the standardization process
> has been too, well, dead to be useful. Is that changing? Perhaps. I'd
> love to see more action on that front. I'm hoping to take on a more
> active role in the committee after my dissertation is out the door (2
> more weeks!).
> > 
> > I see only one real way to change the situation -- standardize all
> > widely used extensions and declare anything new as experimental
> > unless
> > accepted by the Haskell Prime Committee.
> 
> Agreed here.

Great. So I propose to split section "9. GHC Language Features" of the
user manual into "Stable language extensions" and "Experimental
language extensions", move all the recently added extensions into the
latter one, explicitly state in the proposed process that all new
extensions go to the "Experimental" subsection initially and specify
when they go to the "Stable" subsection.


> I think that's what we're trying to do. If you have a good
> specification for GADT type inference, that would help us. :)

I'd personally prefer to mark GADT and TH as experimental. The
difficulties with their standardizing is a sign of immaturity. I regret
about each time I used them in production code.

> 
> Richard
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: Proposal process status

[Richard Eisenberg]

> On Jul 21, 2016, at 2:25 PM, Yuras Shumovich  wrote:
> 
> It is hopeless. Haskell2020 will not include TemplateHaskell, GADTs,
> etc.

Why do you say this? I don't think this is a forgone conclusion. I'd love to 
see these standardized.

My own 2¢ on these are that we can standardize some subset of TemplateHaskell 
quite easily. GADTs are harder because (to my knowledge) no one has ever 
written a specification of type inference for GADTs. (Note that the OutsideIn 
paper admits to failing at this.) Perhaps we can nail it, but perhaps not. Even 
so, we can perhaps standardize much of the behavior around GADTs (but with 
pattern matches requiring lots of type annotations) and say that an 
implementation is free to do better. Maybe we can do even better than this, but 
I doubt we'll totally ignore this issue.

> Haskell Prime committee will never catch up if GHC will continue
> adding new extensions.

Of course not. But I believe some libraries also refrain from using new 
extensions for precisely the same reason -- that the new extensions have yet to 
fully gel.

> In 2020 everybody will use pattern synonyms,
> overloaded record fields and TypeInType, so the standard will be as far
> from practice as it is now.

Pattern synonyms, now with a published paper behind them, may actually be in 
good enough shape to standardize by 2020. I don't know anything about 
overloaded record fields. I'd be shocked if TypeInType is ready to standardize 
by 2020. But hopefully we'll get to it.

> 
> The whole idea of language extensions, as it is right now, works
> against Haskell Prime.

I heartily disagree here. Ideas that are now standard had to have started 
somewhere, and I really like (in theory) the way GHC/Haskell does this.

The (in theory) parenthetical is because the standardization process has been 
too, well, dead to be useful. Is that changing? Perhaps. I'd love to see more 
action on that front. I'm hoping to take on a more active role in the committee 
after my dissertation is out the door (2 more weeks!).
> 
> I see only one real way to change the situation -- standardize all
> widely used extensions and declare anything new as experimental unless
> accepted by the Haskell Prime Committee.

Agreed here. I think that's what we're trying to do. If you have a good 
specification for GADT type inference, that would help us. :)

Richard
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: Proposal process status

[Yuras Shumovich]

On Thu, 2016-07-21 at 13:25 -0400, Richard Eisenberg wrote:
> > 
> > On Jul 21, 2016, at 11:29 AM, Yuras Shumovich  > > wrote:
> > 
> > Unfortunately Haskell *is* implementation-defined language. You
> > can't
> > compile any nontrivial package from Hackage using Haskell2010 GHC.
> 
> Sadly, I agree with this statement. And I think this is what we're
> trying to change.

And I'd like it to be changed too. I'm paid for writing SW in Haskell,
and I want to have a standard. At the same time I'm (probably unusual)
Haskell fan, so I want new cool features. Don't you see a conflict of
interests?
https://www.reddit.com/r/haskell/comments/4oyxo2/blog_contributing_to_ghc/d4iaz5t

> 
> > And
> > the same will be true for Haskell2020. We rely on GHC-specific
> > extensions everywhere, directly or indirectly. If the goal of the
> > Haskell Prime is to change that, then the GHC-specific extensions
> > should not be first class citizens in the ecosystem.
> 
> My hope is that Haskell2020 will allow us to differentiate between
> standardized extensions and implementation-defined ones. A key part
> of this hope is that we'll get enough extensions in the first set to
> allow a sizeable portion of our ecosystem to used only standardized
> extensions.

It is hopeless. Haskell2020 will not include TemplateHaskell, GADTs,
etc. Haskell Prime committee will never catch up if GHC will continue
adding new extensions. In 2020 everybody will use pattern synonyms,
overloaded record fields and TypeInType, so the standard will be as far
from practice as it is now.

The whole idea of language extensions, as it is right now, works
against Haskell Prime.
https://www.reddit.com/r/haskell/comments/46jq4i/what_is_the_eventual_fate_of_all_of_these_ghc/d05q9no

I abandoned my CStructures proposal because of that. I don't want to
increase entropy.
https://phabricator.haskell.org/D252

> > 
> > We can continue pretending that Haskell is standard-defined
> > language,
> > but it will not help to change the situation. 
> 
> But writing a new standard that encompasses prevalent usage will help
> to change the situation. And that's the process I'm hoping to
> contribute to.

I see only one real way to change the situation -- standardize all
widely used extensions and declare anything new as experimental unless
accepted by the Haskell Prime Committee. Probably there are other ways,
but we need to cleanup the mess ASAP. New extensions only contribute to
the mess -- that is my point.

> 
> Richard
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: Proposal process status

[Richard Eisenberg]

> On Jul 21, 2016, at 11:29 AM, Yuras Shumovich  wrote:
> 
> Unfortunately Haskell *is* implementation-defined language. You can't
> compile any nontrivial package from Hackage using Haskell2010 GHC.

Sadly, I agree with this statement. And I think this is what we're trying to 
change.

> And
> the same will be true for Haskell2020. We rely on GHC-specific
> extensions everywhere, directly or indirectly. If the goal of the
> Haskell Prime is to change that, then the GHC-specific extensions
> should not be first class citizens in the ecosystem.

My hope is that Haskell2020 will allow us to differentiate between standardized 
extensions and implementation-defined ones. A key part of this hope is that 
we'll get enough extensions in the first set to allow a sizeable portion of our 
ecosystem to used only standardized extensions.
> 
> We can continue pretending that Haskell is standard-defined language,
> but it will not help to change the situation. 

But writing a new standard that encompasses prevalent usage will help to change 
the situation. And that's the process I'm hoping to contribute to.

Richard
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: Proposal process status

[Yuras Shumovich]

On Thu, 2016-07-21 at 10:32 -0400, Gershom B wrote:
> On July 21, 2016 at 8:51:15 AM, Yuras Shumovich (shumovi...@gmail.com
> ) wrote:
> > 
> > I think it is what the process should change. It makes sense to
> > have
> > two committees only if we have multiple language implementations,
> > but
> > it is not the case. Prime committee may accept or reject e.g.
> > GADTs,
> > but it will change nothing because people will continue using GADTs
> > regardless, and any feature accepted by the Prime committee will
> > necessary be compatible with GADTs extension.
> 
> I disagree. By the stated goals of the H2020 Committee, if it is
> successful, then by 2020 it will still for the most part have only
> standardized ony a _portion_ of the extentions that now exist today.

Yes, I know. But don't you see how narrow the responsibility of the
H2020 Committee is? GHC Committee makes all important decisions, and
H2020 just collects some of GHC extensions into a set of "standard"
ones. It is useful only when "nonstandard" extensions are not widely
used (e.g. marked as experimental, and are not recommended for day-to-
day use).

> 
> There’s always been a barrier between implementation and standard in
> the Haskell language, that’s precisely one of the things that _keeps_
> it from having become entirely implementation-defined despite the
> prevelance of extensions.

Unfortunately Haskell *is* implementation-defined language. You can't
compile any nontrivial package from Hackage using Haskell2010 GHC. And
the same will be true for Haskell2020. We rely on GHC-specific
extensions everywhere, directly or indirectly. If the goal of the
Haskell Prime is to change that, then the GHC-specific extensions
should not be first class citizens in the ecosystem. Otherwise there is
no sense in two committees.

We can continue pretending that Haskell is standard-defined language,
but it will not help to change the situation. 

> 
> Having two entirely different processes here (though obviously not
> without communication between the individuals involved) helps
> maintain that.
> 
> —Gershom
> 
> 
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: Proposal process status

[Richard Eisenberg]

> On Jul 21, 2016, at 10:32 AM, Gershom B  wrote:
> 
> On July 21, 2016 at 8:51:15 AM, Yuras Shumovich (shumovi...@gmail.com) wrote:
>> 
>> It makes sense to have
>> two committees only if we have multiple language implementations, but
>> it is not the case. 

> I disagree. By the stated goals of the H2020 Committee, if it is successful, 
> then by 2020 it will still for the most part have only standardized ony a 
> _portion_ of the extentions that now exist today.

+1 to Gershom's comment.
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: Proposal process status

[Gershom B]

On July 21, 2016 at 8:51:15 AM, Yuras Shumovich (shumovi...@gmail.com) wrote:
>
> I think it is what the process should change. It makes sense to have
> two committees only if we have multiple language implementations, but
> it is not the case. Prime committee may accept or reject e.g. GADTs,
> but it will change nothing because people will continue using GADTs
> regardless, and any feature accepted by the Prime committee will
> necessary be compatible with GADTs extension.

I disagree. By the stated goals of the H2020 Committee, if it is successful, 
then by 2020 it will still for the most part have only standardized ony a 
_portion_ of the extentions that now exist today.

There’s always been a barrier between implementation and standard in the 
Haskell language, that’s precisely one of the things that _keeps_ it from 
having become entirely implementation-defined despite the prevelance of 
extensions.

Having two entirely different processes here (though obviously not without 
communication between the individuals involved) helps maintain that.

—Gershom


___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: Proposal process status

[Alexander Berntsen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

I'm replying to this to clarify that I object to GitHub in order to
have a clear conscience, not because I think GitHub is a "bad tool".
Attempting to shoot down my arguments against GitHub with arguments
for convenience or it being a "a good tool", or popular, or whatever,
do not work. To me, GitHub is not even an alternative to begin with.
Of course, I don't expect most (or even any) devs here to agree with
my position, but I wanted to elucidate it nonetheless, so that you may
understand it better.

On 21/07/16 10:59, Sven Panne wrote:
> like it or not, the Haskell community already relies *heavily* on 
> GitHub, and it seems that most people don't have a problem with 
> that or consider the alternatives inferior.
Just because other people are doing The Wrong Thing, it does not mean
that you need to do it too, nor does it excuse your doing it.

> And I don't understand the point about "proprietary client-side 
> JavaScript" at all: Should we stop using 99% of the Internet 
> because some server sends us some JavaScript we have no license 
> for?
If you value your freedom: yes. It's proprietary software executed on
your computer, just like any other proprietary software executed on your
computer[0].

> And what about all those routers/switches/etc. in between which 
> connect you to the rest of the world: They definitely run 
> proprietary SW, and nobody cares (for a good reason).
Those do not execute proprietary software on your computer, so that's
not comparable.

> Don't get me wrong: I'm very much for Open Source, but let's not
> go over the top here. Let's use a tool basically everybody knows
> and focus on the content, not on the technology.
I am not in favour of open source at all, I am in favour of free
software. The issue is ethical, not technological, and saying "let's not
go over the top" does not make sense to me, as it is an ethical
position.


[0]  
- -- 
Alexander
alexan...@plaimi.net
https://secure.plaimi.net/~alexander
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCgAGBQJXkM5KAAoJENQqWdRUGk8BncsP/24efH2arxRIriK0YankfO9W
D1OT1Vfh4AtMfcBDV0dutMpLWcrllUcd/pvR2cR9uJTbA6t33LfQmhv6clqsHZ97
ZLQ7CoerfLNxCUA8i+H00YSz9JKMvGMpRJhFM/VAn1oF3OMpakCB9ZjeXXf/uwAT
LVYWh/HCHRULOMnnQZe2N7IrcxUwuw+/Iy0163zWkeMVlOwmVNYj/mMFNfIuZCcK
6hxUMqNQkhL7Ipm2SSGIvZONboYsFQG7dwmAQH/A1Sj6U3oV0lmKF9Nf2gjhZq6+
FEtEDjQzMrIKtMOX0mNKuYc6i6f5N+LTMfsFddJkITMWkqkwOjbAtgStv/i6wFb7
43SIoYcFMivQ980miy3VVLVdkiFlx5/1wxz1YRaM+ieA9oF2Nl0wVU/+6mLFIUaL
q1cyI+o9lywTaMr8zPzr5jSm1BNthQCgwsn4zdno7VCjbzmlsKcX9X6qMPlyAIRn
AnvNhe36z2gCJzz75sqJKMmAiJKIa4bYo2/a/uB2aO1LPWrVHxgUiusQ1sGr7gB5
oCIsWyLg9u5alnv/nGKzCbtnvnn2VxRnMiRtywZXN5H7HKiMpBKjBeYt+B9udrKu
WFtwWQSPM5UjTbjp5tIEZEu9BlrSGPfO+rfCRrj6IWQIAchqfs8x1OADxX3z92UJ
VuJe9cRAtRGtL3/CAM/K
=d4lZ
-END PGP SIGNATURE-
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: Proposal process status

[Yuras Shumovich]

On Wed, 2016-07-20 at 18:37 +0200, Ben Gamari wrote:
> Yuras Shumovich  writes:
> 
> > Looks like reddit is a wrong place, so I'm replicating my comment
> > here:
> > 
> Thanks for your comments Yuras!
> 
> > >   * Do you feel the proposed process is an improvement over the
> > > status quo?
> > 
> > Yes, definitely. The existing process is too vague, so formalizing
> > it
> > is a win in any case.
> > 
> Good to hear.
> 
> > >   * What would you like to see changed in the proposed process,
> > > if
> > > anything?
> > 
> > The proposed process overlaps with the Language Committee powers.
> > In
> > theory the Committee works on language standard, but de facto
> > Haskell
> > is GHC/Haskell and GHC/Haskell is Haskell. Adding new extension to
> > GHC
> > adds new extension to Haskell. So I'd like the process to enforce
> > separation between experimental extensions (not recommended in
> > production code) and language improvements. I'd like the process to
> > specify how the GHC Committee is going to communicate and share
> > powers
> > with the Language Committee.
> > 
> To clarify I think Language Committee here refers to the Haskell
> Prime
> committee, right?

Yes, Herbert used "Haskell Prime 2020 committee" and "Haskell Language
committee" interchangeable in the original announcement https://mail.ha
skell.org/pipermail/haskell-prime/2016-April/004050.html

> 
> I think these two bodies really do serve different purposes.
> Historically the Haskell Prime committee has been quite conservative
> in
> the sorts of changes that they standardized; as far as I know almost
> all
> of them come from a compiler. I would imagine that the GHC Committee
> would be a gate-keeper for proposals entering GHC and only some time
> later, when the semantics and utility of the extension are
> well-understood, would the Haskell Prime committee consider
> introducing
> it to the Report. As far as I understand it, this is historically how
> things have worked in the past, and I don't think this new process
> would
> change that.

I think it is what the process should change. It makes sense to have
two committees only if we have multiple language implementations, but
it is not the case. Prime committee may accept or reject e.g. GADTs,
but it will change nothing because people will continue using GADTs
regardless, and any feature accepted by the Prime committee will
necessary be compatible with GADTs extension.

The difference between standard and GHC-specific extensions is just a
question of formal specification, interesting mostly for language
lawyer. (But it is good to have such formal specification even for GHC-
specific extensions, right?)

Probably it is time to return -fglasgow-exts back to separate standard
feature from experimental GHC-specific ones.

> 
> Of course, let me know if I'm off-base here.
> 
> Cheers,
> 
> - Ben
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: Proposal process status

[Sven Panne]

2016-07-20 23:16 GMT+02:00 Adam Foltzer :

> [...] 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.
>

+1 for that. Just to give a few numbers, just gathered from Hackage by some
grep/sed/wc "technology": 6799 of the 9946 packages (i.e. 68%) use GitHub.
The numbers are even higher when one considers the top 100 downloaded
packages only: 92% of them use GitHub. So like it or not, the Haskell
community already relies *heavily* on GitHub, and it seems that most people
don't have a problem with that or consider the alternatives inferior.

As Ben already said, using some proprietary SW is no real problem as long
as you can get all your data out of it (in a non-proprietary format). And I
don't understand the point about "proprietary client-side JavaScript" at
all: Should we stop using 99% of the Internet because some server sends us
some JavaScript we have no license for? And what about all those
routers/switches/etc. in between which connect you to the rest of the
world: They definitely run proprietary SW, and nobody cares (for a good
reason).

Don't get me wrong: I'm very much for Open Source, but let's not go over
the top here. Let's use a tool basically everybody knows and focus on the
content, not on the technology.
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users