Scripts are tidy, since they're also a source file and you don't have to worry about keeping a separate binary executable up to date. I'm sure this topic has been well discussed on the vast internet. For instance, look at Setup.hs in Cabal. That could be called a script, because it is rarely compiled, although it doesn't have the advantage of being executable via the kernel, which most other scripts on Unix do. Perhaps another important attribute of scripts is that they, or at least the executable ones, contain instructions for running themselves - one doesn't have to read through documentation to figure out which command to pass the file to, in order to make it do something useful. I think the popularity of scripts is due to the combination of these two features: a script is a source file, and it is self-describing in a way that the operating system can "understand". Frederik On Wed, Mar 14, 2007 at 08:58:33PM +0000, Seth Kurtzberg wrote:

I compile the programs, instead of trying to run them as scripts. Is there any reason you prefer to interpret the scripts? I'm not saying it's not a legitimate thing to do, just wondering why you prefer to do it that way.

Seth Kurtzberg

On Wed, 14 Mar 2007 19:31:55 +0000 Frederik Eaton wrote:

...

Hello,

What is the proper technique for creating a Haskell script on a Unix system?

e.g. with Perl I do

#!/bin/sh echo DEFANGED.348224 exit #!/usr/bin/env perl print "hello world\n";

or

#!/usr/bin/perl print "hello world\n";

I tried

$ cat test #!/usr/bin/env runhaskell module Main where main = do putStrLn "hello world"

But that doesn't work:

$ ./test Warning: ignoring unrecognised input `./test'

<interactive>:1:73: Failed to load interface for `Main': Use -v to see a list of the files searched for.

When I use "runghc" I get the same error.

If I change the first line to "-x hs" then the error is:

ghc-6.6: unrecognised flags: -x hs Usage: For basic information, try the `--help' option.

because the #! mechanism only allows a single argument. Thoughts?

Thanks,

Frederik

-- http://ofb.net/~frederik/ _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

-- http://ofb.net/~frederik/

Hello Frederik, Thursday, March 15, 2007, 2:22:19 PM, you wrote: we should ask GHC developers. the problem is that runghc understands only hs and lhs extensions and i don't know how to force it to accept other ones

Is there an alternative? I try not to couple interface with implementation, and since not everything I write is in Haskell that is an aspect of the implementation.

On Thu, Mar 15, 2007 at 12:16:09AM +0300, Bulat Ziganshin wrote:

...

Hello Frederik,

Wednesday, March 14, 2007, 10:31:55 PM, you wrote:

...

What is the proper technique for creating a Haskell script on a Unix system?

try to give them a .hs extension :)

-- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

-- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

FWIW, I used to employ a combination of environment vars and registry entries (for file associations) on Windows in order to be able to work with multiple GHC versions. The environment vars (e.g. for PATH or LIB inclusion) would all depend on a GHC_HOME var, which could be redefined to point to the GHC installation du jour. I am not sure how much common structure there would be among installations of GHC, NHC, HUGS, etc., but maybe the same thing could still work, possibly with some tweaks. Cheers, Dinko On 3/15/07, Sven Panne wrote:

On Thursday 15 March 2007 10:56, Malcolm Wallace wrote:

...

[...] If you install hmake, and change 'runhaskell' to runhs, it works.

This reminds me of something, at least for the Linux world: No Haskell compiler/interpreter should directly install 'runhaskell'. Instead of that, it should only directly install runghc, runhugs, runnhc, ... and use update-alternatives (or a similar technology for that platform) to inform the native package system that there is a new alternative for 'runhaskell'. Similar reasoning holds for cpphs, hsc2hs and friends. I'll update the .spec files accordingly soon.

Doing it that way, the local sysadmin has the choice to configure which Haskell implementation is the default and several versions of the same implementation could be installed side by side.

I don't have a clue how to do this correctly for Mac OS X and Windows, though. And 'runhs' is actually not a very good name to run nhc98, runnhc or runnhc98 would be much better IMHO.

Cheers, S.

On Thursday 15 March 2007 15:27, Malcolm Wallace wrote:

Sven Panne wrote:

...

And 'runhs' is actually not a very good name to run nhc98, runnhc or runnhc98 would be much better IMHO.

Well, I chose 'runhs', because it can equally well invoke ghc, hbc, yhc nhc98, or whatever. It is an extension of hmake, which is compiler-independent. You can configure which compiler get invoked by fiddling with your hmake-config options.

OK, I didn't know that. Then it's actually a home-grown special solution for the general problem update-alternatives is trying to solve. I propose to leave runhs as it is for now because of legacy reasons (perhaps deprecate it in the docs?), install a runnhc (or runnhc98? Same question for runhugs, as the corresponding executable is called hugs98. Hmmm...) in addition, and use update-alternatives in the .spec file. Making Haskell implementations behave more consistently would definitely improve the user experience. For those not knowing what I'm talking about, I've digged up a nice blog about update alternatives: http://blog.stevenkroon.com/2006/08/29/debian-update-alternatives/1/ Although this article talks about Debian only, update-alternatives is used on openSUSE and Fedora as well, and probably other *nix platforms. Cheers, S.