The only issue I would have with such a notation is not being able to visually tell the difference between a monadic function (say, without a explicit type sig, which is how I write parsers), and an applicative one. I'd prefer something like foo = app blah blah If only for some visual distinction, I think it also resolves the "do knowing about types" issue. Plus, this is a good case for some kind of custom-do syntax facility. So we could make do syntax for everything. :) /Joe On Oct 9, 2009, at 1:11 PM, Robert Atkey wrote:

On Fri, 2009-10-09 at 18:06 +0100, Philippa Cowderoy wrote:

...

This leads us to the bikeshed topic: what's the concrete syntax?

I implemented a simple Camlp4 syntax extension for Ocaml to do this. I chose the syntax:

applicatively let x = foo let y = bar in <pure stuff>

I quite like the word "applicatively".

Your overloading suggestion sounds to me like it would require the desugaring process to know something about types, but I'm not sure.

Bob

-- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336.

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

I have idiom brackets in that toy library already, but the ado syntax is fairly useful if you want to refer to several intermediate results by name. To work with idiom brackets you need to manually write a big lambda yourself and them apply it. If you have a lambda that takes several arguments -- which isn't all that uncommon in a parser! -- the names you are binding and their position in the input can get rather far apart, even using idiom sugar. Philippa's ado sugar lets you amortize that big binding statement over several lines and keeps the names closer to the binding. Not sure that it warrants a syntax extension in the Haskell case, but it is pretty convenient. =) -Edward Kmett On Fri, Oct 9, 2009 at 1:52 PM, Daniel Peebles wrote:

I'd prefer "idiom brackets" over something do-ish for Applicatives. Conor McBride's SHE already supports them, if you're willing to use a custom preprocessor.

On Fri, Oct 9, 2009 at 1:45 PM, Joe Fredette wrote:

...

The only issue I would have with such a notation is not being able to visually tell the difference between a monadic function (say, without a explicit type sig, which is how I write parsers), and an applicative one.

I'd prefer something like

foo = app blah blah

If only for some visual distinction, I think it also resolves the "do knowing about types" issue.

Plus, this is a good case for some kind of custom-do syntax facility. So we could make do syntax for everything. :)

/Joe

On Oct 9, 2009, at 1:11 PM, Robert Atkey wrote:

...

On Fri, 2009-10-09 at 18:06 +0100, Philippa Cowderoy wrote:

...

This leads us to the bikeshed topic: what's the concrete syntax?

I implemented a simple Camlp4 syntax extension for Ocaml to do this. I chose the syntax:

applicatively let x = foo let y = bar in <pure stuff>

I quite like the word "applicatively".

Your overloading suggestion sounds to me like it would require the desugaring process to know something about types, but I'm not sure.

Bob

-- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336.

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

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

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

Nicolas Pouillard wrote:

Excerpts from Edward Kmett's message of Fri Oct 09 20:04:08 +0200 2009:

...

I have idiom brackets in that toy library already, but the ado syntax is fairly useful if you want to refer to several intermediate results by name. To work with idiom brackets you need to manually write a big lambda yourself and them apply it. If you have a lambda that takes several arguments -- which isn't all that uncommon in a parser! -- the names you are binding and their position in the input can get rather far apart, even using idiom sugar. Philippa's ado sugar lets you amortize that big binding statement over several lines and keeps the names closer to the binding.

You can still name intermediate *computations* using local bindings, right? Then you just have to use the named computations in idioms brackets.

Not really good enough, because of all the computations whose results aren't used. Being able to tell at a glance which bits of the parser are handling data for the abstract syntax and which're structure to guide the parser is pretty handy. -- flippa@flippac.org