world as value

[P.R. Serrarens]

Hello Adrian,

I do not want to say much about your criticism about the world-as-value
approach of most purely functional language, except that I do like it because
it clearly shows what is affected by the functions, especially in the
multi-environment approach as is used by Clean.

> So here's my idea...
> 
> 1- Forget about the 'world as value' paradigm completely. Instead invent a
> different (non functional?) way of nailing down program behaviour it terms of
> actions that must be executed in response to events external to the program.
> I must confess that I have very little idea how best to do this, or how to
> go about proving that (from a behavioural point of view) a program satisfied
> some kind of formal specification. The only thing I feel reasonably sure about
> is that this approach requires big programs to be decomposable to smaller
> sub-programs which interact my generating events which are seen by other
> sub-programs. Some means of starting new sub-programs dynamically would be
> useful (essential?) too. I think I'll call this the 'action spec' for want
> of a better word. (Does this remind you of Erlang??)

This is actually a rather old idea which was in fashion before monads and
uniqueness typing became popular. The basis lies in the way Miranda and
pre-1.3 Haskell did their I/O. The type of a program was:

   Main :: [ Input ] -> [ Output ]

And there were basically two programs running: the user programming and the
outer world, which communicated by lazyy streams.

This idea was extended into a multi-program model in the Kent Applicative
Operating System (KAOS), which used Stoyes sorting office for routing the
messages between the programs. Each output message was labeled with a
destination address, which was used by the sorting office to direct the
message to the correct receiver. The operating system consists then of many
programs of the type above.

This idea did not become the standard of doing I/O, because programs became
rather complicated in non-trivial programs. It seemed that I/O was something
that was inherently imperative and this fitted the monads/uniqueness typing
model better.

Actually, I use the KAOS model to describe the implementation of the
Concurrent Clean message passing!

papers:

@techreport{NobleRunciman1994a,
 author       = "Noble, R. and Runciman, C.",
 title        = "Functional Languages and Graphical User Interfaces
                 - a Review and a Case Study",
 number       = "YCS-94-223",
 institution  = "Department of Computer Science, University of York",
 month        = "February",
 year         = "1994"
}

Discusses quite a few approaces to graphical I/O, including monads and
uniqueness typing.

@inbook{Turner1990a,
 author       = "Turner, D.A.",
 title        = "An Approach to Functional Operating Systems",
 editors      = "Turner, D.A.",
 booktitle    = "Research Topics in Functional Programming",
 publisher    = "Addison-Wesley Publishing Company",
 pages        = "199--217",
 year         = "1990"
}

Discusses the Kent Applicative Operating System.

@techreport{Stoye1984a,
 author       = "Stoye, W.R.",
 title        = "A new scheme for writing functional operating systems",
 number       = "56",
 institution  = "Copmuter Laboratory, Cambridge University",
 year         = "1984"
}

About this sorting office.

-- 
Pascal Serrarens
Concurrent Clean developer
University of Nijmegen, NL