Chris Smith cdsm...@gmail.com writes:
actually matter. The instant anyone actually compiles an application
that uses your library, however indirectly, they are bound by the terms
There are other uses for code than compilation. Let's say I wrote a
wrapper for a proprietary library that
Hi Folks,
I've come across this a few times - In Haskell, once can prove the
correctness of the code - Is this true?
I know that static typing and strong typing of Haskell eliminate a whole
class of problems - is that related to the proving correctness?
Is it about Quickcheck - if so, how is it
On 11 February 2011 22:06, C K Kashyap ckkash...@gmail.com wrote:
Hi Folks,
I've come across this a few times - In Haskell, once can prove the
correctness of the code - Is this true?
I'm not quite sure where you got that...
But since Haskell is pure, we can also do equational reasoning, etc.
I think one thing it means, is that, with the typesystem, you just can't do
random things where-ever you want. Like, in the pure world if you want to
transform values from one type to another, you always need to have
implementations of functions available to do that. (You can't just take a
pure
On 02/11/2011 12:06 PM, C K Kashyap wrote:
[...]
I know that static typing and strong typing of Haskell eliminate a
whole class of problems - is that related to the proving correctness?
[...]
You might have read about free theorems arising from types. They are a
method to derive certain
On Friday 11 February 2011 12:06:58, C K Kashyap wrote:
Hi Folks,
I've come across this a few times - In Haskell, once can prove the
correctness of the code - Is this true?
One can also prove the correctness of the code in other languages.
What makes these proofs much easier in Haskell than
I've come across this a few times - In Haskell, once can prove the
correctness of the code - Is this true?
One way to prove the correctness of a program is to calculate it from its
specification. If the specification is also a Haskell program, equational
reasoning can be used to transform a
Am 11.02.2011 13:48, schrieb Daniel Fischer:
[...] +1
Testing can only prove code incorrect, it can never prove code correct
(except for extremely simple cases where testing all possible inputs can be
done; but guaranteeing that QuickCheck generates all possible inputs is
generally harder
Kashyap,
2011/2/11 C K Kashyap ckkash...@gmail.com:
I've come across this a few times - In Haskell, once can prove the
correctness of the code - Is this true?
I know that static typing and strong typing of Haskell eliminate a whole
class of problems - is that related to the proving
I'm
writting a function that will remove tautologies from a fomula.The
basic idea is that if in a clause, a literal and its negation are found,
it means that the clause will be true, regardless of the value finally
assigned to that propositional variable.My appoach is to create a
function
I'm writting a function that will remove tautologies from a fomula.The basic
idea is that if in a clause, a literal and its negation are found, it means
that the clause will be true, regardless of the value finally assigned to
that propositional variable.My appoach is to create a function that
On Friday 11 February 2011 18:25:24, PatrickM wrote:
I'm writting a function that will remove tautologies from a fomula.The
basic idea is that if in a clause, a literal and its negation are found,
it means that the clause will be true, regardless of the value finally
assigned to that
Hi cafè,
given the following toy code:
---
module Main where
class Dumb p where
dumb :: p - String
newtype Branded a b = Branded b
unbrand :: Branded a b - b
unbrand (Branded x) = x
wrong :: Dumb a = b - Branded a b
wrong = Branded
right :: Show a = b - Branded a b
right
On Friday 11 February 2011 19:33:27, Cristiano Paris wrote:
Hi cafè,
given the following toy code:
---
module Main where
class Dumb p where
dumb :: p - String
newtype Branded a b = Branded b
unbrand :: Branded a b - b
unbrand (Branded x) = x
wrong :: Dumb a = b -
On Fri, Feb 11, 2011 at 20:00, Daniel Fischer
daniel.is.fisc...@googlemail.com wrote:
...
It's because there's no way to determine the type variable a (in either
wrong or right).
That's what I thought when I wrote the code at first but then I was
surprised to see it working with the Show
I've been trying to deal with how my haskell program handles unicode
filenames. Been dealing with problems like those described here:
http://hackage.haskell.org/trac/ghc/ticket/3307
Or, simply demonstrated by feeding unicode to getLine = readFile
My approach currently is to carefully identify
On Feb 11, 2011, at 11:20 AM, Peter Simons wrote:
If hledger offers optional features by means of Cabal flags, then
users
of the library need the ability to depend on hledger with a specific
set
of features (flags) enabled or disabled, but unfortunately Cabal can't
do that.
The new approach
On Fri, Feb 11, 2011 at 3:06 AM, C K Kashyap ckkash...@gmail.com wrote:
Hi Folks,
I've come across this a few times - In Haskell, once can prove the
correctness of the code - Is this true?
I know that static typing and strong typing of Haskell eliminate a whole
class of problems - is that
On Fri, Feb 11, 2011 at 4:06 AM, C K Kashyap ckkash...@gmail.com wrote:
Hi Folks,
I've come across this a few times - In Haskell, once can prove the
correctness of the code - Is this true?
You can prove the correctness of code for any language that has
precise semantics. Which is basically
Hi Sam. I don't know much about the performance problems you are
seeing, but I think your solution is more cleanly implemented just
under the event level with futures.
I think the reactive function you want has a type like this:
stateMachine :: s - (a - s - s) - (s - Future (b, s)) - Event a -
On Fri, Feb 11, 2011 at 04:48:28PM -0800, Johan Tibell wrote:
Hi Magnus,
network-2.3 supersedes network-bytestring as the modules provided by
the latter were merged into network. network-2.3 and later cannot be
used together with network-bytestring, in one package, as both
expose the same
21 matches
Mail list logo
