Re: Helium II

[Carter Schonwald]

i'm slowly prepping some stuff for ghc and the committee, though i can't
say about the general action. I do think some stuff i've got planned should
make its way in, i cant speak for other folks etc etc

On Fri, Nov 30, 2018 at 5:54 AM Anthony Clayden <
anthony_clay...@clear.net.nz> wrote:

> On *Thu Nov 29 15:00:19 UTC 2018, Doug McIlroy wrote:*
>
> > >* Frankly after you've filtered out all that, I'd be astonished if you**
> have anything left. It seems to be usual practice on Hackage to switch**
> on a swag of LANGUAGE pragmas even if this module isn't using them.*
>
> >>* (MPTCs, FlexibleInstances/Contexts in particular.)*
>
> > A depressing remark, which comes close to saying
> > there is no true Haskell.
>
> ? There wasn't a true Haskell in 1998. Already Hugs (in HugsMode) and GHC 
> (with glasgow-extns) had MPTCs, FlexibleInstances/Contexts, FunDeps, 
> UndecidableInstances. Overlapping instances was optional extra.
>
> > It's one reason I hang mostly with Hugs.
>
> Interesting. Does that mean Hugs98? How on earth do you manage without at 
> least some of the above?
>
> > GHC pretty well repudiates Haskell 2010.
>
> So does Hugs (in HugsMode): a large proportion of the extra features in H2010 
> were suggested by the Hugs teams; and Hugs 2006 was already far advanced 
> beyond it.
>
>
> > May Haskell 2020 receive more respect!
>
> I think you'll need to adjust your expectations: I doubt H2020 will happen. 
> There was a glimmer of activity last month, but this list has resumed its 
> moribund state. So I think we can put last month down to dead cat bounce. If 
> H2020 does happen, HugsMode will still be well ahead of whatever gets added.
>
>
> AntC
>
> ___
> 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: Report merged, steps to follow

[Carter Schonwald]

sounds good to me, we can always tweak stuff as needed

On Sun, Nov 4, 2018 at 10:04 AM Mario Blažević  wrote:

> Four weeks having passed since the previous discussion with no
> objections, I have now merged the content of the Haskell Report
>
> from https://github.com/haskell/haskell-report
>
> into https://github.com/haskell/rfcs
>
>
>  To remind everybody again, the point of this move was to enable
> adding an actionable change to the report to every RFC. From this point
> on, any proposal that passes the full process to becoming accepted can
> update the report by the simple act of getting merged.
>
>  In order to test this process, over a year ago I've picked and
> submitted the least controversial RFC I could find, namely
> https://github.com/haskell/rfcs/pull/17. There has been no objection to
> the proposal. In fact there has been no comment whatsoever, but I
> suppose that's beside the point. So today I have moved the RFC to the
> "Last Call" column (https://github.com/haskell/rfcs/projects/1) as the
> first and only proposal to gain that awesome status.
>
>  It's not at all clear what should happen to the RFC between this
> point and it getting merged, but I'm determined to test drive the
> process with it. This is my plan:
>
> 1. I'm going to add update the report with a patch to the report
> content, then
>
> 2. wait another two weeks for any objection before
>
> 3. moving the proposal from the Last Call to the Ready for Report
> status, then
>
> 4. announce that the proposal is Ready for Report and
>
> 5. wait another two weeks for the full approval, then finally
>
> 6. merge the RFC.
>
>
>  The only flaw in my cunning plan above is defining what constitutes
> "the full approval". The committee being rather ... disengaged and
> scattered, there is little hope of getting 50% of votes from all its
> members. The criteria of no raised objection, which I've used so far,
> seems much too lax for a full approval. I think the only reasonable fair
> criteria of success would be a public and unanimous approval by at least
> N committee members. I have no idea what N should be, but I know that if
> this test proposal can't garner N approvals, no proposal will ever pass
> the hurdle.
>
>  To make it plain, I suggest we take the number of committee members
> that comment on the test proposal as the maximum bound of N. I do hope
> max(N) > 1.
>
>
> ___
> 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: A question about run-time errors when class members are undefined

[Carter Schonwald]

ok, cool! I'm not sure what modular scoping would look like, but it'd be
fun what that looks like!

I do think that the prime list isn't the best list though for figuring that
out / experimentations thereof :)

On Wed, Oct 10, 2018 at 1:36 PM  wrote:

> Hi Carter,
>
> I am not proposing "local scoping". I think local scoping
> does not have substantial gains and at least introduces
> some difficulties and complexity (I have tried it in system CT).
>
> Even modular scope for instances is not mandatory, as I said.
> A general defaulting rule is a remedy, if instance modular scope is not
> supported, for changing the ambiguity rule
> (I prefer modular instance scoping though).
>
> I don't want to fight for anything. I'd like to contribute
> if the Haskell community friendly wishes me to do so in order to
> introduce MPTCs in a relatively simple way, without the need of extra
> mechanisms, based essentially on changing the ambiguity rule:
> I think a type like, say, (F a b, X a) => b is not ambiguous
> (F and X being classes with members f:: a->b and x::a, say),
> since then overloading of (f x) can be resolved, with a new
> ambiguity rule, depending on the context (or type) where (f x) is used.
>
> Kind regards,
>
> Carlos
>
> Em 2018-10-10 12:52, Carter Schonwald escreveu:
> > Carlos, local scoping for type classes is flat out not gonna happen in
> > the haskell language standard any time soon.
> >
> > if you want to make a case for it, demonstrate its utility, this
> > mailing list isn't for that. Especially for something that
> > fundamentally changes the programming model of the language in
> > question in a way that isn't compatible
> >
> > merry adventures!
> > -Carter
> >
> > On Mon, Oct 8, 2018 at 8:47 PM Carlos Camarao
> >  wrote:
> >
> >> Hi.
> >>
> >>> Thanks Carlos. I wish I could say thank you for clarifying, but
> >> I'm
> >>> afraid this is as muddled as all the comments on the two
> >> proposals.
> >>>
> >>> I don't want to go over it again. I just want to say that my
> >>> suggestion earlier in the thread is fundamentally different.
> >>>
> >>>> Global instance scope is not ok either: instances should be
> >> modular.
> >>> I just plain disagree. Fundamentally.
> >>
> >> Global instance scope is not required for principal typing: a
> >> principal type is (just) a type of an expression in a given typing
> >> context that has all other types of this expression in that typing
> >> context as instances.
> >>
> >> (Also: instance modularity is not the central issue.)
> >>
> >>>>> Wadler & Blott's 1988 paper last paragraph had already
> >> explained: "But
> >>>>> there is no principal type! "
> >>
> >>>> There is always a principal type, for every expression.
> >>>> Of course the type depends on the context where the
> >> expression occurs.
> >>
> >>> Then it's not a _principal_ type for the expression, it's just a
> >> local type.
> >>> http://foldoc.org/principal
> >>
> >> A type system has the principal type property if, given a
> >> term and a typing context, there exists a type for this term in this
> >> typing context such that all other types for this term in this
> >> typing
> >> context are an instance of this type.
> >>
> >>> We arrive at the principal type by unifying the principal types of
> >>> the sub-expressions, down to the principal types of each atom. W
> >>> are pointing out that without global scope for instances, typing
> >>> cannot assign a principal type to each method. (They left that as
> >> an
> >>> open problem at the end of the paper. Haskell has resolved that
> >>> problem by making all instances global. Changing Haskell to
> >> modular
> >>> instances would be a breakage. Fundamentally.)
> >>>
> >>> Under my suggestion, we can assign a (global) principal type to
> >> each
> >>> method -- indeed you must, by giving a signature very similar to a
> >>> class declaration; and that distinguishes overloaded functions
> >> from
> >>> parametric polymorphic functions.
> >>
> >> A principal type theorem has been proved: see, for example, Theorem
> >> 1 in [1].
> >>
> >> Kind regards,
> >>
> >> Carlos
> >>
> >> [1]

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

[Carter Schonwald]

Carlos, local scoping for type classes is flat out not gonna happen in the
haskell language standard any time soon.

if you want to make a case for it, demonstrate its utility, this mailing
list isn't for that. Especially for something that fundamentally changes
the programming model of the language in question in a way that isn't
compatible

merry adventures!
-Carter

On Mon, Oct 8, 2018 at 8:47 PM Carlos Camarao 
wrote:

> Hi.
>
> > Thanks Carlos. I wish I could say thank you for clarifying, but I'm
> > afraid this is as muddled as all the comments on the two proposals.
> >
> > I don't want to go over it again. I just want to say that my
> > suggestion earlier in the thread is fundamentally different.
> >
> >>Global instance scope is not ok either: instances should be modular.
> > I just plain disagree. Fundamentally.
>
> Global instance scope is not required for principal typing: a
> principal type is (just) a type of an expression in a given typing
> context that has all other types of this expression in that typing
> context as instances.
>
> (Also: instance modularity is not the central issue.)
>
> >>> Wadler & Blott's 1988 paper last paragraph had already explained:
> "But
> >>> there is no principal type! "
>
> >> There is always a principal type, for every expression.
> >> Of course the type depends on the context where the expression
> occurs.
>
> > Then it's not a _principal_ type for the expression, it's just a local
> type.
> > http://foldoc.org/principal
>
> A type system has the principal type property if, given a
> term and a typing context, there exists a type for this term in this
> typing context such that all other types for this term in this typing
> context are an instance of this type.
>
> > We arrive at the principal type by unifying the principal types of
> > the sub-expressions, down to the principal types of each atom. W
> > are pointing out that without global scope for instances, typing
> > cannot assign a principal type to each method. (They left that as an
> > open problem at the end of the paper. Haskell has resolved that
> > problem by making all instances global. Changing Haskell to modular
> > instances would be a breakage. Fundamentally.)
> >
> > Under my suggestion, we can assign a (global) principal type to each
> > method -- indeed you must, by giving a signature very similar to a
> > class declaration; and that distinguishes overloaded functions from
> > parametric polymorphic functions.
>
> A principal type theorem has been proved: see, for example, Theorem 1 in
> [1].
>
> Kind regards,
>
> Carlos
>
> [1] Ambiguity and Constrained Polymorphism,
> Carlos Camarão, Lucília Figueiredo, Rodrigo Ribeiro,
> Science of Computer Programming 124(1), 1--19, August 2016.
>
>
> On Mon, 8 Oct 2018 at 20:03, Anthony Clayden 
> wrote:
>
>> On Tue, 9 Oct 2018 at 7:30 AM,  wrote:
>>
>> Thanks Carlos. I wish I could say thank you for clarifying, but I'm
>> afraid this is as muddled as all the comments on the two proposals.
>>
>> I don't want to go over it again. I just want to say that my suggestion
>> earlier in the thread is fundamentally different.
>>
>> Em 2018-10-08 06:21, Anthony Clayden escreveu:
>>> > On Mon, 8 Oct 2018 at 8:41 PM, Simon Peyton Jones wrote:
>>> >
>>
>>
>> Strange: Simon's message has not appeared on the forum (he did send to
>> it). I've quoted it in full in my reply, but did break it into separate
>> pieces.
>>
>>
>>>
>>> Global instance scope is not ok either: instances should be modular.
>>
>>
>> I just plain disagree. Fundamentally.
>>
>>
>>> >
>>> > Wadler & Blott's 1988 paper last paragraph had already explained: "But
>>> > there is no principal type! "
>>>
>>> There is always a principal type, for every expression.
>>> Of course the type depends on the context where the expression occurs.
>>
>>
>> Then it's not a _principal_ type for the expression, it's just a local
>> type.
>> http://foldoc.org/principal
>>
>> We arrive at the principal type by unifying the principal types of the
>> sub-expressions, down to the principal types of each atom. W are pointing
>> out that without global scope for instances, typing cannot assign a
>> principal type to each method. (They left that as an open problem at the
>> end of the paper. Haskell has resolved that problem by making all instances
>> global. Changing Haskell to modular instances would be a
>> breakage. Fundamentally.)
>>
>> Under my suggestion, we can assign a (global) principal type to each
>> method -- indeed you must, by giving a signature very similar to a class
>> declaration; and that distinguishes overloaded functions from parametric
>> polymorphic functions.
>>
>>
>> AntC
>> ___
>> 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
> 

Re: Quo vadis?

[Carter Schonwald]

agreed...

i think theres still room for the current for the current committee to
succeed (though depending on ambitions it should maybe slide into being
2022 standard perhaps?)

I cant speak for other members, but i'm still hopeful about putting
together some of the language improvements to the standard in time for
2020, life and other commitments (in addition to living) permitting.

I do think that its ultimately a social / communal activity, and humans are
best motivated when thats in the clear.
So the more progress some folks make, the more motivated one way or another
other folks will be!



On Fri, Oct 5, 2018 at 1:05 PM Simon Peyton Jones via Haskell-prime <
haskell-prime@haskell.org> 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.
>
> 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

Re: Shall the Haskell Report remain in LaTeX?

[Carter Schonwald]

agreed

On Tue, Oct 31, 2017 at 10:37 AM, John Wiegley 
wrote:

> > "DS" == Doaitse Swierstra  writes:
>
> SD> The good thing about laTeX is that out of all the candidates it is the
> SD> most likely one to still work 40 years from now,
>
> +1 from me for LaTeX as well.
>
> --
> John Wiegley  GPG fingerprint = 4710 CF98 AF9B 327B B80F
> http://newartisans.com  60E1 46C4 BD1A 7AC1 4BA2
> ___
> 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: Shall the Haskell Report remain in LaTeX?

[Carter Schonwald]

I personally kinda enjoy latex.  Granted that's assuming it's well written
:)

On Sat, Sep 9, 2017 at 2:41 PM Herbert Valerio Riedel 
wrote:

> Hello *,
>
> On 2017-09-08 at 00:46:52 +0200, Mario Blazevic wrote:
>
> [...]
>
> >> If the report was written in reStructuredText we could simply use
> >> something like the readthedocs.org service. But since it's LaTeX, we
> >> have to do a little bit more work to publishes ("deploys" in newspeak)
> >> .pdf drafts somewhere else, but it's doable.
> >>
> >> I can take care to set it up, if it's clear what kind of CI/CD we want.
>
> > Is the current publishing system really that difficult?
>
> No, it's not that bad, it's just that there likely won't be a service
> that'll work out of the box with GitHub integration like readthedocs...
>
> > To my grizzled ears, this sounds like you're fishing for a volunteer
> > to translate LaTeX to ReST. I'd actually be willing to do that, as I
> > have plenty of experience with text transformations, but I'd need a
> > buy-in from everybody.
>
> ...but I wouldn't go as far as to suggest this is reason enough to
> translate the report into .rst
>
> I guess I was rather trying to fish for some commitment that we want in
> fact to stay with LaTeX; I was planning to pick up where I left things
> in 2015 and clean up/refactor the TeX text and also investigate what our
> current options are to generate state-of-the-art .pdf, .html and .epub
> output. And I'd like to avoid this resulting a waste of effort in case
> we decide to move away from LaTeX in the foreseeable future...
>
> Long story short, is everyone ok to stay with (La)TeX, or is there some
> compelling reason that would justify migrating to a different
> documentation system?
>
> -- hvr
> ___
> 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: Remove eq and show from num class

[Carter Schonwald]

I mostly wanted to confirm that we in fact will actually say yes before
doing the formal writtingup :)

On Fri, Sep 8, 2017 at 2:06 PM, John Wiegley  wrote:

> > "AC" == Anthony Clayden  writes:
>
> AC> All yays from committee members please reply with yes to this email :)
>
> Just to note: I don't recall their being an actual "vote" on this during
> our
> informal meeting of just a few of the committee members here at ICFP, so I
> took Carter's note to be a sign of enthusiasm, and not actual procedural
> decision making.
>
> --
> John Wiegley  GPG fingerprint = 4710 CF98 AF9B 327B B80F
> http://newartisans.com  60E1 46C4 BD1A 7AC1 4BA2
> ___
> 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: Remove eq and show from num class

[Carter Schonwald]

well sure, i'm happy to write the 3 line diff, but because of the sheer
unambiguity of this i'd rather get the votes on email before botthering to
write the diff, at which point the main question is whether i wrote the
diff correctly


please say yes or no. its quite easy with email . i'm not going to write
that little proposal if folks wont accept it :)

On Thu, Sep 7, 2017 at 11:44 PM, Mario Blazevic  wrote:

> On Thu, Sep 7, 2017 at 6:20 PM, Richard Eisenberg 
> wrote:
>
>> I don't mean to be a killjoy, but I think even something as simple as
>> this should have a proposal. We still have to draft the changes to the
>> Report associated with this change, and at least one is non-obvious: now
>> numeric literals induce an Eq constraint (which should be mentioned). I'm
>> certainly not against this change, but I don't think it's as easy as this.
>>
>
> I agree. I just I thought it was implicit that every change to the report
> goes throught a pull request, which is the same as a proposal. Were you
> volunteering for something else, Carter?
>
>
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime

Remove eq and show from num class

[Carter Schonwald]

All yays from committee members please reply with yes to this email :)

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

Re: Haskell Prime Meeting at ICFP (Was: Whose gonna be at icfp?)

[Carter Schonwald]

There's food sans line near c5

On Thu, Sep 7, 2017 at 10:23 AM Henrik Nilsson <
henrik.nils...@nottingham.ac.uk> wrote:

> Hi all,
>
> Reminder: Haskell' is meeting lunchtime today, so shortly after 12:30.
>
> We now, thank to Jeremy Gibbons, also have a room: C5.
>
> So grab lunch and then go to C5.
>
> Best,
>
> /Henrik
>
>
>
>
> This message and any attachment are intended solely for the addressee
> and may contain confidential information. If you have received this
> message in error, please send it back to me, and immediately delete it.
>
> Please do not use, copy or disclose the information contained in this
> message or in any attachment.  Any views or opinions expressed by the
> author of this email do not necessarily reflect the views of the
> University of Nottingham.
>
> This message has been checked for viruses but the contents of an
> attachment may still contain software viruses which could damage your
> computer system, you are advised to perform your own checks. Email
> communications with the University of Nottingham may be monitored as
> permitted by UK legislation.
>
>
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime

Re: Whose gonna be at icfp?

[Carter Schonwald]

Missing Conall's talk seems like a terrible time to meet :(

On Tue, Sep 5, 2017 at 10:54 AM Henrik Nilsson <
henrik.nils...@nottingham.ac.uk> wrote:

> Hi,
>
> On 09/05/2017 10:27 AM, Mario Blazevic wrote:
> > I thought John said 4:40 today. You missed Andres Löh.
>
> Must have missed that. Works for me!
>
> /Henrik
>
>
>
>
>
> This message and any attachment are intended solely for the addressee
> and may contain confidential information. If you have received this
> message in error, please send it back to me, and immediately delete it.
>
> Please do not use, copy or disclose the information contained in this
> message or in any attachment.  Any views or opinions expressed by the
> author of this email do not necessarily reflect the views of the
> University of Nottingham.
>
> This message has been checked for viruses but the contents of an
> attachment may still contain software viruses which could damage your
> computer system, you are advised to perform your own checks. Email
> communications with the University of Nottingham may be monitored as
> permitted by UK legislation.
>
> ___
> 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: Whose gonna be at icfp?

[Carter Schonwald]

Either way, see y'all in oxford

On Sat, Aug 26, 2017 at 6:30 PM Carter Schonwald <carter.schonw...@gmail.com>
wrote:

> Agreed.  Hence let's just have something less structured than the GitHub
> flow ... just any doc will do. Also it'd be simpler to have just one tool
> for coms.
>
> On Sat, Aug 26, 2017 at 12:55 PM Mario Blažević <blama...@ciktel.net>
> wrote:
>
>> On 2017-08-25 06:48 PM, Carter Schonwald wrote:
>> > I'll be this time! :)
>> >
>> > We should coord a committee catch-up at icfp.
>> >
>> > Also I would like to propose we shift back to email based discussion.
>> > There's still the valid and important need of then taking the
>> > discussion and revisions into a new standard. But let's at least make
>> > the first half lighter weight perhaps? the pattern that's working for
>> > ghc proposals doesn't seem to matchup with what works for h2020
>>
>>  I'll be there as well. As for the e-mail based discussion, my
>> feeling for the last while has been that I'd rather bring something,
>> anything, to completion. There's very little feedback and there's a real
>> danger that the discussion doesn't lead to any concrete change to the
>> standard.
>>
>> ___
>> 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: Whose gonna be at icfp?

[Carter Schonwald]

Agreed.  Hence let's just have something less structured than the GitHub
flow ... just any doc will do. Also it'd be simpler to have just one tool
for coms.

On Sat, Aug 26, 2017 at 12:55 PM Mario Blažević <blama...@ciktel.net> wrote:

> On 2017-08-25 06:48 PM, Carter Schonwald wrote:
> > I'll be this time! :)
> >
> > We should coord a committee catch-up at icfp.
> >
> > Also I would like to propose we shift back to email based discussion.
> > There's still the valid and important need of then taking the
> > discussion and revisions into a new standard. But let's at least make
> > the first half lighter weight perhaps? the pattern that's working for
> > ghc proposals doesn't seem to matchup with what works for h2020
>
>  I'll be there as well. As for the e-mail based discussion, my
> feeling for the last while has been that I'd rather bring something,
> anything, to completion. There's very little feedback and there's a real
> danger that the discussion doesn't lead to any concrete change to the
> standard.
>
> ___
> 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: Default module header `module Main where`

[Carter Schonwald]

as a guideline what you say is true, and at least in this case as the
motivation is user focused it should be validated thusly :)

On Fri, May 19, 2017 at 5:35 PM, Mario Blažević  wrote:

> On 2017-05-16 10:18 AM, Joachim Breitner wrote:
>
>> Hi,
>>
>> a very small proposal to be considered for Haskell':
>>
>
> I like it, but it should probably be a GHC proposal first. I don't
> think Haskell' is supposed to make any change to the standard that hasn't
> been already implemented and tested. In this particular case, GHC HQ might
> opt to implement your proposal but hide it behind a command-line option, or
> to enable it by default only in GHCi. There are already precedents for this.
>
>
>
>> Currently, the report states
>>
>> An abbreviated form of module, consisting only of the module body,
>> is permitted. If this is used, the header is assumed to be ‘module
>> Main(main) where’.
>>
>> I propose to change that to
>>
>> An abbreviated form of module, consisting only of the module body,
>> is permitted. If this is used, the header is assumed to be ‘module
>> Main where’.
>>
>> The rationale is that a main-less main module is still useful, e.g.
>> when you are working a lot in GHCi, and offload a few extensions to a
>> separate file. Currently, tools like hdevtools will complain about a
>> missing main function when editing such a file.
>>
>> It would also work better with GHC’s -main-is flag, and avoid problems
>> like the one described in https://ghc.haskell.org/trac/ghc/ticket/13704
>>
>>
>> I don’t see any downsides. When compiling to a binary, implementations
>> are still able to detect that a Main module is not imported by any
>> other module and only the main function is used, and optimize as if
>> only main were exported.
>>
>> Greetings,
>> Joachim
>>
>>
>>
>>
>>
>> ___
>> Haskell-prime mailing list
>> Haskell-prime@haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
>>
>>
>
> --
> Mario Blazevic
> mblaze...@stilo.com
> Stilo International
>
> This message, including any attachments, is for the sole use of the
> intended recipient(s) and may contain confidential and privileged
> information. Any unauthorized review, use, disclosure, copying, or
> distribution is strictly prohibited. If you are not the intended
> recipient(s) please contact the sender by reply email and destroy
> all copies of the original message and any attachments.
>
> ___
> 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: Multiple imports on a single line

[Carter Schonwald]

likewise, why not use semicolon? per se we already can do mulitple lines on
a single line via semicolon :)

On Wed, Feb 1, 2017 at 10:34 AM, Francesco Ariis  wrote:

> On Wed, Feb 01, 2017 at 04:18:13PM +0200, Vassil Ognyanov Keremidchiev
> wrote:
> > Hello!
> >
> > What do you think about an idea to have multiple imports on a single
> line,
> > like:
> >
> > module MyApp where
> > import Data.Text, Data.Foldable, Control.Concurrent
> > ...
>
> Hello Vassil,
>   how would qualified/as work?
> Would import statement like this:
>
> import Data.Text, qualified Data.Foldable as F, Control.Concurrent
>
> be allowed?
>
> ___
> 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: Step-by-step guide for creating a new proposal

[Carter Schonwald]

I'll have some down time at the airport this afternoon and see about
dealing with this

On Friday, October 7, 2016, Carter Schonwald <carter.schonw...@gmail.com>
wrote:

> Sounds good to me unless anyone objects or has an alternative?
>
> On Friday, October 7, 2016, Takenobu Tani <takenobu...@gmail.com
> <javascript:_e(%7B%7D,'cvml','takenobu...@gmail.com');>> wrote:
>
>> GHC proposal process is active at same time.
>> To avoid confusion about starting process, it's good that pre-starting
>> process is written somewhere.
>>
>> What about directly writing at README.rst as following?
>> (It's simpler than PR.)
>>
>> [README.rst]
>>   While the process is open for everyone to participate, contributing
>> entirely
>>   new issues is currently limited to the members of the Core Language
>> Committee.
>> + If you want to create entirely new issue, privately talk with member of
>> the
>> + committee or ask on haskell-prime mailing list.
>>
>> I think that non-member will understand pre-process :)
>>
>> Regards,
>> Takenobu
>>
>>
>> 2016-10-06 23:38 GMT+09:00 Carter Schonwald <carter.schonw...@gmail.com>:
>>
>>> Hrmm, I guess I shall have to do my first pr, unless anyone else thinks
>>> we should tweet this clarification slightly? But i suppose that can be on
>>> the pr :)
>>>
>>>
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime

Re: Step-by-step guide for creating a new proposal

[Carter Schonwald]

Sounds good to me unless anyone objects or has an alternative?

On Friday, October 7, 2016, Takenobu Tani <takenobu...@gmail.com> wrote:

> GHC proposal process is active at same time.
> To avoid confusion about starting process, it's good that pre-starting
> process is written somewhere.
>
> What about directly writing at README.rst as following?
> (It's simpler than PR.)
>
> [README.rst]
>   While the process is open for everyone to participate, contributing
> entirely
>   new issues is currently limited to the members of the Core Language
> Committee.
> + If you want to create entirely new issue, privately talk with member of
> the
> + committee or ask on haskell-prime mailing list.
>
> I think that non-member will understand pre-process :)
>
> Regards,
> Takenobu
>
>
> 2016-10-06 23:38 GMT+09:00 Carter Schonwald <carter.schonw...@gmail.com
> <javascript:_e(%7B%7D,'cvml','carter.schonw...@gmail.com');>>:
>
>> Hrmm, I guess I shall have to do my first pr, unless anyone else thinks
>> we should tweet this clarification slightly? But i suppose that can be on
>> the pr :)
>>
>>
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime

Re: Step-by-step guide for creating a new proposal

[Carter Schonwald]

Hrmm, I guess I shall have to do my first pr, unless anyone else thinks we
should tweet this clarification slightly? But i suppose that can be on the
pr :)

On Thursday, October 6, 2016, Takenobu Tani <takenobu...@gmail.com> wrote:

> Thank you for your kind explanation.
>
> I understood that accountability of a proposal (github PR) is very
> important.
> If it doesn't exist, the github proposal repo may become a collection of
> "throw-out" PRs.
> It's reasonable for me that only committee members can create PRs.
>
>
> In my understanding from your explanation, the proposal process is the
> following:
>
> (1) pre-discussion about a particular proposal [everyone]
>   * privately talk with committee members, or,
>   * talk on the haskell-prime mailing list
>
> (2) creating the new proposal on github [only committee members]
>   * PR by a committee member
>
> (3) open discussion on github [everyone]
>   * conservation on the PR
>
> For me, (1) is now clear.
> If it's written somewhere, it's easy for non-committee members to
> understand the total proposal process:)
>
>
> Thank you for committee's great work,
> Takenobu
>
>
> 2016-10-06 6:50 GMT+09:00 Carter Schonwald <carter.schonw...@gmail.com
> <javascript:_e(%7B%7D,'cvml','carter.schonw...@gmail.com');>>:
>
>> I guess the question is what is the definition of issue in that context?
>>
>> Whatever the specifics, I think if you either
>>
>> a) privately talk with a memeber of the committee about what you intend
>> to do and they are willing to "co own" / "sponsor it", and this is
>> indicated in the pr summary or the like
>> B) ask on the list about a particular proposal / pr you wish to write up
>> and at least 2-3 committee members explicitly respond with supportive noise
>> like "sure"/ "go for it" etc, then linking that thread as part of the
>> description of the PR  counts as support by those committee members for
>> that pr
>>
>> (Mind you I'm making up this approach / rubric)
>>
>> The intent I think of the current language in the repo is that drowning
>> in proposals would not be a good state of affairs, and that likewise
>> members of can hold each other accountable.
>>
>> Anyways: what do you have in mind? :)
>>
>>
>> On Wednesday, October 5, 2016, Takenobu Tani <takenobu...@gmail.com
>> <javascript:_e(%7B%7D,'cvml','takenobu...@gmail.com');>> wrote:
>>
>>> Dear Iavor,
>>>
>>> Members of non prime-commitiee could send pull-request?
>>>
>>>
>>> README.rst [1] is written as follows:
>>>
>>> > While the process is open for everyone to participate, contributing
>>> entirely new issues is currently limited to the members of the Core
>>> Language Committee.
>>>
>>>
>>> [1]: https://github.com/haskell/rfcs
>>>
>>> Regards,
>>> Takenobu
>>>
>>>
>>> 2016-10-04 8:27 GMT+09:00 Iavor Diatchki <iavor.diatc...@gmail.com>:
>>>
>>>> Hello,
>>>>
>>>> During our Haskell Prime lunch meeting at ICFP, I promised to create a
>>>> detailed step-by-step guide for creating Haskell Prime proposals on
>>>> GitHub.  The instructions are now available here:
>>>>
>>>>  https://github.com/yav/rfcs/blob/instructions/step-by-step-
>>>> instructions.md
>>>>
>>>> Please have a look and let me know if something is unclear, or if I
>>>> misunderstood something about the process.
>>>>
>>>> Cheers,
>>>> -Iavor
>>>>
>>>>
>>>> ___
>>>> 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: Step-by-step guide for creating a new proposal

[Carter Schonwald]

I guess the question is what is the definition of issue in that context?

Whatever the specifics, I think if you either

a) privately talk with a memeber of the committee about what you intend to
do and they are willing to "co own" / "sponsor it", and this is indicated
in the pr summary or the like
B) ask on the list about a particular proposal / pr you wish to write up
and at least 2-3 committee members explicitly respond with supportive noise
like "sure"/ "go for it" etc, then linking that thread as part of the
description of the PR  counts as support by those committee members for
that pr

(Mind you I'm making up this approach / rubric)

The intent I think of the current language in the repo is that drowning in
proposals would not be a good state of affairs, and that likewise members
of can hold each other accountable.

Anyways: what do you have in mind? :)

On Wednesday, October 5, 2016, Takenobu Tani  wrote:

> Dear Iavor,
>
> Members of non prime-commitiee could send pull-request?
>
>
> README.rst [1] is written as follows:
>
> > While the process is open for everyone to participate, contributing
> entirely new issues is currently limited to the members of the Core
> Language Committee.
>
>
> [1]: https://github.com/haskell/rfcs
>
> Regards,
> Takenobu
>
>
> 2016-10-04 8:27 GMT+09:00 Iavor Diatchki  >:
>
>> Hello,
>>
>> During our Haskell Prime lunch meeting at ICFP, I promised to create a
>> detailed step-by-step guide for creating Haskell Prime proposals on
>> GitHub.  The instructions are now available here:
>>
>>  https://github.com/yav/rfcs/blob/instructions/step-by-step-
>> instructions.md
>>
>> Please have a look and let me know if something is unclear, or if I
>> misunderstood something about the process.
>>
>> Cheers,
>> -Iavor
>>
>>
>> ___
>> 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: Meet up at ICFP?

[Carter Schonwald]

yeah, i couldn't make it too :(

On Fri, Sep 16, 2016 at 9:51 AM, Mario Blažević  wrote:

> On 2016-09-14 02:17 PM, José Manuel Calderón Trilla wrote:
>
>> Richard has also volunteered to act as secretary for the meeting so
>> that the minutes of the meeting can be posted. Thanks Richard!
>>
>
> Thanks from all of us who can't attend as well. Please do post the minutes!
>
>
> ___
> 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: Scope of committee (can we do *new* things?)

[Carter Schonwald]

On Friday, May 13, 2016, Richard Eisenberg  wrote:

> I strongly agree with all the points Andres makes here:
>  - Focus on existing extensions
>  - Permit discussion and even modification of existing behavior
>  - Allow possibility of discussing new behavior
>  - Strive hard to (or even require) an implementation before
> standardization (at the moment, time is on our side here)
>  - Plan to include an appendix / co-report describing aspects of Haskell
> that are not yet strictly standardized
>
> Richard
>
>
I second this summary and thus Andres' remarks.


> On May 12, 2016, at 4:25 PM, Andres Loeh  > wrote:
>
> > I think we all agree that in general, we should focus on existing
> > language extensions that have an implementation, and expect language
> > extensions to be implemented for them to be seriously considered for
> > inclusion in the standard.
> >
> > But I think it would be wrong to turn this into a hard rule. Language
> > extensions are usually looked at in isolation, whereas the standard is
> > supposed to be a whole. There may be things that fit in well, are
> > useful generalizations of extensions we want to adopt, and so on that
> > are worth discussing. Also, extensions should perhaps be modified or
> > changed in some cases. If we say in advance that we can only
> > standardize things that GHC already implements, and only in exactly
> > this way, then it is a bit too limiting, and this would be throwing
> > away the chance to clean up a few issues.
> >
> > The other side of this is that if we really arrive at the conclusion
> > that something should be different from the current GHC
> > implementations in any significant way, we should at least try to get
> > it implemented during, and not just after, the standardization process
> > so that we can still get practical feedback, and to prevent ending up
> > with a standard that will never be implemented.
> >
> > Also (I think I've said this before), we should keep in mind that the
> > whole process for Haskell 2020 can have more outputs than just the new
> > standard itself. We can make progress towards standardization of
> > features in future versions of Haskell even if they don't yet make it.
> > We can make statements that we would in principle like to see certain
> > features in the standard, and identify the issues that currently
> > prevent them from being included.
> >
> > Cheers,
> >  Andres
> >
> > On Thu, May 12, 2016 at 9:46 PM, Iavor Diatchki
> > > wrote:
> >> I disagree that we should be standardizing language features that have
> not
> >> been implemented.
> >>
> >> I think having an implementation is important because:
> >>   1. the act of implementing a feature forces you to work out details
> that
> >> you may not have thought of ahead of time.  For example, for a small
> >> syntactic extension, the implementation would have to work out how to
> fit it
> >> in the grammar, and how to present the new feature in, say, error
> messages.
> >>   2. having an implementation allows users to try out the extension and
> >> gain some empirical evidence that the extension is actually useful in
> >> practice (this is hard to quantify, I know, but it is even harder if you
> >> can't even use the extension at all).
> >>
> >> If some feature ends up being particularly useful, it could always be
> >> standardized in the next iteration of the language, when we've gained
> some
> >> experience using it in practice.
> >>
> >> -Iavor
> >>
> >>
> >>
> >> On Wed, May 11, 2016 at 11:17 AM, John Wiegley  >
> >> wrote:
> >>>
>  Gershom B > writes:
> >>>
>  While such changes should definitely be in scope, I do think that the
>  proper
>  mechanism would be to garner enough interest to get a patch into GHC
>  (whether through discussion on the -prime list or elsewhere) and have
> an
>  experimental implementation, even for syntax changes, before such
>  proposals
>  are considered ready for acceptance into a standard as such.
> >>>
> >>> Just a side note: This is often how the C++ committee proceeds as
> well: a
> >>> language proposal with an experimental implementation is given much
> higher
> >>> credence than paperware. However, they don't exclude paperware either.
> >>>
> >>> So I don't think we need to rely on implementation before considering a
> >>> feature we all want, but I do agree that seeing a patch in GHC first
> >>> allows
> >>> for much testing and experimentation.
> >>>
> >>> --
> >>> John Wiegley  GPG fingerprint = 4710 CF98 AF9B 327B
> B80F
> >>> http://newartisans.com  60E1 46C4 BD1A 7AC1
> 4BA2
> >>> ___
> >>> Haskell-prime mailing list
> >>> Haskell-prime@haskell.org 
> >>> 

Re: The GADT debate

[Carter Schonwald]

On Sunday, May 8, 2016, Richard Eisenberg  wrote:

>
> On May 7, 2016, at 11:05 PM, Gershom B >
> wrote:
> >
> > an attempt (orthogonal to the prime committee at first) to specify an
> algorithm for inference that is easier to describe and implement than
> OutsideIn, and which is strictly less powerful. (And indeed whose
> specification can be given in a page or two of the report).
>
> Stephanie Weirich and I indeed considered doing such a thing, which
> conversation was inspired by my joining the Haskell Prime committee. We
> concluded that this would indeed be a research question that is, as yet,
> unanswered in the literature. The best we could come up with based on
> current knowledge would be to require type signatures on:
>
> 1. The scrutinee
> 2. Every case branch
> 3. The case as a whole
>
> With all of these type signatures in place, GADT type inference is indeed
> straightforward. As a strawman, I would be open to standardizing GADTs with
> these requirements in place and the caveat that implementations are welcome
> to require fewer signatures. Even better would be to do this research and
> come up with a good answer. I may very well be open to doing such a
> research project, but not for at least a year. (My research agenda for the
> next year seems fairly solid at this point.) If someone else wants to
> spearhead and wants advice / a sounding board / a less active co-author, I
> may be willing to join.
>
> Richard



This sounds awesome.  One question I'm wondering about is what parts of the
type inference problem aren't part of the same challenge in equivalent
dependent data types? I've been doing some Intersting stuff on the latter
front recently.

It seems that those two are closely related, but I guess there might be
some complications in Haskell semantics for thst? And or is this alluded to
in existing work on gadts?



> ___
> 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: The GADT debate

[Carter Schonwald]

On Saturday, May 7, 2016, Gershom B  wrote:

> On May 7, 2016 at 10:30:05 PM, wren romano (w...@community.haskell.org
> ) wrote:
> > Hi all,
> >
> > There's been some discussion about whether to consider including GADTs
> > in the new report, but it's been mixed up with other stuff in the
> > thread on incorporating extensions wholesale, which has unfortunately
> > preempted/preceded the discussion about how to go about having such
> > discussions(!).
> >
> > My position on the debate is that we should avoid having the debate,
> > just yet. (Which I intended but failed to get across in the email
> > which unintentionally started this all off.) I think we have many much
> > lower-hanging fruit and it'd be a better use of our time to try and
> > get those squared away first. Doing so will help us figure out and
> > debug the process for having such debates, which should help the GADT
> > debate itself actually be fruitful. As well as making progress on
> > other fronts, so we don't get mired down first thing.
>
> Thanks for this summary Wren. Let me add something I would be interested
> in seeing happen in the “meantime” — an attempt (orthogonal to the prime
> committee at first) to specify an algorithm for inference that is easier to
> describe and implement than OutsideIn, and which is strictly less powerful.
> (And indeed whose specification can be given in a page or two of the
> report). A compliant compiler could then be required to have inference “at
> least” that good, but also be allowed to go “above and beyond”. Thus fully
> portable H2020 code might require more specified signatures than we need in
> GHC proper, but all such code would also typecheck in GHC. It seems to me
> that the creation of such an algorithm might be an interesting bit of
> research in itself.
>
> —Gershom


I agree, there's definitely value in some research / engineering work that
articulates a clear simple checker and a simple and slightly conservative
inference alg , and that could pave a nice path towards gadts inclusion or
at least a concrete starting point. Thanks for articulating this, I've been
thinking much the same thing.  Of course the proof is in the pudding for
how it works out :)


Peripherally, this also brings up the notion of type equality, and I'm a
bit fuzzy about how big a chasm there is between what that means in Haskell
2010 vs more bleeding edge styles, or am I pointing at a shadows?



> ___
> 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: Limber separators

[Carter Schonwald]

On Saturday, May 7, 2016, wren romano  wrote:

> On Fri, May 6, 2016 at 3:58 PM, Cale Gibbard  > wrote:
> > I can't really be the only one here who thinks that this kind of
> > discussion of extensions to the syntax of Haskell is totally
> > inappropriate when we have a large number of already implemented
> > extensions to the language whose interactions with each other are
> > largely undocumented. The Haskell Report isn't the place to be talking
> > about new features, in my mind. If this project turns into
> > bike-shedding the concrete syntax of the language, it's hard to
> > imagine real progress being made on the actual problem, which is that
> > the Haskell Reports as they stand are not as relevant as they should
> > be with regard to the language in which we're writing programs today.
>
>
> +1.
>
> One of my big concerns here is that the proposal is vague, and
> therefore impossible to judge. As an example of what I mean, what
> counts as a "separator"? Is it a special case only commas? Why not
> also include the vertical pipe in data type definitions? We run into
> the same "difficult to one-line merge" issues when we write things
> like:
>
> data SomeReallyLongNameSoIWantToNewlineWrap
> = Foo ...
> | Bar ...
> ...
>
> Coq and other ML-like languages allow a vertical pipe between the "="
> and the first constructor name, so why shouldn't we? Or, what about
> when people do parser combinator stuff and use the (<|>) operator as a
> "separator", should we handle that too? If so, do we extend it to
> other operators people may want as a leading separator, like (+) in
> large arithmetic expressions? How should these be distinguished from
> typos where an argument is missing or a section was indented?
>
>
> These sorts of complexities are the reason the Haskell' committee has
> always focused on things which have already been implemented. The
> implementation provides (a) a concrete specification of what's being
> proposed, (b) an idea of how that proposal works in the wild, (c) a
> proof that it's easily implementable. Of course, in the process of
> getting included into the report the details may change; but it's a
> very solid starting point. I'm not adamantly opposed to proposals
> which aren't already implemented, but the proposal should measure up
> to the same standards— N.B., it may appear to be held to higher
> standards, since people often neglect to consider the role an
> implementation plays as a component of the proposal itself.
>
> As you say, four years is a decent chunk of time. Why not spend that
> time getting it implemented as an extension in GHC? The implementation
> process will work out a bunch of kinks in what exactly you mean by
> "separators" and how to handle leading vs trailing vs redundant
> separators. Having it available will also make it clearer how many
> people like and want this behavior. Both of these contribute to making
> the argument that we should in fact include it in the report.
>
> --
> Live well,
> ~wren
> __


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

Re: Infrastructure & Communication

[Carter Schonwald]

Yes, persistent commenting / threading somehow on some tool. And I trust
Herbert's judgement

On Saturday, May 7, 2016, Vitaly Bragilevsky  wrote:

> The third one here. I think that process decisions can be made by chairman
> alone without calling votes, that's organizing part of job, not conceptual
> one.
>
> Vitaly
>
> On Sat, May 7, 2016 at 10:05 PM Richard Eisenberg  > wrote:
>
>> I second this motion to call a vote or other concrete, forward-moving
>> action on this topic.
>>
>> I, too, am refraining from commenting on other threads until this issue
>> is resolved.
>>
>> Richard
>>
>> On May 6, 2016, at 12:32 PM, M Farkas-Dyck > > wrote:
>>
>> > I think we ought to make a choice quite soon. Proposals are already
>> > being made on this list, but i hesitate to make comment lest it be
>> > forgotten when we move to our new medium.
>> >
>> > My opinion on our choice of medium is known, i believe. Who or what
>> > makes the final call? hvr? committee member votes?
>> > ___
>> > 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: Limber separators

[Carter Schonwald]

On Saturday, May 7, 2016, Carter Schonwald <carter.schonw...@gmail.com>
wrote:

> I worry that this thread is turning into a bit of bike shed before we have
> a good sense of what construction tools we have on hand!
>
> One side consideration we might want to keep in mind is what spaces of
> parser tech can work off the shelf in various juxtapositions of code and
> features.
>
> The more context sensitive a grammar is, the more humans Pay too!
>
> I've certainly seen agressive amounts of tuple sections in industrial
> code.
>
> Another meta question / challenge that this thread has posed is : given
> Haskell as it is today / will be in the future, is there a meaningfully
> better language tuned diff tool that could exist ?
>
>
>
> On Saturday, May 7, 2016, Kosyrev Serge <_deepf...@feelingofgreen.ru
> <javascript:_e(%7B%7D,'cvml','deepf...@feelingofgreen.ru');>> wrote:
>
>> Bardur Arantsson <s...@scientician.net> writes:
>> > Actually, thinking about it a little further... TupleSections is already
>> > opt-in, so this needn't conflict per se.
>>
>> Isn't this dangerous, in how it now gives a trivial piece of code
>> two very different interpretations, in a plausibly unintentional way?
>>
>> > {-# LANGUAGE TupleSections #-}
>> > (x, y, ) :: t -> (a, b, t)
>>
>> > {-# LANGUAGE LaxCommas #-}
>> > (x, y, ) :: (a, b)
>>
>> I understand that we have OverloadedStrings, viz:
>>
>> > {-# LANGUAGE NoOverloadedStrings #-}
>> > "a" :: [Char]
>>
>> > {-# LANGUAGE OverloadedStrings #-}
>> > "a" :: IsString a => a
>>
>> and yet, the differences in this respect seems significant:
>>
>> The unintentionality of change in interpretation effected by the
>> transition NoOverloadedStrings -> OverloadedStrings is implausible.
>>
>> Whereas with the LaxCommas -> TupleSections transition I guess it would
>> be fair to say that it is plausible.
>>
>> Moreover, OverloadedStrings doesn't disallow using string literals as
>> string literals, whereas LaxCommas and TupleSections are mutually
>> exclusive.
>>
>> --
>> с уважениeм / respectfully,
>> Косырев Сергей
>> ___
>> Haskell-prime mailing list
>> Haskell-prime@haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
>>
>


My bad for forgetting to reply below rather than above :)

Tla+ does have leading AND style syntax in the style of the  what is being
discussed here, but that was done from the outset.

Either way, experiments in syntax and semantics are best grounded in ...
Running experiments using them!  Certainly some parts of what we hope to
achieve need to be grounded thusly, even if it's not changing the type
system or the syntax of the core substrate.  Let's do some experimental
research and see what happens in the wild, in codes natural habitats! 
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime

Re: Limber separators

[Carter Schonwald]

I worry that this thread is turning into a bit of bike shed before we have
a good sense of what construction tools we have on hand!

One side consideration we might want to keep in mind is what spaces of
parser tech can work off the shelf in various juxtapositions of code and
features.

The more context sensitive a grammar is, the more humans Pay too!

I've certainly seen agressive amounts of tuple sections in industrial code.


Another meta question / challenge that this thread has posed is : given
Haskell as it is today / will be in the future, is there a meaningfully
better language tuned diff tool that could exist ?

On Saturday, May 7, 2016, Kosyrev Serge <_deepf...@feelingofgreen.ru> wrote:

> Bardur Arantsson > writes:
> > Actually, thinking about it a little further... TupleSections is already
> > opt-in, so this needn't conflict per se.
>
> Isn't this dangerous, in how it now gives a trivial piece of code
> two very different interpretations, in a plausibly unintentional way?
>
> > {-# LANGUAGE TupleSections #-}
> > (x, y, ) :: t -> (a, b, t)
>
> > {-# LANGUAGE LaxCommas #-}
> > (x, y, ) :: (a, b)
>
> I understand that we have OverloadedStrings, viz:
>
> > {-# LANGUAGE NoOverloadedStrings #-}
> > "a" :: [Char]
>
> > {-# LANGUAGE OverloadedStrings #-}
> > "a" :: IsString a => a
>
> and yet, the differences in this respect seems significant:
>
> The unintentionality of change in interpretation effected by the
> transition NoOverloadedStrings -> OverloadedStrings is implausible.
>
> Whereas with the LaxCommas -> TupleSections transition I guess it would
> be fair to say that it is plausible.
>
> Moreover, OverloadedStrings doesn't disallow using string literals as
> string literals, whereas LaxCommas and TupleSections are mutually
> exclusive.
>
> --
> с уважениeм / respectfully,
> Косырев Сергей
> ___
> 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: Are there GHC extensions we'd like to incorporate wholesale?

[Carter Schonwald]

Well said, having coherent location to collect bits per topic so they don't
get lost to mailing list thread mists of time is pretty important. I don't
care too much as long as it's easy to comment on a topic / ticket and or
propose edits. But probably something we should front load doing.

On Wednesday, May 4, 2016, Richard Eisenberg  wrote:

> There are many points I'd like to make in this discussion, but this one
> screams out the loudest:
>
> This thread is spiraling a bit out of control. I've seen useful
> conversations around many different extensions in here, but these
> conversations are sometimes only tangentially related. I'd personally much
> rather see us decide on a tool/process first, and then we can have
> someplace to have The GADT Discussion and another place to have The
> Overloaded Discussion, etc. Otherwise, we risk losing good points in this
> thread, and someone will have to comb through all of this to extract these
> good points.
>
> The discussion about what our goals are w.r.t. extensions -- whether to
> consider popularity, ease of specification, ease of implementation, making
> standard extensions, etc -- is, to me, more appropriate for this thread and
> this point in the process.
>
> So, might I humbly request that we focus our collective creative energies
> on having a stable process before getting into nitty-gritty details about
> extensions?
>
> Thanks,
> Richard
>
> On May 4, 2016, at 4:21 AM, Henrik Nilsson <
> henrik.nils...@nottingham.ac.uk > wrote:
>
> > Hi all,
> >
> > > For example, much as I love GADTs and would be all for them being
> > > added in some future language report, I do not feel they should be
> > > added this time around. (Though I emphatically and wholeheartedly
> > > support adding GADTSyntax.)
> >
> > In my opinion, GADTs is one of the most important extensions of the
> > Haskell type system over the past decade and definitely a sweet spot
> > in the design space in terms of power vs. complexity, at least from
> > a user perspective. I eagerly await Herbert's summary of of most used
> > extensions (which I think will be an extremely important input when
> > deciding how to go forward in general), but my definite impression is
> > that GADTs (and not just GADT syntax) are used a lot.
> >
> > Point taken about the difficulty of specifying GADT type inference
> > declaratively. But as long as there at least is a way to standardise
> > inference that works, and from what Simon said there is, I do think
> > aiming to make GADTs an official part of Haskell 2020 should be a
> > priority.
> >
> > Best,
> >
> > /Henrik
> >
> > --
> > Henrik Nilsson
> > School of Computer Science
> > The University of Nottingham
> > n...@cs.nott.ac.uk 
> >
> >
> >
> >
> > This message and any attachment are intended solely for the addressee
> > and may contain confidential information. If you have received this
> > message in error, please send it back to me, and immediately delete it.
> > Please do not use, copy or disclose the information contained in this
> > message or in any attachment.  Any views or opinions expressed by the
> > author of this email do not necessarily reflect the views of the
> > University of Nottingham.
> >
> > This message has been checked for viruses but the contents of an
> > attachment may still contain software viruses which could damage your
> > computer system, you are advised to perform your own checks. Email
> > communications with the University of Nottingham may be monitored as
> > permitted by UK legislation.
> >
> > ___
> > 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

[Carter Schonwald]

On Sat, Apr 30, 2016, 10:16 AM Takenobu Tani  wrote:

> Hi Prime,
>
> This is additional information to organize my brain.
>
> This issue also occurs in single thread.
> Especially, when they have side effects.
>
>seq exp1 exp2
>
> Because compiler can always re-order two expressions
> in accordance with seq's denotational semantics.
>
> Regards,
> Takenobu
>

That requires / presumes a none idempotent use of unsafe perform io in
those  sub expressions right?



>
> 2016-04-30 16:11 GMT+09:00 Takenobu Tani :
>
>> Hi Jose and Cale,
>>
>> Thank you for clear and detailed explanation.
>>
>> short summary:
>>
>>  * `seq`  used to eliminate/manage space leaks
>>  * `pseq` used to specify order of evaluation
>>
>>  * `seq` is a bad name, but well established.
>>  * If we introduce parallelism to standard, we need `pseq` or some method.
>>
>>
>> It's depending on whether or not corresponding to the parallelism.
>> I learned a lot. Thank you very much.
>>
>> Regards,
>> Takenobu
>>
>> 2016-04-30 8:17 GMT+09:00 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 

Re: Chairship / responsibility

[Carter Schonwald]

On Saturday, April 30, 2016, Henrik Nilsson 
wrote:

> Hi all,
>
> > It was my understanding that Herbert would be the chair when I asked
> > to be on the committee, and the fact that this question was already
> > answer was a factor in my decision to try to help.
>
> I agree completely with this.
>
>
I as well, Herbert chairing was a big part of why I thought participating
would be a productive and worthwhile experience that would accomplish its
stated goals.



> And thanks to Herbert for now having completed the first step of the
> reboot.
>
> Best,
>
> /Henrik
>
> --
> Henrik Nilsson
> School of Computer Science
> The University of Nottingham
> n...@cs.nott.ac.uk
>
>
>
>
> This message and any attachment are intended solely for the addressee
> and may contain confidential information. If you have received this
> message in error, please send it back to me, and immediately delete it.
> Please do not use, copy or disclose the information contained in this
> message or in any attachment.  Any views or opinions expressed by the
> author of this email do not necessarily reflect the views of the
> University of Nottingham.
>
> This message has been checked for viruses but the contents of an
> attachment may still contain software viruses which could damage your
> computer system, you are advised to perform your own checks. Email
> communications with the University of Nottingham may be monitored as
> permitted by UK legislation.
>
> ___
> 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

[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: Breaking Changes and Long Term Support Haskell

[Carter Schonwald]

Well said!

I do have a small worry that the longer roll out window will be harder to
manage given that every thing is done by (outstanding) volunteers.  But
maybe the answer there is that ghc should do major version releases more
frequently :), eg every 9 months instead of every 12! 

On Wednesday, October 21, 2015, Dan Doel  wrote:

> Hello,
>
> I'm Dan Doel. I'm on the core libraries committee (though I'm speaking
> only for myself). As I recall, one of the reasons I got tapped for it
> was due to my having some historical knowledge about Haskell; not
> because I was there, but because I've gone back and looked at some old
> reports and whatnot (and sometimes think they're better than what we
> have now).
>
> But, I was around (of course) when the core libraries committee
> started up, so perhaps I can play the role of historian for this as
> well.
>
> The reason the committee exists is because a couple years ago, people
> brought up the ideas that were finally realized in the
> Applicative-Monad proposal and the Foldable-Traversable proposal. A
> lot of people weighed in saying they thought they were a good idea,
> and significantly fewer people weighed in saying they thought that it
> shouldn't happen for various reasons---roughly the same things that
> people are still bringing up about these proposals.
>
> This wasn't the first time that happened, either. I think it was
> widely agreed among most users that Functor should be a superclass of
> Monad since I started learning Haskell around 10 years ago. And once
> Applicative was introduced, it was agreed that that should go in the
> middle of the two. But it appeared that it would never happen, despite
> a significant majority thinking it should, because no one wanted to do
> anything without pretty much unanimous consent.
>
> So, one question that got raised is: why should this majority of
> people even use Haskell/GHC anymore? Why shouldn't they start using
> some other language that will let them change 15-year-old mistakes, or
> adapt to ideas that weren't even available at that time (but are still
> fairly old and established, all things considered). And the answer was
> that there should be some body empowered to decide to move forward
> with these ideas, even if there is some dissent. And frankly, it
> wasn't going to be the prime committee, because it hadn't shown any
> activity in something like 3 years at the time, and even when it was
> active, it didn't make anywhere near the sort of changes that were
> being discussed.
>
> And the kicker to me is, many things that people are complaining about
> again (e.g. the FTP) were the very things that the committee was
> established to execute. I don't think we had a formal vote on that
> proposal, because we didn't need to. Our existence was in part to
> execute that proposal (and AMP). And then a year ago, when it was
> finally time to release the changes, there was another ruckus. And we
> still didn't have a CLC vote on the matter. What we did was conduct a
> community poll, and then SPJ reviewed the submissions. But I don't
> mean to pass the buck to him, because I'm pretty sure he was worried
> that we were crazy, and overstepping our bounds. Just, the results of
> the survey were sufficient for him to not overrule us.
>
> So my point is this: there seems to be some sentiment that the core
> libraries committee is unsound, and making bad decisions. But the
> complaints are mostly not even about actual decisions we made (aside
> from maybe Lennart Augustsson's, where he is unhappy with details of
> the FTP that you can blame on us, but were designed to break the least
> code, instead of being the most elegant; if we had pleased him more,
> we would have pleased others less). They are about the reasons for
> founding the committee in the first place. You can blame us, if you
> like, because I think it's certain that we would have approved them if
> we had formally voted. We just didn't even need to do so.
>
> Forgive me if I'm wrong, but suggestions that these decisions should
> have been deferred to a Haskell Prime committee mean, to me, that the
> hope is that they would have been rejected. That the Haskell Prime
> committee should have just vetoed these proposals that something like
> 80% or more of practicing Haskell users (as far as we can tell) wanted
> for years before they finally happened. That the Haskell Prime
> committee should be responsible for enforcing the very status quo that
> led to the CLC in the first place, where proposals with broad support
> but minority dissent never pass for various core modules.
>
> If this is the case, then one could simply repose the earlier
> question: why should most of these people stick around to obey by the
> Haskell Prime committee's pronouncements, instead of getting to work
> on a language that incorporates their input?
>
> And if it isn't, then I don't ultimately understand what the
> complaints are. We try to 

Re: [Haskell-cafe] Several default implementations for instance methods

[Carter Schonwald]

hrm, so youre wanting something even smarter than the MINIMAL pragma stuff,
namely
depending on which subset of the complementary methods are defined, define
this method differently?

On Sat, Oct 4, 2014 at 11:44 AM, Andreas Abel ab...@chalmers.se wrote:

 Consider the following class for an overloaded pretty printer.  For
 atomic data (numeric types, String etc.) one would implement
 prettyShow, for complex data either pretty or prettyPrec.

  import Text.PrettyPrint
 
  class Pretty a where
pretty  :: a - Doc
prettyShow  :: a - String
prettyPrec  :: Int - a - Doc

 Implementing one of these methods should be enough, giving default
 implementations for the other two.

 It is easy to get prettyShow and prettyPrec from pretty.

prettyShow = render . pretty
prettyPrec = const . pretty

 However, to define pretty from one of the others, I need two default
 implementations.

pretty = text . prettyShow
pretty = prettyPrec 0

 Is there a way to get this to work?

 Workarounds (not entirely satisfactory): Technically, one could define
 a cycle of default implementations.  Alternative 1:

pretty   = prettyPrec 0
prettyShow   = render . pretty
prettyPrec _ = text . prettyShow

 Problem: Here, if pretty is defined,

prettyPrec _ = text . render . pretty

 instead of just

prettyPrec _ = pretty

 and (text . render) is not the identity (destroys inner document
 structure).

 Alternative 2:

 pretty   = text . prettyShow
 prettyShow   = render . prettyPrec 0
 prettyPrec _ = pretty

 Problem: Here, if prettyPrec is defined,

 pretty = text . render . prettyPrec 0

 instead of just

 pretty = prettyPrec 0

 I guess alternative 2 is worse than alternative 1, as one would
 usually define prettyPrec to get pretty, and not the otherway round.
 But none of these two alternatives really does the job.

 --
 Andreas AbelDu bist der geliebte Mensch.

 Department of Computer Science and Engineering
 Chalmers and Gothenburg University, Sweden

 andreas.a...@gu.se
 http://www2.tcs.ifi.lmu.de/~abel/
 ___
 Haskell-Cafe mailing list
 haskell-c...@haskell.org
 http://www.haskell.org/mailman/listinfo/haskell-cafe

___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime