Eventually....

If you have to make copies of a module, or have mutable state, use R6.
If you need to attach different packages to an object, use mod.

So acquire() searches from:

• relative path from working directory
• Alongside R's user library (need to be implemented)
• any other configured paths

See http://okmij.org/ftp/Scheme/oop-in-fp.txt in 1999.
It seems that every generation of programmers discover the same old thing again and again.

https://docs.racket-lang.org/guide/module-paths.html

Sometimes you may feel the need of using a package to organize your code. But you would then have to go through the formalities of making one, install it in your own machine (publish it somewhere, and instruct your collaborators to install it),
With mod, your components can ship with any existing code. Each module has their own local search path, so you can attach whatever package you need to each mod::ule, without one conflicting with another.

if a module is already loaded.... read from cache?

Soon!

Feel free to incorporate or dismiss these suggestions. Let me know if clarification is needed on any points.

Meta

• more explicit, real-life examples of why and when mod is useful
• "inst/misc/example_module.R" could be an interesting, real-life example
• remove empty author line in DESCRIPTION
• clarify (in docs and code) the difference between mod::ule() and mod::module()

Food for thought

• how might mod support psyphr? That might be a good approach to building a real-world example.

Language, description, and accessibility

• split README into vignettes
• fix typos and syntactical and grammatical errors (how would you like me to point those out?) (e.g., "declair" = a delicious declaration at breakfast)
• delete unnecessary phrases in README and documentation (e.g., "This is a good question.")
• reduce the use of semi-colons and use hyphens where appropriate
• examples of approaches to modules in other languages
• let users know they can use require() OR library() (don't find the crowd; guide its directions)
• what does "spare qualification" mean?
• double-check code style in vignettes (e.g., spacing, assignment conventions, etc.)
• use complete sentences ("Another way is using provide() function to declair public variables, while all others become private" is missing a thing or two.)
• don't assume your readers understand immediately (e.g., "The following demonstration should be self-explanatory..."
• consider an alternative to "we feel"; you are the sole author, and feelings have nothing to do with this.
• move terms and definitions to beginning of README, or consider a separate vignette with only terms and definitions at start of user experience

Code

• showing my ignorance: Why do we have to quote a mod in drop() but not in use()? (e.g., drop("my_test_mod") vs. use(my_test_mod)
• in the 'refer()' documentation or warnings (beyond default), it would be useful to let the user know that refer() will mask assignments from the previous module.
  e.g.,

my_other_test_mod <- mod::module({
refer(my_test_mod)
a <- 1
b <- 2
})

• In regard to above comment, you might also consider an implementation tool that helps the user compare the contents of each module before a mask occurs. I am reminded of the option to compare versions within Microsoft. Would a function that compares the contents of two modules be feasible?

if same name, detach old, attach new

intermediary(): evaluate expression & make module object
module: quoted expression, call intermediary()
acquire: parse expression from file, call intermediary()

• Thanks, please check the first sentence of your Description text. Does
  it make sense?

• You have examples for unexported functions which cannot run in this way.
  Please either add mod::: to the function calls in the examples, omit
  these examples or export these functions.

• You are using installed.packages():
  "This needs to read several files per installed package, which will be
  slow on Windows and on some network-mounted file systems.
  It will be slow when thousands of packages are installed, so do not use
  it to find out if a named package is installed (use find.package or
  system.file) nor to find out if a package is usable (call
  requireNamespace or require and check the return value) nor to find
  details of a small number of packages (use packageDescription)."
  [installed.packages() help page]

• Please fix and resubmit.

pkg <- asNamespace("'pkg_name")
pkg$fun()

In corporate asNamespace() into acquire(), which would, search for package first and then module??

This will have the same behavior inside or outside a module.

Why isn't the object named how you wanted to use it in the first place? The R way is to keep things named as they are, and that's better. node.js's exports.something = something is completely redundant, and I can't count how many times I have to tell a Python novice that the name of BeautifulSoup package is not "BeautifulSoup".

because it's supposed to change the function's environment to the to env.

and promote using inline definitions of modules in examples and future functionalities.

When developing reusable components, modules should not stand alone, but rather be subordinate to a packcage.

If it know its path, it can use a relative path to source other in-file modules. But is this necessary?
See Also: #24.

modules should have normal behavior as with any other R object, and maintain chain of environment, so that the user is not surprised by not being able to access names in a seemingly outer scope.

by default:

• Inline module defined by module() live in the calling scope through parent.frame().
• thing() too.
• acquire(), too now.

<<- assigns the value to the name where first found, if not, make new at global environment. BAD!
put this in the module mask.

so they appear nicely in ..search..()

name the package mod so that the package can be used when not attached?
Along the vein of emo, and emo::ji(), mod and...

• mo::dule()
• modu::le()
• mod::ule()?