I don't see the similarity (from reading this: http://www.haskell.org/haskellwiki/Idiom_brackets). My suggestion is just a way of using layout to avoid parenthesis. /J 2011/5/25 Brandon Allbery :

2011/5/25 Jonas Almström Duregård

...

Would it be possible to allow this in Haskell (where <applied to> is some new operator or keyword): f <applied to> {x a;y b;z c}

Sounds like idiom brackets to me.

Hi Alexander,

This is "exactly" the applicative style, where idiom brackets come from.

I disagree. Layout has at least two advantages over applicative here: 1) Applicative costs (at least) three additional characters per function parameter. 2) You can not have arbitrary infix operators in the parameters when using applicative. Also your example is not really equivalent to f (x a) (y b) (z c) is it?

Idiom brackets abstract the <$> (fmap) and (<*>) operators away.

But from what I can tell it also reintroduces the parenthesis? How would you write f (x a) (y b) in idiom brackets? /J On 25 May 2011 22:06, Alexander Solla wrote:

2011/5/25 Jonas Almström Duregård

...

I don't see the similarity (from reading this: http://www.haskell.org/haskellwiki/Idiom_brackets). My suggestion is just a way of using layout to avoid parenthesis.

This is "exactly" the applicative style, where idiom brackets come from. Use Control.Applicative: f <$> x a <*> y b <*> z c You can use the identity functor to recover "plain old" function application. Idiom brackets abstract the <$> (fmap) and (<*>) operators away. And yes, you are right that applicative style is very useful.

That's a useful operator! Unfortunately it does not play nice with $. Of less importance: some syntactic constructs can not appear in the arguments without parenthesis, let bindings for instance (although lambda abstraction works parenthesis-free). Also I'm not sure this can be used for defining trees or nested function application since a nesting of the operator inevitably require parenthesis. /J On 26 May 2011 14:52, Daniel Fischer wrote:

On Thursday 26 May 2011 14:35:41, Neil Brown wrote:

...

foo is the function we want to apply, and eg shows how to apply it in do-notation with an argument on each line. I couldn't manage to remove the r$ at the beginning of each line, which rather ruins the whole scheme :-( On the plus side, there's no brackets, it's only two extra characters per line, and you can have whatever you like after the r$.

Wouldn't that be also achievable with

infixl 0 ?

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

eg = foo ? 2 + 1 ? 'c' ? "hello" ++ "goodbye" ? 3.0

?

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

2011/5/26 Daniel Fischer

As far as I'm concerned, a left-associative version of ($) would sometimes be nice (on the other hand, right-associativity of ($) is sometimes also nice), but usually, I don't find parentheses too obnoxious.

I have a whole set of function application/composition/lifting operators that I'm rather fond of, but it involves replacing some standard operators, and in particular changes the fixity of ($) drastically, so it's something I only use in small bits of personal code that I'll never publish anywhere. The main idea is that there are two groups of operators, each of which are internally pretty consistent and vaguely generalized from standard operators. Very low precedence, function application associates toward argument: f <| x = x |> f = f x, (>>>) and (<<<) for composition, and (>>=), (=<<), (>=>), and (<=<) behaving as expected. (<|) takes the place of standard ($), and (|>) allows a "pipe forward" style similar to using (>>=). Mid-to-high precedence, function application associates away from argument: ($) has the same fixity as (<$>) and (<*>), as do the binding operators (=<$) and (=<*), the latter being a function I haven't seen before that does about what you'd expect from the name. Composition is usually just (.) in most cases because of the style in which I use these. What it amounts to is that the first group is used mostly as pseudo-syntax delimiting expressions that would otherwise be parenthesized, while the second group is used for writing expressions that would conceptually be simple one-liners if not for involving lifting into some sort of Functor. The choice of symbols makes it easy to remember which is which, even if it's not perfectly consistent. Mostly, though, this is probably just another reason why my personal coding style would be bafflingly opaque to most people, so oh well. - C.