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 overloading
operators. For example I want
On Tue, Mar 12, 2013 at 3:21 PM, Brandon Allbery allber...@gmail.comwrote:
On Tue, Mar 12, 2013 at 1:52 PM, Carlos Camarao
carlos.cama...@gmail.comwrote:
Sorry, I think my sentence:
To define (+) as an overloaded operator in Haskell,
you have to define and use a type class
On Tue, Mar 12, 2013 at 5:54 PM, Richard A. O'Keefe o...@cs.otago.ac.nz
wrote:
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.
is not quite correct. I meant
On Sat, Mar 9, 2013 at 5:33 PM, Peter Caspers pcaspers1...@gmail.com
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.
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
-- Forwarded message --
From: Carlos Camarao carlos.cama...@gmail.com
Date: Fri, Sep 17, 2010 at 12:01 AM
Subject: Re: [Haskell-cafe] Reachable variables exercise
To: Luke Palmer lrpal...@gmail.com
boolify o has type Boolable a = Bool under the proposal, then
we have ambiguity
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, Carlos Camarao
carlos.cama...@gmail.com wrote:
Hi. Consider for example
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 it).
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 Menendezd...@zednenem.com
wrote:
On Thu, May 27, 2010 at 10:39 AM, Carlos Camarao
carlos.cama...@gmail.com wrote
On Wed, May 26, 2010 at 7:12 PM, Max Bolingbroke batterseapo...@hotmail.com
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
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 problem exactly
when
On Thu, May 27, 2010 at 5:43 PM, David Menendez d...@zednenem.com wrote:
On Thu, May 27, 2010 at 10:39 AM, Carlos Camarao
carlos.cama...@gmail.com wrote:
Isaac Dupree:
Your proposal appears to allow /incoherent/ instance selection.
This means that an expression can be well-typed in one
Sorry to correct myself:
On Sat, May 22, 2010 at 10:24 PM, Carlos Camarao
carlos.cama...@gmail.comwrote:
...
=
PS: I think that a definition of orphan/non-orphan instance definition
for MPTCs should be different.
Letting
On 21 May 2010 01:58, Carlos Camarao carlos.cama...@gmail.com 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
and is
available at
www.dcc.ufmg.br/~camarao/CT/solution-to-MPTC-dilemma.pdf
The well-known dilemma
(hackage.haskell.org/trac/haskell-prime/wiki/MultiParamTypeClassesDilemma)
is that it is generally accepted that MPTCs are very useful, but their
introduction is thought to require the introduction also
On Thu, May 20, 2010 at 11:54 AM, Daniel Fischer
daniel.is.fisc...@web.dewrote:
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
On Thu, May 20, 2010 at 1:25 PM, Max Bolingbroke batterseapo...@hotmail.com
wrote:
On 20 May 2010 16:50, Carlos Camarao carlos.cama...@gmail.com wrote:
Using the available instances to resolve overloading is a tricky thing,
it's very easy to make things break that way.
Using
On Thu, May 20, 2010 at 7:54 PM, Max Bolingbroke
batterseapo...@hotmail.com wrote:
On 20 May 2010 20:30, Carlos Camarao carlos.cama...@gmail.com 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 Wed, Jan 13, 2010 at 7:57 AM, Peter Verswyvelen bugf...@gmail.comwrote:
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.gzhttp://www.dcc.ufmg.br/%7Ecamarao/ct-flops99.ps.gz
Although I
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...
Carlos
Informally, what I see as the defining rule for closed world is: an
expression is typed according to the set of definitions that are
visible in the context in which it is used. Other possibilities
exist, but the nice thing about this is that it is an extension of
what happens without overloading.
How about inserting one more parameter, action, in your class
definition:
class (Ord st) = MinimaxState st action where
successors:: st - [(action,st)]
terminal:: st - Bool
instance MinimaxState Int Int where
terminal i = i == 0
successors i = [(1,i+1), (-1,i-1)]
I'd rather
Say I have the following function, ... :
f n () = (n, f (n + 1))
...
I have two questions:
1. How can I tell from the Haskell 98 Revised Report that this
function isn't allowed? The discussions of typing in the Report
generally defer to the ``standard Hindley-Milner
f n () = (n, f (n + 1))
In your example, if we assume that f has type, say, a-()-(a,b), for
some a,b, then it is used, in its own definition, with type
a-()-b.
Oops, should be: ... then it is used ... with type a-b (or Num a=a-b).
... a-()-b is not (cannot be) an instance of a-()-(a,b)
24 matches
Mail list logo
