On Wed, May 26, 2010 at 4:31 PM, Christophe TROESTLER
<Christophe.Troestler+oc...@umh.ac.be> wrote: > COULD PEOPLE WHO FIND THE DEFAULT USEFUL SPEAK UP NOW ?
I prefer the default:
let x = ... in let y = ... in foo
For what it's worth: I agree with the guidelines that two let-in are like two assumptions and should be indented the same. But I like to visualize the separation between the set of assumptions and what we do with it. Another argument is that let-in creates a new scope, and captures sequences of expressions. Visualizing it helps to understand the structure of code. For example:
On Thu, May 27, 2010 at 12:46 PM, David Baelde <david.bae...@gmail.com> wrote: > On Wed, May 26, 2010 at 4:31 PM, Christophe TROESTLER > <Christophe.Troestler+oc...@umh.ac.be> wrote: >> COULD PEOPLE WHO FIND THE DEFAULT USEFUL SPEAK UP NOW ?
> I prefer the default:
> let x = ... in > let y = ... in > foo
> For what it's worth: I agree with the guidelines that two let-in are > like two assumptions and should be indented the same.
Seconded, I think it looks neat and it avoids too much nesting clutter.
On Thu, May 27, 2010 at 9:25 AM, Eray Ozkural <examach...@gmail.com> wrote: > On Thu, May 27, 2010 at 12:46 PM, David Baelde <david.bae...@gmail.com> wrote: >> On Wed, May 26, 2010 at 4:31 PM, Christophe TROESTLER >> <Christophe.Troestler+oc...@umh.ac.be> wrote: >>> �COULD PEOPLE WHO FIND THE DEFAULT USEFUL SPEAK UP NOW ?
>> I prefer the default:
>> let x = ... in >> let y = ... in >> �foo
>> For what it's worth: I agree with the guidelines that two let-in are >> like two assumptions and should be indented the same.
> Seconded, I think it looks neat and it avoids too much nesting clutter.
This difference is only because of (what I perceive as) flaws in the [if]/[then] syntax. Namely that semicolon-delimited chains of expressions don't parse within the [then] or [else] sections without extra bracketing. This lets adding a bit of debug code (in if/then - exactly where it's usually needed) to totally break the semantics by pushing code outside the if/then expression. With improper indentation (like your second example), one can make it look like one thing is happening while another will happen.
Your first code block is a good example of non indented [let] blocks looking good. Your second example should be indented as follows to clarify its actual structure:
On Thu, May 27, 2010 at 6:01 PM, Edgar Friendly <thelema...@gmail.com> wrote: > Your first code block is a good example of non indented [let] blocks looking > good. Your second example should be indented as follows to clarify its > actual structure:
> if blah then > f () ; > g () ; > h ()
Right, this was a bad example, and I can't think of a good one. Maybe indentation can't help with that tricky syntax after all, and all I can say is "I prefer the way it looks that way" (which is no surprise since I've been learning OCaml under Tuareg).
> Hi, > The original author of the alternative Emacs mode for editing Ocaml code > (tuareg-mode), Albert Cohen, has stopped development some time ago. > Now, with his blessing, Jane Street Capital took over maintenance of the > code from him, and released Tuareg Mode v. 2.0.0. > It is available for download at > <http://www.janestreet.com/ocaml/tuareg.tgz>. > It is still released under the GNU General Public License (GPL) v2. > Please report bugs and submit patches to the dedicated public mailing > list at > <http://groups.google.com/group/tuareg-mode>. > Happy hacking! > Sam
