I, Sverker Nilsson wrote:
> > I would claim it has really nothing to do with first-class modules
> > or parameterized modules. They can be simulated by ordinary Haskell
> > data types with named fields.
Lennart Augustsson wrote:
> No they can not. Haskell records do not allow local polymorphism,
> so you have a significant loss of power.
>
OK, I stand corrected. It was not my meaning to say that first-class
modules can in general be replaced by records. I slipped.
What I was trying to say was that they may not be needed for the
solution of the problem with configurable constants like argv. As I
understand first-class modules, they are modules that can be passed
around to functions like any other values.
Ada's (83) packages and subunites are not first-class in this sense.
They are not values. They are fully static. In a restricted sense, one
may call them a little more first-class than the current Haskell
modules, though: Ada packages can be _declared_ at much the same
places as other things like variables, constants etc.
I might like to have the power of fully first class modules in Haskell
for other reasons, like dynamic types for that matter, but the reason I
seem a little negative is that they may be an overkill for at least
the problem we are discussing right now, and therefore, as a practical
matter, they may not be implemented or standardised in Haskell in a
forseeable future. (I like using standardised and widely implemented
things :-)
A more restricted form of improved modules might perhaps be easier to
incorporate in Haskell. Retaining the statically typed Haskell spirit.
My claim was really that already fully static non-first-class packages
and subunits a'la Ada '83 would be enough to solve this argv and other
problems regarding the practical use of Haskell for large software
projects.
I am still interested to hear from you Lennart and others about this.
For example, how difficult it would be to implement the kind of
separate compilation I wrote about in my previous mail. And what other
kind of problems there might be. And if it seems to solve anything
at all... (I wouldn't call this a hack a'la performOnceBeforeMain,
but then again I may be totally out in the blue this time :-)
Sverker Nilsson
