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 ;) Or, think of taking the continuation of your expression, and

Brandon Moore wrote: transforming it in left-to-right steps into one prepared to accept the value you've got. Brandon

(.) :: a -> (a -> b) -> b x.f == f x

Looks like a parallel of (>>=). Sounds interesting and useful, but why hijack dot? Would work nicely with record gettor functions (but not the settors).

Greg

Tim Newsham http://www.thenewsh.com/~newsham/

On 9/28/06, Brian Hulley wrote:

On Thursday, September 28, 2006 1:33 AM, Greg Fitzgerald wrote:

...

Since there's talk of removal of the composition operator in Haskell-prime, 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".

Hi -

I think the H' proposal http://hackage.haskell.org/trac/haskell-prime/wiki/CompositionAsDot is an extremely bad idea. I really don't see why people have so many problems with the idea of just placing spaces before and after the dot when used as an operator,

If C had something like that, we would use it as yet more reasons to make fun of it for. Spaces around operators shouldn't be significant. It's just extremly messy and ugly IMO.

and in any case it's hard to think of a more important operator in a functional language than composition and a more fitting symbol for it than the simple dot.

Well I would think that '=' is more important, for example. Or how about ->? There are many operators that absolutely essential for the langauge. Composition is, after all, merely a library function. The dot is a nice low-noise operator that could be put to good use as selectors of records and modules (being simliar to other languages in that regard is not a goal in itself, but certainly doesn't hurt). Reserved symbols should get to "choose first" IMO, and then the rest can be used for library functions. How aboug using <> for compositon? It almost looks like a ring. -- Sebastian Sylvan +46(0)736-818655 UIN: 44640862