Re: LAST CALL to comment on the Applicative/Monad Proposal

[Philippa Cowderoy]

On 17/01/2019 16:46, Mario Blažević wrote:

On 2019-01-16 3:26 p.m., Philippa Cowderoy wrote:

...
I'd like to thank you for your work - myself I'm infamously unable to 
get things done (to the point of unemployability), and I've stayed 
off the committee precisely because I can appreciate the effort 
involved.


Apologies, for some reason I thought you were on the committee. 
Your self-description sounds like you'd fit right in.


I couldn't possibly comment! I'll admit it's left me with an eye for 
small-but-significant changes though. A lot of my wider involvement with 
the community has been of a more "social" nature, including my stint as 
Anglohaskell's meta-organiser and sometimes organiser, though I also 
mentored the Summer of Code project that got Parsec 3 off the ground 
once upon a time too.


Thinking about it, that one does suggest I may have a talent for causing 
inevitable yet untold chaos! Perhaps that made it inevitable that 
someone would invite me onto this list in the dim and distant past?


--
Philippa

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

Re: LAST CALL to comment on the Appicative/Monad Proposal

[Philippa Cowderoy]

On 18/12/2018 18:02, Henrik Nilsson wrote:

Moreover, while there is little risk of confusion when arrow
syntax is used, looking just at names, the fact is that the use of the
distinct "returnA" also sends a similar signal to the reader, and
consequently there is a certain consistency in distinct names being
used for the three different computational notions for which 
(variations of) do-notation is provided.


I'm reminded that once upon a time I suggested what we now call 
ApplicativeDo start off with its own keyword for specifically 
Applicative code and that what it now tries to do might be possible! The 
lexical bikeshedding doesn't strike me as fun though.


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

Re: LAST CALL to comment on the Applicative/Monad Proposal

[Philippa Cowderoy]

On 18/12/2018 07:38, Herbert Valerio Riedel wrote:

Hello Mario et al.,

On Tue, Dec 18, 2018 at 4:17 AM Mario Blažević  wrote:

While you're reviewing AMP, please take a bit of time to also comment on
the related new MonadPlus excise proposal at
https://github.com/haskell/rfcs/pull/23

The proposal is very short so it should be an easy decision. Thank you.

As I've explained already on the RFC, I refuse (i.e. to make this very
clear: I'm exercising my veto) to accept the AMP change without also
at least a commitment to MFP and MRP. And note that the committee was
created with the explicit request from SPJ that it ought to be a
consensus-based decision process rather than a democratic voting
process -- and there isn't consensus in this matter as far as I'm
concerned.



To be clear: you would prefer the Report's status quo to AMP without MFP 
and MRP? Because that looks likely to be where we're headed unless we 
wait out GHC implementing both and see if everyone is resigned to that 
result.


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

Re: LAST CALL to comment on the Appicative/Monad Proposal

[Philippa Cowderoy]

Not taken personally, don't worry. You've done enough picking up where 
I've failed to get work done over the years, too!


I'm trying to be deliberate about "this does raise this issue but it 
isn't a blocker and can be separated out" pretty much precisely so I can 
be cheerfully ignored if nobody else cares.


I may have tweeted some minor irritation about how when it comes to my 
code, ApplicativeDo fails to give a, er, *> though :)


<$ could reasonably be rebound to |- in some of my code, and the main 
reason I don't is I'm using it to implement a type system which has its 
own turnstile. Which I'm pretty sure I told you years ago, but it may be 
mildly new to others here.


On 18/12/2018 15:15, Cale Gibbard wrote:
I guess I didn't mean to pick on your suggestion exactly -- the 
comments on the pull request triggered my remark even moreso, but I 
was on my phone and it was slightly easier to reply here.


Where I work, we've come to calling <$ "ice cream cone", so perhaps <* 
is "snow cone", lol.


It's definitely valuable to think about and discuss where the language 
might go, but every time I see that discussion in the context of 
producing the Haskell Report, I think about how H2010 went almost 
nowhere because of how this kind of discussion makes it easy to not 
decide on what any particular change to the Report might be, and sort 
of wish that we had a Report which was current at all...


On Tue, 18 Dec 2018 at 10:07 Philippa Cowderoy <mailto:fli...@flippac.org>> wrote:


Getting to ditch a similar connotation in do notation is exactly
why I've started this thread, of course! Some instances are far
less about having pure/return, at least without some more powerful
constructs we can't have in a standardised Haskell just yet. It's
maybe a personal irritation that ApplicativeDo outright fails in
that situation.

I was slightly appalled when I realised just now what
pronunciations of *> and <* I could most easily justify if nobody
else comes up with a suggestion - I think <* might be "klap".

I do think there's value in wondering whether there are small
changes to GHC we might request if nobody else does it. But that's
partly because the Report has to be descriptive by default -
otherwise there's no good institutional eye on neatening things up
over time that has an eye on standards rather than the concerns
that drive GHC.

Fundamentally, if I'd wanted to drag up MRP rather than round off
an edge, I would've done so explicitly! If someone wants to tell
me where to nag the GHC folks I guess I might find the time. But
I'm definitely looking at removing warts in the context of things
that are already happening myself.

On 18/12/2018 14:52, Cale Gibbard wrote:

Is it just me, or is all the discussion in these threads much
more easily resolved if the Report is simply a report? Describe
what is, rather than what you wish it was, and there's much less
room for disagreement. A future Report can describe the way that
these things work differently in the future when the changes
actually happen in the implementation(s).

I don't know about anyone else, but at least from my perspective
the value of the Report is in being valid documentation. The
extent to which it fails to describe the actual family of
languages we're presently writing code in is the extent to which
it is failing to be a useful resource for our daily lives.

I dunno, I feel kind of strange when people talk about removing
'return' for example, since it's very unlikely to go anywhere any
time soon given how much code it is referenced in. It would be
practically unreasonable even to try to deprecate it. Given that
the Report is going to discuss this part of the language, it
makes sense that it should be documented.

Secondarily, it's a bit hard to describe why this is, but I
personally find it a bit obnoxious whenever someone uses 'pure'
rather than 'return' if the functor is known to be an instance of
Monad and the generality isn't needed. It's a kind of signal that
the code we're writing is (and perhaps needs to be)
Applicative-polymorphic, or that we lack a Monad instance. So
when I see it, I'm forced to consider for a moment why that might
be, and whether I've understood the context incorrectly (and if
it's not the case, that's sort of irritating).

So when I see a suggestion to remove 'return' altogether it's
sort of like "let's make everything mildly annoying to read
forever" (by forcing this thought about exactly how general the
code is, and making it slightly harder to guess the types at a
glance).

It's like while pure and return are equal whenever they would
both typecheck, they've come to have very different connotations
    about the surr

Re: LAST CALL to comment on the Appicative/Monad Proposal

[Philippa Cowderoy]

Getting to ditch a similar connotation in do notation is exactly why 
I've started this thread, of course! Some instances are far less about 
having pure/return, at least without some more powerful constructs we 
can't have in a standardised Haskell just yet. It's maybe a personal 
irritation that ApplicativeDo outright fails in that situation.


I was slightly appalled when I realised just now what pronunciations of 
*> and <* I could most easily justify if nobody else comes up with a 
suggestion - I think <* might be "klap".


I do think there's value in wondering whether there are small changes to 
GHC we might request if nobody else does it. But that's partly because 
the Report has to be descriptive by default - otherwise there's no good 
institutional eye on neatening things up over time that has an eye on 
standards rather than the concerns that drive GHC.


Fundamentally, if I'd wanted to drag up MRP rather than round off an 
edge, I would've done so explicitly! If someone wants to tell me where 
to nag the GHC folks I guess I might find the time. But I'm definitely 
looking at removing warts in the context of things that are already 
happening myself.


On 18/12/2018 14:52, Cale Gibbard wrote:
Is it just me, or is all the discussion in these threads much more 
easily resolved if the Report is simply a report? Describe what is, 
rather than what you wish it was, and there's much less room for 
disagreement. A future Report can describe the way that these things 
work differently in the future when the changes actually happen in the 
implementation(s).


I don't know about anyone else, but at least from my perspective the 
value of the Report is in being valid documentation. The extent to 
which it fails to describe the actual family of languages we're 
presently writing code in is the extent to which it is failing to be a 
useful resource for our daily lives.


I dunno, I feel kind of strange when people talk about removing 
'return' for example, since it's very unlikely to go anywhere any time 
soon given how much code it is referenced in. It would be practically 
unreasonable even to try to deprecate it. Given that the Report is 
going to discuss this part of the language, it makes sense that it 
should be documented.


Secondarily, it's a bit hard to describe why this is, but I personally 
find it a bit obnoxious whenever someone uses 'pure' rather than 
'return' if the functor is known to be an instance of Monad and the 
generality isn't needed. It's a kind of signal that the code we're 
writing is (and perhaps needs to be) Applicative-polymorphic, or that 
we lack a Monad instance. So when I see it, I'm forced to consider for 
a moment why that might be, and whether I've understood the context 
incorrectly (and if it's not the case, that's sort of irritating).


So when I see a suggestion to remove 'return' altogether it's sort of 
like "let's make everything mildly annoying to read forever" (by 
forcing this thought about exactly how general the code is, and making 
it slightly harder to guess the types at a glance).


It's like while pure and return are equal whenever they would both 
typecheck, they've come to have very different connotations about the 
surrounding code.


On Tue, Dec 18, 2018, 05:42 Philippa Cowderoy, <mailto:fli...@flippac.org>> wrote:


I'm having a moment of fail trying to work out how to leave a comment.

Is there a reason (other than GHC not doing it yet) not to have do
notation use *> instead of >> in line with using the least
restrictive
function? I have some otherwise-nice logic programming code that
would
actively benefit from it and it seems like a missing step from here.

On 15/12/2018 23:46, Mario Blažević wrote:
> The very first RFC created
(https://github.com/haskell/rfcs/pull/1),
> the Applicative/Monad Proposal, has now reached the Last Call
stage.
> In order to ground the discussion, I have taken some time to update
> the Prelude and the text of the Haskell Report with its effects
before
> the call. The rendered report is available at
> https://github.com/blamario/rfcs/blob/amp/report/report/haskell.pdf
> for your review.
>
>
> TL;DR:
>
> The proposed changes to the report add the latest design of the
> Applicative and Alternative classes, but otherwise are
intentionally
> minimal. Any further modifications, like the MonadFail proposal or
> moving return out of the Monad class, should be relegated to new
RFCs.
>
>
> In some more detail, the changes are:
>
> 1. Applicative has been added as a subclass of Functor and
superclass
> of Monad, its methods and laws as currently defined in the base
> library. The class and all its methods (pure, (<*>), (<*), (*>),
and
> liftA2) are export

Re: LAST CALL to comment on the Applicative/Monad Proposal

[Philippa Cowderoy]

On 18/12/2018 13:41, Henrik Nilsson wrote:

Hi,

Philippa wrote:

> It's a lot easier to estimate ecosystem impact given a switch that'll
> find all the resulting errors and give everyone a chance to fail any
> tests.

Yes, a good point.

But just to be clear, the impact of some changes go well beyond what can
be assessed by looking at impact on an existing code base alone.
And that is one reason for why MRP has been, and remains, so
controversial.



Sure. I think the one conceptual shift do-uses-*> would create is that 
do notation no longer (except in the degenerate tail case) always brings 
a Monad constraint, instead it would bring Applicative unless something 
is bound with <-. If I'm right then that's certainly a long way short of 
MRP per se, which I'm not interested in discussing at this point :)


I'm not sure how much of a problem that would create for teachers - I 
imagine it depends very much on one's style, as it can even reinforce 
the idea that Monad is partly about (unconstrained) binding! Which is a 
plus if you like making the connection to ANF to some extent and letting 
people think about a family of machine models. I think that's something 
it might even be nice to let students play with in some circumstances? 
Though I've done all my teaching 1:1 or with very small groups myself 
and generally not to first year undergraduates. Nor have I seen how AMP 
is affecting teaching in general properly.


Certainly something I'd be happy to talk about more if and when there's 
time - realistically there's no good reason to hold up AMP over this 
when it could be treated as a third proposal which depends on AMP and 
which MRP mandates. Should I find a TLA for it?


Is there somewhere else I should be pasting my thoughts here to? Any 
other comments? If I'm wasting people's time I'd rather stop, but if 
this is a viable proposal refactoring that might be another matter.


Cheers,
Philippa

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

Re: LAST CALL to comment on the Applicative/Monad Proposal

[Philippa Cowderoy]

On 18/12/2018 12:23, Henrik Nilsson wrote:

Hi all,

Well, I am in favour of discussing AMP and MRP separately


Whoops, my bad, wasn't familiar enough to realise my suggestion was 
effectively covered by MRP!


I think it might be a legitimate thing to tease do-uses-*> apart from 
MRP-as-a-whole as it only affects do notation and is already justifiable 
in terms of AMP's rationale alone, but I'll entirely understand if it's 
a bigger can of worms than is worth it at this point.


That said, if there's any appetite for it we could ask for the relevant 
toggles to be added to GHC and gather some data, possibly branching this 
off as an AMP-or-MRP thing? As I've said, I have a use case for it today 
and in the absence of other extensions or alterations. It's a lot easier 
to estimate ecosystem impact given a switch that'll find all the 
resulting errors and give everyone a chance to fail any tests.


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

Re: LAST CALL to comment on the Appicative/Monad Proposal

[Philippa Cowderoy]

I'm having a moment of fail trying to work out how to leave a comment.

Is there a reason (other than GHC not doing it yet) not to have do 
notation use *> instead of >> in line with using the least restrictive 
function? I have some otherwise-nice logic programming code that would 
actively benefit from it and it seems like a missing step from here.


On 15/12/2018 23:46, Mario Blažević wrote:
The very first RFC created (https://github.com/haskell/rfcs/pull/1), 
the Applicative/Monad Proposal, has now reached the Last Call stage. 
In order to ground the discussion, I have taken some time to update 
the Prelude and the text of the Haskell Report with its effects before 
the call. The rendered report is available at 
https://github.com/blamario/rfcs/blob/amp/report/report/haskell.pdf 
for your review.



TL;DR:

The proposed changes to the report add the latest design of the 
Applicative and Alternative classes, but otherwise are intentionally 
minimal. Any further modifications, like the MonadFail proposal or 
moving return out of the Monad class, should be relegated to new RFCs.



In some more detail, the changes are:

1. Applicative has been added as a subclass of Functor and superclass 
of Monad, its methods and laws as currently defined in the base 
library. The class and all its methods (pure, (<*>), (<*), (*>), and 
liftA2) are exported from Prelude, but no other Applicative-related 
functions (like liftA3) are.


2. The Functor class definition has been moved from module 
Control.Monad to Control.Applicative in order to avoid circular 
imports. Note that neither module is a part of the language 
specification.


3. The Monad class has been left unmodified, apart from making 
Applicative its superclass and adding  return a == pure a  as a law.


4. Alternative has been added to the Control.Applicative module, but 
not to Prelude. This is the same treatment already meted to MonadPlus. 
I'm unsure why MonadPlus even exists in the report, as it has no 
relevance to the language specification, and I would gladly remove 
both classes.



Please take some time within the following three weeks (including some 
extra allowance for the upcoming holiday breaks) to vote for or 
against the proposal, or to leave a comment with suggestions for its 
improvement.



___
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: Helium II

[Philippa Cowderoy]

Good to know!

It's important to keep morale up and do what we can. I imagine that'll 
be small details in my case, but there's meaningful modernisation to be 
done even if major type system features are still too difficult to 
standardise just yet.


On 03/12/2018 21:23, Carter Schonwald wrote:
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 
mailto: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 reasonI 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
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime

Re: Quo vadis?

[Philippa Cowderoy]

On 09/10/2018 00:58, Mario Blažević wrote:

On 2018-10-07 11:32 PM, Philippa Cowderoy wrote:


I'd be remiss if I didn't suggest a candidate with a specific 
problem, a specific goal and a possible solution to its problem. So, 
a modest proposal:


- Standardise OverloadedStrings as an available-but-disabled feature
- Allow default statements for the IsString class without 
OverloadedStrings, using that type for all string literals
- At some future stage, we can use this to migrate away from [Char] 
as the default string literal type
- The Haskell2010 pragma and its successors can be used to ensure 
code written to standard doesn't suffer bit rot when migration happens



The second bullet point could use some clarification. Would you mind 
commenting on the existing defaulting proposal at 
https://github.com/haskell/rfcs/pull/18 ?





Found the spoons - done!
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime

Re: Quo vadis?

[Philippa Cowderoy]

On 09/10/2018 00:58, Mario Blažević wrote:

On 2018-10-07 11:32 PM, Philippa Cowderoy wrote:


I'd be remiss if I didn't suggest a candidate with a specific 
problem, a specific goal and a possible solution to its problem. So, 
a modest proposal:


- Standardise OverloadedStrings as an available-but-disabled feature
- Allow default statements for the IsString class without 
OverloadedStrings, using that type for all string literals
- At some future stage, we can use this to migrate away from [Char] 
as the default string literal type
- The Haskell2010 pragma and its successors can be used to ensure 
code written to standard doesn't suffer bit rot when migration happens



The second bullet point could use some clarification. Would you mind 
commenting on the existing defaulting proposal at 
https://github.com/haskell/rfcs/pull/18 ?





I've been away from the overall process and I'm not in best health right 
now, so it'll take a while to catch up but I'll do my best.


The gist (which someone else may have covered) is that it's not 
overloading if you have exactly one type of string literals, even if we 
let the user say which type it is. I've read enough to see I'll have to 
have my thinking cap on while writing much more than that as a useful 
comment though, not least because of the interaction with an imported 
defaults mechanism that normally needs to work with a sequence of defaults.

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

Re: Quo vadis?

[Philippa Cowderoy]

On 05/10/2018 18:05, Simon Peyton Jones via Haskell-prime wrote:

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.


To pick an example, I'm left wondering if we can achieve a minimal GADT 
specification that doesn't have to stay too stable in the presence of 
extensions. Changes in its behaviour would need documenting though and 
documenting the behaviour of inference is notoriously difficult at present.


While I have some ideas about documenting inference, I remain as 
infamously low on energy as ever - I'm not up to trying it with 
Haskell2010, let alone GHC, and I wouldn't want to make a business case 
for someone else trying it yet! I think it's a problem that sooner or 
later standardised Haskell will need to address though: we're a long way 
past the "Hindley-Milner plus simple, well-behaved constraints that 
don't need annotations" approach that typeclasses helped push the limits 
of.

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

Re: Quo vadis?

[Philippa Cowderoy]

On 08/10/2018 02:51, Mario Blažević wrote:


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 suspect we need to follow the lead of other languages here and accept 
that the LANGUAGE pragma is actually a necessity and a positive good for 
engineering in the presence of changing language versions.


That would mean we should support more standardised pragmas in the vein 
of the existing ones in the report, and perhaps that GHC should give 
more information about the stability of extensions. Perhaps when an 
extension was first introduced and the GHC versions in which the last 
two changes more significant than "bug fix" happened? There might even 
be a need for versioning of extensions.


I'd be remiss if I didn't suggest a candidate with a specific problem, a 
specific goal and a possible solution to its problem. So, a modest proposal:


- Standardise OverloadedStrings as an available-but-disabled feature
- Allow default statements for the IsString class without 
OverloadedStrings, using that type for all string literals
- At some future stage, we can use this to migrate away from [Char] as 
the default string literal type
- The Haskell2010 pragma and its successors can be used to ensure code 
written to standard doesn't suffer bit rot when migration happens

___
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

[Philippa Cowderoy]

You're implicitly arguing that no language should have support for 
declaring informal intentions. That's rather more controversial than you 
might think and it's worth separating out as a subject.


The fact you cheerfully talk about making return and bind inherently 
related via superclass constraints is pretty suggestive. Away from 
monads, there are a lot of other uses for return-like behaviour that 
have a different (if often-related) set of laws. Which is exactly why 
many people want them to be completely separate superclasses of Monad. 
It's only when they're used to form a monad that those extra laws show 
up. Which no, Haskell can't enforce, but there's a big difference 
between "this breaks because seq in a partial language weirds things" 
and "this would be broken in a total setting too". What happens when I 
legitimately want both operations but a different set of laws, and don't 
want my stuff being passed to things that reasonably expect the monad 
laws to hold?


Asking a researcher who's producing actual results "what's the point?" 
is more than a little inflammatory, too. Helium is not accountable to us.



On 06/10/2018 04:18, Anthony Clayden wrote:


On Sat, 6 Oct 2018 at 9:47 AM, Petr Pudlák > 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 

Re: Update on Haskell Prime reboot?

[Philippa Cowderoy]

Agreed - the appropriate means for specifying the type system is 
something I'm not sure we have a truly good answer for at this point 
alas. We're way past being able to rely on an informal "H-M + 
constraints from typeclasses" style description if we want to describe 
even extensions that have been around 15+ years.


(I am not on the committee etc etc, just have spent much time pondering 
related issues!)


On 22/04/2016 20:49, Andres Loeh wrote:

Hi.

I've been talking to Herbert from time to time, and I know he's having
a draft announcement lying around, and is still planning on properly
starting the process soon, and has (this is my opinion, not his) just
been falling into the trap of waiting for a "good moment" which then
never comes.

I'm personally still eager to get the discussions about a new standard started.

While it's true that the old Haskell Prime committee has been doing
good work in creating some sort of catalogue of issues and extensions
at the time, it's still far from proper standardization. And indeed, I
think the bulk of the work that goes into a new standard in my opinon
is to work out all the corner cases and the actual specification of
the extensions. It's less important which ones ultimately go in or
stay out, but actually specfiying them properly is already going to be
a good step forward.

Cheers,
   Andres


On Fri, Apr 22, 2016 at 7:55 PM, José Manuel Calderón Trilla
 wrote:

Hi Richard,


As a concrete suggestion, I wonder if we should have two goals:

1. Write down an updated standard for Haskell.

2. Write down pre-standards for several extensions.

I agree with both of these. It may even be useful to use goal 2 as a
stepping stone to determine what extensions should receive the extra
attention necessary (if any) to be part of goal 1. Were you thinking
that these pre-standards would look something like Mark Jones's
'Typing Haskell in Haskell' paper? A simplified and clear
specification in the form of a Haskell program would go a long way in
clarifying the meaning of certain extensions. To use your example, you
could imagine an implementation of GADTs that forms the baseline of
what the GADT extension should mean (implementations should accept at
least what this one does). That might be too ambitious though.

A lot of the 'obvious' extensions were discussed that last time the
Haskell Prime committee was active, so a lot of groundwork has been
laid already. The most important step right now is empowering people
to move forward with the process.

Herbert Valerio Riedel is the chair of the reboot, and as such gets
final say on who is a member of the committee and any timeline for
deciding. That being said, I think the aim should be to have the
committee membership decided soon and start discussing what the
priorities should be. I'm partial to suggesting a face to face meeting
at ICFP, but realize that it is difficult for many to attend to ICFP.

Cheers,

José


On Fri, Apr 22, 2016 at 9:33 AM, Richard Eisenberg  wrote:

I stand by ready to debate standards and would enjoy moving this process 
forward. However, I'm not in a position where I can lead at the moment -- just 
too consumed by other tasks right now.

As a concrete suggestion, I wonder if we should have two goals:

1. Write down an updated standard for Haskell.

2. Write down pre-standards for several extensions.

About (2): I'm very sympathetic to a recent post on Haskell-cafe about having formal 
descriptions of language extensions. It is not our purview to document GHC. However, 
several extensions are in very common use, but might not be quite ready for a language 
standard. Chief among these, in my opinion, is GADTs. GADTs are problematic from a 
standardization standpoint because it's quite hard to specify when a GADT pattern-match 
type-checks, without resorting to discussion of unification variables. For this reason, I 
would be hesitant about putting GADTs in a standard. On the other hand, it shouldn't be 
too hard to specify some sort of minimum implementation that individual compilers can 
build on. I'm calling such a description a "pre-standard".

Thoughts?

Richard

On Apr 21, 2016, at 5:22 PM, José Manuel Calderón Trilla  wrote:


Hello all,

I'm curious if there is any progress on the reboot of the Haskell
Prime committee. It has been six months since the closing of
nominations and there hasn't been any word that I'm aware of. I've
also spoken to a few others that have self-nominated and they too have
not heard any news.

Personally, I feel that a new standard is very important for the
future health of the community. Several threads on the mailing list
and posts on the web, such as one on reddit today [1], show a desire
from the community for a major consolidation effort.

If there is any way that I can help the process along I would be glad
to do so. It would be a shame to allow for the enthusiasm for a new
committee fade away.

Cheers,

José


[1]: 

Re: Update on Haskell Prime reboot?

[Philippa Cowderoy]

In all honesty, Typing Haskell in Haskell is about as far as anyone 
should push typechecking and type inference while claiming to still work 
in a functional style. I don't think a good GADT pre-spec looks like 
functional programming at all, it's a [constraint] logic programming 
problem and part of what we're looking to establish is the minimum 
information flow people can expect during inference for a given amount 
of syntactic effort.


I'm not saying I never write the implementations in haskell! But they 
tend to involve a lot of "how to implement the constraint system" and 
then a bunch of transliterated typing rules. A good spec for "enough 
annotation this should work easily" would be useful as something that 
permits other implementations to experiment with different extensions in 
combination though!


On 22/04/2016 18:55, José Manuel Calderón Trilla wrote:

Hi Richard,


As a concrete suggestion, I wonder if we should have two goals:

1. Write down an updated standard for Haskell.

2. Write down pre-standards for several extensions.

I agree with both of these. It may even be useful to use goal 2 as a
stepping stone to determine what extensions should receive the extra
attention necessary (if any) to be part of goal 1. Were you thinking
that these pre-standards would look something like Mark Jones's
'Typing Haskell in Haskell' paper? A simplified and clear
specification in the form of a Haskell program would go a long way in
clarifying the meaning of certain extensions. To use your example, you
could imagine an implementation of GADTs that forms the baseline of
what the GADT extension should mean (implementations should accept at
least what this one does). That might be too ambitious though.

A lot of the 'obvious' extensions were discussed that last time the
Haskell Prime committee was active, so a lot of groundwork has been
laid already. The most important step right now is empowering people
to move forward with the process.

Herbert Valerio Riedel is the chair of the reboot, and as such gets
final say on who is a member of the committee and any timeline for
deciding. That being said, I think the aim should be to have the
committee membership decided soon and start discussing what the
priorities should be. I'm partial to suggesting a face to face meeting
at ICFP, but realize that it is difficult for many to attend to ICFP.

Cheers,

José


On Fri, Apr 22, 2016 at 9:33 AM, Richard Eisenberg  wrote:

I stand by ready to debate standards and would enjoy moving this process 
forward. However, I'm not in a position where I can lead at the moment -- just 
too consumed by other tasks right now.

As a concrete suggestion, I wonder if we should have two goals:

1. Write down an updated standard for Haskell.

2. Write down pre-standards for several extensions.

About (2): I'm very sympathetic to a recent post on Haskell-cafe about having formal 
descriptions of language extensions. It is not our purview to document GHC. However, 
several extensions are in very common use, but might not be quite ready for a language 
standard. Chief among these, in my opinion, is GADTs. GADTs are problematic from a 
standardization standpoint because it's quite hard to specify when a GADT pattern-match 
type-checks, without resorting to discussion of unification variables. For this reason, I 
would be hesitant about putting GADTs in a standard. On the other hand, it shouldn't be 
too hard to specify some sort of minimum implementation that individual compilers can 
build on. I'm calling such a description a "pre-standard".

Thoughts?

Richard

On Apr 21, 2016, at 5:22 PM, José Manuel Calderón Trilla  wrote:


Hello all,

I'm curious if there is any progress on the reboot of the Haskell
Prime committee. It has been six months since the closing of
nominations and there hasn't been any word that I'm aware of. I've
also spoken to a few others that have self-nominated and they too have
not heard any news.

Personally, I feel that a new standard is very important for the
future health of the community. Several threads on the mailing list
and posts on the web, such as one on reddit today [1], show a desire
from the community for a major consolidation effort.

If there is any way that I can help the process along I would be glad
to do so. It would be a shame to allow for the enthusiasm for a new
committee fade away.

Cheers,

José


[1]: 
https://www.reddit.com/r/haskell/comments/4fsuvu/can_we_have_xhaskell2016_which_turns_on_the_most/
___
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

Re: Meta-point: backward compatibility

[Philippa Cowderoy]

On Wed, 23 Apr 2008, Johan Tibell wrote:

 An interesting question. What is the goal of Haskell'? Is it to, like
 Python 3000, fix warts in the language in an (somewhat) incompatible
 way or is it to just standardize current practice? I think we need
 both, I just don't know which of the two Haskell' is.
 

Current practice often involves removing certain warts anyway - the MR 
being a great example.

-- 
[EMAIL PROTECTED]

Ivanova is always right.
I will listen to Ivanova.
I will not ignore Ivanova's recomendations.
Ivanova is God.
And, if this ever happens again, Ivanova will personally rip your lungs out!
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime

Re: Status of Haskell Prime Language definition

[Philippa Cowderoy]

On Tue, 16 Oct 2007, apfelmus wrote:

 Robert Will wrote:
  Could someone please summarize the current status and planned time
  line for Haskell'?
 
 John Launchbury wrote:
  Up to now, the Haskell' effort has been mostly about exploring the
  possibilities, to find out what could be in Haskell', and to scope out
  what it might mean. We've now reached the stage where we want to do the
  opposite, namely trying to pin down what we definitely want to have in
  the standard, and what it should look like in detail.
 
 There's still a major technical obstacle, namely  functional dependencies
 vs  associated type synonyms .

The right thing is probably to admit that it's going to take a few years 
to resolve adequately, get a standard now and get a new standard or an 
addendum when those few years are up. This has the problem that it leaves 
us with crippled interfaces for standard libraries, but we already have 
that problem!

-- 
[EMAIL PROTECTED]

Sometimes you gotta fight fire with fire. Most
of the time you just get burnt worse though.
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime

Re: Global variables

[Philippa Cowderoy]

On Thu, 1 Feb 2007, David House wrote:

 I think that's too safe-looking. Anything that translates to something
 involving unsafe* should be tagged with 'unsafe' somewhere as well.
 Also, as unsafe* is still compiler specific, I think a pragma is
 probably most appropriate:
 
 {-# GLOBAL-MUTVAR #-}
 i :: IORef Int
 i = unsafePerformIO (newIORef 1)
 

There might be a more sensible way to handle it while retaining the meat 
of Bulat's proposal, but I don't think it can really be done without 
making significant changes to the module system - it amounts to having 
initialiser actions, and once you've got those there're all sorts of 
things that rapidly become desirable. I've had a couple of occasions where 
being able to treat an entire module as being within a monad or an arrow 
could've been used to good effect though.

-- 
[EMAIL PROTECTED]

The reason for this is simple yet profound. Equations of the form
x = x are completely useless. All interesting equations are of the
form x = y. -- John C. Baez
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime

Re: [Haskell] Views in Haskell

[Philippa Cowderoy]

On Wed, 24 Jan 2007, Claus Reinke wrote:

 the alternative I'm aiming for, as exhibited in the consP example, would be
 to build patterns systematically from view patterns used as abstract
 de-constructors, composed in the same way as one would compose the
 abstract constructors to build the abstract data structure. in other words,
 you define your pattern constructors once, with the adt, and export them;
 and anytime you want to match somethind of that abstract type, you simply
 compose your pattern from those abstract pattern constructors.
 

This would cause an awful lot of kludging to get around the fact you need 
to declare a new ADT to declare new abstract deconstructors, and requires 
an additional extension for abstract deconstructors to be typeclass 
methods - something abstract constructors can do for free. Neither seems 
gainful to me.

-- 
[EMAIL PROTECTED]

Performance anxiety leads to premature optimisation
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime

Re: Are pattern guards obsolete?

[Philippa Cowderoy]

On Wed, 13 Dec 2006, Yitzchak Gale wrote:

 Yitzchak Gale wrote:
   Of course, this is not really the joy of
   pattern guards. It is the joy of monads,
   with perhaps a few character strokes
   saved by a confusing overloading of (-).
 
 Philippa Cowderoy wrote:
  I don't find it any more confusing than the overloading
  of -.
 
 You mean that it is used both for lambda abstractions
 and for functional dependencies? True, but those
 are so different that there is no confusion.
 

You missed out case statements.

-- 
[EMAIL PROTECTED]

My religion says so explains your beliefs. But it doesn't explain
why I should hold them as well, let alone be restricted by them.
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime

Re: Are pattern guards obsolete?

[Philippa Cowderoy]

On Wed, 13 Dec 2006, Yitzchak Gale wrote:

 Philippa Cowderoy wrote:
   I don't find it any more confusing than the overloading
   of -.
 
 I wrote:
  You mean that it is used both for lambda abstractions
  and for functional dependencies? True, but those
  are so different that there is no confusion.
 
 Oh, and case. Also quite different.

This is what I get for replying straight away!

 Anyway, existing problems are not an excuse to
 repeat the mistake and make matters even worse.
 

I think my point is that I'm not aware of many people who actually think 
this is a problem or get confused.

-- 
[EMAIL PROTECTED]

There is no magic bullet. There are, however, plenty of bullets that
magically home in on feet when not used in exactly the right circumstances.
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime

Re: Are pattern guards obsolete?

[Philippa Cowderoy]

On Wed, 13 Dec 2006, Yitz Gale wrote:

 Donald Bruce Stewart [EMAIL PROTECTED] writes:
  The joy of pattern guards
  reveals once you have more conditions.
 
 Of course, this is not really the joy of
 pattern guards. It is the joy of monads,
 with perhaps a few character strokes
 saved by a confusing overloading of (-).
 

I don't find it any more confusing than the overloading of -. Note that 
it's not (-) - it's not an operator.

-- 
[EMAIL PROTECTED]

Sometimes you gotta fight fire with fire. Most
of the time you just get burnt worse though.
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime

Re: Teaching

[Philippa Cowderoy]

On Wed, 29 Nov 2006, Ashley Yakeley wrote:

 That something might confuse the beginning user should count for nothing if it
 does not annoy the more experienced user.
 

This experienced user regularly uses a haskell interpreter for a desk 
calculator, not to mention for producing readable budgets that show all 
the working. Removing defaulting would make that extremely tedious.

-- 
[EMAIL PROTECTED]

The reason for this is simple yet profound. Equations of the form
x = x are completely useless. All interesting equations are of the
form x = y. -- John C. Baez
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime

Re: Teaching

[Philippa Cowderoy]

On Thu, 30 Nov 2006, Iavor Diatchki wrote:

 Hello,
 
 On 11/30/06, Philippa Cowderoy [EMAIL PROTECTED] wrote:
  This experienced user regularly uses a haskell interpreter for a desk
  calculator, not to mention for producing readable budgets that show all
  the working. Removing defaulting would make that extremely tedious.
 
 I do what you suggest all the time (I mean using Hugs as a calculator)
 and I agree that it would be annoying without some sort of defaulting.
 However, I am not sure that this particular use justifies the
 addition of defaulting to the _language_.  For example, it is possible
 that defaulting is implemented as a switch to the command-line
 interpreter.
 

The more generalised Haskell-as-spreadsheet-replacement might, as that 
creates source files.

-- 
[EMAIL PROTECTED]

Performance anxiety leads to premature optimisation
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime

Re: Small note regarding the mailing list

[Philippa Cowderoy]

On Sat, 2 Sep 2006, isaac jones wrote:

 On Tue, 2006-08-29 at 14:04 +0200, Christophe Poucet wrote:
  Hello,
  
  Just a small request.  Would it be feasible to tag the Haskell-prime
  list in a similar manner as Haskell-cafe?
 
 I'd rather not.  If you want to be able to filter, you can use the
 Sender field which will always be:
 Sender: [EMAIL PROTECTED]
 

This isn't really enough if you're scan-reading a pile of stuff - are 
there any particularly good reasons to avoid the tags? They're pretty much 
standard practice.

-- 
[EMAIL PROTECTED]

A problem that's all in your head is still a problem.
Brain damage is but one form of mind damage.
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime

Re: Small note regarding the mailing list

[Philippa Cowderoy]

On Sat, 2 Sep 2006, Aaron Denney wrote:

 I misspoke -- I shouldn't have said out.  Send mailing list
 traffic to seperate mail folders, with seperate new mail indicators, and
 everything is golden.
 

Not really, 99% of the non-spam mail I get's from mailing lists so it 
gives the same problem as having a spam folder. I also get better workflow 
with a single inbox at the moment. 

-- 
[EMAIL PROTECTED]

The task of the academic is not to scale great 
intellectual mountains, but to flatten them.
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime

Re: small extension to `...` notation

[Philippa Cowderoy]

On Wed, 8 Mar 2006, Doaitse Swierstra wrote:

 In Haskell we write `f` in order to infixify the identifier f. In ABC the
 stuff between backquotes is not limited to an identifier, but any expression
 may occur there. This would allow one to write e.g.
 
  xs `zipWith (+)` ys
 
 In general  expr1 `expr2` expr3 = (expr2) expr1 expr3
 
 I think it is a small extension to Haskell, which does not break anything
 existing, and provides yet another opportunity to beautify one programs,
 especially in combination with programs like lhs2TeX.
 

There is one problem with this: it doesn't nest, you can't tell an opening 
from a closing backquote, which can cause problems when transforming or 
rearranging code. Possibly `(expr)` and the existing `identifier`?

-- 
[EMAIL PROTECTED]

'In Ankh-Morpork even the shit have a street to itself...
 Truly this is a land of opportunity.' - Detritus, Men at Arms
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://haskell.org/mailman/listinfo/haskell-prime

Re: exported pattern matching

[Philippa Cowderoy]

On Thu, 9 Feb 2006, S.J.Thompson wrote:

 
 Jim - it's worth looking  at the proposal for views, proposed by Warren
 Burton et al, accessible from
 
   http://haskell.galois.com/cgi-bin/haskell-prime/trac.cgi/wiki/Views
 

Myself I'm of the view transformational patterns (as described in 
http://citeseer.ist.psu.edu/299277.html) are more interesting - I can't 
help wondering why they were never implemented?

-- 
[EMAIL PROTECTED]

My religion says so explains your beliefs. But it doesn't explain 
why I should hold them as well, let alone be restricted by them.
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://haskell.org/mailman/listinfo/haskell-prime

Dictionary definitions on wiki

[Philippa Cowderoy]

I just added a ticket requesting that some definitions be added to the 
wiki (so that other pages and tickets can link to them, helping to 
demystify jargon for those who don't specialise in specific fields). I've 
also included quick definitions for predicative and impredicative in 
the ticket, as these were asked for on the mailing list earlier and will 
no doubt crop up again in type system discussions.

Would anyone like to act on this or contribute more definitions to the 
ticket while it's waiting?

-- 
[EMAIL PROTECTED]

Performance anxiety leads to premature optimisation
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://haskell.org/mailman/listinfo/haskell-prime

Re[2]: give equal rights to types and classes! :)

[Philippa Cowderoy]

On Wed, 1 Feb 2006, Bulat Ziganshin wrote:

 btw, on the http://haskell.galois.com/trac/haskell-prime/wiki/PartialTypeSigs
 author mean using underscore for (exists a . a) types
 

No I don't, for a number of technical reasons.

-- 
[EMAIL PROTECTED]

There is no magic bullet. There are, however, plenty of bullets that 
magically home in on feet when not used in exactly the right circumstances.
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://haskell.org/mailman/listinfo/haskell-prime