RE: Cabal vs Haskell [sic]

newer
Bug in Cabal creating user...

older
RE: Help! no environment variable...

Simon Marlow

23 Apr 2005 23 Apr '05

6:27 p.m.

On 23 April 2005 00:21, ross@soi.city.ac.uk wrote:

...

On Fri, Apr 22, 2005 at 11:28:21PM +0100, Simon Peyton-Jones wrote:

...
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.

This would obscure the hierarchy a bit. A common current practice is a variant of this: modules either have allocated names or their names have the form

allocated prefix + proper name + whatever you like

e.g. Graphics.Rendering.OpenGL.GL.Texturing.Queries -- it seems to work pretty well, and should scale, as long as the proper names are distinct, e.g. package names or otherwise allocated.

Right. Also, prepending package names to module names to avoid the overlap restriction suffers from another difficulty: versioning. You can't combine two versions of a package without including the version number in the module names of all the modules in the package. But then you end up with source code that has to be edited when the version of a package changes, which is highly undesirable. IMO, it's a good thing that package names and versions are separate from module names. It means we can (mostly) stick to the original aim of using the module hierarchy to reflect functionality, and not clutter it up with version numbers and other administravia. Cheers, Simon

Show replies by date

S. Alexander Jacobson

24 Apr 24 Apr

12:54 p.m.

New subject: Cabal vs Haskell [sic]

On Fri, 22 Apr 2005, Simon Peyton-Jones wrote:

...

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.

If the current Haskell story is that module names are top-level then it is incompatible with the current Cabal story. The current Cabal story is that module names are implicitly qualified by package-ids. Cabal's build-depends tag says that some set of package names are required to interpret enclosed import declarations. In other words, that the import declarations are themselves insufficient to identify the external modules required to interpret the enclosed modules. I strongly prefer the current Haskell story to the current Cabal story for reasons enumerated at length in this thread*. Hierarchical module names should need no qualification. But, they do need some syntax to make those names easier on developers. Here is my suggestion: New Syntax Translation ---------- ----------- module Name.Space Foo.M where module Name.Space.Foo.M where import Bing.Baz import Name.Space.Bing.Baz import HAppS ACID import HAppS.ACID from HaXml.Text.XML import Types import HaXML.Text.XML.Types import Escape import HaXML.Text.XML.Escape import Pretty import HaXML.Text.XML.Pretty We also need a standardized way to resolve hierarchical module names to interfaces and implementation, but that is a separate topic. -Alex- * Quick recap of arguments against Cabal: * namespace issues shouldn't be mixed with physical packaging issues * dev tools operate on source files/directories not packages * Cabal fragility with respect to changes in build-depends tag * Cabal fragility with respect to changes in modules of other packages * incompatibility between unqualified imports and Cabal versioning ______________________________________________________________ S. Alexander Jacobson tel:917-770-6565 http://alexjacobson.com On Sat, 23 Apr 2005, Simon Marlow wrote:

...

On 23 April 2005 00:21, ross@soi.city.ac.uk wrote:

...
On Fri, Apr 22, 2005 at 11:28:21PM +0100, Simon Peyton-Jones wrote:

...
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.

This would obscure the hierarchy a bit. A common current practice is a variant of this: modules either have allocated names or their names have the form

allocated prefix + proper name + whatever you like

e.g. Graphics.Rendering.OpenGL.GL.Texturing.Queries -- it seems to work pretty well, and should scale, as long as the proper names are distinct, e.g. package names or otherwise allocated.

Right. Also, prepending package names to module names to avoid the overlap restriction suffers from another difficulty: versioning. You can't combine two versions of a package without including the version number in the module names of all the modules in the package. But then you end up with source code that has to be edited when the version of a package changes, which is highly undesirable.

IMO, it's a good thing that package names and versions are separate from module names. It means we can (mostly) stick to the original aim of using the module hierarchy to reflect functionality, and not clutter it up with version numbers and other administravia.

Cheers, Simon _______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

Isaac Jones

7:49 p.m.

New subject: Cabal vs Haskell [sic]

"S. Alexander Jacobson" writes:

...

On Fri, 22 Apr 2005, Simon Peyton-Jones wrote:

...
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.

If the current Haskell story is that module names are top-level then it is incompatible with the current Cabal story. The current Cabal story is that module names are implicitly qualified by package-ids. Cabal's build-depends tag says that some set of package names are required to interpret enclosed import declarations. In other words, that the import declarations are themselves insufficient to identify the external modules required to interpret the enclosed modules.

This is the case in every language I know of, except perhaps for Java which requires that you prefix your organizational name to your modules. In fact we could do that in Haskell without changing anything.

...

I strongly prefer the current Haskell story to the current Cabal story for reasons enumerated at length in this thread*.

Once again, the current cabal story is not different from the current Haskell story. Please stop saying that. Cabal is layered on Haskell. Cabal "changes" the interpretation of a Haskell module only in the sense that Make changes the interpretation of a Haskell or C program or that "-i" changes the interpretation of a Haskell or C program. This is obvious, and I agree with it, but the way you keep phrasing it makes me wonder if you understand this. (snip)

...

* Quick recap of arguments against Cabal:

* namespace issues shouldn't be mixed with physical packaging issues * dev tools operate on source files/directories not packages * Cabal fragility with respect to changes in build-depends tag * Cabal fragility with respect to changes in modules of other packages * incompatibility between unqualified imports and Cabal versioning

These are too vague to respond to (they have already been responded to). But I want to point out that no matter what system you use, if the modules that my module depends on change in a bad way, then my module will break. The only way around this is good software engineering. peace, isaac

S. Alexander Jacobson

25 Apr 25 Apr

8:01 p.m.

New subject: Cabal vs Haskell [sic]

On Sun, 24 Apr 2005, Isaac Jones wrote:

...

Once again, the current cabal story is not different from the current Haskell story. Please stop saying that.

1. The current Haskell story is that the dependencies of a module are the set of modules identified in its import statements. 2. The current Cabal story is that the dependencies of a package are the set of packages identified in its build-depends statement. 3. Since, a package may contain Haskell modules, the set of modules on which the contained modules depend must themselves dependent on the set of packages identified in the package's build-depends statement. 4. A set of modules may be dependent on a set of packages if and only if that set of packages is the only set of packages that may contain them. 5. Since more than one set of packages may contain the same set of modules, the current Haskell story cannot be consistent with the current Cabal story. QED -Alex- ______________________________________________________________ S. Alexander Jacobson tel:917-770-6565 http://alexjacobson.com On Sun, 24 Apr 2005, Isaac Jones wrote:

...

"S. Alexander Jacobson" writes:

...
On Fri, 22 Apr 2005, Simon Peyton-Jones wrote:

...
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.

If the current Haskell story is that module names are top-level then it is incompatible with the current Cabal story. The current Cabal story is that module names are implicitly qualified by package-ids. Cabal's build-depends tag says that some set of package names are required to interpret enclosed import declarations. In other words, that the import declarations are themselves insufficient to identify the external modules required to interpret the enclosed modules.

This is the case in every language I know of, except perhaps for Java which requires that you prefix your organizational name to your modules. In fact we could do that in Haskell without changing anything.

...
I strongly prefer the current Haskell story to the current Cabal story for reasons enumerated at length in this thread*.

Once again, the current cabal story is not different from the current Haskell story. Please stop saying that. Cabal is layered on Haskell.

Cabal "changes" the interpretation of a Haskell module only in the sense that Make changes the interpretation of a Haskell or C program or that "-i" changes the interpretation of a Haskell or C program. This is obvious, and I agree with it, but the way you keep phrasing it makes me wonder if you understand this.

(snip)

...
* Quick recap of arguments against Cabal:

* namespace issues shouldn't be mixed with physical packaging issues * dev tools operate on source files/directories not packages * Cabal fragility with respect to changes in build-depends tag * Cabal fragility with respect to changes in modules of other packages * incompatibility between unqualified imports and Cabal versioning

These are too vague to respond to (they have already been responded to). But I want to point out that no matter what system you use, if the modules that my module depends on change in a bad way, then my module will break. The only way around this is good software engineering.

peace,

isaac

John Meacham

8:14 p.m.

New subject: Cabal vs Haskell [sic]

On Mon, Apr 25, 2005 at 08:01:56PM -0400, S. Alexander Jacobson wrote:

...

On Sun, 24 Apr 2005, Isaac Jones wrote:

...
Once again, the current cabal story is not different from the current Haskell story. Please stop saying that.

1. The current Haskell story is that the dependencies of a module are the set of modules identified in its import statements.

The haskell report (and hence the haskell language) specifies __nothing__ about how imported module names are actually mapped to code. This has always been left up to implementations. Of course, there is an understanding that implementations should do something sane and most have done something akin to looking up modules in files of the same name and -i statements, but this is not required or specified by the report. This is why comparing haskell to cabal doesn't make sense, cabal is meerly one proposed implementation of behavior that is undefined by Haskell. You can compare Cabal's way of doing things to what specific compilers have done, but not 'Haskell' because 'Haskell' doesn't concern itself with these issues. John -- John Meacham - ⑆repetae.net⑆john⑈

S. Alexander Jacobson

11:54 p.m.

New subject: Cabal vs Haskell [sic]

On Mon, 25 Apr 2005, John Meacham wrote:

...

The haskell report (and hence the haskell language) specifies __nothing__ about how imported module names are actually mapped to code. This has always been left up to implementations. [...] This is why comparing haskell to cabal doesn't make sense, cabal is meerly one proposed implementation of behavior that is undefined by Haskell.

That's what I thought too! But, Malcolm Wallace and Simon Marlow corrected me a few posts back and they are the authors of the spec. They say that, like Haskell, Cabal actually specifies __nothing__ about how imported module names are mapped to code either. Me: My objection to Cabal is that it in fact DOES determine the referent of an import statement (build-depends). Malcolm: I can see why you might object, if that were the case, but Cabal does NOT in fact determine the referent! Cabal is just a convenient way of grouping together the denotational /interface/ of a large bunch of modules. The implementations of those modules can be replaced at any time, provided they still meet the interface. Me: The Cabal spec says "build-depends: [...] a list of packages [..] needed to build this one" Malcolm: "needed to build" tells me which interfaces must be available at compile-time, no more and no less. Simon: Build-depends uses the source-code notion of interface, not the object code. So, build-depends has the same meaning for all compilers.

...

You can compare Cabal's way of doing things to what specific compilers have done, but not 'Haskell' because 'Haskell' doesn't concern itself with these issues.

Yeah Simon Marlow corrected me on this one too. Cabal should be thought of Cabal is part of the Haskell source not its implementation: Me: My fundamental point here is that the meaning of code shouldn't change depending on the location where it is interpreted. [...] Concretely, the meaning of "import Data.List" in a haskell module shouldn't depend on whether the module is on my computer or yours. Simon: You can think of .cabal as part of the source if that helps. It really is part of the source - but implemented and specified as a layer on top of existing language and compiler technology, for convenience and so that we can share the tools. -Alex- ______________________________________________________________ S. Alexander Jacobson tel:917-770-6565 http://alexjacobson.com

...

On Mon, Apr 25, 2005 at 08:01:56PM -0400, S. Alexander Jacobson wrote:

...
On Sun, 24 Apr 2005, Isaac Jones wrote:

...
Once again, the current cabal story is not different from the current Haskell story. Please stop saying that.

1. The current Haskell story is that the dependencies of a module are the set of modules identified in its import statements.

The haskell report (and hence the haskell language) specifies __nothing__ about how imported module names are actually mapped to code. This has always been left up to implementations. Of course, there is an understanding that implementations should do something sane and most have done something akin to looking up modules in files of the same name and -i statements, but this is not required or specified by the report. This is why comparing haskell to cabal doesn't make sense, cabal is meerly one proposed implementation of behavior that is undefined by Haskell.

You can compare Cabal's way of doing things to what specific compilers have done, but not 'Haskell' because 'Haskell' doesn't concern itself with these issues.

John

-- John Meacham - ⑆repetae.net⑆john⑈ _______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

David Roundy

26 Apr 26 Apr

7:15 a.m.

New subject: Cabal vs Haskell [sic]

On Mon, Apr 25, 2005 at 11:54:45PM -0400, S. Alexander Jacobson wrote:

...

Me: My fundamental point here is that the meaning of code shouldn't change depending on the location where it is interpreted. [...] Concretely, the meaning of "import Data.List" in a haskell module shouldn't depend on whether the module is on my computer or yours.

But that has *never* been true. The meaning of import Data.List has always depended on which version of which compiler you've got. And the meaning of an import of a non-standard module (i.e. not included with the compiler) even moreso depends on which versions of that module you have installed, and which compiler flags you use. -- David Roundy http://www.darcs.net

S. Alexander Jacobson

27 Apr 27 Apr

9:58 p.m.

New subject: Cabal vs Haskell [sic]

On Tue, 26 Apr 2005, David Roundy wrote:

...

On Mon, Apr 25, 2005 at 11:54:45PM -0400, S. Alexander Jacobson wrote:

...
Me: My fundamental point here is that the meaning of code shouldn't change depending on the location where it is interpreted. [...] But that has *never* been true. The meaning of import Data.List has always depended on which version of which compiler you've got.

On Tue, 26 Apr 2005, Benjamin Franksen wrote:

...

BTW, I know of no programming language in which module import clauses have a global (world wide) meaning. Resolution of module names in import clauses to actual source or object code is always system or compiler dependent.

Ok, let me be more explicit. The *intensional* meaning of code shouldn't change depending on the location where it is interpreted. e.g. Data.List.sort should always mean "sorting a list" The *extensional* meaning of the code, the implementation, should be at complete disgresion of the user. e.g. whether to implement Data.List.sort as quicksort or insertion sort and with which compiler and on which platform, etc... Note that one and only one implementation of any type/function is allowed per program. So the mapping from meaning to implementation must be program global rather than local to a package/module or you risk incompatibilities. My objection to Cabal is that it either makes the meanings of haskell modules context relative OR it takes implementation choice away from the user/makes it package local (depending on whether build-depends is about meaning or implementation). Isaac proposes that we should modify build-depends to offer a choice from a finite set of implementations. But, my point is that the user should have infinite choice in implementation and that the decision making cannot be package local. The whole build-depends semantic just doesn't belong in Cabal. Effectively, we need less Cabal and more Hackage. Compilers should have access to directory servers that resolve module names to sets of URLs of module implementations. The compiler will select one implementation per module to be shared by all modules that import it. A module implementation make either take the form of Haskell source or a package containing exposing the module. -Alex- ______________________________________________________________ S. Alexander Jacobson tel:917-770-6565 http://alexjacobson.com

Benjamin Franksen

28 Apr 28 Apr

3:25 p.m.

New subject: Cabal vs Haskell [sic]

On Thursday 28 April 2005 03:58, you wrote:

...

On Tue, 26 Apr 2005, David Roundy wrote:

...
On Mon, Apr 25, 2005 at 11:54:45PM -0400, S. Alexander Jacobson wrote:

...
Me: My fundamental point here is that the meaning of code shouldn't change depending on the location where it is interpreted. [...]

But that has *never* been true. The meaning of import Data.List has always depended on which version of which compiler you've got.

On Tue, 26 Apr 2005, Benjamin Franksen wrote:

...
BTW, I know of no programming language in which module import clauses have a global (world wide) meaning. Resolution of module names in import clauses to actual source or object code is always system or compiler dependent.

Ok, let me be more explicit. The *intensional* meaning of code shouldn't change depending on the location where it is interpreted. e.g. Data.List.sort should always mean "sorting a list"

While this sounds like a reasonable expectation, I still don't know of any existing compiler/interpreter/language that enforces conformance of implementations with an intensional meaning. Nor are there languages where the module's /name/, as it appears in an import clause, is associated statically and globally (i.e. world-wide) with such a specification. Surely one could imagine some future system with these (or some of these) properties. But Haskell is and never was such a system. [The Haskell Prelude is one of the very few examples where in fact we have a formal specification [albeit not a complete one, since the IO functions aren't formally specified] and compilers and interpreters are indeed required to conform to this spec. Nevertheless, this is a special situation and conformance is not automatically checkable (apart from testing with random data, that is).] Until we have a way to provide full formal specs and a language in which a module implementation can be automatically checked against such a spec, the meaning of code must be dependent on whatever is installed on the machine that runs resp. compiles the code, however inconvenient this may be in some situations. Apart from that, I can imagine situations where associating module names with specifications in a global (world-wide valid) manner is not even desirable. It could severely limit the evolution of software if local deviations from the global rule aren't allowed. OTOH, if such local deviations are allowed, then the global association of spec with module name cannot be relied upon. Ben

David Brown

4:33 p.m.

New subject: Cabal vs Haskell [sic]

On Thu, 28 Apr 2005 12:25:35 -0700, Benjamin Franksen wrote:

...

While this sounds like a reasonable expectation, I still don't know of any existing compiler/interpreter/language that enforces conformance of implementations with an intensional meaning. Nor are there languages where the module's /name/, as it appears in an import clause, is associated statically and globally (i.e. world-wide) with such a specification.

Eiffel does allow pre-conditions, post-conditions, and invariants to be specified in the interface for a module. Their whole computational model is so different, that I'm not sure how it would apply. Dave

S. Alexander Jacobson

4:46 p.m.

New subject: Cabal vs Haskell [sic]

On Thu, 28 Apr 2005, Benjamin Franksen wrote:

...

While this sounds like a reasonable expectation, I still don't know of any existing compiler/interpreter/language that enforces conformance of implementations with an intensional meaning. Nor are there languages where the module's /name/, as it appears in an import clause, is associated statically and globally (i.e. world-wide) with such a specification.

Of course. By definition, you can't reify intensional meanings (otherwise they would be extensional!). We should think of module names as being like domain names, and module implementations as being like IP addresses. Just as the owner of a domain name determines valid IP addresses for it, the owner of a module name should be able to determine valid implemementations. Just as you can't provide domain name resolution for domain names you don't own, you should not be able to provide module name resolution for module names you don't own. We need a Module Name System analogous to the Domain Name System. Haskell compilers should be able to query a root server to find which MNS server is authoritative for a particular module name. A query to that MNS server should result in URLs for implementations of that module. And we have an existence proof that this sort of system both works and scales reasonably well; the DNS. -Alex- ______________________________________________________________ S. Alexander Jacobson tel:917-770-6565 http://alexjacobson.com On Thu, 28 Apr 2005, Benjamin Franksen wrote:

...

On Thursday 28 April 2005 03:58, you wrote:

...
On Tue, 26 Apr 2005, David Roundy wrote:

...
On Mon, Apr 25, 2005 at 11:54:45PM -0400, S. Alexander Jacobson wrote:

...
Me: My fundamental point here is that the meaning of code shouldn't change depending on the location where it is interpreted. [...]

But that has *never* been true. The meaning of import Data.List has always depended on which version of which compiler you've got.

On Tue, 26 Apr 2005, Benjamin Franksen wrote:

...
BTW, I know of no programming language in which module import clauses have a global (world wide) meaning. Resolution of module names in import clauses to actual source or object code is always system or compiler dependent.

Ok, let me be more explicit. The *intensional* meaning of code shouldn't change depending on the location where it is interpreted. e.g. Data.List.sort should always mean "sorting a list"

While this sounds like a reasonable expectation, I still don't know of any existing compiler/interpreter/language that enforces conformance of implementations with an intensional meaning. Nor are there languages where the module's /name/, as it appears in an import clause, is associated statically and globally (i.e. world-wide) with such a specification.

Surely one could imagine some future system with these (or some of these) properties. But Haskell is and never was such a system.

[The Haskell Prelude is one of the very few examples where in fact we have a formal specification [albeit not a complete one, since the IO functions aren't formally specified] and compilers and interpreters are indeed required to conform to this spec. Nevertheless, this is a special situation and conformance is not automatically checkable (apart from testing with random data, that is).]

Until we have a way to provide full formal specs and a language in which a module implementation can be automatically checked against such a spec, the meaning of code must be dependent on whatever is installed on the machine that runs resp. compiles the code, however inconvenient this may be in some situations.

Apart from that, I can imagine situations where associating module names with specifications in a global (world-wide valid) manner is not even desirable. It could severely limit the evolution of software if local deviations from the global rule aren't allowed. OTOH, if such local deviations are allowed, then the global association of spec with module name cannot be relied upon.

Ben _______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

Benjamin Franksen

26 Apr 26 Apr

3:23 p.m.

New subject: Cabal vs Haskell [sic]

On Tuesday 26 April 2005 05:54, S. Alexander Jacobson wrote:

...

On Mon, 25 Apr 2005, John Meacham wrote:

...
You can compare Cabal's way of doing things to what specific compilers have done, but not 'Haskell' because 'Haskell' doesn't concern itself with these issues.

Yeah Simon Marlow corrected me on this one too. Cabal should be thought of Cabal is part of the Haskell source not its implementation:

Me: My fundamental point here is that the meaning of code shouldn't change depending on the location where it is interpreted. [...] Concretely, the meaning of "import Data.List" in a haskell module shouldn't depend on whether the module is on my computer or yours.

Simon: You can think of .cabal as part of the source if that helps. It really is part of the source - but implemented and specified as a layer on top of existing language and compiler technology, for convenience and so that we can share the tools.

I don't want to take side in this discussion, but this is really nitpicking. Obviously Simon has not meant to say that .cabal is part of the source code in the sense of 'what is in its meaning defined by the Haskell standard'. In fact, it makes sense to think of your Makefile and documentation (and whatever else your package may consist of) as part of the source code, but of course in a wider sense, i.e. one not covered by the language definition. BTW, I know of no programming language in which module import clauses have a global (world wide) meaning. Resolution of module names in import clauses to actual source or object code is always system or compiler dependent. Apart from that, I gebin to wonder if the hierarchical module names were a good idea to start with. Maybe a better solution would have been to delegate resolution of module name conflicts to an external tool, similar to the Lace mechanism in Eiffel. In Eiffel, a program consists of a number of classes, each of which must have a unique name. But with Lace you can not only relate classes to file names, you can also rename conflicting classes (and you can do this for whole 'clusters', if you like, where a cluster is roughly the equivalent of a package). I think this is the superior approach because it gives the end user complete control. Ben

Shae Matijs Erisson

25 Apr 25 Apr

8:21 p.m.

New subject: Cabal vs Haskell [sic]

"S. Alexander Jacobson" writes:

...

4. A set of modules may be dependent on a set of packages if and only if that set of packages is the only set of packages that may contain them.

I don't understand. What does this mean? Modules must be contained by a package to depend on that package?

...

5. Since more than one set of packages may contain the same set of modules, the current Haskell story cannot be consistent with the current Cabal story.

Why can't multiple packages have the same set of modules? -- Programming is the Magic Executable Fridge Poetry, | www.ScannedInAvian.com It is machines made of thought, fueled by ideas. | -- Shae Matijs Erisson

S. Alexander Jacobson

26 Apr 26 Apr

12:50 a.m.

New subject: Cabal vs Haskell [sic]

On Tue, 26 Apr 2005, Shae Matijs Erisson wrote:

...

"S. Alexander Jacobson" writes:

...
4. A set of modules may be dependent on a set of packages if and only if that set of packages is the only set of packages that may contain them.

I don't understand. What does this mean? Modules must be contained by a package to depend on that package?

Package P contains module A. Module A only imports module B. So module A is dependent on itself and access to module B. Package P does not contain a module B, but its build depends tag does identify a set of pacages on which it depends Ps Access to module B is dependent on access to Ps if and only if no other package provides access to module B. The spec says that build-depends identifies the packages "needed to build this one." If packages other than Ps may provide access to module B then the build-depends tag cannot identify the dependencies of module A because Ps are not necessary, only sufficient. Build-depends identifies necessity not sufficiency.

...

...
5. Since more than one set of packages may contain the same set of modules, the current Haskell story cannot be consistent with the current Cabal story.

Why can't multiple packages have the same set of modules?

Exactly! This all started because I had claimed that the Haskell story is that module names identify modules and that the Cabal story is that package names qualify module names to identify modules. If module names fully identify modules then multiple packages may expose the same set of modules. However, if package names qualify module names then, by definition, a module in a different package is a differnt module. I favored the Haskell story, in part, because I believe that multiple packages should be allowed to have the same set of modules. Isaac and Simon Marlow, however denied my interpretation of Cabal. However, this proof shows that Cabal's build-depends doesn't make sense unless only one package may expose a given module and that would be true if and only if package names qualify module names. And, if Cabal requires that package names qualify module names, it is inconsistent with the Haskell story that they don't! -Alex- ______________________________________________________________ S. Alexander Jacobson tel:917-770-6565 http://alexjacobson.com

Isaac Jones

1:32 a.m.

New subject: how to implement optional build-depends <was Cabal vs Haskell [sic]>

"S. Alexander Jacobson" writes: (snip)

...

The spec says that build-depends identifies the packages "needed to build this one."

If packages other than Ps may provide access to module B then the build-depends tag cannot identify the dependencies of module A because Ps are not necessary, only sufficient.

Build-depends identifies necessity not sufficiency.

If that's a big concern, it's easy to fix. I very much hope that the build-depends meaning will be expanded in the future to express more options. Build-depends in Cabal is inspired by Debian build-depends which have a richer syntax. For instance, you can say: Name: Foo Build-Depends: Bar | Bang, Baz I want Cabal to be able to do this some day. It just wasn't the kind of feature we wanted to focus on for Cabal 1.0. If you're very keen for this feature, patches are accepted as usual. It shouldn't be too hard. Tool support for Hackage would probably be a little harder, but not much. So here's what it would probably look like for Cabal: - Write test cases. Not as trivial as it might seem as first since there are a number of environmental issues to take into account. - Alter the Distribution.Version.Dependency type to allow a list of options. - At configure time, you check to see which of the dependencies are present. If none are present, then you can't continue, if more than one is present, then you need some way to choose: Prompt the user, allow configure flags, pick the first in the list, whatever. This will be simlar to how a version is chosen when the build-depends is a version range (already implemented). - Now after this, the rest of the build process is the same. - Write documentation :) For hackage / cabal-get you'd need to perform a similar check to see which packages are installed, and which you want to install before downloading and building the rest of the dependencies. This might make the dependency analysis harder, but not that much (winking at Lemmih). This would possibly cause us to run into the module overlap limitation more often. If it were actually much of a problem, it would probably show up in cases like this, particularly if Bar and Bang don't overlap 100% in their functionality and interface. For now, I'd honestly prefer to leave out optional dependencies until people are clammoring for them. They tend to show up in Debian in cases where two packages serve the same purpose, like mail transfer agents, database back-ends, or Haskell compilers. For the short-term, until Hackage is running smoothly for a little while, I think it's good to keep it simple.

...

...
...
5. Since more than one set of packages may contain the same set of modules, the current Haskell story cannot be consistent with the current Cabal story. Why can't multiple packages have the same set of modules?

Exactly!

Nothing prevents multiple packages from having the same set of modules. We simply can't compile them into a single program. As has been said (many) times already, this is a somewhat difficult engineering task, but not a fundamental limitation. peace, isaac

7327

Age (days ago)

7332

Last active (days ago)

List overview

Download

14 comments

8 participants

participants (8)

Benjamin Franksen
David Brown
David Roundy
Isaac Jones
John Meacham
S. Alexander Jacobson
Shae Matijs Erisson
Simon Marlow

RE: Cabal vs Haskell [sic]

tags

participants (8)