From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from discorde.inria.fr (discorde.inria.fr [192.93.2.38]) by yquem.inria.fr (Postfix) with ESMTP id C29A3BC0B for ; Thu, 14 Dec 2006 09:09:45 +0100 (CET) Received: from violet.abc.se (violet.abc.se [62.80.200.155]) by discorde.inria.fr (8.13.6/8.13.6) with ESMTP id kBE89iwF029146 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 14 Dec 2006 09:09:45 +0100 Received: from [192.168.0.45] (localhost.localdomain [127.0.0.1]) (authenticated bits=0) by violet.abc.se (8.13.1/8.13.1) with ESMTP id kBE89eZa008447 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 14 Dec 2006 09:09:41 +0100 Message-ID: <458106BD.7060103@abc.se> Date: Thu, 14 Dec 2006 09:09:33 +0100 From: Mattias Waldau User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Brian Hurt , caml-list@yquem.inria.fr Subject: Re: [Caml-list] How to refactor a large Ocaml program References: <457FF423.7000703@abc.se> <45800CD5.8050401@janestcapital.com> In-Reply-To: <45800CD5.8050401@janestcapital.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.88.7, clamav-milter version 0.88.7 on violet.abc.se X-Virus-Status: Clean X-Miltered: at discorde with ID 458106C8.000 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; mattias:01 waldau:01 mattias:01 waldau:01 refactor:01 ocaml:01 refactor:01 ocaml:01 syntax:01 'open:01 recompile:01 recompile:01 compiler:01 compiler:01 cvs:01 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 >