misc type comments

[Alan Grover]

Rinus Wrote:

>>Clean provides a type synonym construct, but this does not provide distinct
>>types thus inhibiting overloading.
>
>In general it is not sound to allow type synonyms as instantiation of
>overloaded  >functions. Therefore we do not allow it.

I'm not sure we understand each other on this. I wasn't advocating type
synonyms. I want real types that aren't algebraic so I can do things like:

Have an OSType (4 characters on the Mac), perform String operations on it,
and provide overloaded functions that distinguish between String and
OSType. Obviously I could create an algebraic type, but then I'd have to
duplicate all the String functions. Also, it is a system structure and the
natural Clean mapping is to String.

I respect your expertise, as it it clearly much greater than mine in this
area, and I don't think it is your job to educate me. Please take these
comments in the spirit of improvement (as you seem to do anyway):

Clean would not be expected to figure out that an existing object was of
the new type. The semantics should be the same as for algebraic types.
Thus, a four character string is not an OSType unless it was constructed as
that type. Obviously there needs to be a constructor, I would suggest
something analogous to algebraic types (would this be confusing?):

// please forgive type annotations, I've been away from Clean for awhile
:: OSType = {#char,#char,#char,#char};

// constructing an object
	...
	OSType "APPL";	// just like algebraic style

I would guess that IF an object were typed, the type system would naturally
do the right thing for overloading, etc, at least as far as regards that
type. Since I'm asking for the type system to also recognize that the type
is a subclass, the type system would have to be extended for this notion of
subclass. I think Clean doesn't do that (version 1.2, anyway, though
consider "list of some type" and "list of ints"). From what I've seen,
single inheritance has no complications for resolving overloading
(dispatch, whatever).


---
"Alan Grover, Technical Pb" awgrover@umich.edu
+1 (743) 647-5778
Project Leader
Health Media Research Lab, Cancer Center
5D04 North Ingalls Building, Mail Stop 0471
300 North Ingalls
Ann Arbor, MI 48109-0471