On 04/05/2010, at 13:30, Luke Palmer wrote:
> On Mon, May 3, 2010 at 11:07 AM, Kyle Murphy wrote:
>
>> The fact that it doesn't is proof enough that there's a problem
>> with it even if that problem is simply that the types you're using aren't
>> exactly correct. Further, I'd argue that in the f
On Mon, May 3, 2010 at 10:13 PM, Ivan Miljenovic
wrote:
> On 4 May 2010 13:30, Luke Palmer wrote:
>> Here is a contrived example of what I am referring to:
>>
>> prefac f 0 = 1
>> prefac f n = n * f (n-1)
>>
>> fac = (\x -> x x) (\x -> prefac (x x))
>
> I can't work out how this works (or should
On Tue, May 4, 2010 at 12:13 AM, Ivan Miljenovic
wrote:
> On 4 May 2010 13:30, Luke Palmer wrote:
>> Here is a contrived example of what I am referring to:
>>
>> prefac f 0 = 1
>> prefac f n = n * f (n-1)
>>
>> fac = (\x -> x x) (\x -> prefac (x x))
>
> I can't work out how this works (or should
prefac is just a normal factorial function with recursion factored out. fix
prefac 5 gives 120, for example.
On Tue, May 4, 2010 at 12:13 AM, Ivan Miljenovic
wrote:
> On 4 May 2010 13:30, Luke Palmer wrote:
> > Here is a contrived example of what I am referring to:
> >
> > prefac f 0 = 1
> > pre
On 4 May 2010 13:30, Luke Palmer wrote:
> Here is a contrived example of what I am referring to:
>
> prefac f 0 = 1
> prefac f n = n * f (n-1)
>
> fac = (\x -> x x) (\x -> prefac (x x))
I can't work out how this works (or should work rather); is it meant
to be using church numerals or something (
lrpalmer:
> What I seem to be getting at is this plane of type systems:
>
> Constrained - Expressive
> Unreliable
> | (C)
> |(test suites)
> | (C++).
> |
On Mon, May 3, 2010 at 11:07 AM, Kyle Murphy wrote:
> The problem with dynamic typing is that it has a much higher chance of
> having a subtle error creep into your code that can go undetected for a long
> period of time. A strong type system forces the code to fail early where
> it's easier to tr
On May 4, 2010, at 5:07 AM, Kyle Murphy wrote:
To look at the flip side of your statistics:
Compiler says my code is right => My code is actually wrong -- 40%
Compiler says my code is wrong => My code is actually right -- 5%
I'd argue this is provably wrong, as correct code by definition
wou
In my opinion code is 'right' when it conforms to the specification.
Haskell's type system allows the programmer to express a part of the
specification in the types, which then get checked by the
compiler/type-checker. This is where I see the biggest benefit of a
very expressive statically checked
The problem with dynamic typing is that it has a much higher chance of
having a subtle error creep into your code that can go undetected for a long
period of time. A strong type system forces the code to fail early where
it's easier to track down and fix the problem, rather than trying to perform
d
On Mon, May 3, 2010 at 9:34 AM, Casey Hawthorne wrote:
>>Strict type system allows for a maximum number of programming errors to be
>>caught at compile time.
>
> I keep hearing this statement but others would argue that programming
> errors caught at compile time only form a minor subset of all e
Are you really sure about that... it might cause a typing error if you misspell
something.
Proposal: "The double typing error"
Kind regards,
Samuel
On 4/05/2010, at 3:34 AM, Casey Hawthorne wrote:
> I don't mean "tpynig errros".
___
Haskell-Cafe mai
On Mon, May 3, 2010 at 11:34 AM, Casey Hawthorne wrote:
> >Strict type system allows for a maximum number of programming errors to be
> caught at compile time.
>
> I keep hearing this statement but others would argue that programming
> errors caught at compile time only form a minor subset of all
>Strict type system allows for a maximum number of programming errors to be
>caught at compile time.
I keep hearing this statement but others would argue that programming
errors caught at compile time only form a minor subset of all errors
caught.
So, in functional programming languages with a s
14 matches
Mail list logo