New Issue: Should CPtr be an internal module or a standard one?

16389, “bradcray”, “Should CPtr be an internal module or a standard one?”, “2020-09-15T16:17:28Z”

Currently CPtr.chpl is an internal module. In this issue, I’m proposing that it should be a standard one, using the following argument:

  • I think that “internal” modules should be ones that are used to implement things that are “built into” the language and would be described in a complete version of the language spec. So things like strings, syncs, ranges would all be defined in internal modules.

  • Meanwhile, I think of “standard” modules as being those that aren’t built into the language, yet are so fundamental or useful that any implementation of Chapel should be able to rely on them being available (and, ultimately, stable). I think of standard modules as being ones where you’d surf to the standard module documentation on the docs website and review the symbols that that module makes available.

To me, types like c_ptr() and c_void_ptr are not things that we consider to be an intrinsic features of the Chapel language, but features that are made available in a standard manner to support interoperability and lower-level programming, so it seems obvious that the module should be standard (if others think that c_ptr should be part of the language, let me know and I’ll spawn off a separate issue about that; the rest of this issue will assume it’s not part of the language).

[Also independent of, but related to, this issue, I think CPtr should ultimately be merged into a general CTypes module that also supports things like c_int (currently defined in SysCTypes) and c_double (currently defined in SysBasics). This is related to issue #16131 ].

A counterargument to this proposal might be:

  • internal modules shouldn’t rely on standard modules, but some of our built-in types (like string and bytes) use c_ptr, so CPtr should remain an internal module

I agree that, whenever possible, internal modules shouldn’t rely on standard modules, but I don’t think it’s always possible / desirable, and I’m not convinced that it warrants putting CPtr into the internal modules. Specifically, if c_ptr() is not in the language, I think it would be unfortunate to have the user apply some sort of mental heuristic like “do I think that the Chapel implementers used this module to implement the language?” to determine whether to browse the internal module documentation or the standard module docs to read the c_ptr type’s documentation. Meanwhile, I also think it would be counterproductive to support a second non-user-facing c_ptr type in order to implement strings without CPtr.

We could say “some internal modules will have their documentation placed into the standard module hierarchy in the docs even though they are internal modules”, but to me, this essentially says that they’re standard modules from the user’s perspective, so why not just make them standard modules?