At 09:49 97/08/12, Paul Hudak wrote:
>... I think
>you missed one of the main things that an OS could provide in support of
>languages such as Haskell: garbage collection. There are all sorts of
>malloc-like things that could be better supported, as well as things
>like handles to "fonts", "brushes", etc. which need to be explictly
>created and destroyed for efficiency reasons in the Win 32 API, for
>example. (Perhaps now that Java is here we'll see OS's starting to
>provide such support :-)
I think that Java might be slow, just because of this automatic garbage
collection. But perhaps an OS should supply an optional automatic garbage
collection, which can be overridden at will in the name of efficiency.
At 15:21 97/08/12, jap wrote:
>Perhaps it time to recall a system called Flex, that was developed at
>the (then) Royal Signals and Radar Establishment at Malvern in the
>late 1970s. The hardware was custom and microprogrammable, with an
>operating system, (modular) compiler, editor, garbage collector,
>filing system etc. all written in Algol-68. I think there was also a
>re-implementation on the Perq. No doubt others can supply more precise
>details...
Computers (=RISC) are not microprogrammable, because it is slow; instead
one relies on better compilers.
I think the problem is that, in general, as of today, efficient hardware
structures translates into very imperative programming, and functional and
parallel programming is left out in the cold. If one starts moving more
structure into the byte codes (as in Java), then that may pave the way for
better hardware structures in the future: The hardware structures we see
today, are based on assumptions from the dawn of computer construction,
namely, computers that was used to perform simple, unstructured
mathematical operations. So, with good byte code designs, which become
sufficiently universal, this will surely make the hardware people take that
into account.
Hans Aberg
