From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id UAA16433; Wed, 29 Oct 2003 20:26:49 +0100 (MET) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id UAA13255 for ; Wed, 29 Oct 2003 20:26:47 +0100 (MET) Received: from mail3.tpgi.com.au (mail.tpgi.com.au [203.12.160.59]) by concorde.inria.fr (8.11.1/8.11.1) with ESMTP id h9TJQj102367 for ; Wed, 29 Oct 2003 20:26:45 +0100 (MET) Received: from 203-213-127-53-syd-ts20-2600.tpgi.com.au (203-213-127-53-syd-ts20-2600.tpgi.com.au [203.213.127.53]) by mail3.tpgi.com.au (8.11.6/8.11.6) with ESMTP id h9TJQgP29395 for ; Thu, 30 Oct 2003 06:26:42 +1100 Subject: Re: [Caml-list] non-exported functions From: skaller Reply-To: skaller@ozemail.com.au To: caml-list@inria.fr In-Reply-To: <728D3F38-09A4-11D8-B9F5-000393CFE6B8@spy.net> References: <728D3F38-09A4-11D8-B9F5-000393CFE6B8@spy.net> Content-Type: text/plain Message-Id: <1067451946.2160.7.camel@pelican> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-4) Date: 30 Oct 2003 05:25:47 +1100 Content-Transfer-Encoding: 7bit X-Loop: caml-list@inria.fr X-Spam: no; 0.00; caml-list:01 ozemail:01 helper:01 ocamldoc:01 mli:01 mli:01 0000:98 interfaces:01 module:03 module:03 complex:03 explicit:03 wrote:03 wrote:03 annoying:03 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk On Wed, 2003-10-29 at 11:11, Dustin Sallings wrote: > On Tue, 28 Oct 2003 21:07:57 +0000 > Richard Jones wrote: > > > On Tue, Oct 28, 2003 at 12:02:40PM -0800, Dustin Sallings wrote: > >> > >> I've got a module that contains a few helper functions that should > >> only be used internally. Is there a way to prevent them from being > >> exported and/or included in ocamldoc output? > > > > Define an .mli file for your module. Anything not listed explicitly in > > the .mli file won't be exported. > > I kinda liked automatically generating my .mli, but I guess I can live > with that. Aw, its kind of annoying. Two or three extra keywords might fix 95% of cases: let private x = ... Just don't put x in the interface type abstract x = .. put x in the interface as type x Now you may need an mli in the unusual case a function of type A -> B is constrained to type C -> D in the module and to type E -> F in the interface. Explicit interfaces are of course still needed for more complex constraints. ------------------- 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