Browse files


Signed-off-by: Mike McClurg <>
  • Loading branch information...
Mike McClurg
Mike McClurg committed Oct 21, 2012
1 parent d6f9c55 commit 84caa09c8e2aeaf870129a53d875df2c2e0dc2c0
Showing with 87 additions and 0 deletions.
  1. +87 −0
@@ -173,3 +173,90 @@ Here are some thoughts about this work:
<:str_item< value f a = a >>. Just do <:str_item< value f = fun [
a -> a ] >>.
+* [2012-10-19 Fri] Version 0.1, and the way ahead
+So I haven't officially tagged this as version 0.1, but I think that
+this code is basically useable for generating mock modules from
+interfaces. It is by no means finished, though. While I do have a very
+simple test of the mock generator in this directory, it's really only
+a toy example and not a great test case. I need to write more
+complicated tests, and also try filtering on a non-trivial mli file
+from xapi.
+Some things I need to work on next:
+ - Inject the name of the module into the filter. As far as I can
+ tell, there is no way to recover the name of the mli file that is
+ being operated on. Some ideas I've had:
+ - Functorize the filter. We would pass in a module which would
+ have the name of the module in some variable. We'd have to
+ generate this module, and then compile the new filter, and then
+ apply the filter to the mli file. We could generate this module
+ as part of the 'mock of' syntax extention I'm planning to
+ write.
+ - Post-process the generated ml file. We could just use 'sed -i'
+ to replace a tag in the generated mli file with a real module
+ name. I don't really like this solution, but it's easy.
+ - Find a way to recover the name of the mli file. I don't know if
+ this is possible, and I haven't found a way to do it
+ yet. Perhaps the list or #ocaml will know.
+ - Wait, perhaps we can get the file name out of the _loc? Yes,
+ this is possible. Whew.
+ - Syntax extention 'mock of module Foo'. We would use this extention
+ in our unit tests. We would pass the resulting module in to the
+ SUT as the new DOC. This would take care of generating the mock
+ module file.
+* [2012-10-21 Sun] Testing on xapi_vm.mli
+Some thoughts about shortcomings in the current implementation. We
+need to handle all sig_item cases appropriately, instead of just
+including the original module. This is 1) to avoid side effects that
+might be present in the original module ('let _ = boom!' at the top
+level), and 2) to be sure that we create mocks for everything in the
+interface file, not just the toplevel function definitions. We need to
+ - nested modules (recursively filter)
+ - we might need multiple mock gen objects for this
+ - nested module types (easy, just copy)
+ - type and exception declarations (easy, just copy)
+ - external declarations (easy, just copy)
+ - module opens (easy, just copy)
+ - includes (could be tricky because we'd have to find that signature
+ and process it too, inline)
+ - class definitions (disallow for now -- no objects/classes)
+ - directives (ignore?)
+Problems with compiling mock_xapi_vm.mli:
+ - No polymorphic variables in function defs. I'm not sure if there
+ is a way around this, but I think we may need to require that
+ interfaces define monomorphic functions. I hit this bug because
+ xapi_vm.mli (which was probably mostly autogenerated), erroneously
+ defines the function set_memory_dynamic_min to have a __context of
+ type 'a (it should be type Context.t). When we try to create the
+ constructor T_set_memory_dynamic_min of (type of
+ set_memory_dynamic_min), we get an error on the type _context: 'a,
+ because 'a is an unbound type variable.
+ Is this something we could solve with GADTs? We could also take an
+ entirely different approach to storing mock functions and use refs
+ instead of Hashtables. This would mean that we would have a
+ different ref for every mocked function, and we wouldn't need the
+ types f_name and f_type anymore, since the compiler would be able
+ to infer the types of the references.
+ No, references don't help because they suffer from the same
+ restriction that Hashtbl does. I don't know if it's possilbe to
+ use a GADT for this either. Perhaps encapsulating this in an
+ object would be best. We might have to disallow abstract types in
+ mocked functions, in which case we would have to just skip those
+ in our definition, and include them from the original module.
+ Let's try testing now with any mocked polymorphic
+ functions commented out.

0 comments on commit 84caa09

Please sign in to comment.