refactor(ListModule): trim dependencies, add defaults, improve docstrings

[wpbonelli]

• remove SimModule dependency and sim_message()/stop_with_error() usages
  • minimize dependencies of generic utilities on simulation modules so latter can use former without circularity
  • on programmer error, just print error message and error stop 1
• use associated(x, y) as default isEqual procedure for ContainsObject
• more descriptive docstrings, use compact format

[langevin-usgs]

I'm not sure I understand the dependency on stop_with_error(). It is in GenericUtilitiesModule, which does depend on SimVariablesModule, but the dependencies are minimal.

[langevin-usgs]

We might need to check further on the ramifications of this change. I'm thinking stop_with_error() and its use of call exit() was used intentionally, perhaps for API behavior.

[wpbonelli]

I think error stop 1 is equivalent to call exit(1) (with possibly wider compiler support), both terminating with the given exit code. On the other hand stop 1 prints the ret code to stderr but exits with code 0, which I imagine is what we want to avoid?

At least that is my reading of the following

• https://stackoverflow.com/questions/34475725/what-is-the-difference-between-stop-and-exit-in-fortran
• https://fortran-lang.discourse.group/t/stop-with-non-zero-exit-status/2062/
• https://www.scivision.dev/fortran-stderr-stop-return-code/

[wpbonelli]

Since gnu, intel, and flang all support an exit() intrinsic subroutine maybe it makes sense to standardize on that directly, and stop_with_error() would be unnecessary

One drawback of error stop is it only supports a variable status code in f2018, while exit() already does

[langevin-usgs]

Would it make sense to keep stop_with_error() in place and use it for all programming errors? It could remain the same or we could pass it a message. If we ever needed to change the behavior, we would only need to change it one place? Or we could get rid of it and just call exit().

[wpbonelli]

Would it make sense to keep stop_with_error() in place and use it for all programming errors? It could remain the same or we could pass it a message. If we ever needed to change the behavior, we would only need to change it one place?

That seems good to me. Maybe it could live in a separate module so generic utilities don't depend on simulation-related things?

[langevin-usgs]

Sounds good to me!

[langevin-usgs]

Interesting this is in here. This must be a remnant from a while back.