December 2002 - Glasgow-haskell-users

Re: Constructors in GHC (fwd)
by Hal Daume III 11 Dec '02

11 Dec '02

...this seemed not to make it to the mailing list (ghc-users(a)haskell.org isn't valid)... -- Hal Daume III "Computer science is no more about computers | hdaume(a)isi.edu 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 <hdaume(a)isi.edu> To: Simon Peyton-Jones <simonpj(a)microsoft.com> Cc: ghc-users(a)haskell.org, Kirsten Chevalier <krc(a)uclink.berkeley.edu> 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.

1 0

Constructors in GHC
by Simon Peyton-Jones 11 Dec '02

11 Dec '02

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

2 1

RE: -hidir separation of search/output paths
by Simon Marlow 11 Dec '02

11 Dec '02

> 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...

1 0

RE: Proposals for changes to searching behaviour
by Simon Marlow 11 Dec '02

11 Dec '02

> 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

1 0

RE: ANNOUNCE: GHC version 5.04.2 released
by Simon Marlow 11 Dec '02

11 Dec '02

> Not sure what happened, but it seems however that > <http://haskell.org/ghc/> was reverted somehow, since it now > only talks about 5.04, there is no longer any mention of > 5.04.2. I moved things around a bit, and forgot to update a couple of links. The 'Download' link on the left contents pane has always pointed to the right place, though. Sorry for the confusion. Cheers, Simon

1 0

Why do not all Syntax elements have a SrcLoc?
by Reto Kramer 11 Dec '02

11 Dec '02

Is there a particular reason why only "top level" AST elements in the Language.Haskell.Syntax libarary have a SrcLoc attribute? It would be very handy for my application to be able to know the src location of each AST element and I was wondering if there was a deeper reason why that's not the case. Also I wonder if other would be interested in an extension that captured the start (line,column) as well as the end (line column) of AST elements (handy for rendering src). - Reto

1 0

Problems with main in a lib*.a. Is that a bug?
by Nicolas Oury 10 Dec '02

10 Dec '02

Hello, 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. The first solution is not convenient as the standard way of getting parameter is "sdl-config" which gives back the second types of argument. -no-hs-main don't change anything on this point. Is there a flag saying ghc not to generate a main? Cheers, Nicolas Oury

2 1

Proposals for changes to searching behaviour
by Simon Marlow 10 Dec '02

10 Dec '02

Hi Folks, Henrik Nillson & I have been discussing the current behaviour of GHC when searching for modules, particularly in combination with hierarchical modules, and have identified two ways in which things might be made more flexible. The current situation forces you to put sources in a directory hierarchy which mirrors the module hierarchy. While simple, this might be inconvenient, and will certainly be painful when the module hierarchy gets deeper. Also, the current situation seems to have caught people out more than once (perhaps that's a documentation problem, though). My own preference is for keeping things as simple as possible, so I'm generally in favour of the status quo - but we always value feedback from our users, so please let us know what you think. Anyway, here's the two suggestions: - The sources for a module A.B.C would be allowed to be placed in either A.B.C.hs or A/B/C.hs relative to one of the directories in the search path. Currently only A/B/C.hs is allowed. This is an easy change to make, and I believe Hugs already does it this way. - 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].' In contrast to the previous suggestion, this would actually save some trips to the OS when GHC is looking for files. Please let us know if either of these would make your life easier, or if there's anything else you'd like to see. Cheers, Simon

6 10

RE: Proposals for changes to searching behaviour
by Simon Marlow 10 Dec '02

10 Dec '02

> > > 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].' > > > > This seems a bit unpredictable to me; it means that you can > > have a whole bunch of unrelated modules sitting together in the > > same directory, and then confuse the user even more with obscure > > GHC commandline switches :). > > First, the point here is to reduce the number of assumptions > built into > a Haskell system about where sources live and what they are called. > The fewer assumptions that are made, the greater the likelyhood that > it will interoperate smoothly with other tools. Try to use the current > mapping from hierarchical module names to file names with the Make > VPATH mechanism for an example of what I mean. I've never quite managed to figure out what VPATH is for; one reason is that I've never got it to cooperate well with automatically-generated dependencies. If there's a specific restriction in GHC that prevents the use of VPATH, could you describe what it is? > > I'd argue that if you have a Graphics.Rendering.OpenGL module, > > you should make it 100% obvious that the module is in > > a Graphics.Rendering category; either putting it in a > > Graphics/Rendering directory or having > > a Graphics.Rendering.OpenGL.hs file makes this explicit. > > I see little merrit in having a Haskell system enforce such rules. It comes down to this: the Haskell system has to find files (normally interface files). Either these files are named according to a simple convention, or you have to tell the compiler more about where they live. You would rather we moved towards the latter position. There's a compromise (well sort of). If you don't need to use --make, then GHC will let you use whatever filenames you like for the sources; the only restriction is that it has to be able to find the interfaces, so you have to arrange they get placed where GHC can find them either by using the -ohi flag or by having the build system move them. 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. Actually, I've just tried this and it almost works. The interface files get put in the current directory and have all but the last component of the module name stripped off, which is fine as long as you don't have any other modules with the same last component. I think perhaps fixing this and documenting the behaviour would be a good step forward. Then would there be any reason to need the other extensions? Cheers, Simon

3 2

Options in hs files; Bug report?
by ketil＠ii.uib.no 10 Dec '02

10 Dec '02

I posted something on haskell@, but perhaps this is a better forum for possible bug reports (I didn't get any replies, at any rate). (Edited severely for brevity and relevance) -kzm -- If I haven't seen further, it is by standing in the footprints of giants

1 0