RE: Libraries and hierarchies
Would you mind illustrating the source-to-source transformation on a small example? Suppose there's a package foo with a module
module C where f = 'a'
that this package is grafted in at both A.B and X, and there's a module
module Foo (f) where import A.B.C (f) import X.C (f)
One possible transformation is this: module A.B.C where f = 'a' module X.C (module A.B.C) where import A.B.C
I also can't see much to gain from local graftings. But that leaves us wanting each combination of
default root for package + local module name
unique across all packages, doesn't it?
No - we don't want globally-unique module names (that's what we were trying to solve in the first place). We therefore do want local grafting. There are good uses for packages which overlap in their default installation - versioning is one example. Cheers, Simon
hello, Simon Marlow wrote:
No - we don't want globally-unique module names (that's what we were trying to solve in the first place). We therefore do want local grafting. globally unique module names and globally unique package names seem to be very similar problems. i thought the problem we were trying to solve was how to present ugly modules names nicely in a (source) program (this is what i understood from simon pj's explanatory email a couple of days ago, although he didn't use those exact words). what i mean is:
if we have unique package names, then we have unique modules names: module A.B in a package P, has the unique name P.A.B. the problem as i understood it, was that package names might be kind of ugly, and change relatively often (e.g. with new releases, even minor ones). so i think simon & simon were suggesting a way to _distribute_ package source code that might avoid that. the source code distributed is "incomplete", as the module names contain "holes" to be filled in when the package is installed. i think "grafting" refers to filling in the holes. so i think if we really wanted it, we _could_ think of this as not being a language extension. having said that, it seems to me that we would always be writing this "incomplete" haskell (as we always refer to modules by their "grafted" names, and not by their real names) and never really see the "real" program. so we have basically extended the language, because after all haskell is what is in the source files. bye iavor -- ================================================== | Iavor S. Diatchki, Ph.D. student | | Department of Computer Science and Engineering | | School of OGI at OHSU | | http://www.cse.ogi.edu/~diatchki | ==================================================
participants (2)
-
Iavor Diatchki -
Simon Marlow