when defined(enable_deprecated):So I really think it would be useful to set such kind of parameters when we import that module, as in
import foreign_module(enable_deprecated = true)Enable_deprecated may be the most useful parameter, i.e. to enable deprecated procs. But such parameters may be useful for other stuff, i.e. enable/disable use of GC in that module, make new, untested functions available, optimize for speed or memory footprint, ...
I think I have seen and used something like that already in Oberon or Modula variants. (Of course when modules are precompiled binaries it may not work.)
[EDIT]
Sure, there may be conflicts when a module is imported multiple times with contradicting parameters. But such conflicts should be rare and can be solved.
There has been some talk of this on irc and the issue tracker ('parameterized modules') however I think, at the moment, there are other, more important things that need to be worked on. That's not to say that Nim won't get parameterized modules, however it may not happen anytime soon.
For what it's worth, the need for parameterized modules is reduced through the use of static parameters, defined symbols, and templates. Static parameters can be used by procedures at compile-time to specialize themselves, defined symbols serve as project-wide switches, and templates can be used for most other things:
proc getFileName(handle: THandle, bufferSize: static[int]): string =
## Get the filename associated with a file handle.
## Uses `bufferSize` as the initial buffer size when interfacing
## with the OS
...
proc calculateSin(x: int): int =
## Calculate the sin of a function.
## When the GC is disabled, doesn't use a lookup table
when defined(gcDisabled):
...
template enableImplicitPathToString =
## Use in your desired module to activate implicit FilePath to string
## conversion
converter pathToString(path: FilePath): string =
...