Re: [Haskell-cafe] Overloading

On Sat, Mar 9, 2013 at 5:33 PM, Peter Caspers wrote: Hi, I just started playing around a bit with Haskell, so sorry in advance for very basic (and maybe stupid) questions. Coming from the C++ world one thing I would like to do is overloading operators. For example I want to w

Re: [Haskell-cafe] Overloading

On 12/03/2013, at 3:15 AM, Carlos Camarao wrote: >> Hi, >> >> I just started playing around a bit with Haskell, so sorry in >> advance for very basic (and maybe stupid) questions. Coming from >> the C++ world one thing I would like to do is ove

Re: [Haskell-cafe] Overloading

On Tue, Mar 12, 2013 at 3:21 PM, Brandon Allbery wrote: > On Tue, Mar 12, 2013 at 1:52 PM, Carlos Camarao > wrote: > >> Sorry, I think my sentence: >> "To define (+) as an overloaded operator in Haskell, >> you have to define and use a type class.&qu

Re: [Haskell-cafe] Overloading

> > On Tue, Mar 12, 2013 at 5:54 PM, Richard A. O'Keefe > wrote: > > Carlos Camarao wrote: > > >> Sorry, I think my sentence: > >>"To define (+) as an overloaded operator in Haskell, > >> you have to define and us

Re: [Haskell-cafe] Re: REMINDER: Contributions to the HC&A Report (November 2004 edition)

On Tue, 26 Oct 2004 19:07:39 +0200, Andres Loeh <[EMAIL PROTECTED]> wrote: > Sorry, the link was incorrect. The pointer should have been: > > > Furthermore, please have a look at http://haskell.org/communities/topics.html > Andres Ooops, I'm sorry!, I sent my "complaint" before seeing this... C

[Haskell-cafe] Re: Proposal to solve Haskell's MPTC dilemma

On 05/26/10 15:42, Carlos Camarao wrote: > I think you are proposing using the current set of instances in > scope in order to remove ambiguity. Am I right? I think that an important point is that it is not exactly "to remove ambiguity", because the proposal tries to solve the

[Haskell-cafe] Re: Proposal to solve Haskell's MPTC dilemma

On Thu, May 27, 2010 at 5:43 PM, David Menendez wrote: > On Thu, May 27, 2010 at 10:39 AM, Carlos Camarao > wrote: > > Isaac Dupree: > >> Your proposal appears to allow /incoherent/ instance selection. > >> This means that an expression can be well-typed in one

Re: [Haskell-cafe] Proposal to solve Haskell's MPTC dilemma

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)

Re: [Haskell-cafe] Re: Proposal to solve Haskell's MPTC dilemma

On Fri, May 28, 2010 at 2:36 AM, Isaac Dupree < m...@isaac.cedarswampstudios.org> wrote: > On 05/27/10 17:42, Carlos Camarao wrote: > >> On Thu, May 27, 2010 at 5:43 PM, David Menendez >> wrote: >> >> On Thu, May 27, 2010 at 10:39 AM, Carlos Camara

Re: [Haskell-cafe] Re: Proposal to solve Haskell's MPTC dilemma

>>The situation is as if we [had] a FD: > Well, that is indeed equivalent here in the second argument of class > F, but I constructed the example to show an issue in the class's > *first* argument. The example should be equivalent in all respects (at least that was my motivation when I wrote i

Fwd: [Haskell-cafe] Proposal to solve Haskell's MPTC dilemma

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

[Haskell-cafe] Reachable variables exercise

Hi. Consider for example an expression e0 like: fst (True,e) where e is any expression. e0 should have type Bool IMHO irrespectively of the type of e. In Haskell this is the case if e's type is monomorphic, or polymorphic, or constrained and there is a default in the current module that remove

Fwd: [Haskell-cafe] Reachable variables exercise

-- Forwarded message -- From: Carlos Camarao Date: Fri, Sep 17, 2010 at 12:01 AM Subject: Re: [Haskell-cafe] Reachable variables exercise To: Luke Palmer boolify o has type Boolable a => Bool under the proposal, then we have ambiguity, type error, right? In general, consi

Re: [Haskell-cafe] Reachable variables exercise

olify :: a -> Bool > >class O a where >o :: a > > main = print $ boolify o > > It seems like under your proposal this should not be a type error. > But if that is so, then what is its output? > > Luke > > On Thu, Sep 16, 2010 at 7:31 AM, C

Re: [Haskell-cafe] Type Inference for Overloading without Restrictions

On Wed, Jan 13, 2010 at 7:57 AM, Peter Verswyvelen wrote: > A while ago, someone provided me a link to the paper "Type Inference > for Overloading without Restrictions" > http://www.dcc.ufmg.br/~camarao/ct-flops99.ps.gz > > Although I don't under

[Haskell-cafe] Proposal to solve Haskell's MPTC dilemma

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

Re: [Haskell-cafe] Proposal to solve Haskell's MPTC dilemma

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 >

Re: [Haskell-cafe] Proposal to solve Haskell's MPTC dilemma

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

Re: [Haskell-cafe] Proposal to solve Haskell's MPTC dilemma

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 &g

Re: [Haskell-cafe] Proposal to solve Haskell's MPTC dilemma

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 t

Re: [Haskell-cafe] Proposal to solve Haskell's MPTC dilemma

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: ..

RE: Rank-2 polymorphism & type inference

Hello. < class C t where op :: t -> Bool < instance C [t] where op x = True < < p y = (let f :: c -> Bool; f x = op (y >> return x) in f, y ++ []) < q y = (y ++ [], let f :: c -> Bool; f x = op (y >> return x) in f) < (b -> Bool, [a]) and Forall a,b. [a] -> ([a], b -> Bool) You can ru