[unios] Re: Timecapsule to the past...

[Laurent Martelli]

>>>>> "Alan" == Alan Grimes <alangrimes@starpower.net> writes:

  Alan> Laurent Martelli wrote:
  >> It looks like our goal is the minimisation of dependencies
  >> between pieces of software. Can this be achieved with a program ?

  Alan> I have been considering the problem. Saying that you had a C
  Alan> compiler that had built in math headers and no OS headers at
  Alan> all such as stdio.h then you could hypothetically perform any
  Alan> computation. The first problem you would face is that you
  Alan> would have no way to input or output data so that system
  Alan> becomes instantly useless. (unless you want to link the
  Alan> program with new data each time then read its memory image to
  Alan> record its output.) 

Of course, access to the basic devices (keyboard, screen) is needed if
we want the system to be useful. However, I think we need not have
strong dependencies on them. These are just GUI concerns and should be
made orthogonal to software specification concerns. This can be
achieved with a technique such as AOP. 

Let's take an example. Consider a Lisp machine. It's _implementation_
relies on a read-and-eval loop. But you can do useful things without
explicitly using the IO functions available. You can define the square
function (defun square (x) (* x x)), and do useful things with
it. SQUARE does not require a specific IO mechanism in order to be
defined. But you'll need one in order to use it. Note that you can use
any IO mechanism that you like : keyboard/screen, mouse/screen,
voice/voice ... 

But if you define square like this : 
	
	(defun square
	  (let ((x read-number))
	    (write (* x x))))

you're finished because you have an explicit dependency on the IO
mechanism. (This one is not very strong because read-number and write
are rather abstract and could be implemented in many ways, but you'll
get the point.)

  Alan> C is an excedingly poor language because it has all kinds of
  Alan> type dependancies making it useless for someone intending to
  Alan> design a portable system. Lets say you had a "unio.h" that
  Alan> claimed to have universal IO capabilitys. Now you can inupt
  Alan> and output to your heart's content!  =) But how should yuo go
  Alan> about implementing "unio"?  You would have to define a highly
  Alan> generalizable but still standardized IO calls. For example to
  Alan> draw a box 3 inches by 4 inches on the user's monitor you
  Alan> would say:

  Alan> Uniout("square", 3,4);

Now, if you want to "draw a square on the screen", it's obvious that
you'll need a screen to do that. The point is not specify you need a
screen unless you really need one. And even if you need one, make it
as abstract as possible. 

-- 
Laurent Martelli
martelli@iie.cnam.fr