Claus Reinke wrote:
Do you argue that overloading logical operations like this in Haskell
sacrifices type safety? Could programs go wrong [1] that use such
abstractions?
If I understand your point correctly, you are suggesting that such
programs
are still type safe. I agree with the claim
On Jun 1, 2009, at 12:17 AM, Henning Thielemann wrote:
On Thu, 28 May 2009, Bulat Ziganshin wrote:
i use another approach which imho is somewhat closer to
interpretation
of logical operations in dynamic languages (lua, ruby, perl): [...]
The absence of such interpretations and thus the
On Mon, Jun 1, 2009 at 3:06 AM, Sebastian Fischer
s...@informatik.uni-kiel.de wrote:
On Jun 1, 2009, at 12:17 AM, Henning Thielemann wrote:
On Thu, 28 May 2009, Bulat Ziganshin wrote:
i use another approach which imho is somewhat closer to interpretation
of logical operations in dynamic
Do you argue that overloading logical operations like this in Haskell
sacrifices type safety? Could programs go wrong [1] that use such
abstractions?
If I understand your point correctly, you are suggesting that such programs
are still type safe. I agree with the claim that such features are
Do you argue that overloading logical operations like this in
Haskell
sacrifices type safety? Could programs go wrong [1] that use such
abstractions?
If I understand your point correctly, you are suggesting that such
programs
are still type safe.
My asking was really meant as a question to
You are absolutely right about the tantalising opportunity. I know that
Lennart has thought quite a bit about this very point when designing his
Paradise system. Likewise Conal for Pan.
One difficulty is, I think, that it's easy to get ambiguity. Eg
ifthenelse (a b) e1 e2
The (ab)
There are multiple possible classes that you might want under different
circumstances (I think the most interesting issue is whether the class
(==), () etc is in has a fundep from the type of the thing being
compared to the type of the boolean), but if NoImplicitPrelude (or some
other extension)
Here's what I usually use. As Simon points out, ambiguity is lurking
as soon as you use conditional. You can avoid it a fundep, but that's
not necessarily what you want either.
-- | Generalization of the 'Bool' type. Used by the generalized 'Eq' and 'Ord'.
class Boolean bool where
() ::
Of course once you've got ifthenelse you find yourself wanting explicit
desugaring of pattern matching (could view patterns help here?),
Could you be more specific about what you want there, perhaps
with a small example? I recognize the other problems from my own
forays into EDSLs, but I'm not
08:46
To: Simon Peyton-Jones; Sebastiaan Visser; Haskell Cafe
Cc: Augustsson, Lennart
Subject: RE: [Haskell-cafe] Bool as type class to serve EDSLs.
There are multiple possible classes that you might want under
different
circumstances (I think the most interesting issue is whether the class
+1. I agree completely, I've missed this often for exactly the same
reasons.
Edsko
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
And I would certainly celebrate when if b then x else y expression becomes polymorphic
in b.
Edsko de Vries wrote on 27.05.2009 17:33:
+1. I agree completely, I've missed this often for exactly the same
reasons.
Edsko
___
Haskell-Cafe mailing list
2009/05/27 Miguel Mitrofanov miguelim...@yandex.ru:
And I would certainly celebrate when if b then x else y
expression becomes polymorphic in b.
class Boolean b where
fromBoolean :: b - Bool
--
Jason Dusek
___
Haskell-Cafe mailing list
13 matches
Mail list logo
