Cabal vs Haskell [sic]

[S. Alexander Jacobson]

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" <alex at alexjacobson.com> 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
>