, at 07:32, Christian Sternagel c.sterna...@gmail.com wrote:
Dear Jurriën.
personally, I like lift (which is of course already occupied in Haskell), since an arbitrary
value is lifted into a monad. (The literature sometimes uses unit.)
cheers
chris
On 08/06/2013 02:14 PM, J. Stutterheim wrote
Dear Jurriën.
personally, I like lift (which is of course already occupied in
Haskell), since an arbitrary value is lifted into a monad. (The
literature sometimes uses unit.)
cheers
chris
On 08/06/2013 02:14 PM, J. Stutterheim wrote:
Dear Cafe,
Suppose we now have the opportunity to
Thanks Wren, for the explanations (also in your previous mail)!
On 07/30/2012 01:29 PM, wren ng thornton wrote:
On 7/24/12 9:19 PM, Christian Sternagel wrote:
(x == y) = True == x = y
(x == y) = False == not (x = y)
(x == _|_) = _|_
(_|_ == y) = _|_
Those axioms state that (==) is sound w.r.t
that it will be safe. But the undecidability of comparing
distinct bottoms means that you have to make a choice.
On 7/24/12, Christian Sternagel c.sterna...@gmail.com wrote:
It's a classically valid inference, so you're safe in that respect,
and it is true that evaluating x == y requires
programs for which (==) is
non-commutative, we should not require it, since we could not formalize
those programs then.
cheers
chris
The classically valid inference:
(x == y) = _|_ = (y == x) = _|_
On 7/25/12, Christian Sternagel c.sterna...@gmail.com wrote:
Dear Alexander,
Let me clarify
On 07/26/2012 11:53 AM, Alexander Solla wrote:
The classically valid inference:
(x == y) = _|_ = (y == x) = _|_
Btw: whether this inference is valid or not depends on the semantics of
(==) and that's exactly what I was asking about. In Haskell we just have
type classes, thus (==) is more or
Dear Alexander,
On 07/26/2012 01:09 PM, Alexander Solla wrote:
On 7/25/12, Christian Sternagel c.sterna...@gmail.com wrote:
On 07/26/2012 11:53 AM, Alexander Solla wrote:
The classically valid inference:
(x == y) = _|_ = (y == x) = _|_
Btw: whether this inference is valid or not depends
Dear all,
with respect to formal verification of Haskell code I was wondering
whether (==) of the Eq class is intended to be commutative (for many
classes such requirements are informally stated in their description,
since Eq does not have such a statement, I'm asking here). Or are there
any
Dear all,
Thanks for your replies. Just to clarify: I am fully aware that inside
Haskell there is no guarantee that certain (intended) requirements on
type class instances are satisfied. I was asking whether the intention
for Eq is that (==) is commutative, because if it was, I would require
It's a classically valid inference, so you're safe in that respect,
and it is true that evaluating x == y requires traversing x and y, so
that if x or y are bottom, (x == y) and (y == x) will both be bottom.
Well, (x == y) could result in bottom, even if neither x nor y are
bottom, e.g.,
Hi all,
I'm not a native English speaker and recently I was wondering about the
two words order and ordering (the main reason why I write this to
the Haskell mailing list, is that the type class Ordering does exist).
My dictionaries tell me that order (besides other meanings) denotes an
11 matches
Mail list logo
