On Fri, Oct 4, 2013 at 10:31 PM, Wvv vite...@rambler.ru wrote:
Newclasses are something like instances, but out of scope. In a baggage.
So under the hood of GHC, newclasses would be partially filled in
dictionaries.
We already have too many classes: (...)
We can't divide all classes to
On Thu, Oct 3, 2013 at 8:16 AM, Wvv vite...@rambler.ru wrote:
Your first two cases will be fixed in 7.10, as Applicative finally
becomes
a superclass of Monad.
Sure, newclassses not about Applicative and Monads only.
This question is more wider.
Must Apply be a superclass of Bind?
Must
I do think something has to be done to have an Eq and Ord with more strict
laws.
* Operators in Eq and Ord diverge iff any of their parameters are bottom.
* The default definitions of (/=), (), () and `compare` are law.
* (==) is reflexive and transitive
* (=) is antisymmetric ((x = y y = x)
On Wed, Oct 2, 2013 at 3:49 PM, Niklas Haas hask...@nand.wakku.to wrote:
On Wed, 2 Oct 2013 15:46:42 +0200, Stijn van Drongelen rhym...@gmail.com
wrote:
I do think something has to be done to have an Eq and Ord with more
strict
laws.
* Operators in Eq and Ord diverge iff any
.
On Wed, Oct 2, 2013 at 5:36 PM, Roman Cheplyaka r...@ro-che.info wrote:
* Stijn van Drongelen rhym...@gmail.com [2013-10-02 15:46:42+0200]
I do think something has to be done to have an Eq and Ord with more
strict
laws.
* Operators in Eq and Ord diverge iff any of their parameters
On Wed, Oct 2, 2013 at 6:57 PM, Stijn van Drongelen rhym...@gmail.comwrote:
On Wed, Oct 2, 2013 at 5:36 PM, Roman Cheplyaka r...@ro-che.info wrote:
* Stijn van Drongelen rhym...@gmail.com [2013-10-02 15:46:42+0200]
I do think something has to be done to have an Eq and Ord with more
strict
Hi!
Your first two cases will be fixed in 7.10, as Applicative finally becomes
a superclass of Monad. I haven't really looked at your third case, so I
can't comment on that. Your fourth case is something I'd really like to see
solved properly (*together* with a better record system), but as you
On Tue, Sep 24, 2013 at 5:39 PM, Sven Panne svenpa...@gmail.com wrote:
2013/9/22 Mike Meyer m...@mired.org:
On Sat, Sep 21, 2013 at 5:28 PM, Bardur Arantsson s...@scientician.net
wrote:
Trying to make something whose name is Not A Number act like a
number sounds broken from the start.
I think you are trying to solve a problem that doesn't exist.
* Float and Double are imprecise types by their very nature. That's exactly
what people are forgetting, and exactly what's causing misunderstandings.
Perhaps(!) it would be better to remove the option to use rational literals
as
On Sep 21, 2013 9:38 AM, Colin Adams colinpaulad...@gmail.com wrote:
On 21 September 2013 08:34, Stijn van Drongelen rhym...@gmail.com wrote:
* As mentioned, there is a total order (Ord) on floats (which is what
you should be using when checking whether two approximations are
approximately
On Sat, Sep 21, 2013 at 10:26 AM, Mike Meyer m...@mired.org wrote:
On Sat, Sep 21, 2013 at 2:21 AM, Bardur Arantsson s...@scientician.net
wrote:
On 2013-09-21 06:16, Mike Meyer wrote:
The single biggest gotcha is that two calculations
we expect to be equal often aren't. As a result of
On Sep 21, 2013 4:17 PM, Bob Hutchison hutch-li...@recursive.ca wrote:
On 2013-09-21, at 4:46 AM, Stijn van Drongelen rhym...@gmail.com wrote:
I do have to agree with Damodar Kulkarni that different laws imply
different classes. However, this will break **a lot** of existing software.
You
On Fri, Sep 20, 2013 at 6:17 PM, damodar kulkarni kdamodar2...@gmail.comwrote:
Ok, let's say it is the effect of truncation. But then how do you explain
this?
Prelude sqrt 10.0 == 3.1622776601683795
True
Prelude sqrt 10.0 == 3.1622776601683796
True
Well, that's easy:
λ: decodeFloat
13 matches
Mail list logo