Re: Chairship / responsibility

[wren romano]

> Hi Prime,
>
> Is there a chair of this committee? Herbert has been acting as such (thank 
> you!) but doesn't list himself as the chair in the initial announcement. I am 
> **in no way** trying to change any status quo and am **not** interested in 
> being chair at the moment, but I just wanted to clarify.
>
> The specific reason I ask is that Takenobu Tani recently asked about `pseq`. 
> I have no intelligent response to offer, but would want to make sure that 
> someone does offer a response. If there is a chair, that person is de facto 
> responsible that we, as a committee, communicate well, both internally and 
> externally.


I don't know that we have one (officially), but I agree that
getting/agreeing-on one should be done soon.

-- 
Live well,
~wren
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime

Re: Infrastructure & Communication

[wren romano]

On Fri, Apr 29, 2016 at 9:17 AM, Mario Blažević  wrote:
> There are two or three distinct components we need to keep track of: the
> draft standard, discussions, and potentially RFCs.
>
> Discussions can be hosted on this mailing list, on Trac, or as Git
> issues. Each of them would serve fine, but we should choose exactly one and
> stick to it. The mailing list looks pretty good in isolation, but the best
> choice depends on whether we want to have RFCs or not.
>
> If we support Requests for Comments, we'll need to also support their
> public submissions and Git pull requests or something to the same effect. In
> that case, at least the inevitable comments on RFCs would best be placed
> close to the RFCs themselves - if the RFCs end up on GitHub the discussions
> of them should be kept as GitHub issues.

I agree with all of this, and think this distinction should be kept in
mind in terms of keeping things organized to whatever tools we choose.

For general discussions I think this mailing list is best. I'm cool
for keeping irc as a side channel for hashing things out more
interactively, but it's all to easy to miss things there so I think
it's best kept as a side channel not a main one.

I like (something like) GitHub issues for tracking the exact content
of proposed changes and their (direct) commentary. As far as the
particular tool I'm mostly agnostic, but lean slightly towards github
over trac. I've never used phabricator so can't say there (though I'm
slightly against, as it'd be another tool to learn.)

As far as wiki stuff goes, to be honest I'm kinda against it. I see
how it might could be helpful as a sort of staging ground prior to
actual RFCs, or as an edited synopsis of email discussion; but in my
experience the wiki proposals for Haskell changes tend to get very
crufty and hard to follow after a few changes have been made. I think
I'd rather see specific versioning on proposals, so it can be clear
when/which parts of the proposal are retracted, amended, etc. This may
very well be a reason to prefer github, since such development can
happen in branches where we can see the iteration of changes prior to
merging a specific one into the master branch.

/me goes off to read about how Fsharp, Rust, and Go do things

-- 
Live well,
~wren
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime

Re: Evaluation order control between two expressions

[Cale Gibbard]

Well, the value of par x y is identical to that of y, so any expression
which you could use to semantically distinguish pseq from seq using par
could be rewritten into one which did so without involving par.

If the way in which we're telling programs apart involves performance
characteristics then it may already be possible to distinguish seq from
pseq. It somewhat comes down to whether the implementation of the language
is clever enough to notice when compiling seq x y any cases where it might
be better to finish evaluating y first and simply evaluate x before making
the result of that first evaluation available. GHC does do this
rearranging, so probably someone can come up with a good example there.
On Apr 29, 2016 5:38 PM, "José Manuel Calderón Trilla"  wrote:

> Hello Takenobu,
>
> Great question, this is actually a pretty interesting issue! It isn't
> out of scope at all.
>
> The first thing to think about is the following thought experiment:
>
> Without the presence of side-effects, how can you tell the difference
> between a `seq` that conforms to the Haskell report and one that
> evaluates it's first argument before its second?
>
> If your answer involves `unsafePerformIO` then you're cheating ;)
>
> Even if your first argument to `seq` is an IO action it won't get
> executed because `seq` only evaluates to WHNF. It might be possible to
> construct a program that allows you to observe the difference, but in
> the general case I don't see how you could. I'd be very interested to
> be shown otherwise though!
>
> Now in a parallel program things change. When we use `pseq` it's
> because we don't want two threads to collide when trying to evaluate
> the same expression. Let's look at an example:
>
> x `par` y `seq` x + y
>
> As you noted, the semantics of `seq` doesn't actually guarantee that
> `y` will be evaluated before `x + y`. But this only matters because
> we've used `par` and introduced threads (via an effect!) and therefore
> the possibility of collision. We can avoid this by using `pseq`
> instead.
>
> So, both `seq` and `pseq` both allow the programmer to express
> *operational* concerns, `seq` is used mostly to eliminate/manage space
> leaks, and `pseq` is used to specify order of evaluation. Those
> concerns sometimes overlap, but they are different!
>
> It could be argued (and I would agree) that `seq` is a bad name; a
> better name might have been something like `synch` [1]. That being
> said, unless we add parallelism to the standard (and even then) I am
> not sure it would be wise to change the operational behavior of `seq`.
> It's current behavior is well established, and if you're writing
> sequential Haskell code where order of evaluation matters, it's
> probably better to reach for a different tool (IMO). However, if
> parallelism is introduced then I'd fight for `pseq` to be part of that
> (as you suggest).
>
> I hope that sheds some light on the issue.
>
> Cheers,
>
> Jose
>
> [1]: John Hughes introduced a `synch` combinator in his thesis, but it
> had very different semantics, so maybe that's a reason it was avoided?
> Someone with more knowledge of the history can probably shed more
> light on this.
>
>
> On Thu, Apr 28, 2016 at 6:56 PM, Takenobu Tani 
> wrote:
> > Dear Community,
> >
> > Apologies if I'm missing context.
> >
> > Does Haskell 2020 specify evaluation order control by `pseq`?
> >
> > We use `pseq` to guarantee the evaluation order between two expressions.
> > But Haskell 2010 did not specify how to control the evaluation order
> between
> > two expressions.
> > (only specified `seq` in Haskell 2010 section 6.2 [1]. but `seq` don't
> > guarantee the order. [2])
> >
> > I think it's better to explicitly specify `pseq` as standard way.
> >
> > Already discussed? or out of scope?
> >
> > [1]:
> >
> https://www.haskell.org/onlinereport/haskell2010/haskellch6.html#x13-1260006.2
> > [2]:
> >
> https://www.schoolofhaskell.com/user/snoyberg/general-haskell/advanced/evaluation-order-and-state-tokens
> >
> > Regards,
> > Takenobu
> >
> >
> > ___
> > Haskell-prime mailing list
> > Haskell-prime@haskell.org
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
> >
> ___
> Haskell-prime mailing list
> Haskell-prime@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
>
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime

Re: Evaluation order control between two expressions

[José Manuel Calderón Trilla]

Hello Takenobu,

Great question, this is actually a pretty interesting issue! It isn't
out of scope at all.

The first thing to think about is the following thought experiment:

Without the presence of side-effects, how can you tell the difference
between a `seq` that conforms to the Haskell report and one that
evaluates it's first argument before its second?

If your answer involves `unsafePerformIO` then you're cheating ;)

Even if your first argument to `seq` is an IO action it won't get
executed because `seq` only evaluates to WHNF. It might be possible to
construct a program that allows you to observe the difference, but in
the general case I don't see how you could. I'd be very interested to
be shown otherwise though!

Now in a parallel program things change. When we use `pseq` it's
because we don't want two threads to collide when trying to evaluate
the same expression. Let's look at an example:

x `par` y `seq` x + y

As you noted, the semantics of `seq` doesn't actually guarantee that
`y` will be evaluated before `x + y`. But this only matters because
we've used `par` and introduced threads (via an effect!) and therefore
the possibility of collision. We can avoid this by using `pseq`
instead.

So, both `seq` and `pseq` both allow the programmer to express
*operational* concerns, `seq` is used mostly to eliminate/manage space
leaks, and `pseq` is used to specify order of evaluation. Those
concerns sometimes overlap, but they are different!

It could be argued (and I would agree) that `seq` is a bad name; a
better name might have been something like `synch` [1]. That being
said, unless we add parallelism to the standard (and even then) I am
not sure it would be wise to change the operational behavior of `seq`.
It's current behavior is well established, and if you're writing
sequential Haskell code where order of evaluation matters, it's
probably better to reach for a different tool (IMO). However, if
parallelism is introduced then I'd fight for `pseq` to be part of that
(as you suggest).

I hope that sheds some light on the issue.

Cheers,

Jose

[1]: John Hughes introduced a `synch` combinator in his thesis, but it
had very different semantics, so maybe that's a reason it was avoided?
Someone with more knowledge of the history can probably shed more
light on this.


On Thu, Apr 28, 2016 at 6:56 PM, Takenobu Tani  wrote:
> Dear Community,
>
> Apologies if I'm missing context.
>
> Does Haskell 2020 specify evaluation order control by `pseq`?
>
> We use `pseq` to guarantee the evaluation order between two expressions.
> But Haskell 2010 did not specify how to control the evaluation order between
> two expressions.
> (only specified `seq` in Haskell 2010 section 6.2 [1]. but `seq` don't
> guarantee the order. [2])
>
> I think it's better to explicitly specify `pseq` as standard way.
>
> Already discussed? or out of scope?
>
> [1]:
> https://www.haskell.org/onlinereport/haskell2010/haskellch6.html#x13-1260006.2
> [2]:
> https://www.schoolofhaskell.com/user/snoyberg/general-haskell/advanced/evaluation-order-and-state-tokens
>
> Regards,
> Takenobu
>
>
> ___
> Haskell-prime mailing list
> Haskell-prime@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
>
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime

Re: Infrastructure & Communication

[Richard Eisenberg]

I think the general interplay between mailing lists / wiki pages / Trac issues 
that GHC uses works well. Specifically:

- Mailing list for routine communication.
- Trac tickets / Git issues / Phab something-or-other for discussion on a 
specific proposal.
- Wiki page to present a specific proposal.

Wiki pages and tickets are therefore often linked together, and sometimes a 
conversation has to move from the mailing list to a ticket (though rarely the 
other way around).

I specifically vote against using the mailing list to debate well-defined 
issues that need to be resolved, as it's far too easy to lose signal in the 
noise and hard to see the thread all in one place.

I'm personally agnostic about the decision between Trac/Github/Phab.

Richard

On Apr 29, 2016, at 9:17 AM, Mario Blažević  wrote:

> On 04/29/2016 07:15 AM, Francesco Ariis wrote:
>> Hello,
>> personally I would be more likely to read/participate in the
>> discussions if such discussions were hosted here or on Trac rather
>> than Github.
> 
>There are two or three distinct components we need to keep track of: the 
> draft standard, discussions, and potentially RFCs.
> 
>Discussions can be hosted on this mailing list, on Trac, or as Git issues. 
> Each of them would serve fine, but we should choose exactly one and stick to 
> it. The mailing list looks pretty good in isolation, but the best choice 
> depends on whether we want to have RFCs or not.
> 
>If we support Requests for Comments, we'll need to also support their 
> public submissions and Git pull requests or something to the same effect. In 
> that case, at least the inevitable comments on RFCs would best be placed 
> close to the RFCs themselves - if the RFCs end up on GitHub the discussions 
> of them should be kept as GitHub issues.
> 
> ___
> Haskell-prime mailing list
> Haskell-prime@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime

___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime

Chairship / responsibility

[Richard Eisenberg]

Hi Prime,

Is there a chair of this committee? Herbert has been acting as such (thank 
you!) but doesn't list himself as the chair in the initial announcement. I am 
**in no way** trying to change any status quo and am **not** interested in 
being chair at the moment, but I just wanted to clarify.

The specific reason I ask is that Takenobu Tani recently asked about `pseq`. I 
have no intelligent response to offer, but would want to make sure that someone 
does offer a response. If there is a chair, that person is de facto responsible 
that we, as a committee, communicate well, both internally and externally.

Thanks,
Richard
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime

Re: Infrastructure & Communication

[Mario Blažević]

On 04/29/2016 07:15 AM, Francesco Ariis wrote:

Hello,
 personally I would be more likely to read/participate in the
discussions if such discussions were hosted here or on Trac rather
than Github.


There are two or three distinct components we need to keep track 
of: the draft standard, discussions, and potentially RFCs.


Discussions can be hosted on this mailing list, on Trac, or as Git 
issues. Each of them would serve fine, but we should choose exactly one 
and stick to it. The mailing list looks pretty good in isolation, but 
the best choice depends on whether we want to have RFCs or not.


If we support Requests for Comments, we'll need to also support 
their public submissions and Git pull requests or something to the same 
effect. In that case, at least the inevitable comments on RFCs would 
best be placed close to the RFCs themselves - if the RFCs end up on 
GitHub the discussions of them should be kept as GitHub issues.


___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime

Re: Infrastructure & Communication

[Carter Schonwald]

Or a phabricator instance ? That might also make sense.

On Friday, April 29, 2016, Francesco Ariis  wrote:

> On Thu, Apr 28, 2016 at 11:56:51PM +0200, Herbert Valerio Riedel wrote:
> > One benefit I see from using GitHub is that this way would we be closer
> > to the Haskell community (given the majority of Hackage packages are
> > hosted on GitHub), and our work would be more transparent for the
> > community as well as offering a lower barrier to
> > participation/contribution.
> >
> > Moreover, I think GitHub would also help make our efforts/progress
> > towards a revised Haskell Report more visible to the community, which in
> > turn may even provide us the motivation to carry on...
>
> Hello,
> personally I would be more likely to read/participate in the
> discussions if such discussions were hosted here or on Trac rather
> than Github.
> haskell-prime@ is just one 'subscribe' away, comes in a familiar package
> to haskell-cafe@ participants (a mailing list) and interface (their mail
> client); I cannot say the same about Github.
> Similarly, Trac allows me to follow new issues (new tickets notifications
> or the life of a single ticket in particular) via rss, without having to
> register to a new service.
>
> Of course:
> 1. this is just my experience -- there are many haskell
>developers on Github and they probably like the workflow
>there (I would still say the haskell-cafe@ audience is bigger
>though).
> 2. I am not a committee member. In the end it's them who are going
>to pour blood/sweat/tears in the report; whichever tool the
>committee chooses is the right one
>
>
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime

Re: Infrastructure & Communication

[Francesco Ariis]

On Thu, Apr 28, 2016 at 11:56:51PM +0200, Herbert Valerio Riedel wrote:
> One benefit I see from using GitHub is that this way would we be closer
> to the Haskell community (given the majority of Hackage packages are
> hosted on GitHub), and our work would be more transparent for the
> community as well as offering a lower barrier to
> participation/contribution.
> 
> Moreover, I think GitHub would also help make our efforts/progress
> towards a revised Haskell Report more visible to the community, which in
> turn may even provide us the motivation to carry on...

Hello,
personally I would be more likely to read/participate in the
discussions if such discussions were hosted here or on Trac rather
than Github.
haskell-prime@ is just one 'subscribe' away, comes in a familiar package
to haskell-cafe@ participants (a mailing list) and interface (their mail
client); I cannot say the same about Github.
Similarly, Trac allows me to follow new issues (new tickets notifications
or the life of a single ticket in particular) via rss, without having to
register to a new service.

Of course:
1. this is just my experience -- there are many haskell
   developers on Github and they probably like the workflow
   there (I would still say the haskell-cafe@ audience is bigger
   though).
2. I am not a committee member. In the end it's them who are going
   to pour blood/sweat/tears in the report; whichever tool the
   committee chooses is the right one



signature.asc
Description: Digital signature
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime

Re: Infrastructure & Communication

[Audrey Tang]

> On Apr 29, 2016, at 5:25 PM, Alexander Berntsen  wrote:
> especially not SaaSS which theoretically can just get rid of all your data 
> without you having a say.

There is a fix for that — Sandstorm.io  (self-hosted, 
not SaaSS) with download-all-data-at-any-time options such as Gogs on Sandstorm 
.
 

Personally I use it as a secondary storage to public github repositories, and 
primary storage for personal projects.

Cheers,
Audrey___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime

Re: Infrastructure & Communication

[Andres Loeh]

Hi.

I'm ok with the general proposals made by Herbert. I'm not a huge fan
of github myself, but it seems like the most pragmatic choice right
now, and I wouldn't know anything else that is clearly better, so I'm
in favour. I'd somewhat prefer to have everything (wiki etc) in one
place then, but I don't have strong opinions on this topic.

Cheers,
  Andres
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime