Sven Panne wrote:

... and I think it is fine that way, I would even be happy if it had to be the very first line. OPTIONS can change the language (well, at least in parts), so they should be placed in a prominent place. It would be easy to change GHC's behaviour the way you asked for, but this would make things hard for a *human* reader of the source code.

But different people may have different opinions on what should go into the most prominent place in a file. Moreover, there is only one first line, and assuming some kind of language pragma is introduced, and assuming Simon Marlow goes ahead and introduces GHC_OPTIONS, and the other implementors goes ahead and introduces HUGS_OPTIONS, NHC_OPTIONS, etc., insisting on all of these being on the first line is obviously not going to work. Morover, extending the current rule to work in this (as yet hypothetical) setting seems a bit complicated. It seems to me that the easiest would be to count comments (including pragmas) as blank lines, and simply insisting that this kind of pragmas occur before the first non-blkank line. Also, if something like the language pragma is introduced and/or compiler-specific option pragmas in the interest of facilitating writing portable code, then the various Haskell implementation also have to agree on this rule, and making that rule as simple and as intuitive as possible seems like a good idea. All the best, /Henrik -- Henrik Nilsson Yale University Department of Computer Science nilsson@cs.yale.edu

nilsson@cs.yale.edu writes:

Moreover, there is only one first line, and assuming some kind of language pragma is introduced, and assuming Simon Marlow goes ahead and introduces GHC_OPTIONS, and the other implementors goes ahead and introduces HUGS_OPTIONS, NHC_OPTIONS, etc., insisting on all of these being on the first line is obviously not going to work.

As it happens, nhc98 already interprets some pragmas in this manner: {-# OPTIONS_COMPILE #-} and {-# OPTIONS_LINK #-} The former gives options for this module alone, whereas the latter are accumulated when linking several modules together into an executable, to permit for instance a binding to a foreign library to be conveniently expressed in the single place where it is most relevant. However, clearly, there are already two of these pragmas, and as Henrik points out they also cannot both be in the first line! The way nhc98 deals with this is to do a quick and dirty parse of the source file in the driver script (i.e. grep "OPTIONS..." or equivalent), which information is then used to turn on/off language features in the invocation of the compiler proper. Seems easy enough. Regards, Malcolm