Version française
Home     About     Download     Resources     Contact us    

This site is updated infrequently. For up-to-date information, please visit the new OCaml website at

Browse thread
What does Jane Street use/want for an IDE? What about you?
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2008-10-25 (23:16)
From: Martin Jambon <martin.jambon@e...>
Subject: Indentation (was Re: [Caml-list] What does Jane Street use/want for an IDE? What about you?)
Daniel Bünzli wrote:
> Le 25 oct. 08 à 14:43, Martin Jambon a écrit :
>> Now I generally tend to use this:
>> let x =
>> (
>>    fun z ->
>>      very_blabla
>>      ...
>>  ) my_list
>> in
> I think the best solution is to name your anonymous function, as the
> guidelines suggest [1].

It says: "Justification: Much clearer, in particular if the name given
to the function is meaningful."

I think that's true for typical functional code which follows some clear
logic or model.

In many cases it's not possible to give a meaningful name to such a
function and defining it out of the current block can make things
needlessly hard to follow.

I can think of 4 cases:

1. anonymous function that fits on one line
2. anonymous function that doesn't fit on one line (my original example)
3. named function defined locally using let-in
4. named function defined globally using let

I don't use (3) very much since:
* it still causes the outermost function definition to be very long and
hard to follow like (2),
* and it's okay to define a function globally (4) because there is no
serious risk of global namespace pollution, thanks to the module system.

I think (3) is most useful for defining named functions that depend on a
lot of locally-defined values. This creates a closure, which is often
acceptable performance-wise, instead of having to make each parameter of
the function explicit.

In performance-critical code or maybe imperative code in general, it
feels good to control when closures are created. In such cases, avoiding
local functions helps.