Could u add support for the module() type?

[fredrikelinder]

[kostis]

We have actually discussed this one in the past. Adding support for the module() type falls in the same category with adding support for the types pid(), node(), etc. Our view is that in all likelyhood one does not want any random value for these types (e.g. any random atom() for module()) but something that makes sense for the use case and is most probably application-specific. Also, even if we e.g. made module() return some module name for a module that it actually present/loaded in the system, it is not so clear what shrinking means for it. Try some other module whose name is shorter? Shrink to the name of a module that is smaller (e.g. has fewer exported functions)?

It may help us if you had some thoughts on the subject or you can describe your particular use case to see whether we can learn something from it.

[fredrikelinder]

1. I really like the spec check feature and without support for module(), pid() etc I cannot use it with specs that expects pid(), module(), reference(), etc.
2. When testing a behaviour I like to be able to have non-static naming of the modules, even if there's no way to shrink them.
3. I'd expect pid(), module() etc to generate any valid values, started/loaded or not. Note, the pid() and module() may not have to exist. a proper_types:pid() -> c:pid(0,random_int(),random_int()). would be ok I guess, with no_shrink option set