[clean-list] ADTs for fields in record types, please!

[Marco Kesseler]

>> I do find the "constructors" more clear in this situation, but the 
>> "problem" I have with this, is that the "methods" have to be very 
>> specific in their public signature about what parts of the object 
>> they refer to. In the end, this affects maintainability of the code, 
>> as you have to change the method signatures as soon as they start 
>> taking different object fields as arguments, which should be 
>> irrelevant for the "external" interface.  This problem also exists in 
>> solutions that employ type class constraints: the contraints provide 
>> an interface on an _element_ of the object, not on the object 
>> _itself_ (or is there a way?).
>
>I didn't really understand what you were getting at there.
>Perhaps an example might help to clarify your point.

The main problem is that the "Integer" object below exposes too much 
of its internal types. There should be no reason to tell the outside 
world that inc works on the "i" field like this.

:: Integer = E.i: {
   value	:: i,
 		inc		:: i -> i,
 		print	:: i -> String
 	}

So we end up having to define "wrapper" functions to hide this flaw 
(like the ones you suggested), and this introduces extra work. Things 
would be simpler with objects like the following, as they would allow 
one to specify that they operate on the object they are contained in, 
without reveiling on what fields exactly. Dealing with these fields 
would then become purely a matter of the method itself, not of some 
external wrapper function.

:: Integer = E.i {
		value	:: i,
		inc		:: Integer -> Integer,
		print	:: Integer -> String
	}

If this were possible, it would make wrapper functions far less 
mandatory, and at least a lot simpler. It is also one step closer to 
a public interface that does not mention the value field at all, in 
the same way that abstract types do not mention their implementation.

I think these "little" issues matter a lot for useablility.

regards,
Marco