On 2008-04-03, Chris Smith <[EMAIL PROTECTED]> wrote:
> Hans Aberg wrote:
>> This problem is not caused by defining f+g, but by defining numerals as
>> constants.
>
> Yup. So the current (Num thing) is basically:
>
> 1. The type thing is a ring
> 2. ... with signs and absolute values
> 3. ... alon
On Thu, 3 Apr 2008, [EMAIL PROTECTED] wrote:
Fractional, Floating, etc. are also horrible. Why the square root needs to
be floating? It can belong to the algebraic number domain.
At least in NumericPrelude we have separated these issues.
___
Haskell
On 3 Apr 2008, at 16:07, Chris Smith wrote:
This problem is not caused by defining f+g, but by defining
numerals as
constants.
Yup. So the current (Num thing) is basically:
1. The type thing is a ring
2. ... with signs and absolute values
3. ... along with a natural homomorphism from Z int
Chris Smith writes:
... So the current (Num thing) is basically:
1. The type thing is a ring
2. ... with signs and absolute values
3. ... along with a natural homomorphism from Z into thing
4. ... and with Eq and Show.
If one wanted to be perfectly formally correct, then each of 2-4 could be
Hello Chris,
Thursday, April 3, 2008, 6:07:53 PM, you wrote:
> On the other hand, I have enough time already trying to explain Num,
> Fractional, Floating, RealFrac, ... to new haskell programmes. I'm not
> sure it's an advantage if someone must learn the meaning of an additive
> commutative sem
Hans Aberg wrote:
> This problem is not caused by defining f+g, but by defining numerals as
> constants.
Yup. So the current (Num thing) is basically:
1. The type thing is a ring
2. ... with signs and absolute values
3. ... along with a natural homomorphism from Z into thing
4. ... and with Eq a
2008/4/2, Dan Piponi <[EMAIL PROTECTED]>:
> On Tue, Apr 1, 2008 at 2:07 PM, PR Stanley <[EMAIL PROTECTED]> wrote:
> > All you'd have to do is to give the inner most function the highest
> > precdence
>
>
> What's the innermost function in "f g x" here?
>
> test :: (a -> b -> c) -> a -> b -> c
>
On Tue, Apr 1, 2008 at 2:07 PM, PR Stanley <[EMAIL PROTECTED]> wrote:
> All you'd have to do is to give the inner most function the highest
> precdence
What's the innermost function in "f g x" here?
test :: (a -> b -> c) -> a -> b -> c
test f g x = f g x
--
Dan
__
PR Stanley wrote:
> All you'd have to do is to give the inner most function the highest
> precdence therefore
> f g x == f (g x)
> let f x = x^2
> let g x = x`div`2
> f g 4 == error while
> f (g 4) == 4
I'm afraid I still don't understand what you're proposing. How can
f g x mean f (g x), and yet
On Apr 1, 2008, at 17:07 , PR Stanley wrote:
I'm beginning to wonder if I fully understand the right
associativity rule for the -> operator.
Read a parenthesized unit as an argument:
> (a -> (b -> (c -> d))) (((f 1) 2) 3)
> (((a -> b) -> c) -> d) (f (1 (2 3)))
--
brandon s.
Are you asking why one doesn't change the rules for all functions? Or
are you asking why Haskell doesn't include a system of user-defined
precedence and associativity for function application so that one could
declare that g binds more tightly than f? I see good reasons for both
questions, but I
PR Stanley wrote:
>>Should that be f (1 (2 3)), or ((f 1) 2) 3?
> The latter, of course, but that's not really what I'm
> driving at. I'm asking why we can't have a function treated differently
> with regard to the precedence and associativity rules. f 1 2 is indeed
> ((f 1) 2). Why not f
12 matches
Mail list logo
