From: oreillym@tartarus.uwa.edu.au (Michael O'Reilly)
Newsgroups: rec.games.mud.lp
Subject: Re: Distributed lpmud
Date: 17 Dec 1992 16:19:19 +0800
Organization: Home
NNTP-Posting-Host: tartarus.uwa.edu.au
X-Newsreader: TIN [version 1.1 PL6]

Mike  Mc Gaughey (mmcg@cs.monash.edu.au) wrote:
: Oh.  Err.  Um, no, generators would have come up (if at all) in a
: different context - I was probably talking about streams (`generator'
: is borrowed from ZF-expression syntax, and is, basically, part of a
: spiffy way to generate sets or lists :)
That sounds better. :)
Whoops. 
Thanks you for clarifying that. 

: I believe I said "if you see a <blah>, you generate an expression
: of type (bleagh|block|blam)" or something - different concept.
Much better. 

: type tree(x) = nil
: 	     + node x tree(x) tree(x)
: 
: type exception = RANGE_CHECK + DIV_BY_0 + ...
: 
: type Int = 1 + 2 + 3 + 4 + ... :)

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

: The context for the coercion of `nil'
: is the "=" function and the possible types of `a' and `nil'.
: Presumably, the type of `a', declared or computed earlier, fixes the
: type of `nil' - if not, the type of the expression is the disjunction
: of all the compatible types, and you have to rely on the context of the
: "=" expression to disambiguate them.

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.

And then ignore the sub-type/super-type bit. Probly a bit theoritical
to be useful.

: >haveing written that, a soluton springs to mind. If you simply define
: >the intersection of the List type and Tree type to be the 'nil' token,
: >then every thing is fine. So the type of 'nil' is (list | Tree).
: 
: Uhh, yes.  There are typechecking difficulties; you have to insist that
: the type of each instance of the value `nil' can be resolved within the
: context of the function or object it appears in (or, effectively, you
: end up having to tag all your values and select appropriate `methods'
: at runtime - assuming that you are worried about eliminating tags!).

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

An object of type A is created and passed to the function 'gidgit'
	D gidgit(B var) {
		return var.widgit();
		}
Question is, how the hell do you work out which widgit function to
call without type tags????? Is this possible with a tagless system?
Discarding tags would be nice (4 bytes per object!!!), but I can't
currently see that you can do it can retain n ice bits like the above.


: See Cardelli & Wegner, "On understanding types, data abstraction, and
: polymorphism", Comp Surv, 17, 4, Dec 1985.  It gives good coverage of
: all this stuff, as well as the idea of treating inheritance (and
: multiple inheritance!) as parameterised polymorphism; beware that the
: type system she describes (with existential types) is undecidable.
Thanks. Will look this up.

: Mike.
Michael
Newsgroups: rec.games.mud.lp