[Haskell-cafe] Re: Function Precedence

2008-04-07 Thread Aaron Denney
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. ... 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 
> split out of Num.  For example, 2 doesn't make sense for polynomials or n 
> by n square matrices.  4 doesn't make sense for functions.  3 doesn't 
> make sense for square matrices of dimension greater than 1.  And, this 
> quirk about 2(x+y) can be seen as an argument for not wanting it in the 
> case of functions, either.  I'm not sure I find the argument terribly 
> compelling, but it is there anyway.

Just a nit, but 3 seems to make perfect sense for square matrices -- n
gets mapped onto I_d for any dimension d.

fromInteger (n*m) == fromInteger n * fromInteger m
fromInteger (n+m) == fromInteger n + fromInteger m

-- 
Aaron Denney
-><-

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] Re: Function Precedence

2008-04-03 Thread Henning Thielemann


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-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] Re: Function Precedence

2008-04-03 Thread Hans Aberg


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 into thing
4. ... and with Eq and Show.

If one wanted to be perfectly formally correct, then each of 2-4  
could be
split out of Num.  For example, 2 doesn't make sense for  
polynomials or n

by n square matrices.


Or ordinals.


4 doesn't make sense for functions.  3 doesn't
make sense for square matrices of dimension greater than 1.  And, this
quirk about 2(x+y) can be seen as an argument for not wanting it in  
the

case of functions, either.  I'm not sure I find the argument terribly
compelling, but it is there anyway.

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 semigroup in order to understand the type signatures  
inferred

from code that does basic math in Haskell.  At least in the U.S., very
few computer science students take an algebra course before getting
undergraduate degrees.


It is probably not worth to change Num, as code already depends on it.

But by inserting some extra classes, and letting it derive, makes it  
possible to use operators such as (+) without tying it to Eq, Show, etc.



In mathematical terms, the set of functions is a (math) module
("generalized vectorspace"), not a ring.


Well, I agree that functions are modules; but it's hard to agree that
they are not rings.  After all, it's not too difficult to verify  
the ring

axioms.


It is the set of function that may be a module or ring, and what it  
is depends on how you define it. - It may be different in different  
contexts.


And there is a different question finding unambiguous notation. How  
would a explicit constant like 2 be defined in HAskell as a constant  
so that 2(sin) becomes possible? INs't OK to write (const 2)?


  Hans


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


[Haskell-cafe] Re: Function Precedence

2008-04-03 Thread jerzy . karczmarczuk
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 
split out of Num.  For example, 2 doesn't make sense for polynomials or n 
by n square matrices.  4 doesn't make sense for functions.  3 doesn't 
make sense for square matrices of dimension greater than 1.  And, this 
quirk about 2(x+y) can be seen as an argument for not wanting it in the 
case of functions, either.  I'm not sure I find the argument terribly 
compelling, but it is there anyway.


Why "formally correct"??
This is *your* vision. I might say that fromInteger makes sense for square
matrices, mapping to a multiple of the unity matrix. 4 makes sense for
functions on finite domains. The full Ring property requires a unit, which
might not be there "formally". The "absolute value" might be a buzzword
for <> which *can* be defined for polynomials. In short, Num is
a conventional hybrid, and trying to squeeze it into *any* math formal
structure is asking for trouble. 

On the other hand, I have enough time already trying to explain Num, 
Fractional, Floating, RealFrac, ... to new haskell programmes.  
... At least in the U.S., very 
few computer science students take an algebra course before getting 
undergraduate degrees.


Not only in US. 


In mathematical terms, the set of functions is a (math) module
("generalized vectorspace"), not a ring.


Well, I agree that functions are modules; but it's hard to agree that 
they are not rings.  After all, it's not too difficult to verify the ring 
axioms.


Oh.
What is the function multiplication?
You say: (f*g)(x) = f x * g x ??
I agree. But if you say that the multiplication IS the *composition*
(for example for the popular implementation of Peano/Church numerals),
then I will also agree. So, there isn't any obvious instance for the
function multiplication. (The composition works even if neither "x" nor
"f x" belong to any ring). 


BTW functions "are" or are not members of modules/vector spaces depending
on the codomain structure, so this requires a constrained instance
specification. 


Fractional, Floating, etc. are also horrible. Why the square root needs to
be floating? It can belong to the algebraic number domain. 


We can continue this ad infinitum. I cared very much about this stuff some
10 years ago, I gave up... I would like, sure, to have the possibility to
derive in Haskell some mathematical subsumptions, e.g., that the ring of
integers modulo N becomes a field if N is prime. Or, that every additive
group is a module over integers. But it seems that we are very far from
such a dream. 

Jerzy Karczmarczuk 



___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] Re: Function Precedence

2008-04-03 Thread Bulat Ziganshin
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 semigroup in order to understand the type signatures inferred
> from code that does basic math in Haskell.  At least in the U.S., very
> few computer science students take an algebra course before getting 
> undergraduate degrees.

we already need to learn Category Theory to say "Hello, World" :)


-- 
Best regards,
 Bulatmailto:[EMAIL PROTECTED]

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


[Haskell-cafe] Re: Function Precedence

2008-04-03 Thread Chris Smith
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 and Show.

If one wanted to be perfectly formally correct, then each of 2-4 could be 
split out of Num.  For example, 2 doesn't make sense for polynomials or n 
by n square matrices.  4 doesn't make sense for functions.  3 doesn't 
make sense for square matrices of dimension greater than 1.  And, this 
quirk about 2(x+y) can be seen as an argument for not wanting it in the 
case of functions, either.  I'm not sure I find the argument terribly 
compelling, but it is there anyway.

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 semigroup in order to understand the type signatures inferred 
from code that does basic math in Haskell.  At least in the U.S., very 
few computer science students take an algebra course before getting 
undergraduate degrees.

> In mathematical terms, the set of functions is a (math) module
> ("generalized vectorspace"), not a ring.

Well, I agree that functions are modules; but it's hard to agree that 
they are not rings.  After all, it's not too difficult to verify the ring 
axioms.


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] Re: Function Precedence

2008-04-02 Thread Loup Vaillant
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
>  test f g x = f g x

g (if I followed correctly). But we have a problem:

If I want f g x to be parsed as f (g x), I would probably want,
f g x y to be parsed as f (g x y), considering g as the innermost
function, again.

I'm almost certain that it would render type inference impossible, and
maybe partial application as well. (id 4 is a total application, but
id (\x -> x+1) is a partial one...)

The only choices left are right associativity or left associativity.

Loup
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] Re: Function Precedence

2008-04-02 Thread Dan Piponi
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
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


[Haskell-cafe] Re: Function Precedence

2008-04-01 Thread Chris Smith
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 f g 4 is different from f (g 4)?

Maybe it'll help to point out that using functions as first-class 
concepts -- including passing them around as data -- is fundamental to 
functional programming languages.  In other words, anything in the world 
could be a function, whether it's acting like a function right now or 
not.  So distinguishing between (f g 4) and (f 1 2) is probably not 
wise.  They either need to both parse like ((f g) 4), or they need to 
both parse like (f (1 2)).  It has been the experience of the Haskell, 
ML, and other related languages that left associativity for function 
application works best.

> I'm beginning to wonder if I fully understand the right associativity
> rule for the -> operator.

It just means that if I have a string of things separated by ->, I can 
put parentheses around all but the leftmost one, and it doesn't change 
the meaning.

-- 
Chris Smith

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] Re: Function Precedence

2008-04-01 Thread Brandon S. Allbery KF8NH


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. allbery [solaris,freebsd,perl,pugs,haskell] [EMAIL PROTECTED]
system administrator [openafs,heimdal,too many hats] [EMAIL PROTECTED]
electrical and computer engineering, carnegie mellon universityKF8NH


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] Re: Function Precedence

2008-04-01 Thread PR Stanley

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'm unsure which you mean.

In both cases, it comes down to consistency of the syntax rules.  In
order for (f 1 g 2) to parse as (f 1) (g 2), one would have to do
something surprising.  It's unclear what that is: perhaps treat literals
differently from variables?  Somehow determine a precedence level for
(f 1)?  Or maybe favor shorter argument lists for grouping function
application?

If you have a very clear kind of grouping that you think makes sense in
all cases, feel free to mention it.  It seems unlikely to me, but perhaps
everyone will agree, once they see it, that it is in fact better than the
current parsing rules.

Paul:
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 beginning to wonder if I fully understand the right associativity 
rule for the -> operator.


Cheers, Paul

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


[Haskell-cafe] Re: Function Precedence

2008-04-01 Thread Chris Smith
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 1 g 2 == ((f 1) (g 2))?

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'm unsure which you mean.

In both cases, it comes down to consistency of the syntax rules.  In 
order for (f 1 g 2) to parse as (f 1) (g 2), one would have to do 
something surprising.  It's unclear what that is: perhaps treat literals 
differently from variables?  Somehow determine a precedence level for
(f 1)?  Or maybe favor shorter argument lists for grouping function 
application?

If you have a very clear kind of grouping that you think makes sense in 
all cases, feel free to mention it.  It seems unlikely to me, but perhaps 
everyone will agree, once they see it, that it is in fact better than the 
current parsing rules.

-- 
Chris Smith

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe