/
Simon
From: Haskell-prime On Behalf Of Anthony
Clayden
Sent: 06 October 2018 04:19
To: Petr Pudlák
Cc: haskell-prime@haskell.org
Subject: Re: A question about run-time errors when class members are undefined
On Sat, 6 Oct 2018 at 9:47 AM, Petr Pudlák
mailto:redir...@vodafone.co.nz>> wrote:
Am 08.10.2018 um 11:21 schrieb Anthony Clayden:
> I wonder how different would have been the history of Haskell if Wadler had
> not borrowed the terminology "class" and "method". Since Helium has a focus
> on Haskell learners/beginners: I wonder how much confusion we might have
> saved those
Am 06.10.2018 um 05:18 schrieb Anthony Clayden:
> On Sat, 6 Oct 2018 at 9:47 AM, Petr Pudlák wrote:
> 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.
Thank you Carlos, but oh dear
this is fast becoming as exasperating as the github rounds.
We've been talking about modular/scoped instances.
All of a sudden you've introduced MPTCs, which nobody even mentioned.
And you have a definition of "reachable" which is not GHC's definition:
'"reachable"
Hi.
A concise proposal for the introduction of MPTCs in Haskell follows.
A similar ghc-proposal has been written before, but without success
(certainly it would be better if some experimentation in ghc was done
first, as Carter suggested). The proposal is based essentially on the
following (1.
On Mon, 8 Oct 2018 at 8:41 PM, Simon Peyton Jones wrote
You may be interested in Carlos Camarao’s interesting work. For a long
> time now he has advocated (in effect) making each function into its own
> type class, rather that grouping them into classes. Perhaps that is in
> line with your
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
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
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
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
Em 2018-10-08 06:21, Anthony Clayden escreveu:
On Mon, 8 Oct 2018 at 8:41 PM, Simon Peyton Jones wrote:
You may be interested in Carlos Camarao’s interesting work. For a
long time now he has advocated (in effect) making each function into
its own type class, rather that grouping them into
oaded function".
AntC
*From:* Haskell-prime *On Behalf
Of *Anthony
> Clayden
> *Sent:* 06 October 2018 04:19
> *To:* Petr Pudlák
> *Cc:* haskell-prime@haskell.org
> *Subject:* Re: A question about run-time errors when class members are
> undefined
>
>
>
>
>
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
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
On Fri, 5 Oct 2018 at 9:00 PM, Jurriaan Hage wrote:
>
> We first go the slavish route, to provide a basis for changing things
> later.
Ah. That comment seemed strange, but I've just read up on Helium: you're
aiming to provide a beginners' environment for Haskell.
Then without type classes,
Hi everyone,
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,
such as the important laws between `return` and `>>=`. And then for example
a class with just `return` doesn't give any information what
On Fri, 5 Oct 2018 at 9:00 PM, Jurriaan Hage wrote:
>
> We first go the slavish route, to provide a basis for changing things
> later.
>
> So I am not looking for alternative ways of doing this, I am just
> wondering whether there is a rationale for doing things this way.
> The document does not
Hi Anthony,
We first go the slavish route, to provide a basis for changing things later.
So I am not looking for alternative ways of doing this, I am just wondering
whether there is a rationale for doing things this way.
The document does not give one.
And now I hear that records suffer from
> We are adding classes and instances to Helium.
> We wondered about the aspect that it is allowed to have a class instance
> of which not all fields have a piece of code/value associated with them, ...
I have a suggestion for that. But first let me understand where you're
going with Helium.
This and the fact that you may leave record fields unspecified when
initially constructing a record are two things I'd probably change if I
could. In the rare case of a class with a method that will usually be an
error, you could still define that as the default method implementation in
the class.
20 matches
Mail list logo
