RE: RFC: External library infrastructure
I'd like to throw the following into the pot:
The Hugs and GHC developers work pretty hard to keep the two compilers compatible. For example, the next Hugs release will ship with libraries from the same source tree as GHC uses and the same foreign function interface as GHC and the GHC folk recently gave up a feature they dearly wanted in the foreign function interface in the name of portability.
So as people try to come up with a distribution and build mechanism that will work for GHC, it would be good to think about how that same mechanism would work for Hugs too.
Absolutely. I didn't mean to sound so GHC-centric. It would be great if the same infrastructure supports multiple compilers/interpreters.
For example, an extension of GHC's existing package mechanism might work well because it would be easy for Hugs to extract the pieces it needs and the package mechanism has little irrelevant stuff. In contrast a variation on the existing Makefile system would work poorly because the complexity for the library developer of buying into the infrastructure far exceeds the complexity of the task (which for Hugs is overcoming a few minor platform dependencies using autoconf or the like, building any foreign function interface libraries, and overcoming a few remaining Hugs-GHC incompatabilities).
Could you be more concrete? What extension of the package mechanism did you have in mind? (personally I had in mind a standard autoconf + Makefiles story for the build system, but I'm sure there are better ways). It'll be tricky to balance the requirements of a glorious all-encompassing infrastructure with keeping a low "buy-in" cost (as you put it), but that must be one of the goals or we won't have achieved anything.
We might also want to develop a common testing infrastructure for libraries which, ideally, would work with all compilers.
Right on. I'd like to propose we start from GHC's current testing system. It's a small collection of Python scripts (about 900 lines), and is designed to be compiler-independent, although I haven't used it with anything except GHC yet. Cheers, Simon
Could you be more concrete? What extension of the package mechanism did you have in mind? (personally I had in mind a standard autoconf + Makefiles story for the build system, but I'm sure there are better ways).
I was thinking "add all the things that make packages insufficient to use as an infrastructure" :-) One thing is autoconf support for those doing ffi. We might also want conditionals in package specs (cpp enough?). I don't see Makefiles as part of a cross-compiler story. Rather, I see an enhanced package system that includes a subset of makefile functionality (e.g., Hugs' import chasing and GHC's --make functionality). It would be good to have a portable way of specifying most compiler flags which affect language features. For example, features = {FFI, MPTC} would be translated into -ffi and <whatever> for GHC and -98 for Hugs and would trigger an error in NHC which lacks MPTC. Flags would only be standardized as we agree on them and there's be a way to provide flags in a compiler-specific way to deal with the rest.
We might also want to develop a common testing infrastructure for libraries which, ideally, would work with all compilers.
Right on. I'd like to propose we start from GHC's current testing system. It's a small collection of Python scripts (about 900 lines), and is designed to be compiler-independent, although I haven't used it with anything except GHC yet.
That sounds good. I think we already plan (but haven't scheduled :-)) to do that for the compiler testing side so hopefully a more widely useful library testing system could come out of it? -- Alastair
On Tue, Nov 12, 2002 at 05:56:13PM -0000, Simon Marlow wrote:
Absolutely. I didn't mean to sound so GHC-centric. It would be great if the same infrastructure supports multiple compilers/interpreters.
On the other hand, my impression is that if someone did something that worked with GHC it would be fairly easy to adapt to Hugs, probably with a script that preprocessed a tree of modules. The exception is modules that need extra command-line arguments, particularly FFI modules. For those, Hugs needs a mechanism to set options on a per-file and per-hierarchy basis.
On Tue, Nov 12, 2002 at 05:56:13PM -0000, Simon Marlow wrote:
Absolutely. I didn't mean to sound so GHC-centric. It would be great if the same infrastructure supports multiple compilers/interpreters.
Ross Paterson
On the other hand, my impression is that if someone did something that worked with GHC it would be fairly easy to adapt to Hugs, probably with a script that preprocessed a tree of modules. The exception is modules that need extra command-line arguments, particularly FFI modules. For those, Hugs needs a mechanism to set options on a per-file and per-hierarchy basis.
I think adding a package like mechanism to Hugs would (or, at least, could): 1) Provide a place to put those extra ffi flags. 2) Make it easier to distribute Hugs packages. Instead of editing your HUGSFLAGS environment variable you run pkg-add (or whatever). 3) By having a single file (the package description file) containing a single copy of all the information needed by any compiler, we might make it easier to maintain libraries such that they 'just work' on all compilers instead of requiring the writer or interested parties to maintain multiple copies of what is, essentially, the same information. Obviously, the 3rd reason is the one of most relevance to this thread. -- Alastair Reid alastair@reid-consulting-uk.ltd.uk Reid Consulting (UK) Limited http://www.reid-consulting-uk.ltd.uk/alastair/
Alastair Reid
3) By having a single file (the package description file) containing a single copy of all the information needed by any compiler, we might make it easier to maintain libraries such that they 'just work' on all compilers instead of requiring the writer or interested parties to maintain multiple copies of what is, essentially, the same information.
Obviously, the 3rd reason is the one of most relevance to this thread.
Indeed, the idea of being able to just install a package for ghc, nhc or hugs and use it sounds very attractive indeed. Jens
participants (4)
-
Alastair Reid -
Jens Petersen -
Ross Paterson -
Simon Marlow