RE: Functional programming in Python
Peter Hancock wrote:
foo( bar( baz( x ) ) ) it's: (foo ( bar (baz x) ) )
Clearly the outer parentheses are unnecessary in the last expression. One undeniable advantage of (f a) is it saves parentheses.
Yes and no. In ( ( ( foo bar) baz) x ) the parens can be omitted to leave foo bar baz x but in ( foo ( bar (baz x) ) ) You would want the following I think. foo . bar . baz x which does have the parens omitted, but requires the composition operator. --PeterD
Peter Douglass writes: : | but in ( foo ( bar (baz x) ) ) | | You would want the following I think. | | foo . bar . baz x | | which does have the parens omitted, but requires the composition | operator. Almost. To preserve the meaning, the composition syntax would need to be (foo . bar . baz) x or foo . bar . baz $ x or something along those lines. I favour the one with parens around the dotty part, and tend to use $ only when a closing paren is threatening to disappear over the horizon. do ... return $ case ... of ... -- many lines Regards, Tom
Does anyone know why the haskell designers did not make the syntax right associative? It would clean up a lot of stuff. Haskell Non-Haskell Left Associative Right Associative foo (bar (baz (x))) foo bar baz x foo $ bar $ baz x foo bar baz x add (square x) (square y) add square x square y add (square x) y add square x y ------------From Prelude---------------------- map f x (map f) x f x (n - 1) x f x n - 1 x f x (foldr1 f xs) f x foldr1 f xs showChar '[' . shows x . showl xs showChar '[] shows x showl xs You just need to read from right to left accumulating a stack of arguments. When you hit a function that can consume some arguments, it does so. There is an error if you end up with more than one value on the argument stack. -Alex- On Fri, 25 May 2001, Tom Pledger wrote:
Peter Douglass writes: : | but in ( foo ( bar (baz x) ) ) | | You would want the following I think. | | foo . bar . baz x | | which does have the parens omitted, but requires the composition | operator.
Almost. To preserve the meaning, the composition syntax would need to be
(foo . bar . baz) x
or
foo . bar . baz $ x
or something along those lines. I favour the one with parens around the dotty part, and tend to use $ only when a closing paren is threatening to disappear over the horizon.
do ... return $ case ... of ... -- many lines
Regards, Tom
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
___________________________________________________________________ S. Alexander Jacobson Shop.Com 1-646-638-2300 voice The Easiest Way To Shop (sm)
"S. Alexander Jacobson" wrote:
Does anyone know why the haskell designers did not make the syntax right associative? It would clean up a lot of stuff.
Haskell Non-Haskell Left Associative Right Associative foo (bar (baz (x))) foo bar baz x foo $ bar $ baz x foo bar baz x add (square x) (square y) add square x square y add (square x) y add square x y ------------From Prelude---------------------- map f x (map f) x f x (n - 1) x f x n - 1 x f x (foldr1 f xs) f x foldr1 f xs showChar '[' . shows x . showl xs showChar '[] shows x showl xs
You just need to read from right to left accumulating a stack of arguments. When you hit a function that can consume some arguments, it does so. There is an error if you end up with more than one value on the argument stack.
Note that in your proposal, add square x y is parsed as add (square x) y instead of add (square (x y)), so it's not right associative either. As you explained, the parse of an expression depends the types of the sub-expressions, which imo is BAD. Just consider type inference... -- Zhanyong
On Fri, 25 May 2001, Zhanyong Wan wrote:
As you explained, the parse of an expression depends the types of the sub-expressions, which imo is BAD. Just consider type inference...
Ok, your complaint is that f a b c=a b c could have type (a->b->c)->a->b->c or type (b->c)->(a->b)->a->c depending on the arguments passed e.g. (f head (map +2) [3]) has different type from (f add 2 3). Admittedly, this is different from how haskell type checks now. I guess the question is whether it is impossible to type check or whether it just requires modification to the type checking algorithm. Does anyone know? -Alex- ___________________________________________________________________ S. Alexander Jacobson Shop.Com 1-646-638-2300 voice The Easiest Way To Shop (sm)
S. Alexander Jacobson writes: | On Fri, 25 May 2001, Zhanyong Wan wrote: | > As you explained, the parse of an expression depends the types of the | > sub-expressions, which imo is BAD. Just consider type inference... Also, we can no longer take a divide-and-conquer approach to reading code, since the syntax may depend on the types of imports. | Ok, your complaint is that f a b c=a b c could have type | (a->b->c)->a->b->c or type (b->c)->(a->b)->a->c depending on the arguments | passed e.g. (f head (map +2) [3]) has different type from (f add 2 3). | | Admittedly, this is different from how haskell type checks now. I guess | the question is whether it is impossible to type check or whether it just | requires modification to the type checking algorithm. Does anyone know? Here's a troublesome example. module M(trouble) where f, g :: (a -> b) -> a -> b f = undefined g = undefined trouble = (.) f g -- ((.) f) g :: (a -> b) -> a -> b -- (.) (f g) :: (a -> b -> c) -> a -> b -> c <Villainous cackle> Regards, Tom
It seems that right-associativity is so intuitive that even the person proposing it doesn't get it right. :-) Partial applications are a particular problem:
Haskell Non-Haskell Left Associative Right Associative ------------From Prelude---------------------- f x (foldr1 f xs) f x foldr1 f xs
Wouldn't the rhs actually mean f x (foldr1 (f xs)) in current notation?
showChar '[' . shows x . showl xs showChar '[] shows x showl xs
Wouldn't the rhs actually mean showChar '[' (shows x (showl xs)) in current notation? This is quite different to the lhs composition. For these two examples, the correct right-associative expressions, as far as I can tell, should be: f x (foldr1 f xs) f x (foldr1 f) xs showChar '[' . shows x . showl xs showChar '[' . shows x . showl xs Regards, Malcolm
participants (5)
-
Malcolm Wallace -
Peter Douglass -
S. Alexander Jacobson -
Tom Pledger -
Zhanyong Wan