* Re: [Caml-list] unused function detection
2004-06-22 17:59 ` Nicolas Cannasse
@ 2004-06-22 18:32 ` skaller
2004-06-22 18:33 ` Michael Furr
2004-06-22 18:38 ` Eric Dahlman
2 siblings, 0 replies; 12+ messages in thread
From: skaller @ 2004-06-22 18:32 UTC (permalink / raw)
To: Nicolas Cannasse; +Cc: 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:skaller@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-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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Caml-list] unused function detection
2004-06-22 17:59 ` Nicolas Cannasse
2004-06-22 18:32 ` skaller
@ 2004-06-22 18:33 ` Michael Furr
2004-06-22 19:27 ` skaller
2004-06-22 18:38 ` Eric Dahlman
2 siblings, 1 reply; 12+ messages in thread
From: Michael Furr @ 2004-06-22 18:33 UTC (permalink / raw)
To: caml-list
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
-------------------
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Caml-list] unused function detection
2004-06-22 18:33 ` Michael Furr
@ 2004-06-22 19:27 ` skaller
2004-06-22 19:46 ` Michael Furr
0 siblings, 1 reply; 12+ messages in thread
From: skaller @ 2004-06-22 19:27 UTC (permalink / raw)
To: Michael Furr; +Cc: 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:skaller@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-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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Caml-list] unused function detection
2004-06-22 19:27 ` skaller
@ 2004-06-22 19:46 ` Michael Furr
0 siblings, 0 replies; 12+ messages in thread
From: Michael Furr @ 2004-06-22 19:46 UTC (permalink / raw)
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
-------------------
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Caml-list] unused function detection
2004-06-22 17:59 ` Nicolas Cannasse
2004-06-22 18:32 ` skaller
2004-06-22 18:33 ` Michael Furr
@ 2004-06-22 18:38 ` Eric Dahlman
2004-06-22 19:18 ` skaller
2 siblings, 1 reply; 12+ messages in thread
From: Eric Dahlman @ 2004-06-22 18:38 UTC (permalink / raw)
To: caml-list
Cc: 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
On Jun 22, 2004, at 12:59 PM, Nicolas Cannasse wrote:
>> skaller <skaller@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-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
>
-------------------
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Caml-list] unused function detection
2004-06-22 18:38 ` Eric Dahlman
@ 2004-06-22 19:18 ` skaller
0 siblings, 0 replies; 12+ messages in thread
From: skaller @ 2004-06-22 19:18 UTC (permalink / raw)
To: Eric Dahlman; +Cc: 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:skaller@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-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
^ permalink raw reply [flat|nested] 12+ messages in thread