Changes between Version 12 and Version 13 of Commentary/Packages/GhcPackagesProposal


Ignore:
Timestamp:
Jul 5, 2006 7:40:22 AM (8 years ago)
Author:
simonpj
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • Commentary/Packages/GhcPackagesProposal

    v12 v13  
    6060The exact syntax is unimportant. The important thing is that the programmer can specify the package in the source text. 
    6161 
    62 An open question: if A.B.C is in the package being compiled, and in an exposed package, and you say {{{import A.B.C}}}, do you get an error ("ambiguous import"), or does the current package override.  And if the former, how can you say "import A.B.C from the current package"? 
     62If we adopt the idea that an import statement can specify the source package, several design choices arise: 
     63 
     64=== Is the 'from <package>' compulsory? === 
     65 
     66If you want to import A.B.C, a module exported by package "foo", can you say just {{{import A.B.C}}}, or must you say {{{import A.B.C from "foo"}}}? 
     67 
     68We think of this as rather like the question "If you import f from module M, can you refer to it as plain "f", or must you refer to it as "M.f"?  The answer in Haskell 98 is that you can refer to it as plain "f" so long as plain "f" is umambiguous; otherwise you can use a qualified reference "M.f" to disambiguate. 
     69 
     70We propose to adopt the same principle for imports. That is, you can say "{{{import A.B.C}}}" so long as that is umambiguous (meaning that there is only one module A.B.C exported by any installed package).  If the reference to A.B.C is ambiguous, you can qualify the import by adding "{{{from "foo"}}}". 
     71 
     72=== Package versions === 
     73 
     74We probably want some special treatment for multiple versions of the same package.  What if you have both "foo-3.9" and "foo-4.0" installed, both exporting A.B.C?  This is jolly useful when you want to keep install new packages, but keep old ones around so you can try your program with the older one.  So we propose that this is not regarded as ambiguous: importing A.B.C gets the latest version, unless some compiler flag (-hide-package) takes it of the running. 
     75 
     76=== Importing from the home package === 
     77 
     78If A.B.C is in the package being compiled (which we call "the home package"), and in an exposed package, and you say {{{import A.B.C}}}, do you get an "ambiguous import" error , or does the current package override.  And if the former, how can you say "import A.B.C from the current package"? 
     79 
     80=== The 'as P' alias === 
     81 
     82We propose to maintain the local, within-module "as P" alias mechanism unchanged.  Thus: 
     83{{{ 
     84   import A.B.C( T ) from "foo" as M 
     85   type S = M.T -> M.T 
     86}}} 
     87Here, the qualified name "M.T" refers to the T imported from A.B.C in package "foo". 
     88 
     89=== Qualified names === 
     90 
     91We propose that the default qualified name of an entity within a module is just the module name plus the entity name.  Thus 
     92{{{ 
     93  import A.B.C( T ) from "foo"  
     94  type S = A.B.C.T -> A.B.C.T 
     95}}} 
     96If you want to import multiple A.B.C's (from different packages) then perhaps they define different entities, in which case there is no problem: 
     97{{{ 
     98  import A.B.C( T1 ) from "foo"  
     99  import A.B.C( T2 ) from "bar"  
     100  type S = A.B.C.T1 -> A.B.C.T2 
     101}}} 
     102But if they both export entities with the same name, there is no alternative to using the 'as M' mechanism: 
     103{{{ 
     104  import A.B.C( T ) from "foo" as M1 
     105  import A.B.C( T ) from "bar" as M2 
     106  type S = M1.T -> M2.T 
     107}}} 
     108 
     109=== Exporting modules from other packages === 
     110 
     111It is perfectly OK to export entities, or whole modules, imported from other packages: 
     112{{{ 
     113  module M( f, g, module Q ) where 
     114  import A.B( f, g ) from "foo" 
     115  import X.Y.Z from "bar" as Q 
     116}}} 
     117 
     118=== Syntax === 
     119 
     120Should package names be in quotes?  Probably not.  They have a well-defined syntax. 
     121 
     122It's been suggested that one might want to import several modules from one package in one go: 
     123{{{  
     124    from "base" import 
     125        Prelude hiding (length) 
     126        Control.Exception 
     127        qualified Data.List as List 
     128}}} 
     129What we don't like about that is that it needs a new keyword "{{{from}}}".  Perhaps all imports can start with the keyword {{{import}}}, and then we are free to use extra (context-specific) keywords.  (Haskell already has several of these, such as {{{hiding}}}.  Something like this: 
     130 
     131{{{  
     132    import from "base" 
     133        Prelude hiding (length) 
     134        Control.Exception 
     135        qualified Data.List as List 
     136    import from "foo" M( x, y ) 
     137}}}