From: mmcg@cs.monash.edu.au (Mike  Mc Gaughey)
Subject: Re: Distributed lpmud
Organization: Computer Science, Monash University, Australia
Date: Thu, 17 Dec 1992 10:01:24 GMT

oreillym@tartarus.uwa.edu.au (Michael O'Reilly) writes:

>Just being idlely curious. Is there a method for building countably
>infinite, and un-countably infinite types??

Well, lists are countably infinite aren't they?
Therefore lists of lists are uncountably infinite...

Heh.  No, I don't think so :)

>Correct me if I am wrong then, you could view all types such that
>	type T is an atomic type.
>	       is a set of types T.

Well, you could, but there'd be no point (except from the compiler's
point of view).  `Sets of types' are really just an interpretation of
what's really happening - that is, that your *values* are one of these
types.  If there is more than one type in the set after type checking
the function, your value needs a tag.  Otherwise, it doesn't.

>This is a question I meant to ask a long time ago. How to you
>eliminate tags altogether? I can see eliminateing it in most case but
>what about this...

>	type C is a super-type of D.
>	type B implements the method 'C widgit(void)'
>	type A is a super-type of B. 
>		It override B's defn of widgit with 
>			'D widgit(void)'.

Mmph.  What makes you think that should be possible? :)

There are two issues here: if every object is a type, and most objects
have code in them, there seems to be little difficulty in placing
appropriate type definitions or tags in the object's code definition.
At any time, there are a couple of orders of magnitude more of these
than there are objects - therefore, it *might* be reasonable to simply
treat all object values as 'tagged'.  Assuming you believe in
inheritance, that is :)

The second issue is: what is inheritance? If you type-check a function,
and you *know* that it expects an object of type <snuggle> to be passed
to it, and the caller wants to pass a subtype (you've called this
`supertype' above) of <snuggle>, the caller could simply coerce the
value to the appropriate type before calling the function - i.e.
actually pass the pointer to the sub-object.  This, of course, means
you can't redefine functions in subtypes - I'm still not sure whether
this is reasonable (several O-O languages prohibit this; looking at our
mudlib, we only use such redefinitions in a few places, probably due to
poor design of the original objects).

My current feeling is that being able to redefine functions in subtypes
is either not worth the trouble at all (if you want to be completely
tagless[1]), or is worth allowing the use of tags.  I have put some
thought into a system that allows function redefinition, but it seems,
ultimately, to always lead back to the use of tags (or function
closures, or being able to see all objects at compile time).  Bleagh.

Anyway, this discussion is getting a little too technical for here.
Email is better :)

Mike.

[1] some work I am doing is on taglessness; I thought the mud would
make an appropriate testbed for the ideas.  Otherwise, I'd just say
"fuck it, inheritance is useful" and tag all (code) objects.
--
Mike McGaughey			AARNET:	mmcg@bruce.cs.monash.edu.au

"Head stompin', ass kickin', finger licking nastiness"