RE: Summary of current change suggestions
* specifying libraries in the source isn't the right way to go. Library names change independently of APIs, and can be platform-specific.
I like the high level goal this is heading towards and was in complete agreement with implementing it in rules like this until.... I realised that all that Hugs sees is the source (i.e., there's no makefile to put extra compilation info into) - so if it ain't in the source, where is it?
But I like the rule...
Well... there's no reason why hugs couldn't use something like GHC's packages. In fact, it could use the scheme largely unchanged; but perhaps the package spec should be extended to include a path to source files (the alternative is to overload the path to the interface files and put the sources in the same place if you want to share a package between Hugs & GHC). The package spec format is designed to be used with "read" (i.e. it's Haskell syntax), so Hugs could just read it using its built-in parser. Cheers, Simon
On Thu, 22 Feb 2001, Simon Marlow wrote:
The package spec format is designed to be used with "read" (i.e. it's Haskell syntax), so Hugs could just read it using its built-in parser.
The format should be extensible, i.e. adding future fields should not break old code which does not use these fields. IMHO each field which is a list should be allowed to be skipped, defaulting to the empty list. -- Marcin 'Qrczak' Kowalczyk
"Simon Marlow" <simonmar@microsoft.com> wrote,
* specifying libraries in the source isn't the right way to go. Library names change independently of APIs, and can be platform-specific.
I like the high level goal this is heading towards and was in complete agreement with implementing it in rules like this until.... I realised that all that Hugs sees is the source (i.e., there's no makefile to put extra compilation info into) - so if it ain't in the source, where is it?
But I like the rule...
Well... there's no reason why hugs couldn't use something like GHC's packages. In fact, it could use the scheme largely unchanged; but perhaps the package spec should be extended to include a path to source files (the alternative is to overload the path to the interface files and put the sources in the same place if you want to share a package between Hugs & GHC).
I think, a path to source files would be a good idea. Cheers, Manuel
participants (3)
-
Manuel M. T. Chakravarty -
Marcin 'Qrczak' Kowalczyk -
Simon Marlow