Watershed posts ...
winikoff@cs.mu.oz.au
winikoff@cs.mu.oz.au
Tue, 31 May 94 13:09:14 EST
~From comp.os.research Thu May 19 14:24:55 1994
Path: cs.mu.OZ.AU!munnari.oz.au!newshost.anu.edu.au!harbinger.cc.monash.edu.au!msuinfo!agate!darkstar.UCSC.EDU!osr
~From: dpw93@ecs.soton.ac.uk (David Wragg)
Newsgroups: comp.os.research
Subject: Design of a more usable [operating] system
Date: 17 May 1994 04:29:40 GMT
Organization: Electronics and Computer Science, University of Southampton
Lines: 249
Approved: comp-os-research@ftp.cse.ucsc.edu
Message-ID: <2r9h7k$kjk@darkstar.UCSC.EDU>
NNTP-Posting-Host: ftp.cse.ucsc.edu
Originator: osr@ftp
When I use a computer I seem to spend much of my time working against
the computer, rather than using the computer to experiment with
ideas. This is what I feel computers should be for, rather than
word-processing or programming or whatever.
What I would like is to develop software which would fit a very
open-ended specfication:
"Help people to store and manipulate their ideas"
I'd like to throw the design and development of this system open to a
large number of people. Below I elaborate the ideas, and suggest the
best ways to implement them.
An important point is that this specification affects the operating
system used by the software. OS mainstream is biased towards catering
for large programs. However, the size of programs makes them
inflexible and coarse-grained and therefore unsuitable for
manipulating objects at a human concept level. However, the bottom
levels of OS design are suitable, since these are distant enough from
user levels.
What follows is a more top-down discussion of the idea.
Then I'll go into implementing these ideas in a piece of software I
have called Watershed. Watershed is a framework in which to develop
software which works with human-oriented data types.
What computer software should do
================================
The following principles are important:
o Software should be intuitive to use.
This means that the computer should adapt to represent objects and
their operations in a way that is natural to the user, whether that
user has large amounts of experience with computers, or very little.
This has nothing to do with prettiness of the user-interface, or ease
of use for some stereotypical target user.
o Software should be easily maintainable, and resilient to errors and
crashes. Security may also be an issue.
Who wants a computer that gives wrong answers, often crashes, and
loses all its data in a power failure?
o Software should be highly abstract
Much of the difficulty with today's software is that it lacks
generality. So concepts that are close in the human mind (with its
powers of generalization) may be unconnected in the computer. So to
represent ideas the software should be highly abstract from as low a
level as possible.
How to "correct" current computers
==================================
These suggestions are drawn from the principles above.
o Remove direct connections between the user-interface and operations
on the objects that the user manipulates. So users can decide which
parts of which user-interface they want to use, and adapt their
user-interface to suit themselves.
o The systems need far more explicit knowledge about the operations
occurring and the types of objects involved, so it can properly schedule
them (especially in multiprocessor systems) and guard against crashes
and subtle errors.
o Provide very good, very general mechanisms and leave as much
policy as possible out. Policies are dependent on the preferences of
the user, and so should be part of into the user-interface.
Programming is the creation of operations on objects. So provide
mechanisms for declaring relationships between operations and objects.
I've mentioned objects, because the system should use abstract data
types, to make the representations in the computer closer to the user's
mental model, ease programming and improve reliability and
maintainability.
To encourage this abstract model the system should discourage big
programs, and instead favor small operations on objects, with
explicit properties.
Automating tasks should be a simple procedure at any level.
Manipulating graphical representations with a mouse is a formal way of
manipulating objects just as much as a program.
Storage and Filing Systems
==========================
Traditionally main store and backing store appear separate to the
user. There are many signs that at the operating systems level (with
virtual memory, disc caches and memory-mapped files) there are moves
towards a unified concept of storage. But still the user has to decide
to save from main store to backing store.
This division should be smoothed over at the operating system
level. Main store and backing store are of course very different, but
the system would know enough about the data and operations that it
could take advantage of these differences.
This would mark the end of the "directories and filenames" filing
system with its unchallenged monopoly. But if people cannot bear to
let that go, it would be easy to design a new user-interface element
which implemented directory and filename-like structures.
Implementing Watershed
======================
So is implementing Watershed practical?
Watershed needs services provided by today's operating systems, such
as a filing system, process management, memory management, and a
graphical display. So it makes sense to design it as a layer on top of
another operating systems. This provides hardware independence.
(In fact, the process management of operating systems is inadequate to
handle the small operations discussed above. But it's easier to make
do)
However, the conceptual differences between Watershed and current
operating systems are too great to allow Watershed programs access to the
underlying operating system.
Implementing a Watershed subsystem on a well-designed microkernel
should be very effective.
Compatibility
=============
Compatibility with existing operating systems will be limited, so
compatibility between Watershed systems is important.
Compatibility between operating systems has traditionally been managed
by emulating the ABI of a particular system, so that binary files can
run unchanged. But to make Watershed independent of any host operating
system the format (and the existence) of binaries must remain
invisible to Watershed programs.
It will be more efficient to make Watershed systems compatible at the
installation phase, so that a software package can be extracted from
one Watershed system and added to another. By specifying the format of
such a package carefully, compatibility can be guaranteed.
Object oriented ideas
=====================
Watershed will make use of object oriented ideas. However, there are
different ways to implement OO ideas, at different levels. The objects
Watershed works with will tend to be on a larger scale than
programming language objects. For example Watershed does not need to
be able to efficiently represent a single integer since they are
covered by programming languages. But Watershed should represent, for
example, a color image, which would be made up of many integers.
The strength of the association between objects and their methods, and
quuestions of inheritance, vary between different OO systems. Since
these are policy decisions, all Watershed needs to do is provide the
mechanism of a very general polymorphic procedure call, and a way for
objects to access their own storage.
Programming languages
=====================
First of all, I intend to write the Watershed basic system in C. See
"Watershed and C" below.
Watershed should be programming language independent. It is difficult
to say at this stage how languages should integrate with Watershed,
since specifying a mechanism may rule some languages out (for example,
I am fond of pure functional languages but it will be difficult to
integrate them with Watershed).
Many of the nice features in Watershed may cause problems to languages
which already have strong support for these features. Watershed will
have its own ideas about modules, OOP, and error handling.
Also, many languages have features which are meaningless in
the context of Watershed. For example, the standard C library has file
input and output functions.
All I can suggest is that Watershed in not an environment to port
existing applications to, so languages should be used on Watershed on
their own merits. Languages should firstly support Watershed, and
secondly stick as closely to the language specification (i.e. there
should be no change in the general syntax of a language).
However, for quite a while Watershed will not host its own compilers,
or program entry. Compilers will run on the host operating system, and
should generate Watershed packages, and the package format will be
driven by the needs of languages.
Eventually Watershed will have a program development environment built
into it, and there will be objects representing packages so the
Watershed system alone can create and export packages containing
programs. To ensure portability of packages, these programs could use a
byte code, which would be interpreted or compiled when the package is
loaded onto a system.
Watershed and C
===============
To maximise portability, until Watershed supports its own development
environment it should be written in C. C is the best language to write
anything which interacts with the host operating system.
I don't expect C to become the only language for Watershed
development, but it makes a good language for developing efficient
primitive operations, and so a lot of the early programming of objects
will be done in C. Eventually a reasonable alternative language should
be found
How much work is there to do
============================
At the moment, the most important thing is to create a stable
Watershed specification and write a minimal system to support it. I
intend to accomplish this in a few months.
Then more sophisticated Watershed systems can be evolved, whilst basic
Watershed software is written.
If all that goes according to plan, a standard graphics interface can
be created and advanced user-interface development can begin. Then a
proper development environment can be built.
Any discussion is welcome. If anyone wishes to contribute towards the
design of the Watershed system, could they mail me
(dpw93@ecs.soton.ac.uk).
Thanks,
Dave.
~From comp.os.misc Fri May 20 15:33:10 1994
Xref: cs.mu.OZ.AU comp.os.misc:3254 comp.object:16798 comp.sys.misc:3164
Path: cs.mu.OZ.AU!munnari.oz.au!bunyip.cc.uq.oz.au!harbinger.cc.monash.edu.au!msuinfo!agate!howland.reston.ans.net!usc!nic-nac.CSU.net!coyote.csusm.edu!coyote.csusm.edu!not-for-mail
~From: tanksley@coyote.csusm.edu (Billy Tanksley)
Newsgroups: comp.os.misc,comp.object,comp.sys.misc
Subject: Re: Design of a more usable [operating] system
Date: 18 May 1994 09:57:58 -0700
Organization: California State University San Marcos
Lines: 16
Message-ID: <2rdhem$kqq@coyote.csusm.edu>
References: <2rbns1$4gp@picasso.ecs.soton.ac.uk>
NNTP-Posting-Host: coyote.csusm.edu
Your specification for a OS you called 'Watershed' is a good idea;
[un]fortunately, it has already been taken. Email orders@geoworks.com and
ask for thier programming overview.
Geos has a user interface that is both replacable and scalable, and comes
in two levels (patented): Specific, which the user deals with; and
General, which the program deals with. The UI is also scalable, with all
menu selections being 'graded' by the programmer, and choosing a different
'user level' will eliminate (or add) menu item inappropriate (or vise
versa) to that user level.
Of course, Geos runs on Intel only now, but they're working on a portable
version.
-Billy
~From comp.os.misc Sat May 21 16:54:00 1994
Xref: cs.mu.OZ.AU comp.os.misc:3255 comp.object:16821 comp.sys.misc:3168
Path: cs.mu.OZ.AU!munnari.oz.au!newshost.anu.edu.au!harbinger.cc.monash.edu.au!msuinfo!agate!howland.reston.ans.net!pipex!doc.ic.ac.uk!bright.ecs.soton.ac.uk!dpw93
~From: dpw93@ecs.soton.ac.uk (David Wragg)
Newsgroups: comp.os.misc,comp.object,comp.sys.misc
Subject: Re: Design of a more usable [operating] system
Date: 20 May 1994 14:59:21 GMT
Organization: Electronics and Computer Science, University of Southampton
Lines: 30
Message-ID: <2rij89$evu@bright.ecs.soton.ac.uk>
References: <2rbns1$4gp@picasso.ecs.soton.ac.uk> <2rdhem$kqq@coyote.csusm.edu>
NNTP-Posting-Host: herbert.ecs.soton.ac.uk
In <2rdhem$kqq@coyote.csusm.edu> tanksley@coyote.csusm.edu (Billy Tanksley) writes:
>Your specification for a OS you called 'Watershed' is a good idea;
>[un]fortunately, it has already been taken. Email orders@geoworks.com and
>ask for thier programming overview.
>Geos has a user interface that is both replacable and scalable, and comes
>in two levels (patented): Specific, which the user deals with; and
>General, which the program deals with. The UI is also scalable, with all
>menu selections being 'graded' by the programmer, and choosing a different
>'user level' will eliminate (or add) menu item inappropriate (or vise
>versa) to that user level.
Unfortunately, Geos only approaches one goal of Watershed: a slight
decoupling of the users interface from the program. Full decoupling
would allow the user to ditch the window system, and use a totally
different GUI, or ditch the GUI completely, and move to a command
line.
Geos doesn't even try for some of the other aims: it still has
monolithic program, no object system, and no persistent object system.
I think I may still have some work ahead of me.
Dave W.
--
"They said Linux would never take off, they were wrong: So switch to
Watershed now!"
~From comp.os.misc Sun May 22 19:36:47 1994
Xref: cs.mu.OZ.AU comp.os.misc:3261 comp.object:16845 comp.sys.misc:3177
Path: cs.mu.OZ.AU!munnari.oz.au!bunyip.cc.uq.oz.au!harbinger.cc.monash.edu.au!msuinfo!agate!howland.reston.ans.net!cs.utexas.edu!usc!nic-nac.CSU.net!coyote.csusm.edu!coyote.csusm.edu!not-for-mail
~From: tanksley@coyote.csusm.edu (Billy Tanksley)
Newsgroups: comp.os.misc,comp.object,comp.sys.misc
Subject: Re: Design of a more usable [operating] system
Date: 20 May 1994 14:06:18 -0700
Organization: California State University San Marcos
Lines: 41
Message-ID: <2rj8oa$fsc@coyote.csusm.edu>
References: <2rbns1$4gp@picasso.ecs.soton.ac.uk> <2rdhem$kqq@coyote.csusm.edu> <2rij89$evu@bright.ecs.soton.ac.uk>
NNTP-Posting-Host: coyote.csusm.edu
In article <2rij89$evu@bright.ecs.soton.ac.uk> dpw93@ecs.soton.ac.uk (David Wragg) writes:
>Unfortunately, Geos only approaches one goal of Watershed: a slight
>decoupling of the users interface from the program. Full decoupling
>would allow the user to ditch the window system, and use a totally
>different GUI, or ditch the GUI completely, and move to a command
>line.
Er, wrong. So far Motif, CUA, Open Look, PM (OS/2), and one other UI
whose name I've forgotten have been ported. It's a total decoupling.
>Geos doesn't even try for some of the other aims: it still has
>monolithic program, no object system, and no persistent object system.
Whoops! Wrong on all counts. Try using Geos.
1) According to all Geos literature and programmers I've talked to, the
file structure is NOT monolithic in any sense of the word. If you mean
single file; no. If you mean big file, no also; because Geos executables
are generally VERY small, with the full function WP being ~80K.
2) No object system!! Really, now. Geos was the first EVER PC based OO
OS! The ONLY competitor (aside from one PD text-mode-only system) is
NExTSTEP, hardly competition. Try it.
3) Er, are we talking about different programs here? you can shut down
Geos completely, and have it come up in exactly the same state-- ALL
windows, programs, and even uncompleted text entries.
Say, are you talking about the old Commodore Geos? That might explain it.
PC/Geos is made by the same company, but is MUCH different.
>I think I may still have some work ahead of me.
Good luck-- although I'd rather you put the work into making PC-Geos
portable. :)
>Dave W.
-Billy
"Watershed NT"
~From comp.os.misc Mon May 23 10:40:41 1994
Xref: cs.mu.OZ.AU comp.os.misc:3263 comp.object:16872 comp.sys.misc:3181
Path: cs.mu.OZ.AU!munnari.oz.au!bunyip.cc.uq.oz.au!harbinger.cc.monash.edu.au!msuinfo!uwm.edu!spool.mu.edu!howland.reston.ans.net!nctuccca.edu.tw!news.cc.nctu.edu.tw!debbie.cc.nctu.edu.tw!cc.nctu.edu.tw!u8123033
~From: u8123033@cc.nctu.edu.tw (Paladin Mu)
Newsgroups: comp.os.misc,comp.object,comp.sys.misc
Subject: Re: Design of a more usable [operating] system
Followup-To: comp.os.misc,comp.object,comp.sys.misc
Date: 22 May 1994 01:33:09 GMT
Organization: Computer Center, National Chiao-Tung University, Taiwan
Lines: 34
Message-ID: <2rmcol$grf@debbie.cc.nctu.edu.tw>
References: <2rbns1$4gp@picasso.ecs.soton.ac.uk> <2rdhem$kqq@coyote.csusm.edu> <2rij89$evu@bright.ecs.soton.ac.uk>
NNTP-Posting-Host: u8123033@ccsun17.cc.nctu.edu.tw
X-Newsreader: TIN [version 1.2 PL2]
David Wragg (dpw93@ecs.soton.ac.uk) wrote:
: Unfortunately, Geos only approaches one goal of Watershed: a slight
: decoupling of the users interface from the program. Full decoupling
: would allow the user to ditch the window system, and use a totally
: different GUI, or ditch the GUI completely, and move to a command
: line.
What I interpreted from your article is a OS in which everything
is highly abstract. To achieve the goal of abstraction, you might
adobt the comcept of objects.
One of my question: once you've decided to build such a system
you start to setup your own (very general) rules of the system,
or the abstract world you're creating. Then you build objects
as a model of your imaginine world. But, usually, you also
represent the same world to your user by some user interface.
How do you make the interface independent from the abstract
world?
This project made reminded me of Smalltalk system or Oberon.
What makes Watershed different? :)
And another point of my curiosity: what is the rule of
inheritence (of objects) in your system?
Best Regards,
--
plato. rene descartes.william somerset maugham. albert einstein.alan turing
pablo picasso.homer.nicolaus copernicus PALADIN MU georg
cantor. lau tzu . kurt goedel .johnann u8123033@cc.nctu.edu.tw seb
astian bach. alonzo church.claude monet DEP. OF CIS, NCTU. TAIWAN donald
knuth.charles babbage.john backus.von neumann.william shakespeare.aristotle
~From comp.lang.functional Fri May 27 11:36:58 1994
Xref: cs.mu.OZ.AU comp.lang.functional:4514 comp.object:16962 comp.os.misc:3270 comp.sys.misc:3201
Newsgroups: comp.lang.functional,comp.object,comp.os.misc,comp.sys.misc
Path: cs.mu.OZ.AU!munnari.oz.au!news.Hawaii.Edu!ames!hookup!news.moneng.mei.com!howland.reston.ans.net!EU.net!uknet!comlab.ox.ac.uk!lady0065
~From: lady0065@black.ox.ac.uk (David J Hopwood)
Subject: Re: Design of a more usable [operating] system
Message-ID: <1994May18.164745.6260@black.ox.ac.uk>
Originator: lady0065@black
Keywords: operating systems functional object oriented
Sender: david.hopwood@lmh.oxford.ac.uk
Organization: Oxford University Computing Laboratory
References: <2rbns1$4gp@picasso.ecs.soton.ac.uk>
Date: Wed, 18 May 1994 16:47:45 GMT
Lines: 322
[ I've added comp.lang.functional to this discussion, since what we are
discussing is raising the level of abstraction of operating systems, which
is as relevant to functional programming as it is to object-oriented
programming ]
In article <2rbns1$4gp@picasso.ecs.soton.ac.uk> dpw93@ecs.soton.ac.uk (David Wragg) writes:
>When I use a computer I seem to spend much of my time working against
>the computer, rather than using the computer to experiment with
>ideas. This is what I feel computers should be for, rather than
>word-processing or programming or whatever.
>
>What I would like is to develop software which would fit a very
>open-ended specfication:
>
>"Help people to store and manipulate their ideas"
>
>I'd like to throw the design and development of this system open to a
>large number of people. Below I elaborate the ideas, and suggest the
>best ways to implement them.
>
>An important point is that this specification affects the operating
>system used by the software. OS mainstream is biased towards catering
>for large programs. However, the size of programs makes them
>inflexible and coarse-grained and therefore unsuitable for
>manipulating objects at a human concept level. However, the bottom
>levels of OS design are suitable, since these are distant enough from
>user levels.
I couldn't agree more. Large applications which appear monolithic to the user
(regardless of their internal design), are a very bad idea.
The problem is that the OO-edness (or any other abstract high-level design)
of programs is to a large extent hidden from the user; every object belongs to
a program, and you have to boot up the program and go through a menu structure
to get at it. Current mechanisms for sharing objects between programs
(clipboards, OLE, temporary files) are just kludges.
A good analogy is constrasting a program which inputs some numbers from the
keyboard and outputs their sum to the display, with the function sum in
a functional language.
The former program is literally useless. It isn't designed to communicate with
anything but the user. Its input and output are coerced into having a textual
format which is totally unnatural for the concept of a number.
Getting current programs to communicate is like trying to use this program
whenever you want to sum a list:
- convert the numbers to a list in text format
- write them to a temporary file
- redirect stdin from this file, and stdout to another file
- execute the sum program
- read the result from the output file
- convert it to a number.
_I'm not joking_. This is effectively equivalent to what the user has to do
every time she wants to move data from one application to another.
Prettification exercises like drag-and-drop between applications do not affect
the fact that this, or something even more complicated, is how the transfer is
actually achieved.
The function sum in, say, Haskell, is an expression of exactly the same
algorithm, but to do the same as above you just apply it to the list.
'Nuff said, really.
In this example the operating system just got in the way; since the function
sum was defined within the same program, the operating system wasn't needed
and hence the result was orders of magnitude simpler.
But what if you want a much more complicated function that was written by
someone else. You can copy its source definition into your program; but then
you haven't solved the problem, you've just moved it.
What you need is something which preserves the simplicity of calls within a
single program and language _between_ entities written by different people,
at different times, which have no implementation dependence on each other.
Conceptually, this is not difficult to imagine. First, you have to get rid of
all the stuff in conventional systems which gets in the way.
Take the concept of saving and loading data. It's really a side effect of
having an untyped filesystem, separate from the objects stored in memory.
Get rid of the distinction (at the programmer's level) between memory and
backing store, and you can then change objects in place by calling methods on
them (or by using monads in a functional system).
The same situation is present on a larger scale between objects in a local
filesystem, and those on a wide-area network; you can get rid of that dist-
inction as well.
I've more to say, but I'll stop here since this article is getting quite long.
David Hopwood
david.hopwood@lmh.oxford.ac.uk
There follows a repeat of the rest of the original article, for those in
comp.lang.functional. It should be attributed to dpw93@ecs.soton.ac.uk
(David Wragg).
-----------------------------------------------------------------------------
What follows is a more top-down discussion of the idea.
Then I'll go into implementing these ideas in a piece of software I
have called Watershed. Watershed is a framework in which to develop
software which works with human-oriented data types.
What computer software should do
================================
The following principles are important:
o Software should be intuitive to use.
This means that the computer should adapt to represent objects and
their operations in a way that is natural to the user, whether that
user has large amounts of experience with computers, or very little.
This has nothing to do with prettiness of the user-interface, or ease
of use for some stereotypical target user.
o Software should be easily maintainable, and resilient to errors and
crashes. Security may also be an issue.
Who wants a computer that gives wrong answers, often crashes, and
loses all its data in a power failure?
o Software should be highly abstract
Much of the difficulty with today's software is that it lacks
generality. So concepts that are close in the human mind (with its
powers of generalization) may be unconnected in the computer. So to
represent ideas the software should be highly abstract from as low a
level as possible.
How to "correct" current computers
==================================
These suggestions are drawn from the principles above.
o Remove direct connections between the user-interface and operations
on the objects that the user manipulates. So users can decide which
parts of which user-interface they want to use, and adapt their
user-interface to suit themselves.
o The systems need far more explicit knowledge about the operations
occurring and the types of objects involved, so it can properly schedule
them (especially in multiprocessor systems) and guard against crashes
and subtle errors.
o Provide very good, very general mechanisms and leave as much
policy as possible out. Policies are dependent on the preferences of
the user, and so should be part of into the user-interface.
Programming is the creation of operations on objects. So provide
mechanisms for declaring relationships between operations and objects.
I've mentioned objects, because the system should use abstract data
types, to make the representations in the computer closer to the user's
mental model, ease programming and improve reliability and
maintainability.
To encourage this abstract model the system should discourage big
programs, and instead favor small operations on objects, with
explicit properties.
Automating tasks should be a simple procedure at any level.
Manipulating graphical representations with a mouse is a formal way of
manipulating objects just as much as a program.
Storage and Filing Systems
==========================
Traditionally main store and backing store appear separate to the
user. There are many signs that at the operating systems level (with
virtual memory, disc caches and memory-mapped files) there are moves
towards a unified concept of storage. But still the user has to decide
to save from main store to backing store.
This division should be smoothed over at the operating system
level. Main store and backing store are of course very different, but
the system would know enough about the data and operations that it
could take advantage of these differences.
This would mark the end of the "directories and filenames" filing
system with its unchallenged monopoly. But if people cannot bear to
let that go, it would be easy to design a new user-interface element
which implemented directory and filename-like structures.
Implementing Watershed
======================
So is implementing Watershed practical?
Watershed needs services provided by today's operating systems, such
as a filing system, process management, memory management, and a
graphical display. So it makes sense to design it as a layer on top of
another operating systems. This provides hardware independence.
(In fact, the process management of operating systems is inadequate to
handle the small operations discussed above. But it's easier to make
do)
However, the conceptual differences between Watershed and current
operating systems are too great to allow Watershed programs access to the
underlying operating system.
Implementing a Watershed subsystem on a well-designed microkernel
should be very effective.
Compatibility
=============
Compatibility with existing operating systems will be limited, so
compatibility between Watershed systems is important.
Compatibility between operating systems has traditionally been managed
by emulating the ABI of a particular system, so that binary files can
run unchanged. But to make Watershed independent of any host operating
system the format (and the existence) of binaries must remain
invisible to Watershed programs.
It will be more efficient to make Watershed systems compatible at the
installation phase, so that a software package can be extracted from
one Watershed system and added to another. By specifying the format of
such a package carefully, compatibility can be guaranteed.
Object oriented ideas
=====================
Watershed will make use of object oriented ideas. However, there are
different ways to implement OO ideas, at different levels. The objects
Watershed works with will tend to be on a larger scale than
programming language objects. For example Watershed does not need to
be able to efficiently represent a single integer since they are
covered by programming languages. But Watershed should represent, for
example, a color image, which would be made up of many integers.
The strength of the association between objects and their methods, and
questions of inheritance, vary between different OO systems. Since
these are policy decisions, all Watershed needs to do is provide the
mechanism of a very general polymorphic procedure call, and a way for
objects to access their own storage.
Programming languages
=====================
First of all, I intend to write the Watershed basic system in C. See
"Watershed and C" below.
Watershed should be programming language independent. It is difficult
to say at this stage how languages should integrate with Watershed,
since specifying a mechanism may rule some languages out (for example,
I am fond of pure functional languages but it will be difficult to
integrate them with Watershed).
Many of the nice features in Watershed may cause problems to languages
which already have strong support for these features. Watershed will
have its own ideas about modules, OOP, and error handling.
Also, many languages have features which are meaningless in
the context of Watershed. For example, the standard C library has file
input and output functions.
All I can suggest is that Watershed in not an environment to port
existing applications to, so languages should be used on Watershed on
their own merits. Languages should firstly support Watershed, and
secondly stick as closely to the language specification (i.e. there
should be no change in the general syntax of a language).
However, for quite a while Watershed will not host its own compilers,
or program entry. Compilers will run on the host operating system, and
should generate Watershed packages, and the package format will be
driven by the needs of languages.
Eventually Watershed will have a program development environment built
into it, and there will be objects representing packages so the
Watershed system alone can create and export packages containing
programs. To ensure portability of packages, these programs could use a
byte code, which would be interpreted or compiled when the package is
loaded onto a system.
Watershed and C
===============
To maximise portability, until Watershed supports its own development
environment it should be written in C. C is the best language to write
anything which interacts with the host operating system.
I don't expect C to become the only language for Watershed
development, but it makes a good language for developing efficient
primitive operations, and so a lot of the early programming of objects
will be done in C. Eventually a reasonable alternative language should
be found
How much work is there to do
============================
At the moment, the most important thing is to create a stable
Watershed specification and write a minimal system to support it. I
intend to accomplish this in a few months.
Then more sophisticated Watershed systems can be evolved, whilst basic
Watershed software is written.
If all that goes according to plan, a standard graphics interface can
be created and advanced user-interface development can begin. Then a
proper development environment can be built.
Any discussion is welcome. If anyone wishes to contribute towards the
design of the Watershed system, could they mail me
(dpw93@ecs.soton.ac.uk).
Thanks,
Dave.
~From comp.lang.functional Mon May 30 10:42:03 1994
Xref: cs.mu.OZ.AU comp.lang.functional:4525 comp.object:17030 comp.os.misc:3285 comp.sys.misc:3214
Newsgroups: comp.lang.functional,comp.object,comp.os.misc,comp.sys.misc
Path: cs.mu.OZ.AU!munnari.oz.au!constellation!osuunx.ucc.okstate.edu!newsfeed.ksu.ksu.edu!moe.ksu.ksu.edu!vixen.cso.uiuc.edu!sdd.hp.com!col.hp.com!srgenprp!news.dtc.hp.com!hplextra!hplb!rlea.hpl.hp.com!rjl
~From: rjl@rlea.hpl.hp.com (Rodger Lea)
Subject: Re: Design of a more usable [operating] system
Sender: news@hplb.hpl.hp.com (Usenet News Administrator)
Message-ID: <CqGLuw.8yA@hplb.hpl.hp.com>
Date: Fri, 27 May 1994 11:42:31 GMT
References: <2rbns1$4gp@picasso.ecs.soton.ac.uk> <1994May18.164745.6260@black.ox.ac.uk> <2s3lkt$66i@staff.cs.su.oz.au>
Nntp-Posting-Host: rlea.hpl.hp.com
Organization: Hewlett-Packard Laboratories, Bristol, England
Keywords: operating systems functional object oriented
Lines: 38
In article <2s3lkt$66i@staff.cs.su.oz.au>, gary@cs.su.oz.au (Gary Capell) writes:
> >Take the concept of saving and loading data. It's really a side effect of
> >having an untyped filesystem, separate from the objects stored in memory.
> >Get rid of the distinction (at the programmer's level) between memory and
> >backing store, and you can then change objects in place by calling methods on
> >them (or by using monads in a functional system).
> >The same situation is present on a larger scale between objects in a local
> >filesystem, and those on a wide-area network; you can get rid of that dist-
> >inction as well.
>
> Sounds like a job for a Distributed Persistent Operating System...
>
> There is a research group here at Sydney Uni working on just such a
> beastie, called Grasshopper (I am not in that group). I think that it
> would allow the niftyness described above, but I don't know if they've
> given much thought yet as to how to use this new functionality (typed
> persistent data). I would love to play with such a system.
Look at the last few International workshop on object oriented in
operating systems (IWOOOS IEEE press). There's a myriad number of
systems that have built or partially built systems that use a notion
of objects that abstract away from location (distribution) and
storage (persistence) - it's the age old concept of a single level
store.
An interesting point is that such systems have been built from scratch eg
Apertos, Grasshopper, IK, KeyKos- some have been built on micro-kernels such as
COOL, Guide and some have been built on Unix - Comet, Oisin (these are
just systems I'm familiar with, there are many more) - it's not clear we
need new OS architectures to support this functionality.
rodger
--
Rodger Lea rjl@hplb.hpl.hp.com
Hewlett-Packard Laboratories
Bristol, England +44 272 228455