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) we should add a field to the cabal file: build-style: simple build-style: make build-style: custom runhaskell Setup.lhs build-style: custom runhaskell MyBuild.hs -c % where custom will just run its value passing through arguments to it. '%' should be filled in with the name of the current cabal file so it need not be seperatly specified to your custom handler. 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.

...

Certainly there doesn't seem much point in having *both* cabal-install and another wrapper, so clearly they should be the same thing. I do think this is the way to go, though.

You think we should move away from saying that "setup" is the interface? Would we start distributing cabal-install w/ the compilers, or expect users to install it on their own?

I definitly think cabal-install should be an independent project on its own. it should also come with the 'runhaskell' script that has the logic currently in cabal-install to choose an appropriate runghc vs runhugs vs runjhc as appropriate since that makes sense also as a compiler independent project and distributing it with cabal-install seems like a natural choice. (especially since the logic is already implemented in there)

A better solution might be to work hard on stabalizing the interface. I would like to try to stabalize cabal and move future development into layered tools.

these are laudable goals, but seem somewhat independent. We need a working cabal-install now. we can easily start building better tools on top of it then since for 90% of projects it will already be feature complete. <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> John -- John Meacham - ⑆repetae.net⑆john⑈

On Wed, Feb 01, 2006 at 08:52:16PM -0800, Isaac Jones wrote:

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.

it is because a user might want to use something other than runhaskell Setup.hs (which appears to be what you mean by the 'setup' option) as their custom build system. build-style: setup would be equivalent to build-style: custom runhaskell Setup.hs for backwards compatability cabal files without a build-style field would be interpreted as build-style: setup I never wanted to disallow Setup.hs, but it should not be the required way to do things.

...

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 :)

arn't a lot of them IO ExitCode anyway? that is because we probably expect a lot of them to just be System.system "foo". it seems like a very natural thing to add. like I said, the library exists, but for something as simple as hooks that just call programs, it should not be needed when cabal-install can take care of it.

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.

it is forcing them to. which is bad. no matter how beautiful haskell is. Quadruply especially so since it does not gain you anything. since it is not needed. I don't see cabal files becoming anywhere near turing complete. then it wouldn't be declarative (at least in the sense I mean). at most, string interpolation will be the only operation on its fields. I am actually trying to simplify cabal a lot with these changes. a program is hugely simpler than a library. Just from a maintenence point of view, must of the issues dealing with syncing cabal and ghc releases, cabal library version changes, etc would just have never been issues. what about multiple compilers and keeping your cabal installs in sync among all of them? it is just a big mess. not to mention how much simpler cabal development will be once it is decoupled from the compiler libraries and can evolve independently.

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.

no, in the current situation you have no _choice_ but to bail out into a turing complete langauge. which will promptly be used to get back into a standard library most of the time which has already been linked into the executable that bailed you into the turing language to begin with. it really seems silly. especially when there are so many pitfalls. I really don't see how it can be considered a good idea to force a users hand when you don't have to, and can simplify things in the process. at least with a build-style: option then meta-tools can look and imediatly know which packages it needs to handle specially. you don't even have that option if everything is _required_ to use a program. A program that can modify arbitrary things at that. want to build the program as a user and then just do the install as root? well you are going to be running arbitrary user code as root since you need to to do a runhaskell Setup.hs install. rather than having to audit every program you install, you just need to look at the ones with install-hooks. Easy things easy and hard things possible. making cabal a library definitly makes easy things possible, but certainly not easy. John -- John Meacham - ⑆repetae.net⑆john⑈

I haven't been following this closely, but I think I have to agree with Isaac on this point. To me it seems that the .cabal language is already Turing complete in the sense that one can get it do anything by writing to the Haskell mailing lists. That's neither efficient for the users, nor for Isaac. (However, I do think it would be much nicer if one could use say "cabal-setup" or just "cabal" instead of "runhaskell Setup.hs"...)

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 _______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries