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

[Mattias Waldau <mattias.waldau@abc.se>]

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
>