Don't hardwire OS features (was Re: Build OS features i

[Alaric B. Williams]

On  3 Dec 96 at 22:51, Francois-Rene Rideau wrote:

> > I love your capacity for damning remarks,
> 
> > usually including the word 'lame' ;-)
> Yeah. I admit I don't know many familiar deprecatives.
> Perhaps I should purchase this french-english dictionary of slang...

Well I can teach you some if you want. Start a seperate thread with 
me, so we don't clutter the Tunes list :-)
 
> >>    With Tunes, you could add a system-enforced prerequisite
> >> that input to the routine should be of the right format,
> >> and it would ensure that only objects of the right format
> >> are given to the routine
> > 
> > That'd be a precondition in Eiffel or the proposed ARGOT language.
> >
> Only Eiffel just CAN'T PROVE anything about the precondition.
> It can only test it at runtime. And even then, this means that Eiffel
> preconditions should be only computable statements.
> Hence, not very expressive. All that is better than nothing,
> but this doesn't remotely mean "good".

Eiffel was designed so it is possible to prove things, just no 
compilers do much proving beyond type inference. So Far.
 
> The problem is when you try to prove something about an arbitrary
> program chosen at random. We're talking about requiring
> that programs be specifically designed not to crash the system...

That can be done quite easily, IMHO. Enumerate the things that cause 
crashes, and mask them off.

It becomes hard when there's a "dirty" component, such as the Windows 
kernel, which we cannot check. It becomes a "back door" our checker 
cannot analyse, allowing us to sneak faults through!
 
> >>    In Tunes, the interrupted task would be basically be told
> >> "now do your best to yield execution ASAP,
> >> after putting the system in a rightful state".
> >
> > Yes, that's the kind of thing I'm aiming at with implicit yields. But
> > there's a temporial and informational efficiency penalty!
> >
> Time penalty: not sure, because cooperation reduces the need
> for blind context saving (and according page faults),

It's faster when there's a switch, but there needs to be a switch 
check in the core of even the tightest loop unless that loop will 
only run for a (proveably) short time.

> > I was worrying about the in-memory space! Larger machine code = more 
> > swapping...
> >
> We also have
> Not cooperative
> <=> more context to save& more code to acquire frequent locks
> <=> more swapping
> So that a study must be done about it...

I guess so :-) 
 
> >>> Trap handlers in the OS don't take up much space, and I don't expect a
> >>> runtime compiler to be a small piece of software.
> >>>
> >> Trap handlers in the OS do take place.
> > 
> > Yes, but not an incredible amount! They fit in QNX's 8k, along with 
> > some other stuff, right :-)
> >
> What you are talking about is only trap redirectors.
> If traps are not to be used, this is already too much;
> if they are to be used, then you also need a real handler
> outside of QNX, which will take place, etc.
 
Minor grammar point - you mean take space, not place. A place is a 
point, the Latin for place is locus; yet space is an amount, like a 
volume :-)

Anyway, back to the thread. The most minimal trap handling code would 
print an apologetic message to some kind of output system, then kill 
that task/process/address space/module/whatever...
 
> > Unless we have pairs of CPUs - a MISC controller, with a set of CISC
> > coprocessors to do stunning single-opcode FFTs, raytrace in hardware,
> > that sort of thing!
> >
> I'd see it as the coprocessors as being stupid specialized hardware
> rather than CISC CPUs:

Depends on the device - more flexible things are more like CISC CPUs. 
By flexible things, I mean graphics coprocessors with their own 
thread of execution in a graphics-based instruction set ("line 
x1,y1,x2,y2,col") and stuff like that.
 
> Because a call instruction is so short,
> you can compress your code by calling well-factored routines,
> instead of inlining them. The stack helps factoring a lot
> (as compared to register machines); all in all,
> for non-critical code, you can achieve great code compacity
> by having lots of subroutine calls.
> (compare that to 40 bits needed for a subroutine call on
> intel architecture, 64 bits on most RISC architecture).

Ah, right! The FORTH model of modularity :-) 
 
> > Bloated hardware can do things faster... do you disagree that if 
> > something can be done in software on a general purpose CPU, a circuit 
> > can be made to do it much faster? Yes, it's hardwired and inflexible, 
> > but if we're building a computer for multimedia applications we can 
> > guess that it'll benefit from hardware MPEG decoding!
>
> Specialized != bloated.

I /meant/ specialised - and used the wrong word :-)

> > That's semantically identical to it being in an instruction set! Note 
> > that qsort(), the quicksort, is in the C instruction set...
>
> Nope. Being in a library extension to C is not the same as being in C.
> The former means that you can strip it off the C implementation,
> that you needn't special compiler support,
> and that other features can similarly be added.
> Making it an instruction means that it has a special compiler support,
> that other extensions can't have.

The distinction is arbitary. The compiler may just translate "a+b" into 
"+(a,b)". In fact, consider a system where you can define your own 
operators at will, like Ada or Prolog. 

You could strip floating point off a C implementation, just it'd be 
harder than removing stdio streams! The division between "in the 
compiler" and "in the standard libraries" is quite arbitary; some 
languages just make it more syntactically visible.

> >> Yes yes yes. Object code should be irreversibly produced for a particular
> >> target, while a *high-level* language or maximal possible expressivity
> >> should be used to represent user-level and/or portable objects.
> > 
> > Until we develop a truely fundamental theory of computation, 
> > anyway...
>
> Not sure what you mean.

I mean, a mathematical system for converting from syntax A to syntax 
B, with the /maximum/ efficiency possible. As in, if syntax A is a 
turing machine, and syntax B contains a simple instruction for most 
of what a neural net does, then a neural network implemented in A 
will use this instruction in B. IE, the ultimate compiler will be one 
application of a fundamental theory of computation!

> > Yeah, but that's not part of the C standardl writing "portable" ANSI 
> > C, we can't assume anything like that, and have to write rotation in 
> > terms of << and>> and | and all that stuff.
> >
> Two things: 1) GCC can also compile <<|>> statements to ROT.

It requires unnecessary amounts of raw cunning (and CPU time). A 
simple "<<<" operator would be much easier to detect!

> 2) even if it couldn't without the help of a asm/*.h macro, so what?
> People do not program C because ANSI C is a nice language
> that should do everything;
> C is chosen but because it is actually available on actual platforms.
> There's no problem with providing features
> through architecture-dependent files.

Yes, but if we write code for Linux and try to compile it on my DOS 
machine with DJGPP, it won't find asm/*.h and I'll have to figure out 
exactly what they did from gcc's error messages and write them 
myself!

> C is architecture-dependent anyway (pointer sizes, etc).

Yes, but our languages won't be!
 
> > Another of those cutting comments :-) My plan for ARGOT (the 
> > language) bytecode contains some functional features. I won't be 
> > studying much functional theory until I get into University, though. 
> > Unsurprisingly, I want to take a degree in computer science :-)
> > My admissions interview for Cambridge is on Thursday - wish me luck!
> >
> Good luck!
> Do take courses in functional language theory and practice.
 
Yes, they're the only topic in computing [that interests me] that I 
can't find much [comprehensible] information about on the 'net!
 
> > Yup; I don't see how this can be done without the programmer's 
> > input, though - as in completely automatically!
>
> Complete automaticity means that *one* programmer did it *once*,
> and the user doesn't have to worry about it thereof.

Well, I'd call that cunningness on the part of the OS when it comes
to sharing information transparently accross wide area networks! I'd
call full automaticity the seperation of the real [normalised]
semantics of a class, and the derivation from that of a normalised 
(and thus identical for all "classes" that do the same thing) 
representation. Phew! Way beyond current technology!

> Of course the computer won't invent the formats,
> the conversion routine, and the call to it!

Oh, good. I thought you were quite mad :-) 
 
> Sure. But that's the same as above:
> once it's done for the first time,
> no one needs to care about it anymore,
> unless specifically tweaking it for optimization.

Yes, I agree, now I see what you're aiming at!

> > Things like "array" are 'atomic' for transmission, in that they 
> > explain themselves, as do things like integers.
> >
> Yes. I wouldn't use the term "atomic", though.
> Rather "terminal", "context-free", "self-sufficient",
> or "easily reifiable", or perhaps only "pure".

I think "atomic"'s a nice word; it implies we don't have to deal with 
internal structure (meaning "indivisible")!
 
> > We might want to allow variable precision on those Yu'v' channels. In 
> > fact, why not. Let the precision be controllable by the programmer, 
> > defaulting to 32:16:16.
>
> I see no reason to define overkill image formats
> just for the sake of uniformity. If you need the original image,
> take it, instead of wasting bits in a 32:16:16 Yu'v' stuff.

Yes, if a protocol can be defined to agree on this. If two objects 
are of totally identical class (in terms of internal representation), 
then just blit 'em accross as they are!

> > Another wonderful nice sentence :-) I'm not flaming you for these, 
> > BTW, don't be offended... I just admire your directness!
> >
> I'm not offended. I take it as a compliment.

Phew :-)
 
> Well, now that we have formalized what an interface is,
> writing a program without specifying the exact interface
> is just a matter of
> having
>    ...
>    interface(foo)
>    ...
>    interface(bar)
>    ...
> The interface macro will expand into an epsilon of type Interface_T
> that the system will reflectively fill into whichever interface
> is appropriate to the user
> (WIMP interface, text windows, tty, voice, smell, etc).

It'll still need appropriate resources, right - a picture of an 
envelope for a WIMP email, the sound of the word "email" (Please, 
God, not in another cheery American accent...) for voice, the smell 
of fresh stationary for smell, the taste of envelope glue, etc...
 
What are foo and bar in the example? More to the point, what the 
hell's an /epsilon/???

> >> You can add criteria on the above objects
> >> for the computability/acceptability/complexity/whatever
> >> of displays and interfaces.
> 
> > Right! I take this to mean, you /do/ explain how the object should be 
> > represented/interacted with when you are designing/modifying it :-)
>
> I'm not sure what you mean.
> What I mean is that the formal definition for an interface that I gave
> could be refined with other criteria to judge to quality of the interface
> (e.g. Kolmogorov complexity,
> amount of information gatherable per single view,
> vs amount of information to feed the system needed
> to choose the "right" view, etc).

What I meant was, you had to specify some representational details 
when creating a "class". IE, tell it that complex numbers are 
expected to stringify to "a+ib". That sort of thing. If you don't 
tell it how to create a thought for a complex number, it can't express 
it through a thought control interface, etc!
 
> > What I take this to be getting at is not that you're aiming for
> > "self interacting objects", but more for a philosophical thing in
> > programming style that we keep the interface seperate from the
> > "gubbins" (innards).
>
> I achieve one by the other.
> Thanks to reflective programming,
> I can postpone interface and implemenntation stuff
> outside of formal object definition.
> When I have enough information, I can

Uhuh, right.
 
> > Ie, don't even think about designing the higher
> > level interfaces until you've made the object work from the most
> > basic and fastest interface of "a.b(x,y,z)" or whatever your
> > favourite syntax is!
>
> I'd rather say "don't need think about it",
> as the system can "think it over" for you.
> Surely, you should be able to do it if you want.

Yes, I agree, but I still don't know where 'epsilon' fits in!

> > epsilon-calculus?????
>
> Unhappily not currently:
> I only recently invented the concept for use in reflective programming.

You man :-)  [that's a colloquial compliment. Thought I'd better make 
              that clear!]

> Perhaps the concept has been previously invented by someone else
> under some other name; but I don't know it. If you find something,
> please do tell me! [I've been told about some kind of mu-calculus...]

I've heard of lambda, pi, and mu calculi. I know what lambda is. Pi 
is like lambda just with (so I'm told) some good way of expressing 
concurrency? Dunno about mu, it just rings a bell...

>    The name epsilon comes from the Hilbert epsilon symbol,
> as used in formal logic, where
> epsilon x.P which represents a object x fulfilling the property P,
> if there exists any (if there doesn't, either the statement
> is considered invalid, or an arbitrary object might be returned).

Oh, right. In set theory we define subsets like so:

{x epsilon super_set; x satisfies condition}

ie:

{x espilon real numbers; x < 10}

> Basically, epsilons are to existential quantifiers
> what lambdas are to universal quantifiers
> (also see Curry-Howard isomorphism).

Oh boy!

>    Only epsilons are NOT computable in the general case,
> so that no one before me seems to have had this ridiculous idea
> of using some epsilon-calculus in computer programs!
> But after having tried hard to formalize reflective programming,
> I found that epsilon-calculus was exactly
> what reflective programming was about:
> externally and dynamically defining tactics
> to fill those holes in computable foundation.
> Much more general than late-binding
> (one of the two principles of traditional "OO", besides encapsulation).
>    All this might look difficult to understand for
> people without a background in formal logic and its relation
> to computational semantics. Please excuse me.

I'm building me a background :-)

> Writing a well proven clean and understandable article about that
> could be a job for a masters thesis...
>    Any taker?

I'll be needing a master's thesis in about three years :-)
 
> >     Finally, the fact that different languages are given to
> >> "programmers" and "end-users", each being crippled in many ways,
> >> constitutes a barrier between them.
> >
> > Uhuh. Not that we want to bring back the days of BASIC as the OS CLI, 
> > like on the old BBC micros - although that sure merged users and 
> > programmers, the implementation was naff!
>
> Today, FORTH systems, HP RPL-based hand calculators, Mathematica,
> some LISP systems (Emacs?) and other such software,
> do provide a unified computing environment,
> much better than old BASIC-based systems of the early 80's.
> Only they don't ambition to be generic enough
> so as encompass the whole of computing in a unified environment:
> FORTH is for low-level programming;
> RPL for hand-calculators only;
> Mathematica is directed toward doing math,
> and is a purely commercial product;
> Emacs ain't efficient.
> Other LISP systems might be nearer to ,
> but there's no effort to build 

Ahah. Have you heard of the Self system? Completely dynamic, you can 
grab an obejct at runtime and recode it, and it runs about half as 
fast as compiled C! The problem is, it needs at least 64Mb of RAM on 
a Sun workstation - if you have access to one, it's free from 
"http://self.smli.com/", I think. If that URL doesn't work, yell at 
me, and I'll dig it out of my bookmarks...

> > Right. You'll be comforted to know that I designed the ARGON
> > paradigm, then invented a security layer for it, rather than vice
> > versa :-)
> >
> Ahem. And did you choose scoping as the basic protection paradigm,
> as in Tunes?

It's possibly semanticall equivelant to scoping. 

Such that if you are "told about" an entity, you can access it. But you 
can only tell something about an entity to a certain level.

To present a unified interface to this, I'm naming the access levels 
after colours.

none
red
orange
yellow
green
blue
indigo
violet

If you just have the name of an entity, you get "none-level" access. 
If that name has a red tag on it, you get "none" and "red" levels. 
Every entity has a "public accessibility", which is the minimum 
access level; if you classify for access below that, it gets bumped 
up. To make an entity totally public (usually foolish!), set it's 
public accessability to violet...

When you create an entity, you get a violet-level key returned. One 
of the violet-level standard features of an entity is to provide 
lower level keys, so you can pass your friend a green-level key.

The exact meaning of each colour depends, of course, on what you've 
programmed the entity to do, but to stick to a standard scheme.

none = no access possible.
red = opaque visibility; you cannot use the entity, but you can ask 
it what it is, that kind of thing. Usually granted to container 
entities.
...
violet = adminsitrative powers

It's simple and flexible...
 ...perhaps I should try and define a fundamental calculus of access 
control? There are so many schemes, but the field feels like there's 
a mathematical basis to be found...


Regards,


ABW
--
Governments are merely protection rackets with good images.

Alaric B. Williams Internet : alaric@abwillms.demon.co.uk
<A HREF="http://www.abwillms.demon.co.uk/">http://www.abwillms.demon.co.uk/</A>