[Haskell-cafe] Proposal: TypeDirectedNameResolution
Richard O'Keefe
ok at cs.otago.ac.nz
Mon Jul 27 19:32:28 EDT 2009
I would find a third meaning for dot in Haskell just a little
bit too many.
Especially with hierarchical modules, Haskell encourages
writing small modules, or at any rate no larger than they
have to be. (SML goes further, of course.) So if we're
doing what the software engineering books say (small
highly cohesive loosely coupled modules) we should have
that much of a name overloading problem in the first place, no?
The alias facility for imports, and the practice that has
sprung up of using single-letter abbreviations for modules,
make the existing practice fairly light-weight.
I'm not sure, therefore, that we have a problem that OUGHT
to be "solved", still less by a method that I find less
readable.
It seems to me that there's an approach that could be
swiped from ML. One of the declaration forms in ML is
local
<private declarations>
in
<public declarations>
end
Just as "where" lets you share a bunch of definitions
across a bunch of clauses, so "local" makes everything
in the <private declarations> visible inside the
<public declarations> but not outside; from the outside
only the <public declaration> can be seen.
Waving my hands a bit, this is roughly equivalent to
(x1,...,xn) =
let <private declarations> in
let <public declarations> in
(x1,...,xn)
What has this to do with imports?
It means that you can introduce local renamings that
can be _shared_ by a group of declarations, while
elsewhere in the module, another group of declarations
can share different resolutions for the same names.
The advantages of that over type directed resolution
include
- what's happening is visible to the programmer
- it's basically ordinary declarations, not some new
constraint satisfaction process that has to be
interwoven somehow with type inference
- that makes life easier for other tools as well
- it doesn't overload dot (or my small head)
More information about the Haskell-Cafe
mailing list