wiki:SolveThePackageAbstractionProblem

Version 1 (modified by simonmar@…, 8 years ago) (diff)

--

I don't have a strong view about the global library organisation question, but I do think it's time to fix the broken-abstraction problem.

Consider (1)

Suppose a program consists of modules A,B,C, X,Y,Z Modules A,B,C were written by one person Modules X,Y,Z were written by someone else

Suppose C and Z both define a function 'f', not exported

THEN it would be unacceptable for the program to be rejected

Why unacceptable? Because 'f' is an internal matter to C and Z.

Consider (2)

Same setup (1), but this time C and Z export 'f' But only B imports C and only Y imports Z

THEN it would also be unacceptable to reject the program

Why unacceptable? Because again 'f' is internal to the groups of modules.

And indeed, Haskell is happy with both these scenarios.

Now consider (3)

A program uses package P and Q Package P exposes module A, and has hidden modules B,C Package Q exposes module X, and also has hidden modules B,C

I think it's equally unacceptable to reject the program. The packages were written by different people, and they just happened to use the same module name -- but that's internal to the package.

Even if B,C were exposed by both P and Q, that should not cause a problem, if you never say 'import B' or 'import C'. After all, there is no problem in setup (2) if we both C and Z, provided we do not mention 'f'.

Bottom line: I argue that the identity of a module should be a pair of (package name, module name), not just (as now), the module name. Anything else breaks abstraction, by revealing internal details to a client, and that's wrong for a clean language like Haskell.

--SimonPJ