Re: [Haskell-cafe] Packages and modules
I'm not sure on which mail of this thread I should append MHO. What happens if two programmers happen to choose the same package name? (Prepend the location on the filesystem? ;-) If something like a package name is introduced I would prefer not separating package and module name with a . because you might then even use the package name to point to a web address from where to load code (source/ binary/ byte code??) from.. Then creating something like Java applets would be more easy. We can't ignore this completely as the world (or important parts eg Windows) will try to bring more richness to internet applications/ the user.. They strive to integrate web applications so that you as user can't see if you're running a native or a downloaded application... If you use eg , as separator you can use dots in the package name without hassle. Marc ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Packages and modules
Marc Weber wrote: I'm not sure on which mail of this thread I should append MHO. What happens if two programmers happen to choose the same package name? (Prepend the location on the filesystem? ;-) If something like a package name is introduced I would prefer not separating package and module name with a . because you might then even use the package name to point to a web address from where to load code (source/ binary/ byte code??) from.. Then creating something like Java applets would be more easy. We can't ignore this completely as the world (or important parts eg Windows) will try to bring more richness to internet applications/ the user.. They strive to integrate web applications so that you as user can't see if you're running a native or a downloaded application... If you use eg , as separator you can use dots in the package name without hassle. I think the package alias syntax would help here eg (non-existent url): package http://www.metamilk.com/packages/duma-1.0 as Duma import Duma/Text.Line -- etc I don't think the package name should ever be written directly into the import statement, because the package name needs to be able to use normal filename syntax but a component of a module identifier needs to conform to Haskell syntax because it could be used anywhere (*) eg let x = Duma/Text.Line.take 5 y Also, to clarify my reasons for wanting to make the package part of the module id syntactically distinct (by using eg / instead of .), the entire namespace of hierarchical modules is supposed to be internal to each package, and therefore any id of the form A.B.C belongs to this internal namespace and therefore must refer to an internal module. All modules in external packages have ids of the form PackageAlias/ModulePath so when you read the source you (and the compiler) can tell at a glance whether you're referring to an internal or external module. An extra advantage of making the package alias part syntactically visible is that we could make package directives optional in the common case where we want to just use the latest version of a package that has a globally agreed name eg import Fps/Data.ByteString -- uses latest fps package whereas if we just used import Fps.Data.ByteString the compiler would have no way to tell whether we're referring to an external package Fps or another module in our own package, and, imho, this would just simply be messy and inconsistent. Also, although this requires changes to existing code, it should be possible to completely automate the change by using a simple conversion utility which knows about current packages, their prefixes, and what modules they contain (and therefore should be much less troublesome than the change from flat module namespace to hierarchical namespace). (*) As an aside, it is a question to me whether identifiers in the body of a module should be allowed to be qualified with anything other than a module *alias*. Haskell98 just had flat modules, so the qualification was of the form A.val, whereas with the hierarchical extension you can use A.B.C.val etc. However does anyone actually ever use this rather than specifying an alias for A.B.C and using the alias to qualify val instead? This becomes a more urgent question if the lexical syntax for a module id needs to use another symbol such as /. Regards, Brian. -- Logic empowers us and Love gives us purpose. Yet still phantoms restless for eras long past, congealed in the present in unthought forms, strive mightily unseen to destroy us. http://www.metamilk.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Packages and modules
Simon and I have been thinking about fixing this, and we think we might actually do so for GHC 6.6. Your message provoked us to write up the design. It's here http://hackage.haskell.org/trac/ghc/wiki/GhcPackages Feedback welcome It's worth reading the old threads; for example http://www.haskell.org//pipermail/libraries/2005-August/004281.html But there are many others! Simon | -Original Message- | From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Brian | Hulley | Sent: 25 June 2006 10:16 | To: Haskell-cafe | Subject: [Haskell-cafe] Packages and modules | | Hi - | At the moment there is a problem in that two packages P and Q could contain | the same hierarchical module eg Data.Foo, and the only way for user code to | ensure the right Data.Foo is used is to ensure that packages P and Q are | searched in the right order. | However suppose P and Q also contain another module with the same name, eg | Data.Bar. | And suppose a user module wants to use Data.Foo from P but Data.Bar from | Q!!! ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Packages and modules
Simon Peyton-Jones wrote: Simon and I have been thinking about fixing this, and we think we might actually do so for GHC 6.6. Your message provoked us to write up the design. It's here http://hackage.haskell.org/trac/ghc/wiki/GhcPackages Feedback welcome It's worth reading the old threads; for example http://www.haskell.org//pipermail/libraries/2005-August/004281.html But there are many others! [from wiki] ghc -c -package P1 M1.hs ghc -c -package P2 M2.hs ...compile other modules... ghc -o app M1.o M2.o ... -package P1 -package P2 I don't think this solves the whole problem. Suppose M1 needs to use A.B.C from P1 *and* A.B.C from P2, then it would need to be compiled with P1 and P2, and there is no way (from the part of the proposal in this section alone) to distinguish between these packages from within M1 itself if we're still to be limited by the import A.B.C syntax. It only seems to address the problem of app needing to use M1 and M2 but not A.B.C directly where M1 only uses P1 and M2 only uses P2. [from wiki] import Packages.Gtk-1_3_4.Widget.Button Allowing package aliases in the source could make this easier to type and avoid the necessity to capitalise and change underscores to dots: package gtk-1_3_4 as Gtk or package gtk as Gtk -- use the current version of gtk or if package directive is omitted an import Xyz/Mod is equivalent to: package xyz as Xyz -- initial letter capitalised import Xyz/Mod and making the package part of the module id explicit prevents ambiguity problems (David House's idea) though at the expense of using more syntax ie import Widget.Button from Gtk or import Gtk/Widget.Button -- instead of grafting In all cases I think it would be an absolute disaster to allow modules to be imported without an explicit package id because this would defeat the whole purpose of having a simple per-package namespace for modules and wouldn't allow the reader of source to know which packages it's referring to. Of course all code would need to be changed, but this could be accomplished by a conversion program which, given a list of packages and alias names, would just recursively traverse a source directory replacing imports and module exports by package directives and the fully qualified name of each module. [from wiki] Optional extra: grafting ambiguity ( http://www.haskell.org//pipermail/haskell-cafe/2006-June/016317.html ) The use of / instead of . (or from) gives the advantage of grafting in terms of succinct qualified module names without this ambiguity. Summary of my suggestions: 1) All module names would be of the form PackageAlias/ModId 2) package directives in the source bind aliases to actual packages 3) version number or package directive can be omitted when we are only interested in using the current version of that package 4) Package aliases have their own namespace Regards, Brian. -- Logic empowers us and Love gives us purpose. Yet still phantoms restless for eras long past, congealed in the present in unthought forms, strive mightily unseen to destroy us. http://www.metamilk.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Packages and modules
On Mon, Jun 26, 2006 at 04:20:16PM +0100, Brian Hulley wrote: I don't think this solves the whole problem. Suppose M1 needs to use A.B.C from P1 *and* A.B.C from P2 For a simple example of a case where this might arise, suppose M1 is the migration module for data (stored in a database, received over a network, or some other such case) in P version 1's format to P version 2's format. [from wiki] import Packages.Gtk-1_3_4.Widget.Button I'm also not a fan of this magic Packages.* hierarchy, nor the package name change hoops it makes us jump through. package gtk-1_3_4 as Gtk or package gtk as Gtk -- use the current version of gtk or if package directive is omitted an import Xyz/Mod is equivalent to: package xyz as Xyz -- initial letter capitalised import Xyz/Mod The package gtk as Gtk bit makes sense to me, but I'd expect then to use Gtk.Foo.Bar for module Foo.Bar in package Gtk. import gtk-1.3.4/Foo.Bar also makes sense, although personally I'd prefer the syntax from gtk-1.3.4 import Foo.Bar where either from packagename is an optional prefix to current import declaration syntax, or from packagename starts a block so we can say from gtk1 import Foo.Bar as Gtk1.Foo.Bar import Baz.Quux as Gtk1.Baz.Quux from gtk2 import Foo.Bar as Gtk2.Foo.Bar import Baz.Quux as Gtk2.Baz.Quux If we have gtk-1.something and gtk-2.something (rather than gtk1-version and gtk2-version as above) then we'd probably instead want the wiki's -package gtk-2.0.1=Gtk2 which could be generated due to a .cabal build-depends of gtk (= 2) as Gtk2 Thanks Ian ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Packages and modules
Simon, We covered this extensively in the Cabal vs Haskell thread starting here: http://www.haskell.org//pipermail/libraries/2005-April/003607.html You concluded it by saying on April 22: And this observation points towards a simpler solution: rather than invisibly pre-pend the package name, just get the programmer to do so. So package P exposes a module called P.M and package Q exposes Q.M. All P's internal modules are called P.something, and similarly for Q. (We rely on some social mechanism for allocating new package names, as now.) Now of course you can import P.M and Q.M in a single module. That would be simple. It might be pretty inconvenient to say 'import Base.Data.List' rather than just 'import Data.List'. But nothing forces you to do this -- and indeed we don't do it for the current 'base' package. The point is that it's an easy way for a package author to ensure their package won't conflict with others. If they choose not to avail themselves of it, it's more likely that their package will be unusable because of accidental name conflicts. Bottom line: the current story is pretty defensible. I'm not sure that keeping names unique by implicitly using package-ids is worth the bother. http://www.haskell.org//pipermail/libraries/2005-April/003672.html It seems like you are changing your position with this proposal? Any reason for doing so? -Alex- __ S. Alexander Jacobson tel:917-770-6565 http://alexjacobson.com On Mon, 26 Jun 2006, Simon Peyton-Jones wrote: Simon and I have been thinking about fixing this, and we think we might actually do so for GHC 6.6. Your message provoked us to write up the design. It's here http://hackage.haskell.org/trac/ghc/wiki/GhcPackages Feedback welcome It's worth reading the old threads; for example http://www.haskell.org//pipermail/libraries/2005-August/004281.html But there are many others! Simon | -Original Message- | From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Brian | Hulley | Sent: 25 June 2006 10:16 | To: Haskell-cafe | Subject: [Haskell-cafe] Packages and modules | | Hi - | At the moment there is a problem in that two packages P and Q could contain | the same hierarchical module eg Data.Foo, and the only way for user code to | ensure the right Data.Foo is used is to ensure that packages P and Q are | searched in the right order. | However suppose P and Q also contain another module with the same name, eg | Data.Bar. | And suppose a user module wants to use Data.Foo from P but Data.Bar from | Q!!! ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Packages and modules
Hi - At the moment there is a problem in that two packages P and Q could contain the same hierarchical module eg Data.Foo, and the only way for user code to ensure the right Data.Foo is used is to ensure that packages P and Q are searched in the right order. However suppose P and Q also contain another module with the same name, eg Data.Bar. And suppose a user module wants to use Data.Foo from P but Data.Bar from Q!!! I'm wondering: would it not be easier to just make it that the package name is prepended to the hierarchical module name, so the modules would instead be called by the names P.Data.Foo and Q.Data.Bar? As I see it, this would have at least these advantages: 1) A package author would only have to ensure that the name of the package (eg Edison, FPS, Base) is globally unique, and would then be free to name the modules in the package without having to worry about conflicts with other packages 2) Users of packages could specify exactly which modules they want to use, which would also make it easier to switch between different implementations of the same data type provided by different people etc 3) When you read the program text, you could immediately see which packages the modules came from, so you would know which packages you need to download if you don't currently have that module on your system. (At the moment, if I come across import Data.Foldable I've got no idea where to get it from.) It seems to me that the only reason this wasn't done in the first place was that originally there was just a flat module namespace, whereas with hierarchical modules it seems obvious to put the package name at the beginning (eg in Java the modules are called java.xyz, com.company.xyz etc to ensure there are no namespace conflicts) (On the Haskell' wiki there is http://hackage.haskell.org/trac/haskell-prime/wiki/SolveThePackageAbstractionProblem but this doesn't appear to consider the above solution.) Regards, Brian. -- Logic empowers us and Love gives us purpose. Yet still phantoms restless for eras long past, congealed in the present in unthought forms, strive mightily unseen to destroy us. http://www.metamilk.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Packages and modules
Apologies to Brian for the multiple copies, this wasn't originally sent to the list. On 25/06/06, Brian Hulley [EMAIL PROTECTED] wrote: I'm wondering: would it not be easier to just make it that the package name is prepended to the hierarchical module name, so the modules would instead be called by the names P.Data.Foo and Q.Data.Bar? This has the disavantage that if you move a module from one package to another, all existing code using that module breaks. Perhaps we need something analoguous to qualified imports: as well as specifying the modules hierarchical path, you could also specify its package. E.g., import Network.HTTP from HTTP Or, using your syntax: import HTTP.Network.HTTP I prefer mine because we could also allow not qualifying the package: import Network.HTTP -- will search all known packages for a Network.HTTP package This is likely to be less of a pain in the majority of cases when the module names don't overlap. Also, ambiguity. Given 'import HTTP.Network.HTTP', the compiler has to search for both packages named HTTP and modules with a full hierarchical name of HTTP.Network.HTTP. In the unlikely sitatution where a different package did indeed provide a module called HTTP.Network.HTTP, there would be an overlap. Finally the compiler could give better error messages if the module doesn't exist. I.e. one of 'Package X not found' or 'Module Y not found within package X' instead of 'Module Y not found'. -- -David House, [EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Packages and modules
David House wrote: Apologies to Brian for the multiple copies, this wasn't originally sent to the list. On 25/06/06, Brian Hulley [EMAIL PROTECTED] wrote: I'm wondering: would it not be easier to just make it that the package name is prepended to the hierarchical module name, so the modules would instead be called by the names P.Data.Foo and Q.Data.Bar? This has the disavantage that if you move a module from one package to another, all existing code using that module breaks. Existing code also breaks when you rename a module, although perhaps that's not so common as moving a module to another package (it's probably just me that has a bad habit of always wanting to rename everything later ;-) ) Perhaps we need something analoguous to qualified imports: as well as specifying the modules hierarchical path, you could also specify its package. E.g., import Network.HTTP from HTTP Or, using your syntax: import HTTP.Network.HTTP [rearranged] Also, ambiguity. Given 'import HTTP.Network.HTTP', the compiler has to search for both packages named HTTP and modules with a full hierarchical name of HTTP.Network.HTTP. In the unlikely sitatution where a different package did indeed provide a module called HTTP.Network.HTTP, there would be an overlap. Finally the compiler could give better error messages if the module doesn't exist. I.e. one of 'Package X not found' or 'Module Y not found within package X' instead of 'Module Y not found'. I agree with the advantages of making the package part explicit for preventing ambiguity and getting better error messages. [rearranged] I prefer mine because we could also allow not qualifying the package: import Network.HTTP -- will search all known packages for a Network.HTTP package This is likely to be less of a pain in the majority of cases when the module names don't overlap. I think though that a problem with allowing the package part to be omitted would be that when code is shared people would get different results when trying to compile it depending on which packages they happen to have installed. At the moment, although different packages can define modules with the same name, everyone afaik takes great care to try and avoid this so that the hierarchical namespace is hopefully unique regardless of the search order of packages. However if we are allowed to qualify a hierarchical name by a package name, we might end up with a lot less uniqueness in the hierarchical namespace (since this is partly the whole point since uniqueness can't be guaranteed at the moment anyway unless everyone knows about everything that everyone else is developing or intending to make globally available) leading to more unintended combinations of modules when they're imported unqualified. Therefore to get 100% safe code (assuming uniqueness of package names), I think it would be better to make the package qualification mandatory. import Network.HTTP from HTTP import qualified Newtork.HTTP from HTTP as H Other possibilities: import HTTP\Network.HTTP import Com.Company\Network.HTTP package Com.Company as C -- a package alias import qualified C\Network.HTTP as H Not that I'm necessarily suggesting \ but just trying to find some character that is easy to type (perhaps /) and can also be used in the lexical syntax without making too much impact on the CFG. Regards, Brian. -- Logic empowers us and Love gives us purpose. Yet still phantoms restless for eras long past, congealed in the present in unthought forms, strive mightily unseen to destroy us. http://www.metamilk.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Packages and modules
On Sunday 25 June 2006 05:16 am, Brian Hulley wrote: Hi - At the moment there is a problem in that two packages P and Q could contain the same hierarchical module eg Data.Foo, and the only way for user code to ensure the right Data.Foo is used is to ensure that packages P and Q are searched in the right order. However suppose P and Q also contain another module with the same name, eg Data.Bar. And suppose a user module wants to use Data.Foo from P but Data.Bar from Q!!! I'm wondering: would it not be easier to just make it that the package name is prepended to the hierarchical module name, so the modules would instead be called by the names P.Data.Foo and Q.Data.Bar? [snip discussion of this idea] The idea of improving the module system has been discussed a number of times before. Here is a thread started by a suggestion from the simons which generated a fair bit of discussion: http://www.haskell.org/pipermail/libraries/2003-August/001310.html I'm not sure whatever became of this idea; discussion seemed to sort of reach a consensus, and then nothing happened. The module grafting mechanism always seemed kind of nice to me. I think some of the problems discussed in this thread could be by using cabal, especially to specify the graftings expected for compilation. It seems like grafting can give a plausible story for dealing with dynamicly loaded code, which is a nice bonus. -- Rob Dockins Talk softly and drive a Sherman tank. Laugh hard, it's a long way to the bank. -- TMBG ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Packages and modules
Robert Dockins wrote: On Sunday 25 June 2006 05:16 am, Brian Hulley wrote: [snip] I'm wondering: would it not be easier to just make it that the package name is prepended to the hierarchical module name, so the modules would instead be called by the names P.Data.Foo and Q.Data.Bar? [snip discussion of this idea] The idea of improving the module system has been discussed a number of times before. Here is a thread started by a suggestion from the simons which generated a fair bit of discussion: http://www.haskell.org/pipermail/libraries/2003-August/001310.html I'm not sure whatever became of this idea; discussion seemed to sort of reach a consensus, and then nothing happened. Thanks for the link... At the risk of being a devil's advocate I think the above idea is too flexible and overly complicated. Imho it would be like trying to have a conversation with a group of people where each person is constantly jumping about, changing their name and appearance, and might be replicated in several places at once... :-) I'd have thought all that's needed is a nice simple cathedralish design where each module knows its globally unique place and just stays there forever so that it's easy to develop and share code which uses it. (Could Java be seen as a proof of concept here? ) Package aliases in the code would then make it easy to upgrade to the latest package eg package Graphics.Rendering.OpenGL-8-9 as OpenGL import OpenGL/GL.Bitmaps In a sense the package alias idea is a little bit like grafting, except the aliasing is specified in the source code instead of somewhere else. Perhaps package aliases could even be inherited from parent modules... The module grafting mechanism always seemed kind of nice to me. I think some of the problems discussed in this thread could be by using cabal, especially to specify the graftings expected for compilation. You'd then have to keep the Cabal info in sync with the source. At the moment I can just use ghc --make and don't need to know about Cabal at all unless I want to distribute a package (or install one). It seems like grafting can give a plausible story for dealing with dynamicly loaded code, which is a nice bonus. I hadn't thought of dynamically loaded code though... Regards, Brian. -- Logic empowers us and Love gives us purpose. Yet still phantoms restless for eras long past, congealed in the present in unthought forms, strive mightily unseen to destroy us. http://www.metamilk.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
