Dear Haskellers, Mark Jones writes:
As a solution to that problem, the many-command-line-options scheme described seems quite poor! It's far too tool specific, not particularly scalable, and somewhat troublesome from a software engineering perspective.
I've also been thinking about this, and Mark Jones certainly points out a very real problem that ought to be fixed as soon as posisble. Moreover, as Isaac Jones points out, addressing this problem would also be very helpful in the context of the Library Infrastructure Project. While it is possible to use Make to provide a mechanism that hides the differences between the flags that have to be passed to compilers to enable various languages extensions, this becomes extremely unweildy if flags have to be passed on a per module basis. In any case, the Makefile (or whatever) is arguably the WRONG place for such information. However, I also agree with Simon Marlow's analysis, and I'm not convinced that the module system provides the right mechanism for solving the problem. My main reason is that for readability, I think it is good if each module clearly states what the language used in that module is. I worry that if it were possible to abstract over language extensions (in this case using the module system), it would quickly become very hard for a *human* reader to figure out what extensions that actually are used. When it comes to the syntax for specifying the language extensions, it is, as Simon Marlow suggests, probably most straightforward to use the pragma syntax. But instead of reusing a somewhat archaic command-line syntax for specifying the language extensions, let's opt for something more legible. For example something like: {-# LANGUAGE <specification> #-} where <specification> is one or more (if compatible) of keywords like Haskell98 Pure Haskell 98, no extensions. SharedExtenisons (Haskell02???) A set of agreed-upon extensions implemented by all "major" Haskell systems. RecursiveDo ArrowSyntax TemplateHaskell OverlappingInstances UndecidableInstances FFI Foreign Function Interface MPTC Multi-parameter Type Classes (abbreviations used when three or more words). The OPTION pragma would be used for compiler-specific options, although, in the interest of supporting portable code without having to resort to preprocessing using CPP, maybe it would make sense to provide OPTIONS-GHC OPTIONS-Hugs OPTIONS-NHC ... as well, the idea being that a compiler/interpreter then only would look at options pertinent to itself. /Henrik -- Henrik Nilsson Yale University Department of Computer Science nilsson@cs.yale.edu