Why do not all Syntax elements have a SrcLoc?

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 c

Re: ANNOUNCE: GHC version 5.04.2 released

Manuel M T Chakravarty <[EMAIL PROTECTED]> writes: > RPMs built on Red Hat 8.0 are now available from > > ftp://ftp.cse.unsw.edu.au/pub/users/chak/jibunmaki/i386/ghc-5.04.2-1.i386.rpm Thank you very much. Just found them on haskell.org too (they're in

Re: Proposals for changes to searching behaviour

Hi Alastair! > The suggested changes sound hard to understand and to implement > consistently in all compilers. I lean towards leaving the spec as it > is. I think they're pretty straightforward, actually. Coudl you elaborate on why it seems complicated to you? As to implementation, I can't im

Re: Proposals for changes to searching behaviour

Hi Simon, CC Glasgow-Haskell-Users > 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. As long as one uses automatic variables in all commands, it seems to work fine. Well, I have at leas

Problems with main in a lib*.a. Is that a bug?

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

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

Options in hs files; Bug report?

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 --- Begin Message --- [...] Talking about warnings, it is probably patently stupid to put {-# OPTIONS

-hidir separation of search/output paths

On Tue, Dec 10, 2002 at 10:15:58PM +1100, Andre Pang wrote: > 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? Oops, one more request which I almost forgot: -hidir currently specifies both where to searc

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

RE: Libraries needing a main and ghci

> I am doing a small binding to SDL lib. It needs on some platforms to > have a C main function. > > So I make a C main that call Haskell initialisation, Haskell > main and > call shutdownHaskell. > > It works fine with ghc. > > When linking with ghci I have an error : > > > ghci -packag

RE: Proposals for changes to searching behaviour

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

RE: Proposals for changes to searching behaviour

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

RE: Ticky-ticky profiling?

You need to cd into fptools/libraries, and say 'make way=t'. (The "way" stuff is described in the building guide. Better still, set GhcLibWays=t to your build.mk file.) This will build a library tree with flag -ticky, which is what you need. You do need to build from source to do this. Simon