OOP

[Richard A. O'Keefe]

OOP is all very well, but it's worth bearing in mind that there are at least
two audiences for something like Clean:
	- people who want to extend the technology
	- people who want to USE the technology

I'm going to be teaching a functional programming course next year.
What I'll need for that is something which
 - is _supported_ on UNIX and ideally NextStep as well as MacOS
 - is _robust_; it should *never* be possible to get a GPF, Blue Screen,
   core dump, or whatever from a program *unless* the programmer has
   explicitly switched *off* some check.
Also, for credibility, it helps if all the neat features described in the
manual (like safe destructive update) are actually _implemented_.

Well, Clean doesn't provide that.  The Clean team have, with good reason,
decided to not to worry very much about UNIX (and of course there never
was a NextStep version), and it is all too easy to get unheralded crashes
from Clean programs.

The recent release of the 1.0 IO system is a great step forward; it's very
much in the spirit of realising long-standing promises.

Here's my priority list for things that really have to happen before it
would be _responsible_ for the Clean team to go haring off after OOP:

 - make the default state of the system bomb-proof (i.e. it should NEVER
   be possible for a Clean program to provoke an error message from the
   underlying operating system *unless* the programmer has explicitly
   switched off stack checking, array subscript checking, overflow checking,
   &c).

 - we've been promised safe destructive update for a long time.  Do it.
   (I get the impression that Mercury has this working in an internal
   version, maybe even the current release.)

 - the language is called *Concurrent* Clean.  Get the concurrency stuff
   finished and released on at least one platform.  Or else yank the stuff
   out of the manual entirely and remove the word 'Concurrent' from the name.

 - spruce up the Clean documentation.  At the very least, have it
   thoroughly proof-read by a good technical writer who is a native
   speaker of English.  (This is perhaps the one area of Clean where I
   could help.)  Make sure the release notes for each version accurately
   describe the release and installation procedure.

 - eliminate the radically silly assumption that everyone is free to
   redefine what a TAB means.


I'm currently giving very serious consideration to using Mercury as the
language in the Functional Programming course.  It's originally a logic
programming language, but it does have a functional sublanguage, and it
has Clean-style uniqueness types, and while a Tk interface is a heck of
a lot less sexy than the really neat Clean stuff, it _is_ multiplatform
right now.