Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!linus!decvax!harpo!floyd!clyde!ihnp4!inuxc!pur-ee!uiucdcs!parsec!ctvax!uokvax!andree
From: andree@uokvax.UUCP
Newsgroups: net.lang
Subject: Re: Anti-CLU... Anti-Strong-Typing... - (nf)
Message-ID: <4338@uiucdcs.UUCP>
Date: Sun, 4-Dec-83 22:59:44 EST
Article-I.D.: uiucdcs.4338
Posted: Sun Dec  4 22:59:44 1983
Date-Received: Tue, 6-Dec-83 23:13:05 EST
Lines: 35

#R:dartvax:-41100:uokvax:9000008:000:1341
uokvax!andree    Dec  3 14:27:00 1983

It sounds like what mark wants from his typing is something halfway between
C/FORTRAN/Assembler/BCPL/etc and Snobol/LISP/Smalltalk. I.e. - something
that will catch typos, but NOT force you to rebuild a tool for every type
it would be usefull on.

Let me propose the following:

1) A LISP-like expression structure: Everything is a function call.
	To avoid the Lots-of-Insidious-Single-Parens problem, lets
	add syntactic sugar for the common operations, so that
	`a + b' is identical to `add(a, b)'. This should work on
	user-defined types as well as the built-in types.
2) The type-checking gets done at the function call. The call `f(x, y)'
	only compiles if x and y are of the same type, and of a type
	handled by f.
3) The decleration of a function carries the typechecking information.
	A good example could be:

	sort = proc [t: type] (x: array[t])
		where t has lt: proctype (t, t) returns (bool)

	which would declare a function to sort an array of arbitrary type,
	just so the type has an lt (less than) operator.


I like this - which is one of the reasons I started using CLU.
For a better and more complete description of how this works, see
the Springer-Verlag `Lecture Notes in Computer Science', #114:
`CLU Reference Manual' by Barbara Liskov et. al. CLU also has
some other nice mechanisms that aren't in common use.

	<mike