Changes between Initial Version and Version 1 of SolveThePackageAbstractionProblem


Ignore:
Timestamp:
Dec 1, 2005 11:58:44 AM (8 years ago)
Author:
simonmar@…
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • SolveThePackageAbstractionProblem

    v1 v1  
     1I don't have a strong view about the global library organisation 
     2question, but I do think it's time to fix the broken-abstraction 
     3problem. 
     4 
     5Consider (1) 
     6        Suppose a program consists of modules A,B,C, X,Y,Z 
     7        Modules A,B,C were written by one person 
     8        Modules X,Y,Z were written by someone else 
     9 
     10        Suppose C and Z both define a function 'f', not exported 
     11 
     12        THEN it would be unacceptable for the program to be rejected 
     13 
     14Why unacceptable?  Because 'f' is an internal matter to C and Z. 
     15 
     16Consider (2) 
     17        Same setup (1), but this time C and Z export 'f' 
     18        But only B imports C 
     19        and only Y imports Z 
     20 
     21        THEN it would also be unacceptable to reject the program 
     22 
     23Why unacceptable?  Because again 'f' is internal to the groups of 
     24modules. 
     25 
     26And indeed, Haskell is happy with both these scenarios. 
     27 
     28 
     29Now consider (3) 
     30        A program uses package P and Q 
     31        Package P exposes module A, and has hidden modules B,C 
     32        Package Q exposes module X, and also has hidden modules B,C 
     33 
     34I think it's equally unacceptable to reject the program.  The packages 
     35were written by different people, and they just happened to use the same 
     36module name -- but that's internal to the package. 
     37 
     38Even if B,C were exposed by both P and Q, that should not cause a 
     39problem, if you never say 'import B' or 'import C'.  After all, there is 
     40no problem in setup (2) if we both C and Z, provided we do not mention 
     41'f'. 
     42 
     43 
     44Bottom line: I argue that the identity of a module should be a pair of 
     45(package name, module name), not just (as now), the module name. 
     46Anything else breaks abstraction, by revealing internal details to a 
     47client, and that's wrong for a clean language like Haskell. 
     48 
     49--SimonPJ