[clean-list] Comments on the module system

Marco Kesseler m.wittebrood@mailbox.kun.nl
Fri, 26 Jul 2002 23:09:03 +0200


Hi Maks,

>> 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.

ah, okay, that sounds reasonable.

>> 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.

The following comes to mind:
- dcl files describe the module interface and should be 
human-readable. This probably means that they should include 
interface documentation. I doubt whether machine-generated dcl files 
will meet this goal.
- export statements (and whatever) that drive dcl generation will 
pollute the icl file.
- avoiding code duplication can also be avoided by allowing the 
exported function typedefs to be omitted from the icl file. This is 
consistent with the approach taken for macros and data-types.
- w.r.t. keeping things together: I consider this an IDE issue. There 
is no reason why the IDE would not present the dcl/icl combo as a 
single unit.

>> 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.

I think that it is important to keep together related things too. The 
main question is: what is the relation? One could keep all 
definitions concerning a particular function together. One could also 
keep all exported stuff together as opposed to internal stuff.

These different views are not supported by a simple text editor, but 
they could by a specialised IDE.

>> > ... 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.

Yes, I agree.

regards,
Marco