From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id GAA03875; Tue, 3 Jun 2003 06:27:50 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id GAA03798 for ; Tue, 3 Jun 2003 06:27:49 +0200 (MET DST) Received: from mail1.tpgi.com.au (mail.tpgi.com.au [203.12.160.57]) by concorde.inria.fr (8.11.1/8.11.1) with ESMTP id h534RkH19316; Tue, 3 Jun 2003 06:27:46 +0200 (MET DST) Received: from ozemail.com.au (203-219-225-76-syd-ts24-2600.tpgi.com.au [203.219.225.76]) (authenticated (0 bits)) by mail1.tpgi.com.au (8.11.6/8.11.6) with ESMTP id h534RhP29486; Tue, 3 Jun 2003 14:27:43 +1000 Message-ID: <3EDC23BF.2090902@ozemail.com.au> Date: Tue, 03 Jun 2003 14:27:43 +1000 From: John Max Skaller User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2.1) Gecko/20010901 X-Accept-Language: en-us MIME-Version: 1.0 To: Xavier Leroy CC: caml-list@inria.fr Subject: Re: [Caml-list] generating a call-graph References: <52762.141.155.88.179.1053707680.squirrel@minsky-primus.homeip.net> <20030526111416.A31160@pauillac.inria.fr> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam: no; 0.00; ozemail:01 caml-list:01 invocation:01 non-trivial:01 recursion:01 currying:01 toxteth:01 glebe:01 2037,:01 9660:01 0850:01 ocaml:01 nsw:01 polymorphic:01 patch:02 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk Xavier Leroy wrote: >>Does anyone know a way of generating a call-graph from a set of ocaml >>sources? What I want to do is, at a minimum, get a list of all the >>functions that could be called as a result of a given function invocation. >> > > This requires a non-trivial static analysis called "control flow > analysis" in the literature; particular instances include Shivers' > 0-CFA and k-CFA, Jagannathan and Wright's "polymorphic splitting", > etc. > > The difficulty is that functions are first-class values .. and the difficulty can be bypassed by considering the actual industrial requirement, which probably isn't as stated above. We often want to know what the definition of a function depends on, and that clearly *excludes* any functions passed in as parameters. Second, an incomplete graph would still be very useful. For example to determine if you can move a function definition earlier in the code, so as to call it from some other function -- or whether you would have to move a lot more functions back -- and if so which ones -- and, indeed, if it is possible at all (without recursion). I guess a patch to the parser could gather the required information easily ( the main difficulty being the huge number of anonymous functions that tend to float around when one does currying). -- John Max Skaller, mailto:skaller@ozemail.com.au snail:10/1 Toxteth Rd, Glebe, NSW 2037, Australia. voice:61-2-9660-0850 ------------------- To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/ Beginner's list: http://groups.yahoo.com/group/ocaml_beginners