[Haskell] Re: package mounting
Benjamin Franksen wrote:
Assume library A uses library B. Then, presumably, lib A must chose a mount
point for its use of lib B. Now imagine a program P wants to use lib A as
well as directly import some module from lib B. Is P now free to give lib B
its own mount point, independent of the one that was chosen by lib A? I
think this should definitely be possible. There may, however, be some
issues regarding implementation: Can a compilation system share code
between both 'versions' of lib B (I assume they are /not/ really different
versions but exactly the same one, only referred to via a different 'mount
point')? Hmm, maybe this isn't really a problem. The compiler could simply
alias the module names, similar as to what it does for 'import M as N'.
Right - mounting is just a way of manipulating names in source code. If you
import a module twice with different names ('import A as B and import A as
C), this doesn't give you two copies of A, and mounting would work the same way.
(not that I necessarily agree that mounting is the best approach, I just wanted
to answer this point).
Cheers,
Simon
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Re: package mounting
On 10/30/06, Frederik Eaton [EMAIL PROTECTED] wrote: On Sun, Oct 29, 2006 at 10:03:32PM -0400, Samuel Bronson wrote: On 10/25/06, Frederik Eaton [EMAIL PROTECTED] wrote: http://hackage.haskell.org/trac/ghc/wiki/PackageMounting It looks nice, but don't you think the -package-base flag ought to take both the package name *and* the mountpoint? My intention was that -package-base specifies a base for the package specified in the preceding -package flag, but I'll clarify it in the document. In other words, it is an optional argument and the syntax is ghc ... -package PACKAGE -package-base BASE ... (giving package PACKAGE mount point BASE) Otherwise, this looks like what I've wanted all along, if only I knew it ;-). Excellent, thanks. What about packages with multiple module trees like, say, Cabal? -- Cheers, Lemmih ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] Re: package mounting
Frederik Eaton [EMAIL PROTECTED] writes: It looks nice, but don't you think the -package-base flag ought to take both the package name *and* the mountpoint? My intention was that -package-base specifies a base for the package specified in the preceding -package flag [...] In other words, it is an optional argument and the syntax is ghc ... -package PACKAGE -package-base BASE ... How about something like ghc ... -package [EMAIL PROTECTED] (where the @BASE part is optional)? -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Re: package mounting
What about packages with multiple module trees like, say, Cabal? That's a good question, and I think the right answer is not to do anything special to support them. I assume that what you're referring to with Cabal is that there is no common prefix for all of the module names, but rather a small set of common prefixes (Distribution.*, Language.Haskell.Extension). Under my proposal, if we want to get rid of the 'Distribution' module prefix within the Cabal source code, then we'll have to either rename the Language.Haskell.Extension module, or move it to another package. Best, Frederik -- http://ofb.net/~frederik/ ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] RE: package mounting
| http://hackage.haskell.org/trac/ghc/wiki/PackageMounting | | It looks nice, but don't you think the -package-base flag ought to | take both the package name *and* the mountpoint? | | Otherwise, this looks like what I've wanted all along, if only I knew it ;-). I think most of you know that GHC 6.6 made (IHMO) a significant step forward, by allowing a program to contain multiple modules with the same name, if they are from different packages. That means that package authors can choose module names freely, rather than worry about accidentally colliding with other packages. (We'd regard it as unacceptable if the local variables of a function could not have the same name as the local variables of another procedure!) That still leaves an open question, not resolved by GHC 6.6: what to do if you want to import module M from two different packages into the same module? (A related question is when you have to decide what your module is called.) This can be tackled in at least three different ways, one being Frederik's proposal. Simon and I are not wedded to any particular one, and we'd welcome a consensus on what to do. The state of play is summarised here http://hackage.haskell.org/trac/ghc/wiki/GhcPackages which includes a link to the package-mounting proposal. If you care about this stuff, do debate it -- and please record points that survive a bit of discussion on the Wiki pages. None of this is very hard to implement; the difficulty is settling on a good design. Simon ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] RE: package mounting
Simon Peyton-Jones wrote: | http://hackage.haskell.org/trac/ghc/wiki/PackageMounting | | It looks nice, but don't you think the -package-base flag ought to | take both the package name *and* the mountpoint? | | Otherwise, this looks like what I've wanted all along, if only I knew it ;-). I think most of you know that GHC 6.6 made (IHMO) a significant step forward, by allowing a program to contain multiple modules with the same name, if they are from different packages. That means that package authors can choose module names freely, rather than worry about accidentally colliding with other packages. I think this is true only in a very technical sense. I fear that in practice, library authors will go to great lengths to avoid such overlapping module names, because introducing them will cause too much difficulties for library users. The only way to make halfway sure that this doesn't happen is to use (fixed) module hierarchy prefixes containing (more or less) the package name, as in Text.ParserCombinators.Parsec, even though technically they aren't forced to do so. (We'd regard it as unacceptable if the local variables of a function could not have the same name as the local variables of another procedure!) Yes, but this analogy seems to cover only the problem with internal (package-local, non-exposed) modules. To widen your analogy, we'd regard it as similarly unacceptable if we had to qualify each exported entity with the module name each time we use them, even if we are inside the module that defines them, wouldn't we? Which is today's situation on the package/module level: We have to completely qualify module names with their mount point in the module hierarchy, even when refering to them from inside the package that defines them. I see, however, one point with Frederik's proposal that isn't clear to me: Assume library A uses library B. Then, presumably, lib A must chose a mount point for its use of lib B. Now imagine a program P wants to use lib A as well as directly import some module from lib B. Is P now free to give lib B its own mount point, independent of the one that was chosen by lib A? I think this should definitely be possible. There may, however, be some issues regarding implementation: Can a compilation system share code between both 'versions' of lib B (I assume they are /not/ really different versions but exactly the same one, only referred to via a different 'mount point')? Hmm, maybe this isn't really a problem. The compiler could simply alias the module names, similar as to what it does for 'import M as N'. That still leaves an open question, not resolved by GHC 6.6: what to do if you want to import module M from two different packages into the same module? What if I want to import them into /different/ modules (which are nevertheless part of the same package)? Can this be easily accomplished with ghc-6.6? Cheers Ben ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] Re: package mounting
On Sun, Oct 29, 2006 at 10:03:32PM -0400, Samuel Bronson wrote: On 10/25/06, Frederik Eaton [EMAIL PROTECTED] wrote: http://hackage.haskell.org/trac/ghc/wiki/PackageMounting It looks nice, but don't you think the -package-base flag ought to take both the package name *and* the mountpoint? My intention was that -package-base specifies a base for the package specified in the preceding -package flag, but I'll clarify it in the document. In other words, it is an optional argument and the syntax is ghc ... -package PACKAGE -package-base BASE ... (giving package PACKAGE mount point BASE) Otherwise, this looks like what I've wanted all along, if only I knew it ;-). Excellent, thanks. Frederik -- http://ofb.net/~frederik/ ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] RE: Package mounting proposal
| Subject: Package mounting proposal | | Hi lists, | | (I hope my cross-posting is okay, but somehow this post seems to apply to | all of you, so here goes...) I think 'libraries' is the list that anyone interested in this will hang out, so I'll reply there alone Simon ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] Re: package mounting
(By the way, sorry about cross-posting again. People have already replied to just 'haskell@' and just 'libraries@' but I'll try to stick to 'libraries@' after this since it seems that some users' mail clients show them two copies otherwise) This idea has been raised before, but it was a while back, and we called it grafting. Here's the start of the thread, which went on for quite some time: http://www.haskell.org/pipermail/libraries/2003-August/001310.html Actually it looks like that is slightly different from my idea, perhaps I should have expounded a bit more in my original post. Correct me if I'm wrong, but in my proposal: - grafting/mounting would be done per compilation unit. In yours it seems it would be done per (user, system). - configuration of graft/mount points would be done at compile time, zero or one times per package import option. In yours it would be at package install time. I think my proposal is better. In it there would be no cross-system compatibility issues: since each program would specify where its imported packages get mounted itself, you could write a Haskell program on one system and be assured that someone else could use it on another system without problems. I think this is a rather important property and we shouldn't allow it to be broken - a warning that, as you say, This wouldn't be recommended though: any source code you write won't compile on someone else's system that doesn't have the same convention is quite insufficient in my opinion! Plus, I think the ability to remount packages at non-standard locations is an important one, but for the above reason your proposal makes it too dangerous and therefore unusable in practice. Our proposals agree on this point: The implementation must obey the following rule: When compiling a module belonging to a package, that package is temporarily grafted into the root of the module hierarchy. It was kind of implicit in my proposal though. I think the alternative design which is mentioned in your proposal is interesting: Alternative design: modules in the current package could be specified explicitly, perhaps by prefixing them with '.'. This would avoid the possibility of overlap between the current package and the global hierarchy, at the expense of having to add lots of extra '.'s. I think that might be a useful feature. Obviously one could introduce the '.' syntax and still allow the present sytax to be used for backward compatibility. Frederik -- http://ofb.net/~frederik/ ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
