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
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=
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/
> 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
-------------------
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
... 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
-------------------
> 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
-------------------
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
It seems there was none in 2004:
https://groups.google.com/d/topic/fa.caml/D8aWkamzr-U/discussion