Re: Cabal vs Haskell [sic]

Isaac,

You are free to not use -package and you are free to not use build-depends and only use "-i". Nothing is forced on anyone. All you are saying is that "-package refers to a package."

I am looking for a module resolution mechanism that fulfills all the requirements I posted. Neither Cabal nor -package nor -i nor any combination of them does that. For example, neither individually nor in combination do they allow me to share a naked implementation over the Internet. And they fail on the measures to which I referred earlier as well. If you think some of my requirements don't need to be met that is fine. However, I don't think you can claim that they are.

...

I think they are descriptive of vastly different ways to understand a Haskell program. Under Haskell, the module is the starting point for understanding a program. Under Cabal, the Cabal file is the starting point for understanding a program (e.g. the main-is tag).

No. Under Cabal, the .cabal file is the starting point for understanding a package.

It is Cabal's main-is tag that defines the entry point for interpreting a program rather than Haskell's main function. It is Cabal's build-depends tag that determines the meaning of import statement rather than the Haskell source.

The source code is still plain-old Haskell.

With Cabal, the source code is plain-old Haskell PLUS the plain-old Cabal of the package that encapsulates it. And while I would agree that Cabal is not changing the *syntax* of Haskell source, it is most definitely changing its meaning. Do you seriously want to argue that the two models are equivalent? I think we should keep our eye on the ball here. The existing module resolution mechanisms are inadequate to our needs. Lets focus on building something that meets them. -Alex- ______________________________________________________________ S. Alexander Jacobson tel:917-770-6565 http://alexjacobson.com On Wed, 20 Apr 2005, Isaac Jones wrote:

"S. Alexander Jacobson" writes:

...

...

...

1. It should require minimal work for a user to share an implementation.

...

Unfortunately, our existing module resolver mechanisms are severely inadequate here. Build-depends and -package both violate #1 because they both force users to create packages even to share standalone pure haskell modules.

That's not true. Of course a single standalone pure haskell module or a set of simple modules can just sit in your source tree or elsewhere on the search path, just as they always have.

Neither Build-depends nor -package support finding a naked implementation at an arbitrary location in the filesystem. Both only recognize modules that have been packaged. -i complies with #1, but it violates "the works over the Internet" requirement.

If build-depends or -package somehow took away the "-i" option, then it might be true that "they both force users to create packages even to share standalone pure haskell modules." But that's not the case.

You are free to not use -package and you are free to not use build-depends and only use "-i". Nothing is forced on anyone. All you are saying is that "-package refers to a package."

...

...

Also framing this as a "Cabal vs. Haskell" discussion where you claim that your opinion is the True Haskell Way is both unfair and annoying.

If the names annoy you, please suggest alternatives.

How about the "Cabal / HC-PKG approach vs the Alex Jacobson approach"? It's much less loaded.

...

I think they are descriptive of vastly different ways to understand a Haskell program. Under Haskell, the module is the starting point for understanding a program. Under Cabal, the Cabal file is the starting point for understanding a program (e.g. the main-is tag).

No. Under Cabal, the .cabal file is the starting point for understanding a package. The source code is still plain-old Haskell.

...

...

- Cabal doesn't require any changes or extensions to the Haskell language (it's not Cabal vs. Haskell!)

Yes it does! It requires that you understand Cabal to interpret a Haskell program.

Cabal is layered on top of the language. It doesn't change the language.

(snip)

...

In any case, my goal in this discussion is to spur better understanding of the model. Please do not take any of my comments as a disparagement of any implementation.

I'm not taking it like that. I'm trying to help clarify what I think are mischaracterizations on your part.

peace,

isaac