Re: argument ordering (was: Re: Priority Queues, or lack thereof)
David Roundy wrote:
This style supports multiple operations nicely, especially with combined with the $ operator. For example, to insert 3 elements into a set, you can say insert 1 $ insert 2 $ insert 3 $ someSet (the last $ is optional). With the other argument ordering, you would say insert (insert (insert someSet 3) 2) 1
With this ordering, couldn't one simply write
someSet `insert` 3 `insert` 2 `insert` 1
?
Sure, although I'll admit that I have an aversion to the backquote style of infix operators. The bigger problem with this style is what to do about non-binary operations. For example, insert for a dictionary takes three arguments. So you could write insert 1 a $ insert 2 b $ insert 3 c dict but not dict `insert` 1 a `insert` 2 b `insert' 3 c Of course, you could potentially package some arguments in a tuple dict `insert` (1,a) `insert` (2,b) `insert` (3,c) but having some arguments in tuples has its own problems. -- Chris
Okasaki, C. DR EECS wrote:
insert 1 a $ insert 2 b $ insert 3 c dict
A further argument for this notation is its close resemblance to the notation with function composition: insert 1 a . insert 2 b . insert 3 c $ dict particularly if the final argument "$ dict" can be omitted, i.e. in a function definition or a lambda expression. Cheers Christian
Christian Maeder wrote:
Okasaki, C. DR EECS wrote:
insert 1 a $ insert 2 b $ insert 3 c dict
A further argument for this notation is its close resemblance to the notation with function composition:
insert 1 a . insert 2 b . insert 3 c $ dict
... of course keeping in mind that that's exactly the "wrong" way to compose functions. See any algebra textbook for definition of (f . g) (namely, first apply f, then apply g) Motivations: 1. flow of information should be from left to right 2. consistency with composition of relations. of course you could say that even writing f(x) is "wrong" (see item 1) and there are indeed books that write xf instead (e. g. Sakarovitch: Theorie des Automates - but then even he makes exceptions, e. g. he uses prefix notation for lim, sin, dom ... :-) on the other hand I know at least on textbook that has the relational composition the wrong way around, obviously in order to make it agree with the wrong functional composition. best regards, -- -- Johannes Waldmann -- Tel/Fax (0341) 3076 6479/80 -- ---- http://www.imn.htwk-leipzig.de/~waldmann/ -------
On 8/22/05, Johannes Waldmann
Christian Maeder wrote:
Okasaki, C. DR EECS wrote:
insert 1 a $ insert 2 b $ insert 3 c dict
A further argument for this notation is its close resemblance to the notation with function composition:
insert 1 a . insert 2 b . insert 3 c $ dict
... of course keeping in mind that that's exactly the "wrong" way to compose functions. See any algebra textbook for definition of (f . g) (namely, first apply f, then apply g)
Aaaah.. No... That's not the way I learnt it at least, and it's not how it's defined in Haskell. f . g x = f (g x ) First appy g, then apply f to the result... See e.g. http://mathworld.wolfram.com/Composition.html /S -- Sebastian Sylvan +46(0)736-818655 UIN: 44640862
On Mon, 22 Aug 2005, Johannes Waldmann wrote:
Christian Maeder wrote:
Okasaki, C. DR EECS wrote:
insert 1 a $ insert 2 b $ insert 3 c dict
A further argument for this notation is its close resemblance to the notation with function composition:
insert 1 a . insert 2 b . insert 3 c $ dict
... of course keeping in mind that that's exactly the "wrong" way to compose functions. See any algebra textbook for definition of (f . g) (namely, first apply f, then apply g)
How is this related to the question of argument ordering of 'insert'? If you prefer the "right order" of function composition you can use a different composition operator (say #, like in functional Metapost). dict # insert 3 c # insert 2 b # insert 1 a But the ordering of arguments of 'insert' must be the same.
Just for the record, I would like to point out that for those of us who are heavy users of state monads, having the container as the last argument is a huge convenience. That way, when you use the container as state (and what else would you ever want to do with a container?), you can use modify, gets, modifySTRef, etc. without gratuitous flips all over the place. In fact, I always assumed that was the motivation for the API change between Data.FiniteMap and Data.Map. -Yitz
This is the most convincing argument yet, in my opinion. Frederik On Tue, Aug 23, 2005 at 01:00:30PM +0300, Yitzchak Gale wrote:
Just for the record, I would like to point out that for those of us who are heavy users of state monads, having the container as the last argument is a huge convenience. That way, when you use the container as state (and what else would you ever want to do with a container?), you can use modify, gets, modifySTRef, etc. without gratuitous flips all over the place.
In fact, I always assumed that was the motivation for the API change between Data.FiniteMap and Data.Map.
-Yitz _______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries
participants (7)
-
Christian Maeder -
Frederik Eaton -
Henning Thielemann -
Johannes Waldmann -
Okasaki, C. DR EECS -
Sebastian Sylvan -
Yitzchak Gale