I forgot to cc the message below to haskell-cafe...
-- Forwarded message --
From: Carlos Camarao
Date: Thu, Jun 10, 2010 at 4:40 PM
Subject: Re: [Haskell-cafe] Proposal to solve Haskell's MPTC dilemma
To: "Brandon S. Allbery KF8NH"
On Wed, Jun 9, 2010 at 1:5
On Jun 8, 2010, at 15:32 , Job Vranish wrote:
It seems like this would make working with MPTCs much easier.
When programming, I generally want to only specify the minimum
amount of information to make my code logically unambiguous.
If the code contains enough information to infer the proper
i
Sorry for reopening an old thread, but I thought I'd counter some of the
negative feedback :)
I think this proposal is a great idea!
It seems like this would make working with MPTCs much easier.
When programming, I generally want to only specify the minimum amount of
information to make my code
On Wed, May 26, 2010 at 7:12 PM, Max Bolingbroke wrote:
> I broadly agree, but pragmatically the notion of orphans is useful for
> designing robust libraries, even if the notion is a bit horrible. ...
>
I guess that a MPTC instance (C t1 .. tn) for class C in module M1 is NOT an
> orphan if:
1)
Hi Carlos,
Apologies for the lateness of my reply.
On 23 May 2010 02:24, Carlos Camarao wrote:
> I think that a notion of orphan instances based on whether an
> instance is defined or not in the module where the class of the
> instance is defined is not very nice
I broadly agree, but pragmatica
Sorry to correct myself:
On Sat, May 22, 2010 at 10:24 PM, Carlos Camarao
wrote:
> ...
> =
> PS: I think that a definition of orphan/non-orphan instance definition
> for MPTCs should be different.
> Letting: ...
>
instance-de
On 21 May 2010 01:58, Carlos Camarao wrote:
>> But this type-correct program would become not typeable if
>> instances such as the ones referred to before (by Daniel Fischer) ...
> It seems that single param type classes enjoy a nice property: ...
> * Adding an instance to the module defining t
On Fri, May 21, 2010 at 3:56 AM, Max Bolingbroke
wrote:
> On 21 May 2010 01:58, Carlos Camarao wrote:
>> But this type-correct program would become not typeable if
>> instances such as the ones referred to before (by Daniel Fischer)
>
> I was thinking this through, and the situation is more compl
Hi Max.
Excerpts from Max Bolingbroke's message of Sex Mai 21 04:56:51 -0300 2010:
(...)
> (Incidentally, the link to your paper is broken, so I haven't actually
> been able to read it, sorry!)
It was easy to find it on google.
http://www.dcc.ufmg.br/~camarao/CT/solution-to-mptc-dilemma.pdf
Gre
On 21 May 2010 01:58, Carlos Camarao wrote:
> But this type-correct program would become not typeable if
> instances such as the ones referred to before (by Daniel Fischer)
I was thinking this through, and the situation is more complex than I
had thought.
It seems that single param type classes
Hi Evan
EHC - Essential Haskell Compiler - is the 'family of compilers' that
UHC - Utrecht Haskell Compiler - is instance one of. The EHC family
starts with a simple Haskell subset and adds features building up to
(almost) Haskell98 for UHC and extended Haskell for some of the EHC
variations. This
> Hi Evan, hasn't EHC had something like this for a while with 'type
> class directives'?
I dunno, I don't even know what ehc is. Is it this?
http://www.cs.uu.nl/wiki/Ehc/WebHome
I turned up a paper that mentioned type class directives, but I
haven't read it yet. In any case, the EHC page says
On Thu, May 20, 2010 at 7:54 PM, Max Bolingbroke <
batterseapo...@hotmail.com> wrote:
> On 20 May 2010 20:30, Carlos Camarao wrote:
>
> > ... Also, the same fragilty occurs if FDs are used.
>
> This remark is surprising to me. I thought the point of the FDs being
> declared on the original cla
On 20 May 2010 20:30, Carlos Camarao wrote:
> Consider instances defined in non-imported modules to be visible in the
> current
> context is not correct, I think...
I was under the impression that this was not specified, because
orphans are a bit of an oddity. But naturally the Haskell spec says
On 20 May 2010 21:16, Evan Laforge wrote:
> Someone recently described the HASP project, at
> http://hasp.cs.pdx.edu/. It describes "habit", a haskell like
> language with some additions and subtractions. There are a couple
> interesting extensions to 'instance' declarations:
>
> -- explicitly
> I wonder: Of cases where overload resolution via available instances
> would be reasonable, how many would also make sense as a closed type
> class? By comparison, it seems that many uses of OverlappingInstances
> are really just trying to express a closed type class with one or more
> default in
On Thu, May 20, 2010 at 1:25 PM, Max Bolingbroke wrote:
> On 20 May 2010 16:50, Carlos Camarao wrote:
> >> Using the available instances to resolve overloading is a tricky thing,
> >> it's very easy to make things break that way.
> >
> > Using the available instances is the natural, in fact the
On Thu, May 20, 2010 at 12:25 PM, Max Bolingbroke
wrote:
> "Available instances" are not a natural addition to this list. In
> particular, using that information can cause programs to become
> untypeable when the module or *any module it imports transitively*
> defines a new instance. This leads t
On 20 May 2010 16:50, Carlos Camarao wrote:
>> Using the available instances to resolve overloading is a tricky thing,
>> it's very easy to make things break that way.
>
> Using the available instances is the natural, in fact the only way, to
> resolve overloading.
AFAIK no other Haskell feature
On Thu, May 20, 2010 at 11:54 AM, Daniel Fischer
wrote:
>
> On Thursday 20 May 2010 16:34:17, Carlos Camarao wrote:
> > In the context of MPTCs, this rule alone is not enough. Consider, for
> > example (Example 1):
> >
> >class F a b where f:: a->b
> >class O a where o:: a
> > and
> >
On Thursday 20 May 2010 16:34:17, Carlos Camarao wrote:
> In the context of MPTCs, this rule alone is not enough. Consider, for
> example (Example 1):
>
> class F a b where f:: a->b
> class O a where o:: a
> and
> k = f o:: (C a b,O a) => b
>
> Type forall a b. (C a b,O a) => b can be con
This message presents, informally, a proposal to solve Haskell's MPTC
(multi-parameter type class) dilemma. If this informal proposal turns
out to be acceptable, we (I am a volunteer) can proceed and make a
concrete proposal.
The proposal has been published in the SBLP'2009 proceedings and is
avai
22 matches
Mail list logo
