> > The report should state the least common denominator interface to
> > command line tools, at least up to relatively simple tasks like
> > compiling a multi-module program (spanning several directories).
> >
> > How about `haskell2 [-I <dirs>] <main module>'?
>
> 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.
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.
The solution I would like to see is to allow users to specify how
"import" converts a foreign file into Haskell types. What I mean by this
user defined import is that you could do things like:
> import java "Foo" -- exposes java class to current module
> import dbSchema "odbc:myServer/myDb" -- exposes database schema in haskell
> import xmlDTD "http://foo.org/myDTD -- expose xmldtd as haskell type
The above are implementations of research by various people on this list.
In this example, they define functions java,dbSchema, and xmlDTD
of type (String -> IO ModuleInterace). I am not sure what this looks like, but
I believe the Hugs/GHC integration project is defining something like this.
Of course we want to cover less exotic things as well:
> import haskell "MyHaskellModule" -- obtain module from search path
> import packageHaskell "MyPackage/MyModule" --obtain module from a MyPacakge
> --subdirectory off of searchpath
In both of these cases the function retrieves the module bytecode or
finds source and compiles it.
One of the big advantages of this approach is that it makes it
ridiculously easy to import from other languages and effectively solves
the missing <someLib> library problem.
-Alex-
* a sane module namespace would allow two different packages to have
modules with the same name.
___________________________________________________________________
S. Alexander Jacobson Shop.Com
1-212-697-0184 voice The Easiest Way To Shop
