How to refactor a large Ocaml program

How to refactor a large Ocaml program

[Mattias Waldau]

I have a large ocaml program and I need to make major changes.

After using C# with ReSharper in Visual Studio I am bit spoiled :-)
Having a reliable "Find Usage" feature in the browser is really useful 
when you start tearing apart a program. It is really nice to be able to 
go to the definition of a function directly, and find all locations it 
is used.

However, when I go back to Ocamlm, Emacs and Otags and -dtypes doesn't 
give a lot of help except the types.

For example Emacs "Find-tag" on Std.left, which find the following 
functions:

left, margin_left,......

Do anyone know about better ways of doing this?

-- Mattias

Re: [Caml-list] How to refactor a large Ocaml program

[Pietro Abate]

not an answer, but a general comment, maybe also a bit OT ...

On Wed, Dec 13, 2006 at 01:37:55PM +0100, Mattias Waldau wrote:
> I have a large ocaml program and I need to make major changes.
> After using C# with ReSharper in Visual Studio I am bit spoiled :-)
> Having a reliable "Find Usage" feature in the browser is really useful 
> when you start tearing apart a program. It is really nice to be able to 
> go to the definition of a function directly, and find all locations it 
> is used.

the other day I was talking with a friend and during a discussion about
java and visual development tool, he put forward the lack of refactoring
tool as a major obstacle in the adoption of "accademic" programming
languages. 

In java or c# you often end up writing programs that are more then 10K
lines long and composed of many tightly couple modules/components. 
This is because of the verbosity of the language itself and because OOP
make you structure your programs as a graph of object/classes. In this
context, refactoring a program without some aid can be really messy,
time consuming and error prone.

On the other hand, in ocaml, I've never written modules/logical units
bigger than 1K lines, and even if the project can grow very big, the
level of interaction between modules is often confined to the module
interface and changing the name of a function is usually never a big
problem.

To some extent, the lack of visual tool can be justified by this
difference.  Where for java/c# developers (in particular on windows)
visual tool are essential for productivity, ocaml developers often get
way without using anything more than vi/emacs because the programs
written in ocaml are more manageable by a human. For me 10K loc for a
logical unit is the maximum I can hold in my head at once. More then
that drive me crazy and often induces me to re-think my entire
architecture.

Does this match your experience ?

p

-- 
++ Blog: http://blog.rsise.anu.edu.au/?q=pietro
++ 
++ "All great truths begin as blasphemies." -George Bernard Shaw
++ Please avoid sending me Word or PowerPoint attachments.
   See http://www.fsf.org/philosophy/no-word-attachments.html

Re: [Caml-list] How to refactor a large Ocaml program

[Jon Harrop]

On Wednesday 13 December 2006 13:09, Pietro Abate wrote:
> Does this match your experience ?

Such tools are certainly less useful in functional languages but I do find the 
basic functionality provided by Visual Studio's F# mode useful.

-- 
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
Objective CAML for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists

Re: [Caml-list] How to refactor a large Ocaml program

[skaller]

On Thu, 2006-12-14 at 00:09 +1100, Pietro Abate wrote:
> not an answer, but a general comment, maybe also a bit OT ...

> On the other hand, in ocaml, I've never written modules/logical units
> bigger than 1K lines, and even if the project can grow very big, the
> level of interaction between modules is often confined to the module
> interface and changing the name of a function is usually never a big
> problem.

Felix compiler (Ocaml code) is 100K loc. 
The largest hand written files appear to be around 5K  loc.
The compiler runs in phases so coupling is vaguely 'vine like' :)

One of the longest (5K loc) files is more or less
a single huge let-rec. I wish I *could* factor it
more easily. It is a very hard module to understand,
and also consumes about 65% of the compiler running time.

I'm not a very good programmer.. there's no way I could
have gotten this code running in C++ or Java.

Ocaml is quite reasonably expressive. It mainly lets
me think about semantics without too much worrying
about house keeping.

-- 
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net

Re: [Caml-list] How to refactor a large Ocaml program

[Richard Jones]

On Thu, Dec 14, 2006 at 12:09:22AM +1100, Pietro Abate wrote:
> not an answer, but a general comment, maybe also a bit OT ...
>[...]
> For me 10K loc for a logical unit is the maximum I can hold in my
> head at once. More then that drive me crazy and often induces me to
> re-think my entire architecture.
>
> Does this match your experience ?

I just analysed all the code written by Merjis, all 77,070 lines of
it.  (This is split across dozens of programs and libraries.)

Longest files:

   1905 ./freeware/weblogs/weblogs_charset.ml
   1149 ./freeware/pgocaml/pGOCaml.ml

The first wasn't written by me, but snarfed from mldonkey. The second
is mostly a series of translations between PostgreSQL types and OCaml
types, so it doesn't really count as complicated.

573 files, so average lines/file = 134 lines.

Median is 77 lines.

Refactoring is something we've certainly not worried about.

Rich.

-- 
Richard Jones, CTO Merjis Ltd.
Merjis - web marketing and technology - http://merjis.com
Internet Marketing and AdWords courses - http://merjis.com/courses - NEW!
Merjis blog - http://blog.merjis.com - NEW!

Re: [Caml-list] How to refactor a large Ocaml program

[Yann Coscoy]

My opinion is that you are right when you say that ocaml programs are
often shorter than Java one. However, I have the feeling that you are
over-enthusiastic about manageability of ocaml programs.

I think that the only reason why ocaml programmers do no use refactoring
tools is that such tools do not exits of ocaml.

And if these tools do not exists it is not because nobody need nor want
them. It is because it requires a huge effort to have good ones. And
nobody has done is effort yet.

       Yann Coscoy

Re: [Caml-list] How to refactor a large Ocaml program

[Jon Harrop]

On Wednesday 13 December 2006 14:00, Yann Coscoy wrote:
> And if these tools do not exists it is not because nobody need nor want
> them. It is because it requires a huge effort to have good ones. And
> nobody has done is effort yet.

I don't think it would be a huge effort to write refactoring tools for OCaml. 
Indeed, I've propose this idea for F#. The hard part is writing the lexer and 
parser, which is already found in the front end of the compiler (albeit 
without parsing of comments). Then you're just rewriting an AST, which is a 
piece of cake in ML. :-)

-- 
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
Objective CAML for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists

Re: [Caml-list] How to refactor a large Ocaml program

[Yann Coscoy]

Jon Harrop a écrit :
> On Wednesday 13 December 2006 14:00, Yann Coscoy wrote:
>> And if these tools do not exists it is not because nobody need nor want
>> them. It is because it requires a huge effort to have good ones. And
>> nobody has done is effort yet.
> 
> I don't think it would be a huge effort to write refactoring tools for OCaml. 
> Indeed, I've propose this idea for F#. The hard part is writing the lexer and 
> parser, which is already found in the front end of the compiler (albeit 
> without parsing of comments). Then you're just rewriting an AST, which is a 
> piece of cake in ML. :-)
> 

I don't think either that it is difficult to write a refactoring tools
for OCaml. But I still believe it is would be huge effort to have a
*good* tool to do it.

When I say a good tool, I think of something user-friendly, with nice
interface (graphical or not)... In a word something that would convince
you to use it instead of search/replace under emacs (or vi).

The hard part is not writing the lexer and the parser, the hard part is
 to make some environment to interact with the developer.


    Yann Coscoy

Re: [Caml-list] How to refactor a large Ocaml program

[Mattias Engdegård]

>I don't think it would be a huge effort to write refactoring tools for OCaml. 
>Indeed, I've propose this idea for F#. The hard part is writing the lexer and 
>parser, which is already found in the front end of the compiler (albeit 
>without parsing of comments). Then you're just rewriting an AST, which is a 
>piece of cake in ML. :-)

Writing smooth refactoring tools isn't always that simple, as it's not
just a question of parsing and emitting trees. It is very desirable to
preserve existing layout as far as possible, including comments.
This doesn't mean it's hard, just that it may not be as trivial as an
innocent programmer might think from your comment.

See the Refactoring Functional Programs project, especially its final
report. It was done for Haskell but anyone aspiring to write an OCaml
refactoring tool would do well to learn from it.

Intimately related to refactoring tools are programming environments
with knowledge of the language - for code completion, type information,
source navigation and so on. Tuareg-mode is very nice, but limited.

Re: [Caml-list] How to refactor a large Ocaml program

[Gerd Stolpmann]

Am Mittwoch, den 13.12.2006, 15:00 +0100 schrieb Yann Coscoy:
> My opinion is that you are right when you say that ocaml programs are
> often shorter than Java one. However, I have the feeling that you are
> over-enthusiastic about manageability of ocaml programs.

Well, it is certainly possible to write Ocaml programs that turn out to
be unmanageable. My experience (which is currently a 53 kloc commercial
project) is different, however. We are refactoring all the time, and it
is no big deal.

Ok, we are only refactoring from "good design A" to "good design B", and
not from a bad design to a hopefully better design.

> I think that the only reason why ocaml programmers do no use refactoring
> tools is that such tools do not exits of ocaml.

I wouldn't use such a tool if it were more complicated than the status
quo.

Anyway, I think it is more the people who make a large program
manageable, not the availability of such tools.

Gerd
-- 
------------------------------------------------------------
Gerd Stolpmann * Viktoriastr. 45 * 64293 Darmstadt * Germany 
gerd@gerd-stolpmann.de          http://www.gerd-stolpmann.de
Phone: +49-6151-153855                  Fax: +49-6151-997714
------------------------------------------------------------

Re: [Caml-list] How to refactor a large Ocaml program

[Jon Harrop]

On Wednesday 13 December 2006 16:48, Gerd Stolpmann wrote:
> Ok, we are only refactoring from "good design A" to "good design B", and
> not from a bad design to a hopefully better design.

I have also found it beneficial to write only awesome code.

-- 
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
Objective CAML for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists

Re: [Caml-list] How to refactor a large Ocaml program

[Jim Miller]

[-- Attachment #1: Type: text/plain, Size: 1980 bytes --]

This is where I think I enjoy the test driven design that I've followed over
the past few years (I guess the agile folks have taken it as their own).  I
don't use any development tools for any language (java or Ocaml) and depend
on the compiler.

(I also take refactoring to mean that you're changing the design of a piece
of software that's resident behind a module or class interface.)

I then start refactoring making sure that I'm running the tests at almost
every compile to make sure that I didn't break something.  I do everything
from clean compiles (Ocaml's compiler is nice and fast) so that the compiler
will tell me everywhere that a function is used.

This has worked for me but I will also say that I pay very strong attention
to module interdependencies (Large Scale C++ Software Design by John Lakos
makes some great arguments that directly apply to Ocaml as well) so I'm able
to track my dependencies pretty easily.

Good luck

On 12/13/06, Mattias Waldau <mattias.waldau@abc.se> wrote:
>
> I have a large ocaml program and I need to make major changes.
>
> After using C# with ReSharper in Visual Studio I am bit spoiled :-)
> Having a reliable "Find Usage" feature in the browser is really useful
> when you start tearing apart a program. It is really nice to be able to
> go to the definition of a function directly, and find all locations it
> is used.
>
> However, when I go back to Ocamlm, Emacs and Otags and -dtypes doesn't
> give a lot of help except the types.
>
> For example Emacs "Find-tag" on Std.left, which find the following
> functions:
>
> left, margin_left,......
>
> Do anyone know about better ways of doing this?
>
> -- Mattias
>
> _______________________________________________
> Caml-list mailing list. Subscription management:
> http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
> Archives: http://caml.inria.fr
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs
>

[-- Attachment #2: Type: text/html, Size: 2564 bytes --]

Re: [Caml-list] How to refactor a large Ocaml program

[Mattias Waldau]

Yes, editing and compiling until it works is a way to refactor, and I 
used that method before. However, this only works if you know what you 
are doing. In many cases you realize the change you made was stupid and 
you have to roll back, i.e. undo or revert using CVS.

One problem with ocaml syntax is the open-statement, i.e. this makes it 
unclear for an editor

Ocaml already has the -dtypes. Why doesn't this file contain information 
about where the functions and types are defined.

For example, if you have a function call

open Filename;

let _ =
	concat .........

in main.ml

the main.annot contains

"main.ml" 183 7050 7070 "main.ml" 183 7050 7085
type(
   string -> string -> string
)

An improvement would be if it also contained information about the 
function, i.e.

"main.ml" 183 7050 7070 "main.ml" 183 7050 7085
type(
   Filename.concat: string -> string -> string
)

Then, the editor mode 'M-x goto-tag' or similar could look in the .annot 
file and open the correct file and go to the definition. (Maybe more 
information than Filename.concat is needed).

Also, it would be very simple to find all calls to a specific function, 
for example Filename.concat, just grep through all the annot-files.

---

When I wrote this, I thought that a simple solution would be to always 
write the module name first and stop using 'open Filename'. However, 
this doesn't work, since you are not allowed to write Filename.concat 
inside the filename.ml file. Why? Couldn't we have a special case for this?

-- Mattias


Brian Hurt wrote:
> Mattias Waldau wrote:
> 
>> I have a large ocaml program and I need to make major changes.
>>
>> After using C# with ReSharper in Visual Studio I am bit spoiled :-)
>> Having a reliable "Find Usage" feature in the browser is really useful 
>> when you start tearing apart a program. It is really nice to be able 
>> to go to the definition of a function directly, and find all locations 
>> it is used.
> 
> 
> I have had good experiences with the following process: 1) make major 
> changes to some module, 2) recompile everything, 3) have the recompile 
> fail with an error because the changes made in step 1 changed the types, 
> and I forgot to fix someplace that called the changed code- but the 
> compiler gives me filename and line number of where I need to go fix, 4) 
> repeat steps 2 & 3 until the code compiles, 5) test the code to make 
> sure I haven't broken anything subtle.
> 
> The reason there isn't a seperate tool for doing this is that it's built 
> in to the compiler.
> 
> Brian
> 

Re: [Caml-list] How to refactor a large Ocaml program

[Bruno De Fraine]

Hello,

I think there are a number of factors that certainly make it easier  
to develop refactoring tools for Ocaml:
- it is a static language
- there is already source code available for working with Ocaml code,  
e.g. ocamlc

> Ocaml already has the -dtypes. Why doesn't this file contain  
> information about where the functions and types are defined.

Yes, it seems like a good idea for ocamlc to emit defines/uses  
annotations, at least for lowercase identifiers in the syntax tree.  
For example, if I show these annotations in-place as comments:

let foo(* defines: _global01 *) = 12 ;;
let bar(* defines: _global02 *) x(* defines: _local01 *) =
	foo(* uses: _global01 *) + x(* uses: _local01 *) ;;
bar(* uses: _global02 *) foo(* uses: _global01 *) ;;
let foo(* defines: _global03 *) = "foo" ;;
(* etc. *)

Your editor would be able to jump from definition to usage and vice  
versa with this information.

Editing and recompiling is what we currently use to discover this  
information mechanically, but it seems better not to have to make  
destructive changes to source files.

Bye,
Bruno

-- 
Bruno De Fraine
Vrije Universiteit Brussel
Faculty of Applied Sciences, INFO - SSEL
Room 4K208, Pleinlaan 2, B-1050 Brussels
tel: +32 (0)2 629 29 75
fax: +32 (0)2 629 28 70
e-mail: Bruno.De.Fraine@vub.ac.be

Re: [Caml-list] How to refactor a large Ocaml program

[Brian Hurt]

Mattias Waldau wrote:

> Yes, editing and compiling until it works is a way to refactor, and I 
> used that method before. However, this only works if you know what you 
> are doing. In many cases you realize the change you made was stupid 
> and you have to roll back, i.e. undo or revert using CVS.


I prefer subversion, but basically, yes.  Ignoring for the moment that 
"always use version control" and "commit early, commit often" are good 
advice no matter what programming language or tool set you are using, 
undoing changes works much the same way- the compiler will catch the 
places you haven't switched back yet.  In fact, it's not unusual for me 
to start making a change, update a bunch of places but not all, decide 
that isn't what I wanted to do after all, and partially undo the first 
change to make the second change.  So now I have some places in the code 
that haven't been changed at all, some places which have been changed 
once and now need to be changed again, and some places that have been 
changed twice and don't need to be changed.  Compile them all, let Ocaml 
sort things out.

There may be an advantage to having an advanced refactoring tool, my 
point is that I really doubt the advantage will be the night and day 
difference it is in other languages.

Brian

Re: [Caml-list] How to refactor a large Ocaml program

[Florian Hars]

Brian Hurt wrote:
> Compile them all, let Ocaml sort things out.

Except that more often than not the compiler will flag the type error
at one of the locations where the type is already the way you want it
and you have to hunt through all other files in your project trying to
divine where the conflicting type assignment comes from.

Yours, Florian.

Re: [Caml-list] How to refactor a large Ocaml program

[Remi Vanicat]

2006/12/15, Florian Hars <hars@bik-gmbh.de>:
> Brian Hurt wrote:
> > Compile them all, let Ocaml sort things out.
>
> Except that more often than not the compiler will flag the type error
> at one of the locations where the type is already the way you want it
> and you have to hunt through all other files in your project trying to
> divine where the conflicting type assignment comes from.

You can then explicitly declare the type you want, and the error will
be found where it is.

Re: [Caml-list] How to refactor a large Ocaml program

[Christian Stork]

On Sat, Dec 16, 2006 at 11:14:13AM +0100, Remi Vanicat wrote:
> 2006/12/15, Florian Hars <hars@bik-gmbh.de>:
> >Brian Hurt wrote:
> >> Compile them all, let Ocaml sort things out.

> >Except that more often than not the compiler will flag the type error
> >at one of the locations where the type is already the way you want it
> >and you have to hunt through all other files in your project trying to
> >divine where the conflicting type assignment comes from.

> You can then explicitly declare the type you want, and the error will
> be found where it is.

Unless it's a polymorphic type, in which case the type annotation only
has to unify with the offending location's type.

-- 
Chris Stork   <>  Support eff.org!  <>   http://www.ics.uci.edu/~cstork/
OpenPGP fingerprint:  B08B 602C C806 C492 D069  021E 41F3 8C8D 50F9 CA2F

Re: [Caml-list] How to refactor a large Ocaml program

[Florian Hars]

Remi Vanicat schrieb:
> You can then explicitly declare the type you want

So, essentially, type inference and refactoring without tool
support don't mix that well. QED ;-)

Yours, Florian.

Re: [Caml-list] How to refactor a large Ocaml program

[Jacques Garrigue]

From: Mattias Waldau <mattias.waldau@abc.se>

> One problem with ocaml syntax is the open-statement, i.e. this makes it 
> unclear for an editor
> 
> Ocaml already has the -dtypes. Why doesn't this file contain information 
> about where the functions and types are defined.
> 
> For example, if you have a function call
> 
> open Filename;
> 
> let _ =
> 	concat .........
> 
> in main.ml
> 
> the main.annot contains
> 
> "main.ml" 183 7050 7070 "main.ml" 183 7050 7085
> type(
>    string -> string -> string
> )
> 
> An improvement would be if it also contained information about the 
> function, i.e.
> 
> "main.ml" 183 7050 7070 "main.ml" 183 7050 7085
> type(
>    Filename.concat: string -> string -> string
> )
> 
> Then, the editor mode 'M-x goto-tag' or similar could look in the .annot 
> file and open the correct file and go to the definition. (Maybe more 
> information than Filename.concat is needed).

FYI, ocamlbrowser can already do that: open your file, typecheck it,
double-click on an identifier, and use the "impl" button in the type
browser.
It would not be much more difficult to do it in emacs, I suppose.

   Jacques Garrigue

Re: [Caml-list] How to refactor a large Ocaml program

[Mattias Waldau]

Hi Jacques,

Thank you for the tip.

I think we are talking about different things. Since there is no 
refactoring I will have to settle for something simpler.

A nice thing would be to be able to navigate the program, i.e.

1. Goto to definition (Ctrl-B in Visual Studio)

2. Find usage. (Alt-F7 in Resharper)

A enhanced .annot file as described below would enable that for compiled 
programs. (Resharper and similar tools makes it work for non-compilable 
programs.)

-- Mattias

Jacques Garrigue wrote:
> From: Mattias Waldau <mattias.waldau@abc.se>
> 
>> One problem with ocaml syntax is the open-statement, i.e. this makes it 
>> unclear for an editor
>>
>> Ocaml already has the -dtypes. Why doesn't this file contain information 
>> about where the functions and types are defined.
>>
>> For example, if you have a function call
>>
>> open Filename;
>>
>> let _ =
>> 	concat .........
>>
>> in main.ml
>>
>> the main.annot contains
>>
>> "main.ml" 183 7050 7070 "main.ml" 183 7050 7085
>> type(
>>    string -> string -> string
>> )
>>
>> An improvement would be if it also contained information about the 
>> function, i.e.
>>
>> "main.ml" 183 7050 7070 "main.ml" 183 7050 7085
>> type(
>>    Filename.concat: string -> string -> string
>> )
>>
>> Then, the editor mode 'M-x goto-tag' or similar could look in the .annot 
>> file and open the correct file and go to the definition. (Maybe more 
>> information than Filename.concat is needed).
> 
> FYI, ocamlbrowser can already do that: open your file, typecheck it,
> double-click on an identifier, and use the "impl" button in the type
> browser.
> It would not be much more difficult to do it in emacs, I suppose.
> 
>    Jacques Garrigue
> 

Re: [Caml-list] How to refactor a large Ocaml program

[Jan Rehders]

Hi,

On 15. Dez 2006, at 08:49, Mattias Waldau wrote:
> A nice thing would be to be able to navigate the program, i.e.
>
> 1. Goto to definition (Ctrl-B in Visual Studio)

This is possible with Otags

On the utility of a refactoring tool: I believe it would be very  
useful in OCaml. It doesn't matter that much whether a language is  
expressive or not, tools doing repetitive  work are always a great  
relieve. Imagine changing the signature of a function in a module  
type which is realized by several modules which in turn are used all  
around the program. You don't need bad code to save much time here if  
the name change is done by a tool in seconds instead of by a  
programmer in minutes or hours. Apart from that an "extract  
method"/"pull up let expression" refactoring would be especially  
useful in OCaml where one uses nested "let" expressions often. I find  
myself pulling a local function up a level frequently.

There is a huge gap between tools which are aware of the program  
structure and those who are not. Take a language where such tools  
exist like Java: can anyone who ever got used to IDEA IntelliJ or  
Eclipse JDT going back to a simple text editor? I even prefer them  
over Emacs for Java coding. There is so much an IDE can provide if it  
can work on an AST of the language that you don't want to miss it.  
Not even in a language like OCaml. Searching references, changing  
names and structure etc. are things which can be done by the editor/ 
IDE. A powerful language can do much to improve programmers  
productivity but it will only reach it's full potential together with  
equally powerful tools - would anyone program OCaml in MS Notepad?

Has anyone tried adding OCaml support for Emacs semantic? This might  
be a starting point

-- Jan

Re: [Caml-list] How to refactor a large Ocaml program

[skaller]

On Fri, 2006-12-15 at 13:36 +0100, Jan Rehders wrote:
> would anyone program OCaml in MS Notepad?

I use Vim, which is close :) No, I do not use
any scripts, tags, or advanced editing, not even syntax
colouring.

-- 
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net

Re: [Caml-list] How to refactor a large Ocaml program

[Mattias Waldau]

I agree that the smaller size of Ocaml programs makes them more 
manageable, however it doesn't solve all problems. My experience from 
doing refactoring like this is that you end up with a non-compiling 
program for a while, and in a day or two, your programs works well again.

A "real" refactoring tool requires parsers, lexer etc, and I am not sure 
Ocaml syntax is very good for doing this kind of parsing on 
non-compiling code. (A side note, are there any programming language 
defined whose syntax has been designed so that fragments can be parsed?).

However, a simple solution is to improve the .annot files as described 
in the previous entry, so that we at least can analyze compiled programs.

> Am Mittwoch, den 13.12.2006, 15:00 +0100 schrieb Yann Coscoy:
>> My opinion is that you are right when you say that ocaml programs are
>> often shorter than Java one. However, I have the feeling that you are
>> over-enthusiastic about manageability of ocaml programs.
> 
> Well, it is certainly possible to write Ocaml programs that turn out to
> be unmanageable. My experience (which is currently a 53 kloc commercial
> project) is different, however. We are refactoring all the time, and it
> is no big deal.
> 
> Ok, we are only refactoring from "good design A" to "good design B", and
> not from a bad design to a hopefully better design.

Re: [Caml-list] How to refactor a large Ocaml program

[malc]

On Wed, 13 Dec 2006, Mattias Waldau wrote:

> I have a large ocaml program and I need to make major changes.
>
> After using C# with ReSharper in Visual Studio I am bit spoiled :-)
> Having a reliable "Find Usage" feature in the browser is really useful when 
> you start tearing apart a program. It is really nice to be able to go to the 
> definition of a function directly, and find all locations it is used.
>
> However, when I go back to Ocamlm, Emacs and Otags and -dtypes doesn't give a 
> lot of help except the types.
>
> For example Emacs "Find-tag" on Std.left, which find the following functions:
>
> left, margin_left,......
>
> Do anyone know about better ways of doing this?

Not really relevant nevertheless curious fact - in 2003 a team which
included two JetBrains[1] employees won a second prize at ICFP contest[2],
with an entry in a mixture of OCaml and C[3].

[1] Though on the page the company name is spelled as IntelliJ software
[2] http://www.dtek.chalmers.se/groups/icfpcontest/
[3] http://oops.tepkom.ru/~msk/icfp2003.html

--
vale