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