> > I have nothing against someone promulgating a standard CLI for Haskell compilers,
>but it should not be in the language definition because it is an operating system
>issue, not a language issue. There are many different ways to present an interface to
>programs and data, etc., and CLI is only one of them. No need to mandate one
>particular case in the language definition.
> > Besides, it is difficult to take into account the flexibility that an implementor
>might need or want. I'm not just talking about flags and options. You said yourself
>that this sort of thing doesn't apply to an interpreter, for instance, but an
>interpreter is certainly a valid implementation of the Haskell definition.
> > Finally, I expect that anyone who has sufficient motivation to create a standalone
>executable, rather than simply using an interpreter like Hugs, will be familiar to
>some extent with the compiler CLI we have all inherited from cc.
>
> I strongly disagree with this.
> All Java compilers know how to do "import chasing".
> When a java source file imports a class, the compiler
> searches the classpath for bytecode. If it doesn't find bytecode,
> it searches the srcpath for soure code, and compiles this source into
> valid bytecode, prior to compiling the importing class.
> Java programmers almost never have to use make.
I might remind you that Sun is marketing Java not just as a programming language any
longer, but in fact as a "platform"---in other words, an operating system in itself.
Not that I have anything against Java's way of doing this; on the contrary, I think
it's very convenient. I just don't think it belongs in the language definition.
GHC can do automatic recompilation for you. Do you think this belongs in the standard
report too? Java does. Eiffel does.
How about HUGS' REPL? It's pretty stable and everyone would benefit from knowing that
all future interpreters will share the same interface. Should we standardize that?
LISP does. Scheme does.
How about GHC's interface file format? Should we standardize that? I don't think so.
(On the other hand, I do believe very strongly that Haskell needs support for module
signatures.)
Do I have something against automatic recompilation, REPLs and interfaces files? No.
Do these belong in the language definition? No. Why not? Because they're not
language-level issues, not for Haskell.
> Hugs currently has a notion of search path that encompasses this concept,
> but, because Haskell still lacks a sane module namespace*, managing
> these directories is still a pain.
Fine; then GHC can implement import chasing too. No need to put it in the Report,
though. If it's such a great thing, then every other Haskell implementation will soon
follow anyway. If you want to standardize it, then put it somewhere else, the Haskell
Implementation Report or something. I think such a thing could be very useful,
frankly. It would be a good place to put the new FFI, and the COM/CORBA-Haskell
mappings too. (BTW, another Good Thing would be to standardize the Haskell abstract
syntax as a Haskell type, but this properly belongs in the Library Report, I guess.)
But even then, I have to admit that the notion of equating a module with a file makes
me uneasy. At least, the notion of _mandating_ such an identity does. The whole point
of Haskell is to abstract _away_ from the underlying machine/platform (not subsume it,
like Java); this seems like a step backward.
--FC
