What should the name of the type in the `DynamicLoading` module be?

[dlongnecke-cray]

This is a child issue of #27687.

A companion issue is #29216.

Currently, the DynamicLoading module exposes a type with the name binary used to represent a loaded program. E.g.,

record binary {
// ...
}

var bin = try! binary.load('path/to/program');

However, in discussions we concluded that binary may not be the most intuitive name for the type.

Note that there is no strong motivation for the current name. I chose it because it felt right on a whim as I often refer to native programs as "binaries".

Here are some other possible options for a type name:

• program
• library
• dynamicLibrary
• dynLib

[bradcray]

I've been balking when I see binary.foo() in examples we've created to demonstrate dynamic loading because, absent any context, the term takes my mind to things like "1s and 0s" or "binary IO" rather than "binary files" (though all three are obviously related). It also seems inconsistent with other standard modules to me to have the module named DynamicLoading and for the type name not to be related in some way to the module name (thinking of things like List and list or BlockDist and blockDist). dynamicLoading probably the right name for the type, but dynamicLibrary or library or dynLib all feel more clearly related to the module name if we continue to use type-based methods.

[edit: related, if we were to not use type methods in this module, as being discussed in #29216, and the module were to serve as the singleton in any sort of foo.load() type of syntactic pattern, it raises a question for me about whether DynamicLIbrar[y|ies] or DynamicLib[s] or DynLib might be a better module name. I think "DynamicLoading" is a better description of what the module is about, but DynamicLibrary.load() is a bit more descriptive than DynamicLoading.load(). That said, I'm the type of programmer who would probably just do `use ; load(…); anyway, so may not be the right target audience]

[jabraham17]

Of the proposed names, I like either library or dynamicLibrary as the type name. I don't have a super strong preference one way or the other, with maybe a slight preference for dynamicLibrary.

I do have a pretty negative reaction to dynLib, which feels too short and just sorta rubs me the wrong way.

I don't have strong support for my opinions here other than vibes based. The primary language I've used that treats libraries as a first class object in this way (i.e. adding some kind of nice UX over dlopen in C). is Python's ctypes module. They use the type name CDLL for all dynamic libraries - windows and other OSes alike. This is imo a pretty bad name so isn't a great source of inspiration for us

[jabraham17]

Regardless of if type methods are used or not, I would be up for renaming this module DynamicLoading->DynamicLibrary, since dynamic loading is more a description of the feature and dynamic library is the user-facing outcome of that feature. But I don't feel super strongly about that

[dlongnecke-cray]

I really like the name program and I think that captures what I was going for a lot better than binary (which I agree with Brad is too generic and can be misconstrued for any binary thing). It also addresses my niche complaint about "technically any native program can be loadable".

I'm OK with library or dynamicLibrary too. I agree that dynLib feels a bit too short, but honestly it has kind of grown on me over time. My main concern at this point is that it's really close to the Mac .dylib file format. However, there is some small precedent for calling it a dynLib in at least 1-2 other languages (Nim and Odin upon a quick Google).

I am OK with renaming the module as well if we decide that's appropriate.