* [Caml-list] Automatic generation of mli files
@ 2003-06-06 9:57 Stefan Heimann
2003-06-06 11:53 ` Maxence Guesdon
2003-06-06 15:33 ` Brian Hurt
0 siblings, 2 replies; 15+ messages in thread
From: Stefan Heimann @ 2003-06-06 9:57 UTC (permalink / raw)
To: caml-list
Hi,
I searching for a way for generating the .mli file for a given source .ml
file automatically. My basic idea is like that:
(1) Specify in the .ml file which values and types should be exported
and if a type should be exported abstract or not. This could be
done with a special comment at the top of the file.
(2) Filter the output of `ocamlc -i' to exclude the values and types
that should not be exported and to make the types abstract if
needed.
Of course, the tool should check of there is an existing .mli
file. If the .mli file was not generated by the tool it is not
overwritten. If the list of exported values and types has not changed
the .mli file is not updated too.
I experimented a little bit with parsing the output of `ocamlc -i'
and printing the modified parse tree. I took must code from the ocaml
distribution. However, I don't think that this is a good way.
Any ideas of how to implement such a tool? Are there any existing
tools with this functionality?
Bye,
Stefan
--
Stefan Heimann
http://www.stefanheimann.net :: personal website.
http://cvsshell.sf.net :: CvsShell, a console based cvs client.
-------------------
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] 15+ messages in thread
* Re: [Caml-list] Automatic generation of mli files
2003-06-06 9:57 [Caml-list] Automatic generation of mli files Stefan Heimann
@ 2003-06-06 11:53 ` Maxence Guesdon
2003-06-06 15:33 ` Brian Hurt
1 sibling, 0 replies; 15+ messages in thread
From: Maxence Guesdon @ 2003-06-06 11:53 UTC (permalink / raw)
To: caml-list
On Fri, 6 Jun 2003 11:57:23 +0200
Stefan Heimann <lists@stefanheimann.net> wrote:
> Hi,
>
> I searching for a way for generating the .mli file for a given source .ml
> file automatically. My basic idea is like that:
>
> (1) Specify in the .ml file which values and types should be exported
> and if a type should be exported abstract or not. This could be
> done with a special comment at the top of the file.
>
> (2) Filter the output of `ocamlc -i' to exclude the values and types
> that should not be exported and to make the types abstract if
> needed.
>
> Of course, the tool should check of there is an existing .mli
> file. If the .mli file was not generated by the tool it is not
> overwritten. If the list of exported values and types has not changed
> the .mli file is not updated too.
>
> I experimented a little bit with parsing the output of `ocamlc -i'
> and printing the modified parse tree. I took must code from the ocaml
> distribution. However, I don't think that this is a good way.
>
> Any ideas of how to implement such a tool? Are there any existing
> tools with this functionality?
You could develop a custom generator for ocamldoc, outputting an mli
file instead of html, latex, ... files. For example, only commented
elements would be printed to the generated .mli file, and custom tags
could be used to give additional information (abstract types, ...).
See the ocamldoc manual for more information about developing custom
generators, and feel free to ask me if you encounter difficulties.
--
Maxence Guesdon
-------------------
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] 15+ messages in thread
* Re: [Caml-list] Automatic generation of mli files
2003-06-06 9:57 [Caml-list] Automatic generation of mli files Stefan Heimann
2003-06-06 11:53 ` Maxence Guesdon
@ 2003-06-06 15:33 ` Brian Hurt
2003-06-06 15:59 ` Stefan Heimann
2003-06-06 18:30 ` Chris Hecker
1 sibling, 2 replies; 15+ messages in thread
From: Brian Hurt @ 2003-06-06 15:33 UTC (permalink / raw)
To: Stefan Heimann; +Cc: caml-list
On Fri, 6 Jun 2003, Stefan Heimann wrote:
> Hi,
>
> I searching for a way for generating the .mli file for a given source .ml
> file automatically. My basic idea is like that:
>
> (1) Specify in the .ml file which values and types should be exported
> and if a type should be exported abstract or not. This could be
> done with a special comment at the top of the file.
>
> (2) Filter the output of `ocamlc -i' to exclude the values and types
> that should not be exported and to make the types abstract if
> needed.
Not sure what advantage this would gain. Step #1 is about as difficult as
simply writting the .mli file directly. Actually, a fairly fast way to
produce an mli file is to do ocamlc -i foo.ml > foo.mli and fire up your
local text editor and delete everything out of foo.mli you don't want
exported.
I don't have a problem with .mli files being seperate from .ml files for
two reasons:
1) .mli is your external interface- changing that interface generally
means changing other files as well. In this case, you're generally
already chaging other files.
2) The compiler checks the signature of the .mli file against what is
produced by the .ml file, so if you do "accidentally" change an exported
function's interface, and forget to change the .mli to match, the compiler
will catch it.
Brian
-------------------
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] 15+ messages in thread
* Re: Re: [Caml-list] Automatic generation of mli files
2003-06-06 15:33 ` Brian Hurt
@ 2003-06-06 15:59 ` Stefan Heimann
2003-06-06 16:17 ` Ville-Pertti Keinonen
2003-06-06 18:30 ` Chris Hecker
1 sibling, 1 reply; 15+ messages in thread
From: Stefan Heimann @ 2003-06-06 15:59 UTC (permalink / raw)
To: caml-list
On Fri, Jun 06, 2003 at 10:33:25AM -0500, Brian Hurt wrote:
> On Fri, 6 Jun 2003, Stefan Heimann wrote:
>
> > Hi,
> >
> > I searching for a way for generating the .mli file for a given source .ml
> > file automatically. My basic idea is like that:
> >
> > (1) Specify in the .ml file which values and types should be exported
> > and if a type should be exported abstract or not. This could be
> > done with a special comment at the top of the file.
> >
> > (2) Filter the output of `ocamlc -i' to exclude the values and types
> > that should not be exported and to make the types abstract if
> > needed.
>
> Not sure what advantage this would gain. Step #1 is about as difficult as
> simply writting the .mli file directly. Actually, a fairly fast way to
> produce an mli file is to do ocamlc -i foo.ml > foo.mli and fire up your
> local text editor and delete everything out of foo.mli you don't want
> exported.
I don't think that step #1 is as difficult as writing the .mli file by
hand. If you have a complex type definition it's much easier to write
`export my_type' than keeping the 2 definitions in the .ml and .mli file
in sync.
> I don't have a problem with .mli files being seperate from .ml files for
> two reasons:
It is not my problem that there is this separation between interface
and implementation file. I think this is very good and helpful,
especially when you want to see what functionality a module
provides. I just want to make it easier to write the implementation
file. Programmers are lazy and so writing an interface file should be
as easy as possible.
> 1) .mli is your external interface- changing that interface generally
> means changing other files as well. In this case, you're generally
> already chaging other files.
>
> 2) The compiler checks the signature of the .mli file against what is
> produced by the .ml file, so if you do "accidentally" change an exported
> function's interface, and forget to change the .mli to match, the compiler
> will catch it.
Maybe I should tell how I want to use the tool. I don't want to update
the .mli file automatically everytime I change something in the .ml
file. I want to use the compiler as I would do without the tool. The
tool comes only into play when the compiler complains about a
non-matching implementation for the interface. Then I have to decide
if this is because I "accidentally" changed something in the
implementation. If yes, I change to implementation. If no, I use to
tool to update to .mli file instead of applying the changes by hand.
Bye,
Stefan
--
Stefan Heimann
http://www.stefanheimann.net :: personal website.
http://cvsshell.sf.net :: CvsShell, a console based cvs client.
-------------------
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] 15+ messages in thread
* Re: [Caml-list] Automatic generation of mli files
2003-06-06 15:33 ` Brian Hurt
2003-06-06 15:59 ` Stefan Heimann
@ 2003-06-06 18:30 ` Chris Hecker
2003-06-06 19:16 ` Brian Hurt
1 sibling, 1 reply; 15+ messages in thread
From: Chris Hecker @ 2003-06-06 18:30 UTC (permalink / raw)
To: Brian Hurt, Stefan Heimann; +Cc: caml-list
>Not sure what advantage this would gain. Step #1 is about as difficult as
>simply writting the .mli file directly.
Yeah, but not if things are changing a lot and you have big types and
whatnot. Cutting and pasting or doing the ocaml -i thing is a bit of a
pain. I could see it being a useful tool. Basically anything that
eliminates repetition is a positive.
>I don't have a problem with .mli files being seperate from .ml files for
>two reasons:
>1) .mli is your external interface-
>2) The compiler checks the signature of the .mli file
Don't forget "3) having a separate interface allows you to decouple
implementations which is important for large scale software". Oh wait.
:/
Chris
-------------------
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] 15+ messages in thread
* Re: [Caml-list] Automatic generation of mli files
2003-06-06 18:30 ` Chris Hecker
@ 2003-06-06 19:16 ` Brian Hurt
2003-06-06 19:21 ` Chris Hecker
` (2 more replies)
0 siblings, 3 replies; 15+ messages in thread
From: Brian Hurt @ 2003-06-06 19:16 UTC (permalink / raw)
To: Chris Hecker; +Cc: Brian Hurt, Stefan Heimann, Ocaml Mailing List
On Fri, 6 Jun 2003, Chris Hecker wrote:
>
> >Not sure what advantage this would gain. Step #1 is about as difficult as
> >simply writting the .mli file directly.
>
> Yeah, but not if things are changing a lot and you have big types and
> whatnot. Cutting and pasting or doing the ocaml -i thing is a bit of a
> pain. I could see it being a useful tool. Basically anything that
> eliminates repetition is a positive.
My basic opinion here: feel free to create such a tool. Have fun. *I*
won't use it, but it's no skin off my nose either way.
If I'm heavily modifying a file *and* it's interface, I generally don't
even bother with a .mli file. That gets generated when the interface
settles down. If you're making big changes in the interface *and* have
other files that depend upon the interface you're trying to keep up to
date, then you're going to be having fun anyways. Be thankfull the
compiler detects all of those places you forgot to update.
Here's one problem I've hit several times. In the .ml file, I do
something like:
type t = foo * bar * bang
Then several functions that use type t. The type inference will come up
with types like:
val add: foo * bar * bang -> foo -> bar -> bang -> foo * bar * bang
when what I wanted was:
vall add: t -> foo -> bar -> bang -> t
How do you deal with this?
>
> >I don't have a problem with .mli files being seperate from .ml files for
> >two reasons:
> >1) .mli is your external interface-
> >2) The compiler checks the signature of the .mli file
>
> Don't forget "3) having a separate interface allows you to decouple
> implementations which is important for large scale software". Oh wait.
>
Function calls are about 1-1.5 clock cycles the last time I measured them.
I wouldn't have a problem if ocaml disabled all cross-module inlining.
Inlining within a module is, IMHO, critical- but between modules I would
bet is sigifigantly less important. People who have hard numbers feel
free to jump in.
Brian
-------------------
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] 15+ messages in thread
* Re: [Caml-list] Automatic generation of mli files
2003-06-06 19:16 ` Brian Hurt
@ 2003-06-06 19:21 ` Chris Hecker
2003-06-06 21:06 ` Manos Renieris
2003-06-06 20:24 ` Stefan Heimann
2003-06-07 0:27 ` John Max Skaller
2 siblings, 1 reply; 15+ messages in thread
From: Chris Hecker @ 2003-06-06 19:21 UTC (permalink / raw)
To: Brian Hurt; +Cc: Brian Hurt, Stefan Heimann, Ocaml Mailing List
>If I'm heavily modifying a file *and* it's interface, I generally don't
>even bother with a .mli file.
Yes, this is what I do as well. It's very nice that you don't need an mli
at all in ocaml, that makes for a nice dynamic process during
development. (See, I said something positive! :)
And, for having mlis around for decoupling for build dependencies (as
opposed to having them for interface design, where you care about what's
exported), ocaml -i > foo.mli works just fine.
But, if the tool was lightweight and easy enough, it could be useful.
Chris
-------------------
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] 15+ messages in thread
* Re: [Caml-list] Automatic generation of mli files
2003-06-06 19:21 ` Chris Hecker
@ 2003-06-06 21:06 ` Manos Renieris
2003-06-06 22:06 ` Chris Hecker
0 siblings, 1 reply; 15+ messages in thread
From: Manos Renieris @ 2003-06-06 21:06 UTC (permalink / raw)
To: Chris Hecker; +Cc: Brian Hurt, Stefan Heimann, Ocaml Mailing List
On Fri, Jun 06, 2003 at 12:21:17PM -0700, Chris Hecker wrote:
>
> And, for having mlis around for decoupling for build dependencies (as
> opposed to having them for interface design, where you care about what's
> exported), ocaml -i > foo.mli works just fine.
At least under unix, it does not.
The shell creates foo.mli before the compilation starts; ocamlc sees
that and believes a .cmi should exist; but it doesn't; so compilation
aborts.
Xavier Leroy has promised
(http://caml.inria.fr/archives/200302/msg00078.html)
a separate command line option to generate .mli's without compiling,
but I don't see it yet.
-- Manos
-------------------
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] 15+ messages in thread
* Re: [Caml-list] Automatic generation of mli files
2003-06-06 21:06 ` Manos Renieris
@ 2003-06-06 22:06 ` Chris Hecker
0 siblings, 0 replies; 15+ messages in thread
From: Chris Hecker @ 2003-06-06 22:06 UTC (permalink / raw)
To: Manos Renieris
Cc: Chris Hecker, Brian Hurt, Stefan Heimann, Ocaml Mailing List
> > exported), ocaml -i > foo.mli works just fine.
> At least under unix, it does not.
> The shell creates foo.mli before the compilation starts; ocamlc sees
> that and believes a .cmi should exist; but it doesn't; so compilation
> aborts.
Yeah, I didn't mean it worked in a single build instance (Xavier's
replying to my feature request in your link, and yes, hopefully
that'll make it into the next release :), I just meant it works for
generating an mli file if you just want the text file. In
other words, if I want an mli from an ml, ocamlc -i will generate one
that I can then use for later. The output fix will make it workable
in a makefile, which will be even better!
Now if it only mattered for decoupling compiles! :)
Chris
-------------------
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] 15+ messages in thread
* Re: Re: [Caml-list] Automatic generation of mli files
2003-06-06 19:16 ` Brian Hurt
2003-06-06 19:21 ` Chris Hecker
@ 2003-06-06 20:24 ` Stefan Heimann
2003-06-06 20:38 ` Jeffrey J. Cook
2003-06-07 0:27 ` John Max Skaller
2 siblings, 1 reply; 15+ messages in thread
From: Stefan Heimann @ 2003-06-06 20:24 UTC (permalink / raw)
To: Ocaml Mailing List
On Fri, Jun 06, 2003 at 02:16:59PM -0500, Brian Hurt wrote:
> On Fri, 6 Jun 2003, Chris Hecker wrote:
> [...]
>
> Here's one problem I've hit several times. In the .ml file, I do
> something like:
>
> type t = foo * bar * bang
>
> Then several functions that use type t. The type inference will come up
> with types like:
> val add: foo * bar * bang -> foo -> bar -> bang -> foo * bar * bang
> when what I wanted was:
> vall add: t -> foo -> bar -> bang -> t
>
> How do you deal with this?
You could make an annotation in the comment of the method:
(**
val add: t -> foo -> bar -> bang -> t
*)
let add a x y z = a
Bye,
Stefan
--
Stefan Heimann
http://www.stefanheimann.net :: personal website.
http://cvsshell.sf.net :: CvsShell, a console based cvs client.
-------------------
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] 15+ messages in thread
* Re: [Caml-list] Automatic generation of mli files
2003-06-06 19:16 ` Brian Hurt
2003-06-06 19:21 ` Chris Hecker
2003-06-06 20:24 ` Stefan Heimann
@ 2003-06-07 0:27 ` John Max Skaller
2 siblings, 0 replies; 15+ messages in thread
From: John Max Skaller @ 2003-06-07 0:27 UTC (permalink / raw)
To: Brian Hurt; +Cc: Chris Hecker, Stefan Heimann, Ocaml Mailing List
Brian Hurt wrote:
> On Fri, 6 Jun 2003, Chris Hecker wrote:
> type t = foo * bar * bang
>
> Then several functions that use type t. The type inference will come up
> with types like:
> val add: foo * bar * bang -> foo -> bar -> bang -> foo * bar * bang
> when what I wanted was:
> vall add: t -> foo -> bar -> bang -> t
>
> How do you deal with this?
The problem I have is that I instantiate a functor.
The ocamlc -i generated interface lists all the functions,
which sux big time, since one has to continually
reformat them to look pretty, and it's all clutter anyhow.
I'd rather see the interface instantiated.
Hmm .. can this be done?
--
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
^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2003-06-09 8:10 UTC | newest]
Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-06-06 9:57 [Caml-list] Automatic generation of mli files Stefan Heimann
2003-06-06 11:53 ` Maxence Guesdon
2003-06-06 15:33 ` Brian Hurt
2003-06-06 15:59 ` Stefan Heimann
2003-06-06 16:17 ` Ville-Pertti Keinonen
2003-06-06 18:30 ` Chris Hecker
2003-06-06 19:16 ` Brian Hurt
2003-06-06 19:21 ` Chris Hecker
2003-06-06 21:06 ` Manos Renieris
2003-06-06 22:06 ` Chris Hecker
2003-06-06 20:24 ` Stefan Heimann
2003-06-06 20:38 ` Jeffrey J. Cook
[not found] ` <200306091226.13255.yangsx@fltrp.com>
2003-06-09 4:59 ` Yang Shouxun
2003-06-09 8:10 ` Stefan Heimann
2003-06-07 0:27 ` John Max Skaller
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox