[Haskell-cafe] Re: Function Precedence
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
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
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
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
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
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/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
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
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
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
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
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
