[Caml-list] code duplication when abstracting using explicit signatures

[Caml-list] code duplication when abstracting using explicit signatures

[Jeffrey J. Cook]

I'm trying to avoid code duplication, but have a very simple case where it
seems inescapable utilitizing only the functionality of the ocaml tools.  In
example.mli, I declare several large types, in which I want the full contents
of the types to be visible to other modules.  How do I avoid duplicating those
full definitions in example.ml?  I've tried using "include Example" at the
beginning of example.ml, which ocamlopt has no argument with, but ocamlc gives:

Error while linking example.cmo: Reference to undefined global `Example'


I can't simply skip the .mli, as there are functions in example.ml that
I don't want exported; not to meantion the clean-ness of seperation .mli's
provide.  Any suggestions?

Thanks.

-- 
Jeffrey J. Cook
Graduate Student, Electrical Engineering
University of Illinois at Urbana-Champaign
jjcook@uiuc.edu

-------------------
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

Re: [Caml-list] code duplication when abstracting using explicit signatures

[Michal Moskal]

On Thu, Mar 20, 2003 at 05:32:34PM -0600, Jeffrey J. Cook wrote:
> I'm trying to avoid code duplication, but have a very simple case where it
> seems inescapable utilitizing only the functionality of the ocaml tools.  In
> example.mli, I declare several large types, in which I want the full contents
> of the types to be visible to other modules.  How do I avoid duplicating those
> full definitions in example.ml?  I've tried using "include Example" at the
> beginning of example.ml, which ocamlopt has no argument with, but ocamlc gives:
> 
> Error while linking example.cmo: Reference to undefined global `Example'
> 
> 
> I can't simply skip the .mli, as there are functions in example.ml that
> I don't want exported; not to meantion the clean-ness of seperation .mli's
> provide.  Any suggestions?

Use example_types.mli and example.ml/mli. AFAIR you can only put types
in example_types, not even exceptions.

-- 
: Michal Moskal ::::: malekith/at/pld-linux.org :  GCS {C,UL}++++$ a? !tv
: PLD Linux ::::::: Wroclaw University, CS Dept :  {E-,w}-- {b++,e}>+++ h

-------------------
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

Re: [Caml-list] code duplication when abstracting using explicit signatures

[brogoff]

On Sat, 22 Mar 2003, Michal Moskal wrote:
> Use example_types.mli and example.ml/mli. AFAIR you can only put types
> in example_types, not even exceptions.

And making that example_types.ml instead of .mli will allow exceptions (and 
values!), but I'd prefer having a pure .mli file as you suggest, and just 
creating a fourth file example_exns.ml for any example exceptions. 

Is this "extra interface file" trick in the FAQ yet? 

This is one of those things that bugged me a bit when I was first learning 
OCaml, but it's no longer an issue. 

-- 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

Re: [Caml-list] code duplication when abstracting using explicit signatures

[Christian Lindig]

[-- Attachment #1: Type: text/plain, Size: 1458 bytes --]

On Sat, Mar 22, 2003 at 04:52:13PM -0800, brogoff@speakeasy.net wrote:
> On Sat, 22 Mar 2003, Michal Moskal wrote:
> > Use example_types.mli and example.ml/mli. AFAIR you can only put types
> > in example_types, not even exceptions.
> 
> And making that example_types.ml instead of .mli will allow exceptions (and 
> values!), but I'd prefer having a pure .mli file as you suggest, and just 
> creating a fourth file example_exns.ml for any example exceptions. 

Just for completeness, here is another trick: when you are using a
literate programming tool like NoWEB you can let it do the code
duplication: the file foo.nw contains both interface and implementation
as named chunks, plus some documentation. A named chunk <<types>> that
contains code shared between interface and implementation can be
referenced from both. When foo.mli and foo.ml are extracted from foo.nw
for compilation, all references are resolved and the shared code shows
up in both.

    <<types>>=
    type foo = (* large, shared concrete type *)

    <<foo.mli>>=
    <<types>>
    (* other abstract types, function signatures *)

    <<foo.ml>>=
    <<types>>
    (* rest of implementation *)
    @

In comparison, this approach goes the opposite way: instead of having
more source files, have just one *.nw file that allows internal
references for code chunks.

-- Christian

-- 
Christian Lindig         http://www.eecs.harvard.edu/~lindig/

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]