RE: A question about run-time errors when class members are undefined

[Simon Peyton Jones via Haskell-prime]

Anthony

You may be interested in Carlos Camarao’s interesting work.  For a long time 
now he has advocated (in effect) making each function into its own type class, 
rather that grouping them into classes.   Perhaps that is in line with your 
thinking.
https://homepages.dcc.ufmg.br/~camarao/

Simon

From: Haskell-prime  On Behalf Of Anthony 
Clayden
Sent: 06 October 2018 04:19
To: Petr Pudlák 
Cc: haskell-prime@haskell.org
Subject: Re: A question about run-time errors when class members are undefined


On Sat, 6 Oct 2018 at 9:47 AM, Petr Pudlák 
mailto:redir...@vodafone.co.nz>> wrote:

IIRC one of the arguments against having many separate classes is that a class 
is not a just set of methods, it's also the relations between them,

Hi Petr, I was talking about splitting out Haskell's current class hierarchy as 
a step towards doing away with classes altogether. If your language insists on 
methods being held in classes, that's just tedious bureacracy to invent class 
names.

The relations between classes (including between single-method classes) can be 
captured through superclass constraints. For example, in the Haskell 2010 report

class (Eq a, Show a) => Num a where ...

such as the important laws between `return` and `>>=`. And then for example a 
class with just `return` doesn't give any information what `return x` means or 
what should be its properties.

Then make Bind a superclass constraint on `return` (or vice versa, or both 
ways).

Just as the laws for Num's methods are defined in terms of equality

x + negate x == fromInteger 0  -- for example

Talking about laws is a red herring: you can't declare the laws/the compiler 
doesn't enforce them or rely on them in any way. Indeed the Lensaholics seem to 
take pleasure in building lenses that break the (van Laarhoven) laws.



That said, one of really painful points of Haskell is that refactoring a 
hierarchy of type-classes means breaking all the code that implements them. 
This was also one of the main reasons why reason making Applicative a 
superclass of Monad took so long. It'd be much nicer to design type-classes in 
such a way that an implementation doesn't have to really care about the exact 
hierarchy.

Yes that's what I was saying. Unfortunately for Haskell's Num class, I think 
it's just too hard. So a new language has an opportunity to avoid that. If OTOH 
Helium wants to slavishly follow Haskell, I'm wondering what is the point of 
Helium.

With Applicative, IIRC, refactoring had to wait until we got Constraint kinds 
and type families that could produce them. Would Helium want to put all that 
into a language aimed at beginners?


 For example, in Haskell we could have

class (Return m, Bind m) => Monad m where

without any methods specified. But instances of `Monad` should be only such 
types for which `return` and `>>=` satisfy the monad laws.

First: what does "satisfy the xxx laws" mean? The Haskell report and GHC's 
Prelude documentation state a bunch of laws; and it's a good discipline to 
write down laws if you're creating a class; but it's only documentation. 
Arguably IO, the most commonly used Monad, breaks the Monad laws in rather 
serious ways because it imposes sequence of execution; and it would be unfit 
for purpose if it were pure/lazy function application.

Then: what do you think a language could do to detect if some instance 
satisfies the laws? (Even supposing you could declare them.)


And this would distinguish them from types that have both `Return` and `Bind` 
instances, but don't satisfy the laws.

You could have distinct classes/distinct operators. Oh, but then `do` dotation 
would break.


Unfortunately I'm not sure if there is a good solution for achieving both these 
directions.

I don't think there's any solution for achieving "satisfy the xxx laws".


AntC


čt 4. 10. 2018 v 3:56 odesílatel Anthony Clayden 
mailto:anthony_clay...@clear.net.nz>> napsal:
> We are adding classes and instances to Helium.

> We wondered about the aspect that it is allowed to have a class instance

> of which not all fields have a piece of code/value associated with them, ...



I have a suggestion for that. But first let me understand where you're going 
with Helium. Are you aiming to slavishly reproduce Haskell's classes/instances, 
or is this a chance for a rethink?



Will you want to include associated types and associated datatypes in the 
classes? Note those are just syntactic sugar for top-level type families and 
data families. It does aid readability to put them within the class.



I would certainly rethink the current grouping of methods into classes. Number 
purists have long wanted to split class Num into Additive vs Multiplicative. 
(Additive would be a superclass of Multiplicative.) For the Naturals perhaps we 
want Presburger arithmetic then Additive just contains (+), with `negate` 
certainly in a different class, perhaps (-) subtract also in a dedicated class. 
Also there's people wanting Monads wit

RE: Quo vadis?

[Simon Peyton Jones via Haskell-prime]

|  That sounds like we're stuck with the committee we have. In that case,
|  Simon, could you at least pull some strings to have the actual Haskell
|  Report placed in the same repository?

Sounds like a good plan.  If the haskell-prime committee agreed to do this, and 
it's only a matter of doing it, then you just need someone with commit rights 
to the relevant repository. I don't know who that is (it certainly isn't me), 
but if you make them a PR, and ping them by email, it would be easy for them to 
execute.

Simon


|  -Original Message-
|  From: Mario Blažević 
|  Sent: 08 October 2018 02:52
|  To: Simon Peyton Jones ; haskell-prime@haskell.org
|  Subject: Re: Quo vadis?
|  
|  On 2018-10-05 01:05 PM, Simon Peyton Jones wrote:
|  > I think the difficulty has always been in finding enough people who
|  > are
|  >
|  > * Well-informed and well-qualified
|  > * Willing to spend the time to standardise language features
|  >
|  > GHC does not help the situation: it's a de-facto standard, which
|  reduces the incentives to spend time in standardisation.
|  >
|  > I don’t think we should blame anyone for not wanting to invest this
|  time -- no shame here.  It is a very significant commitment, as I know
|  from editing the Haskell 98 report and the incentives are weak.  Because
|  of that, I am not very optimistic about finding such a group -- we have
|  been abortively trying for several years.
|  
|  
|  That sounds like we're stuck with the committee we have. In that case,
|  Simon, could you at least pull some strings to have the actual Haskell
|  Report placed in the same repository? This is a basic precondition if we
|  expect individual efforts to accomplish anything. The minimal steps to
|  actually updating the Haskell Report are:
|  
|  1. write an RFC (we have some already),
|  2. have it provisionally accepted (not entirely clear how - would
|      "no negative votes in 4 weeks" count?), 3. add the modification to
|  the Haskell Report to the RFC, 4. receive the final approval, 5. merge
|  the RFC into the report.
|  
|  Steps #3 and #5 depend on having the report in the same repository with
|  the RFCs. This has been agreed over a year ago:
|  
|  https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.has
|  kell.org%2Fpipermail%2Fhaskell-prime%2F2017-
|  September%2F004319.html&data=02%7C01%7Csimonpj%40microsoft.com%7C227f
|  843099c5489509da08d62cc0a25f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7
|  C636745603204766102&sdata=z3meiZAXQoKzsiOzPAjicdzLbL2vRp0NPgIsUFM2h%2
|  FY%3D&reserved=0
|  https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.has
|  kell.org%2Fpipermail%2Fhaskell-prime%2F2017-
|  October%2Fthread.html&data=02%7C01%7Csimonpj%40microsoft.com%7C227f84
|  3099c5489509da08d62cc0a25f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6
|  36745603204766102&sdata=ilw5EXJyblsVyqs3e7iczbTpG3TexjNY7nmSokMJFvM%3
|  D&reserved=0
|  https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.has
|  kell.org%2Fpipermail%2Fhaskell-prime%2F2017-
|  November%2Fthread.html&data=02%7C01%7Csimonpj%40microsoft.com%7C227f8
|  43099c5489509da08d62cc0a25f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C
|  636745603204766102&sdata=T5zS7b9Swyn%2FWPW8Yqt9XTOf38KSqYmMkgzglesjAR
|  Y%3D&reserved=0
|  https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.has
|  kell.org%2Fpipermail%2Fhaskell-prime%2F2018-
|  March%2F004356.html&data=02%7C01%7Csimonpj%40microsoft.com%7C227f8430
|  99c5489509da08d62cc0a25f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636
|  745603204766102&sdata=bSimqVnSL0Yp18LhYMJ9LsqnPWT4QmT%2BKpyRwAISbdY%3
|  D&reserved=0
|  
|  
|  > If we want to change that, the first thing is to build a case that
|  greater standardisation is not just an "abstract good" that we all
|  subscribe to, but something whose lack is holding us back.
|  
|  Neither an abstract good nor a good abstraction are something Haskell has
|  ever shied away from. I don't know if you're actually asking for a list
|  of "concrete goods"? To start with, every GHC extension that's added to a
|  standard means:
|  
|  - one less item to type in the ubiquitous {-# LANGUAGE ScaryExtension #-}
|  pragma,
|  - one less item to understand for beginners,
|  - one less item whose necessity must be justified to the team, and
|  - one less item of whose future stability the management needs to be
|  convinced.
|  
|  I could go on.

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

RE: Quo vadis?

[Simon Peyton Jones via Haskell-prime]

I think the difficulty has always been in finding enough people who are

* Well-informed and well-qualified
* Willing to spend the time to standardise language features

GHC does not help the situation: it's a de-facto standard, which reduces the 
incentives to spend time in standardisation.

I don’t think we should blame anyone for not wanting to invest this time -- no 
shame here.  It is a very significant commitment, as I know from editing the 
Haskell 98 report and the incentives are weak.  Because of that, I am not very 
optimistic about finding such a group -- we have been abortively trying for 
several years.

If we want to change that, the first thing is to build a case that greater 
standardisation is not just an "abstract good" that we all subscribe to, but 
something whose lack is holding us back.

Simon

|  -Original Message-
|  From: Haskell-prime  On Behalf Of
|  Mario Blaževic
|  Sent: 05 October 2018 17:47
|  To: haskell-prime@haskell.org
|  Subject: Re: Quo vadis?
|  
|  On 2018-10-05 09:10 AM, Henrik Nilsson wrote:
|  > Hi,
|  >
|  > On 10/05/2018 01:20 PM, Mario Blažević wrote:
|  >>  I hereby propose we formally disband the present Haskell 2020
|  >> committee. Our performance has been so dismal
|  >
|  > It has.
|  >
|  > And I should apologise in particular: I've just had far less time than
|  > I thought over the past year for a variety of reasons.
|  >
|  >> that I feel this is the
|  >> only course of action that gives Haskell 2020 any chance of fruition.
|  >> A new committee could then be formed with some more dedicated
|  membership.
|  >
|  > I'm less convinced about that, though. I believe those who signed up
|  > for H2020 actually are people who believe in the value of an updated
|  > standard and has core expertise to make it happen.
|  
|       Regarding the beliefs, if we really represent the most zealous group
|  of Haskell enthusiasts, I have to say the community is in deep trouble. I
|  have no evidence, but I can only hope you're wrong.
|  
|       As for the expertise, my impression is that *everybody* who self-
|  nominated for the committee got accepted. My own self-nomination e-mail
|  [1] explicitly said that
|  
|  
|  > The main reason I'm applying is because I'm afraid that the commitee
|  > might disband like the previous one. If there are enough members
|  > already, feel free to ignore my nomination.
|  
|  Yet I'm in. This was not a high bar to clear.
|  
|  
|  > I can't see how giving up and forming a new group would speed things
|  > up or even increase the chance of success.
|  
|       I was kinda hoping for a Simon ex machina, where a few universally-
|  accepted members of the community hand-pick a new committee.
|  Alternatively, we could come up with some stricter criteria for the next
|  committee before we disband but that assumes we can even get a quorum.
|  
|       Lest I'm suspected of some Machiavellian plot, let me be clear that
|  I refuse to be a part of the next committee, if my proposal should be
|  accepted. Honestly I feel that all members of the present committee with
|  any sense of shame should recuse themselves as well, but that's not up to
|  me.
|  
|  
|  > Instead, what about focusing on identifying a couple of things that
|  > absolutely would have to be in H2020 to make a new standard
|  > worthwhile, like multi-parameter type classes, possibly GADTs, then
|  > figure out what else is needed to support that (like what Anthony
|  > Clayden sketched), and with that as a basis, find out exactly what
|  > technical problems, if any, are hindering progress?
|  >
|  > If this could be neatly summarized, then we'd actually be in a
|  > position to make some progress.
|  
|       That is much the plan we agreed on over a year ago during ICFP 2018.
|  The activity since then is plain to see.
|  
|  
|  [1]
|  http://mail.haskell.org/pipermail/haskell-prime/2015-
|  September/003939.html
|  
|  ___
|  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 Report 2010: pattern bindings

[Simon Peyton Jones via Haskell-prime]

Thanks Jose.

The other issue I have in mind is that of pattern bindings.  Currently in the 
2010 Haskell Report

  *   The text on the monomorphism 
restriction
 (4.5.5) refers to “simple pattern bindings”.
  *   It claims that a simple pattern binding “is a pattern binding in which 
the pattern consists of a single variable”
  *   You’d expect “simple pattern binding” to be defined in 3.17.1 
Patterns.
  But it isn’t.
  *   Instead, 4.4.3.2 Pattern 
bindings
 explicitly contradicts 4.5.5 by saying “a simple pattern binding has form p=e”.
What a mess!
The simplest way out is probably:

  *   Define “simple pattern binding” to be of form x=e, in 3.17.1.
  *   Fix the first para of 4.4.3.2.
  *   Fix the cross-ref in 4.5.5 to refer to the definition of simple pattern.
Sadly, 4.4.3.2 still is not very well defined.  It’s supposed to say what 
pattern bindings mean, including top-level ones; but it does so by referring to 
3.12 which does not handle top-level bindings.  I’m not sure if this is worth 
fixing.

Simon

From: José Manuel Calderón Trilla 
Sent: 15 March 2018 23:17
To: Simon Peyton Jones ; haskell-prime@haskell.org; 
ghc-d...@haskell.org
Subject: Re: [Haskell] The Haskell Report: who maintains it?

All of us on the Haskell Language Committee have the ability to commit on that 
repo.

I think typos are uncontroversial and I'll happily merge pull requests like 
that.

I think the pull-request you point out suffered from the bystander effect, 
unfortunately. I'll review and merge it now.

If you let me know the typo you'd like fixed I'll make sure that gets done as 
well.

Cheers,
José Manuel



On Thu, Mar 15, 2018, at 6:52 PM, Simon Peyton Jones via Haskell wrote:

Friends



Does anyone know who, if anyone, feels responsible for committing updates to 
the Haskell 2010 Report?



Who even has commit rights?



There’s Frank’s pull request below, and I have another important typo to fix.



Thanks



Simon




From: Frank Steffahn [mailto:notificati...@github.com]
Sent: 11 March 2018 17:03
To: haskell/haskell-report 
Cc: Subscribed 
Subject: [haskell/haskell-report] Fix a typo in: Semantics of Case Expressions, 
Part 3 (s) (#4)



Hi. I noticed this in the Haskell 2010 report, which is an obvious typo / 
mistake. I’m not 100% sure if this is the right branch (or even in general the 
right place) to note this, but I hope it will get fixed ;-)
This seems like it is an artifact of copy-and-pasting from “Semantics of Case 
Expressions, Part 1 (c)” without properly adapting the thing, especially in 
commit bc94554.


You can view, comment on, or merge this pull request online at:

  
https://github.com/haskell/haskell-report/pull/4

Commit Summary

  *   Fix a typo in: Semantics of Case Expressions, Part 3 (s)

File Changes

  *   M 
report/exps.verb
 (1)

Patch Links:

  *   
https://github.com/haskell/haskell-report/pull/4.patch
  *   
https://github.com/haskell/haskell-report/pull/4.diff

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on 
GitHub

The Haskell Report: who maintains it?

[Simon Peyton Jones via Haskell-prime]

Friends

Does anyone know who, if anyone, feels responsible for committing updates to 
the Haskell 2010 Report?

Who even has commit rights?

There’s Frank’s pull request below, and I have another important typo to fix.

Thanks

Simon

From: Frank Steffahn [mailto:notificati...@github.com]
Sent: 11 March 2018 17:03
To: haskell/haskell-report 
Cc: Subscribed 
Subject: [haskell/haskell-report] Fix a typo in: Semantics of Case Expressions, 
Part 3 (s) (#4)


Hi. I noticed this in the Haskell 2010 report, which is an obvious typo / 
mistake. I’m not 100% sure if this is the right branch (or even in general the 
right place) to note this, but I hope it will get fixed ;-)

This seems like it is an artifact of copy-and-pasting from “Semantics of Case 
Expressions, Part 1 (c)” without properly adapting the thing, especially in 
commit 
bc94554.


You can view, comment on, or merge this pull request online at:

  
https://github.com/haskell/haskell-report/pull/4

Commit Summary

  *   Fix a typo in: Semantics of Case Expressions, Part 3 (s)

File Changes

  *   M 
report/exps.verb
 (1)

Patch Links:

  *   
https://github.com/haskell/haskell-report/pull/4.patch
  *   
https://github.com/haskell/haskell-report/pull/4.diff

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on 
GitHub,
 or mute the 
thread.
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime

RE: Remove eq and show from num class

[Simon Peyton Jones via Haskell-prime]

Good summary Herbert.  It'd be great to have it as a page on haskell.org, 
rather than just in soon-lost email.

Simon

| -Original Message-
| From: Haskell-prime [mailto:haskell-prime-boun...@haskell.org] On Behalf
| Of Herbert Valerio Riedel
| Sent: 08 September 2017 09:43
| To: Anthony Clayden 
| Cc: haskell-prime@haskell.org
| Subject: Re: Remove eq and show from num class
| 
| On 2017-09-08 at 09:19:54 +0200, Anthony Clayden wrote:
| 
| [...]
| 
| > If this is to the committee, shouldn't it be on the committee list?
| > (I mean ghc-steering-committee.)
| 
| > Or is there some other committee? I thought the Haskell-prime forum
| > and process was dead/replaced by the github proposals process?
| 
| I can see how the proliferation of committees & github repos may seem
| confusing to casual observers, so let me provide a quick overview which
| hopefully doesn't worsen the confusion... :-)
| 
| ## Haskell Core Library Committee
| 
|  -
| https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwiki.has
| kell.org%2FCore_Libraries_Committee&data=02%7C01%7Csimonpj%40microsoft.co
| m%7Ca13a8633ae3c436a9deb08d4f695bee5%7C72f988bf86f141af91ab2d7cd011db47%7
| C1%7C0%7C636404570444220789&sdata=wQ%2B6bfpKtDPUmnxa54FWVDiq%2F3H7eVfnkGF
| kW4s82Ns%3D&reserved=0
| 
| Basically, the core library committee oversees decisions of what happens
| with core libraries such as `base` which includes the API defined by the
| Haskell library report. However, the Eq/Show=>Num superclass removal
| proposal (),
| however predates the core libraries committee's existence (the CLC was
| originally formed sometime around 2013 to design and manage big changes
| such as the implementation of the Functor/Applicative/Monad proposal --
| for which there was big community support but lack of leadership was
| preventing its implementation).
| 
| Moreover, the CLC together with the Hackage Trustees also maintains the
| https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.c
| om%2Fhaskell%2Fpvp&data=02%7C01%7Csimonpj%40microsoft.com%7Ca13a8633ae3c4
| 36a9deb08d4f695bee5%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63640457
| 0444220789&sdata=uI0uVdaGjBLmNrlUqdrPeO7g6%2B4isWj8w1Qi3CDHIIU%3D&reserve
| d=0 specification which is integral to the way Hackage and the Cabal
| solver interact.
| 
| ## Haskell Language Committee (aka Haskell Prime Committee)
| 
|  - https://mail.haskell.org/pipermail/haskell-prime/2016-
| April/004050.html
| 
| So this committee's incarnation has just been formed last year; it's a
| bit too early to declare it dead.
| 
| ## GHC Steering Committee
| 
|  - https://ghc.haskell.org/trac/ghc/wiki/SteeringCommittee
| 
| This is mostly about user-facing changes to GHC and was created shortly
| after the prime committee's formation was announced. It surely wasn't
| intended to replace the prime committee, but was rather formed as a
| reaction to complaints about GHC's governance, you can read up about its
| intent at
| 
|  - https://ghc.haskell.org/trac/ghc/blog/rethinking-proposals
| 
| Not all changes are even relevant to the Haskell Report (like e.g.
| warning flags); but Report-relevant changes may start their life-cycle as
| GHC extensions to get some empirical field-testing, and if desirable to
| later be promoted to Haskell Prime proposals subject to the Prime
| process.
| 
| ## Other Committees
| 
| For completeness, here's a few other Haskell-related committees and/or
| working-group like processes OTTOMH:
| 
| ### Haskell.org committee
| 
|  -
| https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwiki.has
| kell.org%2FHaskell.org_committee&data=02%7C01%7Csimonpj%40microsoft.com%7
| Ca13a8633ae3c436a9deb08d4f695bee5%7C72f988bf86f141af91ab2d7cd011db47%7C1%
| 7C0%7C636404570444220789&sdata=7yZv2psUaTehR%2FsiCtNY0n1AXzrGcHXrUKoDxeeV
| HyY%3D&reserved=0
| 
| ### The Haskell.org Website Working Group (HWWG)
| 
|  -
| https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.c
| om%2Fndmitchell%2Fhwwg&data=02%7C01%7Csimonpj%40microsoft.com%7Ca13a8633a
| e3c436a9deb08d4f695bee5%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6364
| 04570444220789&sdata=cKoBAcJdILupv2mlkwvHuSCx1lwdwIimCi3%2BTujuSHo%3D&res
| erved=0
| 
| ### Haskell Ecosystem Proposals
| 
|  -
| https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.c
| om%2Fhaskell%2Fecosystem-
| proposals&data=02%7C01%7Csimonpj%40microsoft.com%7Ca13a8633ae3c436a9deb08
| d4f695bee5%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63640457044422078
| 9&sdata=XW3ojdp3kjN8wB%2FhOzeWSi6T2UKYaH2M9u8YaSWzeGQ%3D&reserved=0
| 
| ### Industrial Haskell Group
| 
|  -
| https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Findustry.
| haskell.org&data=02%7C01%7Csimonpj%40microsoft.com%7Ca13a8633ae3c436a9deb
| 08d4f695bee5%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636404570444220
| 789&sdata=tmFLIQlxl%2Bs9HFSS2d6qLV3MKGjjToLDnskN9

RE: Anything happening?

[Simon Peyton Jones via Haskell-prime]

And for our (GHC) part we are moving slowly, partly because it's the summer; 
partly because no technology seems really ideal; and also because we've had 
feedback from only a handful of people, and we're a bit reluctant to commit to 
something new with so little direct endorsement.

Simon

-Original Message-
From: Haskell-prime [mailto:haskell-prime-boun...@haskell.org] On Behalf Of 
José Manuel Calderón Trilla
Sent: 19 July 2016 20:14
To: Michael Walker 
Cc: Haskell Prime 
Subject: Re: Anything happening?

Hello Michael,

We were waiting on the GHC team to settle on a proposal process for their stuff 
so that we could aim to use a similar process and avoid fragmentation.

For those who don't know, GHC HQ just announced their new process
here: https://ghc.haskell.org/trac/ghc/blog/rethinking-proposals and are 
finalising it on the github repo here:
https://github.com/ghc-proposals/ghc-proposals

So pretty soon now we should probably discuss whether we are going to use the 
same process, alter their process, or use a different process altogether. My 
vote would be to mirror their process as much as possible.

Cheers,

José


On Tue, Jul 19, 2016 at 2:08 PM, Michael Walker  wrote:
> Hello,
>
> I haven't seen anything on this mailing list for a little while, is 
> anything going on? Has the process by which proposals will be 
> submitted and worked out been solidified yet?
>
> --
> Michael Walker 
> (https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fwww.b
> arrucadu.co.uk&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7cf9b43
> 1369c1e4152794008d3b008d743%7c72f988bf86f141af91ab2d7cd011db47%7c1&sda
> ta=q6VlRYqOBJ0kpIg0u5xZDBuJBTevEOSsQFrMbOL83a8%3d)
> ___
> Haskell-prime mailing list
> Haskell-prime@haskell.org
> https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.h
> askell.org%2fcgi-bin%2fmailman%2flistinfo%2fhaskell-prime&data=01%7c01
> %7csimonpj%40064d.mgd.microsoft.com%7cf9b431369c1e4152794008d3b008d743
> %7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=K9vwkfQXAFoAx6GX7JvE9a%2
> fonVlnektwJTVsI%2bV%2bVXg%3d
___
Haskell-prime mailing list
Haskell-prime@haskell.org
https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.haskell.org%2fcgi-bin%2fmailman%2flistinfo%2fhaskell-prime&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7cf9b431369c1e4152794008d3b008d743%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=K9vwkfQXAFoAx6GX7JvE9a%2fonVlnektwJTVsI%2bV%2bVXg%3d
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime