solve-the-package-abstraction-problem.md

@@ -4,47 +4,72 @@ 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
@@ -52,16 +77,21 @@ 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
+
+