At 13:03 9/7/95 -0400, Jonathan Shapiro wrote:
>What I'm thinking about is post-mortem analysis. Using your
>terminology, here's a slight expansion on what I had in mind:
>
> severing: One would like to have some sort of notion what *kind* of
> object was severed. Even a small clue can go a long way
> toward figuring out what got broken. One possibility is
> to allow DISCRIM to operate on dead keys to give you key
> classification info.
This seems to be the right level of information.
> uninit: Slots in a virgin node can either be DK(0) or a void key
> (if you buy in to the need for the latter - I'm not
> convinced).
KeyKOS didn't have it so I'm not convinced either.
>
>If called for, the void key would have the property that you can call
>or return to it, but it doesn't do anything. Sort of the /dev/null of
>capabilities :-)
I seriously think this is the wrong model. A void key should generate an error when called. In KeyKOS we give the programmer the choice of handling errors (by accepting the return code), or trapping (by not accepting the return code, and getting a non-zero return code). This is, I think the exact right compromise between the "Unix way" of having all errors come back in a return code no one bothers to check(*) or having to build trap handlers to handle errors that you really expect to happen in normal circumstances.
N.B. I made up the URL from the information I used with creaky old FTP. I hope everying is cased/spelled/slashed/coloned correctly. If it doesn't work anonymous FTP to grilled.cs.wisc.edu and use ls and cd to get to the paper. That's what I had to do.
Bill