RE: [Haskell] Re: RFC: DData in hierarchical libraries

I did not follow the Edison guidelines, nor the GHC "guidelines". I tried different variations but in the end I sticked to the most consistent set I could think of:
1) The structure (i.e. Map, Set, Queue) is always the last argument. 2) All operations are left-biased.
I noticed that the last point is rather important, it means that "insert key x map" will replace the current value of "key" with "x" if it is already present, and that "union map1 map2" will prefer elements of "map1" instead of "map2".
Just as a matter of personal preference, I find a right bias to be more intuitive. Also, if the map argument comes first in 'insert map key x', then partial application is more likely to be useful (you're more likely to be inserting several things in the same map, rather than the same thing in several maps). Cheers, Simon

Am Freitag, 12. März 2004 10:34 schrieb Simon Marlow:
[...]
Also, if the map argument comes first in 'insert map key x', then partial application is more likely to be useful (you're more likely to be inserting several things in the same map, rather than the same thing in several maps).
If you look at one concrete function, you probably use insert, lookup etc. several times with the same map argument and not with the same key argument. But IMO, this isn't a place where partial application is typically used. You often use partial application if you want to specialize a general function. For example, sum can be defined as foldl (+) 0. As you can see from this example, for specializing functions it is often essential to have the container argument last instead of first. Other examples are partial applications of Prelude.map.
Cheers, Simon
Wolfgang

Simon Marlow wrote:
Just as a matter of personal preference, I find a right bias to be more intuitive. Also, if the map argument comes first in 'insert map key x', then partial application is more likely to be useful (you're more likely to be inserting several things in the same map, rather than the same thing in several maps).
This makes a lot of sense!, even when it is inconsistent with "List.elem" (we could argue that List.elem is just wrong :-) So we can do supposedly common things like: any (member s) xs map (lookup m) ks (But I think I can also come up with partial applications where the current design is nicer so I don't think we should get into long discussions about which partial application occurs more often unless we can back it up with data :-) Personally, at the moment, I like "right-bias with structure arguments coming first" more -- so if many others like it better too, I might be persuaded to adapt the implementation. However, this requires quite a bit of work, so I would like to leave this issue open for discussion for a while. All the best, Daan.

"Daan Leijen"
Simon Marlow wrote:
'insert map key x'
So we can do supposedly common things like: any (member s) xs map (lookup m) ks
the current design is nicer so I don't think we should get into long discussions about which partial application occurs more often unless we can back it up with data :-)
If you want a data point, I grepped quickly through my sources and found a handful of "map (lookupFM fm) xs"-type constructs.
more -- so if many others like it better too, I might be persuaded to adapt the implementation. However, this requires quite a bit of work, so I would like to leave this issue open for discussion for a while.
I've no really strong preference, but would vote for keeping the order defined by the old FiniteMap and Set implementations, if for no other reason than being more compatible. -kzm -- If I haven't seen further, it is by standing in the footprints of giants

On Fri, Mar 12, 2004 at 04:06:57PM +0100, Ketil Malde wrote:
"Daan Leijen"
writes: Simon Marlow wrote:
'insert map key x'
So we can do supposedly common things like: any (member s) xs map (lookup m) ks
the current design is nicer so I don't think we should get into long discussions about which partial application occurs more often unless we can back it up with data :-)
If you want a data point, I grepped quickly through my sources and found a handful of "map (lookupFM fm) xs"-type constructs.
more -- so if many others like it better too, I might be persuaded to adapt the implementation. However, this requires quite a bit of work, so I would like to leave this issue open for discussion for a while.
I've no really strong preference, but would vote for keeping the order defined by the old FiniteMap and Set implementations, if for no other reason than being more compatible.
Ack. the new, consistant, useful order and regular bias are some of my major reasons for prefering DData. If you want to do many things to the same Map, there are plenty of functions for dealing with lists of things to add or whatnot, the partially aplied functions with the map at the end give new, useful functionality orthogonal to the list dealing with functions. hope this makes sense. John -- --------------------------------------------------------------------------- John Meacham - California Institute of Technology, Alum. - john@foo.net ---------------------------------------------------------------------------
participants (5)
-
Daan Leijen
-
John Meacham
-
Ketil Malde
-
Simon Marlow
-
Wolfgang Jeltsch