Re: Problems with main in a lib*.a. Is that a bug?
On Tue, Dec 10, 2002 at 05:25:46PM +0100, Nicolas Oury wrote: but when I write ghc -o test Main.hs -lSDLmain, ghc creates its own main, and it doesn't work. Probably a stupid question, but if SDL supplies its own main function, then you don't have to put your functions in a module called Main ...? (i.e. rename your Main module to something else random, like Foo) -- #ozone/algorithm [EMAIL PROTECTED] - trust.in.love.to.save ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: Proposals for changes to searching behaviour
The suggested changes sound hard to understand and to implement consistently in all compilers. I lean towards leaving the spec as it is. Hmm, I'm not sure why you say these changes are hard to understand. Which part(s) in particular do you find difficult? Hugs already implements the first suggestion. IIRC, the current Hugs semantics is a complex balancing act intended to achieve backward compatability and implement module paths at the same time. I'd prefer to see everyone switch over to the new way so that we can drop old features. Johan and I discussed the current search semantics when it was implemented in Hugs, so that we could make GHC(i) and Hugs agree. I believe they currently agree on all but the point I made in my first suggestion. There were two features in Hugs that could be considered backwards compatibility: Hugs allowed a module M to be placed in the file M (no extension), and Hugs allowed an import declaration to give a filename rather than a module name. I thought both these features were gone, but I just checked and the first seems to be still present in the Hugs Nov 2002 release. Cheers, Simon ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: -hidir separation of search/output paths
Oops, one more request which I almost forgot: -hidir currently specifies both where to search for .hi files, and where to output hi files. It would be good to split up the two operations into two distinct options; e.g. use -hidir to search for interface files, and a new option such as -ohidir to specify where to output new interface files. This is very useful if you're trying to build stuff (with --make) outside of the source tree: you could write -i$src/SomeLibrary to tell GHC to find the .hs files in a directory named $src/SomeLibrary, -hidir$build/SomeLibrary to find the .hi files in a directory named $build/SomeLibrary, and -ohidir . to tell GHC to output any .hi files to the current directory Urk! I'm really not sure that we need yet another option that further complicates the behaviour. You don't say whether you're using --make/GHCi or one-shot (ghc -c) mode. This makes a difference to the search behaviour: the former searches for source files, whereas the latter searches for interface files along the search path. One-shot mode tends to be more flexible with respect to the naming of files, so if you want to separate your source files from your interface files or give the source files non-standard names, then one-shot is usually the way to go. If you have pre-built libraries that you don't want to recompile, the proper way is to make it into a package. GHC maintains recompilation information within a package only, and assumes that all packages except the home package are fully up to date. Cheers, Simon I think I should try to write down a precise description of GHC's file searching behaviour so we can discuss changes more easily... ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: -no-hs-main behaviour
On Tue, Dec 10, 2002 at 10:35:22AM -, Simon Marlow wrote: Even if you do need to use --make or GHCi, then I think you can still specify all the source files on the command line. While on the subject of GHC's build options, can we change the behaviour of -no-hs-main when it's used with --make? Currently, if you use --make and GHC finds a main function, it will attempt to link all the modules together to produce an executable -- even if you specify -no-hs-main. Is it possible to modify the behaviour so that if --make -no-hs-main is specified, GHC won't perform the link if it finds a main function? I think we should probably just have a -no-link option rather than overload the behaviour of the -no-hs-main option. Cheers, Simon ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Constructors in GHC
This message is to air a possible change in the way GHC handles constructors. Before I make the change I want to check that it isn't going to mess anyone up. There's some background in http://www.cse.unsw.edu.au/~chak/haskell/ghc/comm/the-beast/data-types.h tml Consider the following data T = MkT !(Int,Int) f x y = MkT (x,y) g (MkT (x,y)) = x If you compile this with -funbox-strict-fields, GHC will unbox the strict pair, to give effectively this data T = MkT Int Int f x y = MkT x y g t = case t of MkT x y - x Rather than find all the applications of MkT, it actually *defines* MkT like this MkT p = case p of (x,y) - $wMkT x y where $wMkT is the real constructor. So the real data type is data T = $wMkT Int Int and MkT is just a wrapper function. However in Core-language case expressions we still print 'MkT': g t = case t of MkT a b - ... even though the real constructor is $wMkT. (On the face of it, MkT a b isn't even well typed.) This is a bit of a mess, especially when we print External Core. Then we get data T = MkT Int Int MkT p = case p of (x,y) - $wMkT x y f x y = $wMkT x y g t = case t of MkT x y - x Strange! MkT looks like the constructor for T, but is also given a definition; and $wMkT doesn't seem to be defined at all. This gives rise to difficulties when reading External Core back in. We could make this more consistent in two ways. Alternative (A): One way would be to make it clearer that $wMkT was the real constructor: data T = $wMkT Int Int MkT p = case p of (x,y) - $wMkT x y f x y = $wMkT x y g t = case t of $wMkT x y - x This is consistent, but it makes External Core a bit funny. (The real constructors are always $w things.) Alternative (B): The other alternative would be to make the original Haskell constructors into the $w things: data T = MkT Int Int $wMkT p = case p of (x,y) - MkT x y f x y = MkT x y g t = case t of MkT x y - x This makes Core (and External Core) nice and consistent, with traditional upper-case constructors, but MkT now has a different type than in the original program. We'd need to take care when printing type errors etc that we didn't print $wMkT when the programmer expected MkT. (That isn't too hard.) Personally, I'm inclined to alternative (B). Do any of you have an opinion? Especially folk using External Core? Simon ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Constructors in GHC
On Wed, Dec 11, 2002 at 11:40:39AM -, Simon Peyton-Jones wrote: We could make this more consistent in two ways. Alternative (A): One way would be to make it clearer that $wMkT was the real constructor: data T = $wMkT Int Int MkT p = case p of (x,y) - $wMkT x y f x y = $wMkT x y g t = case t of $wMkT x y - x This is consistent, but it makes External Core a bit funny. (The real constructors are always $w things.) Speaking as a common user who hasn't used External Core for anything, this one looks much more attractive to me. Consistency and predictable typing is important, and it's ok for things to look funny because, after all, funny things _are_ going on when special optimizations are applied. Lauri Alanko [EMAIL PROTECTED] ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Constructors in GHC (fwd)
...this seemed not to make it to the mailing list ([EMAIL PROTECTED] isn't valid)... -- Hal Daume III Computer science is no more about computers| [EMAIL PROTECTED] than astronomy is about telescopes. -Dijkstra | www.isi.edu/~hdaume -- Forwarded message -- Date: Wed, 11 Dec 2002 08:33:50 -0800 (PST) From: Hal Daume III [EMAIL PROTECTED] To: Simon Peyton-Jones [EMAIL PROTECTED] Cc: [EMAIL PROTECTED], Kirsten Chevalier [EMAIL PROTECTED] Subject: Re: Constructors in GHC Hi, It finally makes sense now :) We could make this more consistent in two ways. Alternative (A): One way would be to make it clearer that $wMkT was the real constructor: data T = $wMkT Int Int MkT p = case p of (x,y) - $wMkT x y f x y = $wMkT x y g t = case t of $wMkT x y - x Alternative (B): The other alternative would be to make the original Haskell constructors into the $w things: data T = MkT Int Int $wMkT p = case p of (x,y) - MkT x y f x y = MkT x y g t = case t of MkT x y - x As someone using external core, I can resoundly say: I don't really care :). I would probably prefer (B), as you seem to, but it's not a strong preference. ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Problems with main in a lib*.a. Is that a bug?
Ok, I have made a ghc -vand see the problem : * on OS X, a SDL program must have a main function supplied by a lib : libSDLmain.a * This is achieved by adding -lSDLmain at the command line. * libHSrts.a supply a main. My program is linked against this lib by a -lHSrts. ld is called by ghc with args : [...] lHSrts [...] -lSDLmain [...] mostly, I think, because S is greater than H. (-l args are in alphabetical order) But, after linking the object, ld seek for a main function. And find first the main function in libHSrts.a. And the main needed by SDL is not used. And my test program crashes. In fact, it would be better to really link with libHSrts.a at last (e.g. after all other -l args). and not only after objetcs and mixed with other -l args. Cheers, Nicolas. I am building a SDL binding on MacOS X (but the same problem should appears on Windows). It defines it's own main function in a libSDLmain.a. But I can't get ghc not to generate a main when linking with -lSDLmain, which is the option that is indicated to get the main function that make SDL usable. when I link write : ghc -o test Main.hs libSDLmain.a , ghc doesn't generate a main as it can see there is a main in libSDLmain. And my test programs works. but when I write ghc -o test Main.hs -lSDLmain, ghc creates its own main, and it doesn't work. Could you give more details? What is the error message? GHC doesn't generate main, there's a main function in libHSrts.a which is linked in last, so that you can override it with your own. You should probably use -no-hs-main, too, otherwise the linker will require that Main.main exists in the Haskell code. Cheers, Simon ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Proposals for changes to searching behaviour
Simon Marlow wrote: - We could provide the ability to specify a module prefix to associate with a directory in the search path. For example, you could say that the directory '.' is associated with the module prefix Graphics.Rendering.OpenGL and avoid having to place your sources in the directory Graphics/Rendering/OpenGL. I'm not sure what syntax we'd use for this. Henrik suggested placing the module prefix in square brackets before the directory, eg. ghc -i '-i[Graphics.Rendering.OpenGL].' Does that mean I can refer to X.hs as [Graphics.Rendering.OpenGL(.Graphics.Rendering.OpenGL)*/]X.hs ?-) Probably no problem with Haskell's explicit imports. Good point, which should be cleared up. We don't intend GHC to have any knowledge of relative pathnames and the meaning of '.' or '..'. So the meaning of an import path [Graphics.Rendering.OpenGL]D would be simply this: when looking for a module's source/interface, if the module name is of the form Graphics.Rendering.OpenGL.M, then we look for D/M.hs. If it doesn't exist, we move on to the next entry in the search path. One comment relating to this potential new syntax: this is the exact syntax used for filesystem paths in [Open]VMS. I believe VMS paths look like this: DISK:[dir.subdir.subdir]filename.ext, and I think the DISK: part is optional. So, if you should ever want to port GHC to OpenVMS (I believe it is a POSIX compliant system), you might regret this particular choice of syntax. Also, programmers familiar with VMS might be confused by the syntax. My 2ยข: I would personally prefer not to change the import path syntax and go with the other suggestion: allow directories named X.Y.Z. It would be easy just to say -i D and make a directory D/Graphics.Rendering.OpenGL/ with the modules inside it. Also it keeps module hierarchy apparent in the directory structure, rather than being buried in a Makefile somewhere. Regards, Matt Harden ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
