I have a question about the Main.main naming convention. Would it be a good idea to lift the restriction and allow any module which exports a function main :: IO () to be compiled into a separate binary? You'd need to specify which module should be the top-level module when compiling, of course. Why I'm asking is because I have several Main modules in one directory, in files like Program1.hs, Program2.hs and so on, but all of these claims (and must claim) to be "module Main". Java, for instance, allows any class which has a main method to be used at the top level. Regards, Martin -- Martin Norbäck d95mback@dtek.chalmers.se Kapplandsgatan 40 +46 (0)708 26 33 60 S-414 78 GÖTEBORG http://www.dtek.chalmers.se/~d95mback/ SWEDEN OpenPGP ID: 3FA8580B
Martin Norbäck <d95mback@dtek.chalmers.se> wrote,
I have a question about the Main.main naming convention. Would it be a good idea to lift the restriction and allow any module which exports a function main :: IO () to be compiled into a separate binary?
You'd need to specify which module should be the top-level module when compiling, of course.
Why I'm asking is because I have several Main modules in one directory, in files like Program1.hs, Program2.hs and so on, but all of these claims (and must claim) to be "module Main".
So? That just means that the file name of Program1.hs, Program2.hs, etc will be different from the name of the module that they contain. I think all Haskell systems allow the Main module to be in a file whose name differs from the module name (in contrast to other modules, which need to be found when chasing imports). Cheers, Manuel
I know I wasn't the intended recipient of this question, but I also lament this, so I'll answer for myself.
So? That just means that the file name of Program1.hs, Program2.hs, etc will be different from the name of the module that they contain.
The problem is that often you'll have a library which you import in a lot of programs which you also want to be executable. For example, I have a module: NLP.Vocabulary which provides an abstract interfact to, essentially, a map from strings to unique ids + some other machinery. There are some common operations you want to do only once using vocabularies, for instance, gobble up a bunch of text files and create a vocabulary containing words in those documents or perhaps display the elements of a vocabulary in a list. Thus, you want a main function in this module so that you can do something like (from the unix prompt) % vocabulary -build myfiles* -o myvocabulary but you still want to be able to 'import NLP.Vocabulary' in your Haskell modules. What you have to do is have a seperate 'ManipulateVocabulary' module which basically imports NLP.Vocabulary and has a very short & sweet main function. In this case, that's not a big deal. But I have at least 10 such modules where I am forced to have two modules per concept. Not impossible, but obnoxious. - Hal
tis 2002-09-10 klockan 01.22 skrev Manuel M T Chakravarty:
Martin Norbäck <d95mback@dtek.chalmers.se> wrote,
I have a question about the Main.main naming convention. Would it be a good idea to lift the restriction and allow any module which exports a function main :: IO () to be compiled into a separate binary?
You'd need to specify which module should be the top-level module when compiling, of course.
Why I'm asking is because I have several Main modules in one directory, in files like Program1.hs, Program2.hs and so on, but all of these claims (and must claim) to be "module Main".
So? That just means that the file name of Program1.hs, Program2.hs, etc will be different from the name of the module that they contain. I think all Haskell systems allow the Main module to be in a file whose name differs from the module name (in contrast to other modules, which need to be found when chasing imports).
Well, one reason is that I may very well want to import the module containing main into another module. Another reason is that hdoc will use the name in the module statement instead of the file name, and rightly so, how is it to know what the module name should be, especially if the module is in a directory in a hirarchical module space. It's not a big thing, but I just wonder if there is a reason not to allow any module containg main to be compiled into a program. Regards, Martin
I always thought it would be nice to just have a compiler option '--main Bar.Foo.testFoo' which would just the specified function (assuming it is of the appropriate type) as main. if you leave off the function name, then it is assumed to be main. It would be nice if it worked whether or not the function name was exported, as that would mean when you do not use it as the main, dead-code elimination could dispose of it, although i could see how this might be problematic if you dont want to recompile depending on what --main is set too. Allowing you to specify the function name as well as the module name is important if you dont want lots of functions named main conflicting with each other. John On Tue, Sep 10, 2002 at 09:29:30AM +0200, Martin Norbäck wrote:
tis 2002-09-10 klockan 01.22 skrev Manuel M T Chakravarty:
Martin Norbäck <d95mback@dtek.chalmers.se> wrote,
I have a question about the Main.main naming convention. Would it be a good idea to lift the restriction and allow any module which exports a function main :: IO () to be compiled into a separate binary?
You'd need to specify which module should be the top-level module when compiling, of course.
Why I'm asking is because I have several Main modules in one directory, in files like Program1.hs, Program2.hs and so on, but all of these claims (and must claim) to be "module Main".
So? That just means that the file name of Program1.hs, Program2.hs, etc will be different from the name of the module that they contain. I think all Haskell systems allow the Main module to be in a file whose name differs from the module name (in contrast to other modules, which need to be found when chasing imports).
Well, one reason is that I may very well want to import the module containing main into another module. Another reason is that hdoc will use the name in the module statement instead of the file name, and rightly so, how is it to know what the module name should be, especially if the module is in a directory in a hirarchical module space.
It's not a big thing, but I just wonder if there is a reason not to allow any module containg main to be compiled into a program.
Regards,
Martin
-- --------------------------------------------------------------------------- John Meacham - California Institute of Technology, Alum. - john@foo.net ---------------------------------------------------------------------------
Martin Norbäck <d95mback@dtek.chalmers.se> wrote, | I have a question about the Main.main naming | convention. Would it be a good idea to lift the | restriction and allow any module which exports a | function main :: IO () to be compiled into a separate | binary? : | Why I'm asking is because I have several Main modules | in one directory, in files like Program1.hs, | Program2.hs and so on, but all of these claims (and | must claim) to be "module Main". A work-around is to call these modules Program1, Program2, and then have one extra module in, say, Main.hs: module Main where import qualified ProgramX main = ProgramX.main Of course one can change X to be 1, 2, ... But I agree it seems a somewhat arbitrary restriction. Another such restriction is the fact that any module which is called Main *must* have a function which is called main in it. In combination with the rule that says that any module which is not explicitly named is called Main, this gets very annoying when using an interactive Haskell system such as ghci. (I don't think that Hugs does insists on this.) This restriction will go too if the main module can have whatever name. /Koen.
hi, koen wrote:
... Another such restriction is the fact that any module which is called Main *must* have a function which is called main in it. ... technically a module called Main need not define a function called main. all that is required is that there is a function called main in scope. if there isn't one ghci gives a warning these days, wihch seems quite reasonable.
martin wrote:
... You'd need to specify which module should be the top-level module when compiling, of course. ... by the way, you can get what you want in GHC i think by the follwoing trick (it is a trick however):
#ifndef MAIN_IS_A module A #endif main = print "A" now you can compile it as follows, to get an executable: ghc -cpp -D=MAIN_IS_A A.hs if you want to use it as a library, just omit the -D part. also if you will be doing this a lot it may be a good idea to use the -odir -hidir flgas of GHC. bye iavor -- ================================================== | Iavor S. Diatchki, Ph.D. student | | Department of Computer Science and Engineering | | School of OGI at OHSU | | http://www.cse.ogi.edu/~diatchki | ==================================================
participants (6)
-
Hal Daume III -
Iavor S. Diatchki -
John Meacham -
Koen Claessen -
Manuel M T Chakravarty -
Martin Norbäck