English version
Accueil     À propos     Téléchargement     Ressources     Contactez-nous    

Ce site est rarement mis à jour. Pour les informations les plus récentes, rendez-vous sur le nouveau site OCaml à l'adresse ocaml.org.

Browse thread
Additional exports from ocamlyacc-generated module?
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2008-04-22 (13:56)
From: Richard Cobbe <cobbe@c...>
Subject: Additional exports from ocamlyacc-generated module?
Is it possible to mark definitions in an .mly file as "public," so that
they're listed in the generated .mli file?

My parser.mly file has some nontrivial function definitions in its header.
While these functions are used only by the parser, I'd like to write some
unit tests for them.  I've defined the test suite in parser.mly's trailer
(after the final %%), but the generated parser.mli file includes only the
token definition and the functions corresponding to my grammar's start
symbols.  Since nobody else can see the test suite, I can't actually run
these tests from outside the module.

The ocamlyacc manual doesn't describe any way to accomplish this, either
with annotations in parser.mly or with command-line args to ocamlyacc.
I've thought of various possible work-arounds, none of which are all that

  - parser.mly's trailer defines the test cases and then runs them itself.
    Not good; this will run the tests every time I load the module.

  - Have the Makefile append
        val tests : OUnit.test
    to the end of parser.mli after calling ocamlyacc.

  - Move the functions out of parser.mly's header into a separate module,
    and put the tests cases for those functions there.  This is probably
    the cleanest solution, but I don't like making these functions visible
    to the rest of the program.

Is there a better way to do this?

If it matters, I'm using OCaml 3.10.2, packaged by Fink; Mac OS 10.5.2
Intel.  I'm using the OUnit test framework, but in the unlikely event that
a different testing framework doesn't suffer from these problems, I'm open
to alternatives.