[Haskell-cafe] flip dot

Brandon Moore brandonm at yahoo-inc.com
Wed Sep 27 21:21:52 EDT 2006


Greg Fitzgerald wrote:
> Since there's talk of removal of the composition operator in 
> Haskell-prime 
> <http://hackage.haskell.org/trac/haskell-prime/wiki/CompositionAsDot>, 
> how about this:
>
> Instead of:
> foo = f . g
>
> you write:
> foo = .g.f
>
> A leading dot would mean, "apply all unnamed parameters to the 
> function on the right".  A trailing dot would mean, "apply the result 
> of the left to the function on the right".
You mean "apply the function on the right to the result of the left"? 
Otherwise .g.f == \x -> (g x) f

> Prelude> notNull = .null.not
> => [a] -> Bool
> notNull [1,2,3]
> => True
>
> [1,2,3].notNull
> => True
> [1,2,3].null.not
> => True
>
> I like this because it has the same perks as the composition operator, 
> yet it looks like OO code and the data flows nicely from left to 
> right.  It reads especially well when using the bind operator on the 
> same line.
>
> Thoughts?
The left-to-right flow is pretty nice. I don't like the mechanics of 
your leading and internal dots - I don't see any way to interpret the 
internal dots as an infix operator without using some fancy typeclasses, 
whatever the leading dot gets to do. The infix dot would have to work at 
types
(a -> b) -> (b -> c) -> (a -> b)
and a -> (a -> b) -> b

Instead, How about making . reverse composition, and having some other 
symbol for flip ($), maybe '#'. Then you get things like

[1,2,3]#null.not

Which still vaguely resemble OO operations, if you think of composing 
together a path of accessors first, and then indexing with it.

you can even work with mutable fields reasonably nicely,
obj#a.b.c.readIORef
obj#a.b.c.flip writeIORef newVal

Finally,

Writing things in this left-to-right order lets you think of the 
starting value and make a sequence of transformations to get a result. 
Dangerously imperative ;)

The existing order instead calls to mind successively reducing the 
problem of producing desired output to simpler problems, eventually 
reaching a previously produced value. Wonderfully mathematical ;)

Brandon


More information about the Haskell-Cafe mailing list