John Meacham
On Wed, Feb 01, 2006 at 09:45:27AM -0800, Isaac Jones wrote:
Do you intend cabal-install to be the main interface to Cabal? That's what Duncan was proposing (and others have suggested) - that we deprecate the use of 'runhaskell Setup.lhs' as the interface to Cabal in favour of a program to do the same.
I don't know if cabal-install should be the main interface or not; I think it's worth experimenting with. As far as I know, I'm the only one who's tried it :)
I very strongly feel that 'cabal-install' should be the main interface to cabal. having Setup.[l]hs files leads to a lot of headache and doesn't gain us anything. (note, I am not saying drop the library, just the need for Setup.* scripts)
I do understand your position as you state it, that you think the Setup scripts cause unnecessary complexity. I think they serve an important purpose that I hope I can explain to you. Maybe you could capture our two arguments on a wiki page somewhere :)
we should add a field to the cabal file:
build-style: simple build-style: make
I am coming around to a certain amount of what you say. I'm leaning toward a scheme something like "if the setup script is there, build it and use it, otherwise use defaultMain." Let's call that the "optional Setup" proposal. This has always been on the table, BTW, and the reason that I resist it is because it's much harder to _add_ a requirement of a setup script than to relax it. The optional Setup proposal helps us get rid of the difficulty of compiling the Setup script (for "simple" systems) in exchange for the difficulty of distributing cabal-install. In fact, distributing runhaskell would basically have the same effect. I think that if we drop the requirement for the Setup scripts, then we'll probably want a build-style field, but I think the values should probably be "simple" and "setup"; maybe "make" and something to represent "main=defaultMainWithHooks defaultUserHooks".
build-style: custom runhaskell Setup.lhs build-style: custom runhaskell MyBuild.hs -c %
You lose me here, I feel like this idea gives up most of the pros we gained by dropping the Setup script.
This makes the simple cases a whole lot easier and less brittle and doesn't lose any functionality.
I would also add
build-prehook: build-posthook: ...
to the cabal file and have cabal-install just fill in those fields in the hook record with the values from the file.
So the build hooks basically all become IO ()? That's rather unsatisfying to me as a functional programmer :) (snip)
<noise>
there is also a philosophical objection to Setup.hs as well as a practical one. turing completeness is a one-way ratchet. once you decide on an arbitrary program rather than having a declarative format then you lose the ability to write meta-tools that analyze your projects in ways that were originally unintended. a program is only good for its one task, you can't look inside it, it is a black box. a declarative format can be parsed and looked at in new and interesting ways. making things programs should always be a last resort. Also, it is kind of passing the buck. we avoid thinking about the hard problems by just saying 'write a custom Setup.hs' to handle it. Of course, the joke is on us since we are the ones using cabal so we are just passing the buck to ourselves. Also, it feels a little embarasing that a functional language wouldn't use a declarative format by default with a program as a last resort.
</noise>
While we're talking philosophy maybe I can let you in on the philosophy behind the Setup script. One problem with domain-specific declarative languages like the .cabal file is that they grow into (ugly) turing complete programming languages. I would prefer to keep cabal rather simple (it's already almost too complex, IMO) and yes, push the complexity into the setup script. You may see it as passing the buck, I see it as allowing the end user to program in a beautiful language for those inevitable turing-tasks. Cabal can and should leverage abstraction where it appears, such as preprocessors and Programs (which it can detect and add nice flags like --with-foo-path= and --with-foo-args=). You did seem to recognize the necessity for escaping to a turing-complete language in your build-style: custom proposal. Indeed, your proposal requires us to bail out to a turing complete language in exactly the same circumstances as the current situation. peace, isaac