Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

[Caml-list] unused function detection

91 views
Skip to first unread message

skaller

unread,
Jun 22, 2004, 1:10:58 PM6/22/04
to caml...@inria.fr
Can Ocaml find unused functions, or does someone happen
to have a tool lying around that does so?

I just love writing functions in Ocaml so much
I often forget to actually use them .. ;)

--
John Skaller, mailto:ska...@users.sf.net
voice: 061-2-9660-0850,
snail: PO BOX 401 Glebe NSW 2037 Australia
Checkout the Felix programming language http://felix.sf.net

-------------------
To unsubscribe, mail caml-lis...@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

David MENTRE

unread,
Jun 22, 2004, 1:32:34 PM6/22/04
to ska...@users.sourceforge.net, caml...@inria.fr
Hello,

skaller <ska...@users.sourceforge.net> writes:

> Can Ocaml find unused functions, or does someone happen
> to have a tool lying around that does so?

Use ocaml profiling tools to find function called zero times?

Yours,
d.
--
David Mentré <dme...@linux-france.org>

-------------------
To unsubscribe, mail caml-lis...@inria.fr Archives: http://caml.inr=
ia.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr=

Nicolas Cannasse

unread,
Jun 22, 2004, 2:02:19 PM6/22/04
to ska...@users.sourceforge.net, David MENTRE, caml...@inria.fr
> skaller <ska...@users.sourceforge.net> writes:
>
> > Can Ocaml find unused functions, or does someone happen
> > to have a tool lying around that does so?
>
> Use ocaml profiling tools to find function called zero times?
>
> Yours,
> d.

That's not complete enough, since the behavior - then the code executed - of
the application might depend of different kind of inputs : network, user,
command line, ...
Since there is no guarantee that after removing the functions called zero
time, you program will even compile , what he needs is actually a statical
analysis tool using a code coverage algorithm, given one or more entry
points. This analysis can find without even executing the program the most
small subset of functions needed in order to compile the applications.
That's actually quite an interesting piece of code to write in a functional
language, and it would be nice if it can detects also unused *types*.

Regards,
Nicolas Cannasse

-------------------
To unsubscribe, mail caml-lis...@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/

skaller

unread,
Jun 22, 2004, 2:36:22 PM6/22/04
to Nicolas Cannasse, David MENTRE, caml-list
On Wed, 2004-06-23 at 03:59, Nicolas Cannasse wrote:

> what he needs is actually a statical
> analysis tool using a code coverage algorithm, given one or more entry
> points.

In my case the entry points (roots) can be determined automatically
for any *.ml file from the corresponding *.mli file.


--
John Skaller, mailto:ska...@users.sf.net
voice: 061-2-9660-0850,
snail: PO BOX 401 Glebe NSW 2037 Australia
Checkout the Felix programming language http://felix.sf.net

-------------------

Michael Furr

unread,
Jun 22, 2004, 2:36:30 PM6/22/04
to caml...@inria.fr

On Tue, 22 Jun 2004, Nicolas Cannasse wrote:
> Since there is no guarantee that after removing the functions called zero
> time, you program will even compile , what he needs is actually a statical
> analysis tool using a code coverage algorithm, given one or more entry
> points. This analysis can find without even executing the program the most
> small subset of functions needed in order to compile the applications.
> That's actually quite an interesting piece of code to write in a functional
> language, and it would be nice if it can detects also unused *types*.

I just finished(well almost) writing a tool which does something very
similar. The motivation was if I have some module M and a program P, what
is the most general(opaque) signature for M which still lets P compile.
This information can be extremely useful since you know exactly which
types are used opaquely and thus you can safely re-implement those data
structures. Also, if you have some internal function in a module and it
is not used anywhere in the program, it won't show up in the resulting
signature.

-mike

Eric Dahlman

unread,
Jun 22, 2004, 2:39:40 PM6/22/04
to caml-list, Nicolas Cannasse, <skaller@users.sourceforge.net>, David MENTRE

Some old lisp systems had this ability they would identify that bit of
your program needed to support a given set of functions and allow you
to purge the rest. There were some constraints on what the program
could do (no applying random symbols for example) and possibly some
heuristics as well. The name for this process was "tree shaking" if
anyone is interested in looking into what was involved. A quick google
search on my part surprised me with the size of both the christmas tree
and pecan industries on the net, but little of real interest.

-Eric

skaller

unread,
Jun 22, 2004, 3:20:24 PM6/22/04
to Eric Dahlman, caml-list, Nicolas Cannasse, David MENTRE
On Wed, 2004-06-23 at 04:38, Eric Dahlman wrote:
> The name for this process was "tree shaking" if

... camlshake .. is that a drink .. or a warning
to hide under the nearest park bench and quiver in fear?

> anyone is interested in looking into what was involved.

The problem is well understood -- it's just garbage collection
after all. The hard part is getting at the internals of the
Ocaml compiler, so as to avoid reinventing the wheel in
terms of parsing, lookup, etc but at the same time not
reporting generated garbage (compilers often generate
junk because it might be useful and optimise it away later).

----

Actually there is a modification of the original
problem which is slightly more interesting theoretically:
I personally often write:

let rec f x = ..
and g x = ...
and h x = ...

i.e. a huge chain of not necessarily mutually recursive
functions at the top level. It would be interesting
to see how one's scope control could be refined to make
the actual dependencies more evident. I also often
write:

let f x = .. in
let g x = .. in
..

when there is no dependency -- it just looks cleaner than

let
f x = .. and
g x = .. and
..
in

Obviously let[rec] [and] in can't express everything you want
in terms of scope control, so I doubt there is an 'ideal'
way to combine a set of functions .. which is what makes
the problem of re-writing them to better express the
dependencies interesting. [Of course there is a perfect
solution using modules]

--
John Skaller, mailto:ska...@users.sf.net
voice: 061-2-9660-0850,
snail: PO BOX 401 Glebe NSW 2037 Australia
Checkout the Felix programming language http://felix.sf.net

-------------------

skaller

unread,
Jun 22, 2004, 3:29:13 PM6/22/04
to Michael Furr, caml-list
On Wed, 2004-06-23 at 04:33, Michael Furr wrote:

> I just finished(well almost) writing a tool which does something very
> similar. The motivation was if I have some module M and a program P, what
> is the most general(opaque) signature for M which still lets P compile.
> This information can be extremely useful since you know exactly which
> types are used opaquely and thus you can safely re-implement those data
> structures. Also, if you have some internal function in a module and it
> is not used anywhere in the program, it won't show up in the resulting
> signature.

ocaml -i + ocamldep. Shaken (not stirred)

Hmmm. At present, you are looking for uses of functions

M.f1 M.f2 M.f3 ...

in modules

P1 P2 P3 P4 ..

To solve my problem, you only need to add M to that list,
looking for uses of M.f1 etc in M itself. [Of course I want
the complement of the answer .. ]

--
John Skaller, mailto:ska...@users.sf.net
voice: 061-2-9660-0850,
snail: PO BOX 401 Glebe NSW 2037 Australia
Checkout the Felix programming language http://felix.sf.net

-------------------

Michael Furr

unread,
Jun 22, 2004, 3:50:06 PM6/22/04
to caml-list

On 23 Jun 2004, skaller wrote:

> On Wed, 2004-06-23 at 04:33, Michael Furr wrote:
>
> > I just finished(well almost) writing a tool which does something very
> > similar. The motivation was if I have some module M and a program P, what
> > is the most general(opaque) signature for M which still lets P compile.
> > This information can be extremely useful since you know exactly which
> > types are used opaquely and thus you can safely re-implement those data
> > structures. Also, if you have some internal function in a module and it
> > is not used anywhere in the program, it won't show up in the resulting
> > signature.
>
> ocaml -i + ocamldep. Shaken (not stirred)

Well, for handling types, its slightly more than that. For instance, if
I'm using some module with a definition:
type t = int * int
val f0 : int -> int -> t
val f1 : int -> t
val f2 : t -> t

and I have the program:
let x = f0 1 2 in
let y = f1 (fst x) in
let z = f2 x y in z

Then the inferred signature would be
type inferred1;
type inferred2;
type inferred3;
type t = inferred1 * inferred2
val f0 : int -> int -> t
val f1 : inferred1 -> t
val f2 : t -> inferred3

Thus you would know that 't' is only treated as a pair and never as a pair
of ints. Thus you could easily, say, swap out int for int32 without
affecting the rest of the program.

> Hmmm. At present, you are looking for uses of functions

[...]

> To solve my problem, you only need to add M to that list,
> looking for uses of M.f1 etc in M itself. [Of course I want
> the complement of the answer .. ]

Which shouldn't be too hard. The tool is just a (non-invasive) patch to
the compiler which I'll probably clean up and release in a few weeks once
I get a little more time. If you're interested in playing around with it,
let me know and I'll try to get to it sooner rather than later.

-mike

Radu Grigore

unread,
Feb 8, 2011, 5:52:08 AM2/8/11
to caml...@inria.fr
Is there a tool that finds unused functions?

It seems there was none in 2004:
https://groups.google.com/d/topic/fa.caml/D8aWkamzr-U/discussion

Message has been deleted
Message has been deleted
0 new messages