[clean-list] Comments on the module system

[Maks Verver]

Hi Marco.

On Friday 26 July 2002 17:17, Marco Kesseler wrote:
> I find the possibilty to omit definitions from the implementation
> module VERY useful. Not so much for new modules, as then things
> mostly proceed as you describe above, but rather for existing ones
> that get modified. I am VERY glad that I don't have to modify things
> twice anymore.

I agree that it is better this way, but I think it is not enough. You pointed 
out that it is a good thing to place type definitions only in one file, so 
you only have to modify them in one place when they are modified. For the 
exact same reason, I'd like to see function definitions in a single place as 
well.

> A machine does not know which definitions you want to make publicly
> known. It also does not know which types need to be abstract.

I acknowledge that it is important to keep the public and private parts of a 
library separated, but I think it is even more important to keep related 
information in the same place.

It would not be hard to introduce a keyword/symbol to indicate that a certain 
definition is to be exported. This would certainly make things work a bit 
more consistently than the way it works now (ie. type definitions may be 
omitted, but function definitions must be repeated), which is a good thing as 
well.

> Having separate dcl and icl files at least makes it possible to
> release a binary version of a module.

I don't think compiler-generated dcl files would make this any harder.

> I think it makes sense to have implementation and interface
> documentation separated. It may not always be easy, but it is important.

As I said earlier, it is a tradeoff between seperating implementation and 
interface and keeping together related stuff. I think the latter is more 
important, but that's just my point of view.

> > ... prevent common errors that result from function definitions
> >not matching their implementation.
>
> The compiler will inform you, so what errors do you mean?
>
> >This is now possible, but makes no sense since it could never work.
>
> I do not understand this sentence.

What I meant to say, is that there is no point in being able to give a 
different definition of a function in the declaration and implementation 
files. They MUST be the same (and the compiler does indeed guarantee this), 
so why should I copy them? If they MUST be the same, the compiler could have 
'derived' the second one.

I think you must agree that it is nothing but annoying to be forced to update 
a modified function in two places, as this was your main point as well. 
Ofcourse, it's not a very important property of a functional programming 
language, but since the discussion arose and Clean is still in a state of 
development, I thought it would be useful to at least point it out.

Kind regards,
Maks Verver.