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
MPTCMulti-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
[EMAIL PROTECTED]
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell
