import resolution (was RE: exposed packages and cabal depends)

S. Alexander Jacobson alex at alexjacobson.com
Tue Apr 12 14:57:48 EDT 2005


Simon,

My main goal here is to free the user from the hassle of manual 
package installation.  A module written in one location should "just 
work" when moved to another.  Right now, we have that location 
transparency within a single box or networked file system.  I am 
saying we should also have it for moves accross the Internet.

So, the meaning of an import statements should not depend on its 
context (in effect, module identifiers in import statements should be 
a form of URL) and compilers/interpreters should be able to resolve 
those URLs to module implementations without user intervention.

And, if the meaning of module names is parametrized by package then 
package names should be part of import statements.  If packages are 
purely adminisistrative, then they shouldn't.

Do we agree on at least this much?

-Alex-

PS In my last few posts I assumed you had rejected removing the 
overlap restriction because that is what I interperted you to have 
said e.g. here:

   We're not going to support this, at least for the forseeable future.
   It's a pretty big change: every entity in the program becomes
   parameterised by the package name as well as the module name, because
   module names can overlap.

   http://www.haskell.org//pipermail/haskell/2005-March/015597.html

And here

   Also, the Haskell module hierarchy is supposed to reflect functionality,
   whereas package names are purely administrative.  This is a reason for
   not including package names in source code.

   http://www.haskell.org//pipermail/libraries/2005-April/003513.html

Did you change your mind or am I misinterpreting?

-Alex-


______________________________________________________________
S. Alexander Jacobson tel:917-770-6565 http://alexjacobson.com






Note, in my last few posts have I assumed that you had rejected 
removing the overlap restriction:

   We're not going to support this, at least for the forseeable future.
   It's a pretty big change: every entity in the program becomes
   parameterised by the package name as well as the module name, because
   module names can overlap.

   This means a change to the language: there might be multiple types
   called M.T in the program, which are not compatible (they might have
   different representations).  You can't pass a value of type M.T that you
   got from version 1.0 of the package to a function expecting M.T in
   version 2.


And that you wanted packages to be administrative entiries without 
functional consequence e.g.














I feel like you ha





The rest of this discussion has been detail that depends on whether or 
not



You appear to be


Earlier in this discussion you had said that packages were purely 
administrative:


and that you would not





So, if package name is part of the module identifier, then that means 
a standard way to resolve package names to URLs.  If not, then that 
means a standard way to revolve module names to URLs.

Either way, my point is that the meaning of solution of import statements should be 
global/universal and not local to a particular Haskell installation.



   effectively module identifiers 
should resolve to 
URLs and not locations within a local filesystem.





  without explicit user 
intervention.

Achieving this level of location transparency requires that


In effect



Achieving this level of location transparency requires that we have a 
universal way to identify module functionality for use in import 
statements.  In other words, compilers/interpreters should be able to 
resolve the module identifiers in import statements to module 
implementation URLs (or URLs of packages from which implementations 
can be built).







You said:







implementations have a way to resolve module identifiers in import 
statements to package or module URLs.

Note, in my last few posts, I've been assuming that you were NOT 
planning to make the package name part of the module identifier, 
because you said so:


Did you change your mind or am I misinterpreting what you are saying 
here?

Either way, the only way to eliminate untracked dependencies is if 
import statements contain enough information to identify sufficiently 
the exact functionality required by the module.  As you say packages 
should be entirely administrative:













On Tue, 12 Apr 2005, Simon Marlow wrote:

> On 12 April 2005 01:28, S. Alexander Jacobson wrote:
>
>> On Mon, 11 Apr 2005, Simon Marlow wrote:
>>>> The problem is, we don't want to import two modules, only to
>>>> discover that somewhere in their dependencies they each use the
>>>> same module name to refer to conflicting module implementations.
>>>
>>> This is the problem that the overlap restriction leads to, yes.
>>
>> No, you have this problem even with atomic modules. It is a result
>> simply of not allowing two modules to share the same name in the same
>> program and has nothing to do with package overlap.
>
> When I say "overlap restriction" I mean the restriction that prevents
> having two modules with the same name in the same program.
>
>>>> Therefore, we really want to say that no two modules we might want
>>>> to import into our programs (either directly or indirectly) should
>>>> share the same name.  And, in particular, we don't want a packaging
>>>> or versioning system that encourages it!
>>>
>>> No, you've drawn a bogus conclusion again.  We most definitely want
>>> the ability to choose between multiple instances of a particular
>>> module in programs.
>>
>> My point is that the choice of instance should be made at
>> compile/build/run times and not at packaging time.
>
> Dependencies must be expressed at package time, otherwise they are
> untracked dependencies.  Right?
>
> A package must state that it needs implementation P of module M rather
> than implementation Q, otherwise there's a chance that the guy building
> the package will get the wrong one.
>
> Build-depends lets you select an implementation from a range (currently
> it's just a version range, but we could make the language more
> expressive and include alternatives, I doubt it would be that useful in
> practice, though).
>
> So dependencies are selected at compile time.  Selecting dependencies at
> run-time (I assume this is what you mean by late binding) is another
> kettle of fish: at least, it would mean that GHC couldn't do its
> aggressive cross-module optimisation against the library that you're
> late-binding to.  But I think it's worthwhile investigating to what
> extent this is possible, so that we can have upgradable shared
> libraries.
>
>>> For example, if I have two versions of a package installed,
>>> say P-1 and P-2, I want to be able to compile my old code that
>>> depends on P-1 while still being able to write new code against P-2.
>>> And I want to be able to use other packages that still depend, for
>>> the time being, on P-1.  When P-3 comes out, I don't want to be
>>> forced to uninstall P-1 and P-2 before I can use it.
>>
>> Now what happens when you want to use one package that depends on P-1
>> and another that depends on P-2 at the same time?
>
> Of course, you can't do that.  That's what the "overlap restriction"
> prevents.  As I've explained.
>
> [ the next three paragraphs, which I deleted, all complain about
> scenarios which we can't handle because of the overlap restriction.  I
> don't think I need to comment any further. ]
>
> [ more stuff deleted, this thread is too long already ]
>
> Cheers,
> 	Simon
>



More information about the Libraries mailing list