Consider the following module:
:- module(foo, []).
a.
We get:
?- module_property(foo, exports(L)).
L = [].
?- module_property(foo, exported_operators(L)).
false.
The exported_operators/1 property failing instead or returning empty list makes handling it cumbersome. Any reason to not behave the same as the exports/1 property?
Except for that is how it happens to be implemented, I guess not. Now I guess module_property/2 is not widespread, but if other systems would adopt it they might not have a notion of exporting operators (e.g., SICStus). My guess is that if you aim at portability you should anticipate on properties not being present. Much like flags that typically only means something is present if the flag is present and tells you the feature you are looking for is supported.
If it simplifies things enough I’m happy to return [].
YAP returns both predicates and operators when using the exports/1 property. SICStus Prolog doesn’t provide a module_property/2 predicate (and, as in YAP, operators are not local to modules). ECLiPSe provides instead a get_module_info/3 predicate with a raw_interface property, which returns a list with both exported predicates and operators. Summarizing, the usual Babel tower.
I do think that SWI-Prolog exports/1 and exported_operators/1 should be consistent and return an empty list when there are no exports to report.
3 posts were split to a new topic: What is empty?
Pushed. If you think you can push several developers to do the same (or at least for the core features), I’m happy to support such an initiative. Changing this shouldn’t affect many people.