Why I Want Global Field Names (By Default)
wren ng thornton
wren at freegeek.org
Tue Mar 6 06:04:34 CET 2012
On 3/5/12 12:03 AM, Gershom Bazerman wrote:
> So, suppose we have a locally declared fields solution (such as DORF).
> Now, where do these fields live? Arguably, we want a module per record.
Rather, part of the point of all this is precisely that we *don't* want
one module per record. That's the organization required presently, since
it's the only way to use the module system for namespace resolution.
Ideally we should be able to define multiple records with the same field
name within a single module, rather than being forced to break the
module up into many files (and polluting the module namespace along the
Also, if your goal is to have a global namespace, that can be
approximated precisely by placing all declarations in a single module.
In virtue of being in a single module, they're all in the same
namespace; the client then just has to import your "global" module in
order to get everything. Indeed this has the benefit of modularity
because if my code depends on two separate projects which both want
"global" namespaces, this would allow me to use them simultaneously. If
we are to have any packaging and code reuse at all, this ability to
compose multiple packages is absolutely essential.
Furthermore, this would *avoid* spurious recompilation, since if I
upgrade my dependency on project A then I don't need to recompile any
modules which only depend on project B.
More information about the Glasgow-haskell-users