Priorities

[Tril]

On Sat, 26 Dec 1998, Anders Petersson wrote (in unios@onelist.com):

> I was also thinking of "user" as the *final users* of the system, not
> developers. I think these two groups are so different in their needs that
> they should be separated from each other. The users could retain their
> place, while developers get a higher rank.

Here is my philosophy.  Final users are the most important.  They are the
people who the system should be most convenient for.  The needs of users
are so diverse that pre-packaged applications (written by someone else)
can't always work.  The best solution in every case is to get a program
written specifically for that user, for the problem they have right then.
It only makes sense, then, to have the system assist users in creating
programs to solve their problems.

> >> [Tril:]
> >> That means no C-like inability to check array boundaries (for example).
> >> You CAN focus on stability in the initial design: use strong type
> >> checking, throughout the system.  This just means that operations are not
> >> allowed to operate on values that don't make sense.  I am currently
> >> developing a strong, integrated type system for TUNES, because I believe
> >> it is the center of the system.  There will be no kernel, just this type
> >> system.  All objects will take part in the type system (or they won't
> >> exist).
> 
> Is the quality of the programmers' code really something system developers
> can do anything about? How could it be?

Language designers can do something about it.  At least, they can design
languages that allow maximum expressibility, so the developer doesn't have
to obfuscate the code to adapt it to the language.  This happens a lot in
C because programmers have to completely reorganize their program for
optimization.  That should be the job of the compiler.  Of course, I go
much farther and say that the choice of "data structures", which are
usually chosen for speed (linked list vs. arrays vs. trees etc), should be
abstracted so the programmer doesn't need to decide, but the system can
pick which structure to use for data.

> Sounds like this type system provides the security, is that so? But what if
> the binary code is altered - by mistake or on purpose? And can all
> programming languages be used, or just one?

Yes, the type system is what provides the security.  Altering binary
code.. is interesting.  Since the system knows the binary code depends on
the source, changing the binary code will give you several options:

* Try to figure out what to change in the source code to correspond with
the binary change you made. (you and the system would work together on
this, i.e. the system would try to figure it out but you would help if it
failed)  It may not be possible to express the change in the language used
in the source, if so, then one of the below options would have to be used. 

* Add a low-level "note" that the change you made should be used
instead of the regular binary code , next time that same code is generated
from the source.

* The change causes a "copy on write", or a duplicate of the binary that
no longer depends directly on the source. (it would still have a history
that it originally came from that source, but it would not be dependent in
the sense that it could be automatically invalidated and changed when the
source changes.  That is to preserve your change.)

* Or something else you can think of can happen.

> >> In TUNES we say stability and reliability are just by-products of security
> >> (strong typechecking).  So when we say security we mean all three.
> 
> They are very much interrelated. But this strong typechecking idea is not
> clear for me.

Everything you do involves a typecheck.  Moving the mouse, typing text,
running a program, deleting an object, etc.  Nothing will happen unless
the operation to be done and the object it is operating on match their
types.  If they don't match, that is a type error.  All errors are type
errors.  There is a flexible system to describe what to do on type errors
(each type error can have its own behavior, the user can customize, there
can be defaults, etc).  Everything in the system has a type.  All types
are explicitly defined...  much of what you do in programming languages
today is just creating new types in my model.

> >Stability - The need for the components that the system is composed of, to
> not
> >(be able) scrutinize the flow of run time code.  This does allow for
> incorrect
> >object usage (if binary is corrupted), as that is a logic bug, which should
> >not take down the system.  As you say, this will probably involve a typecheck
> >system.
> 
> _Compile-time_ typecheck?

Good question.  Typechecks are done as soon as possible, but sometimes it
can't be until runtime.  However there is a major difference in my system
regarding the relationship between compiled and interpreted.  Everything
is partially evaluated, and "compiled" is just one form an expression can
be in.  "interpreted" means compiling each sub-expression, then running
its code, before compiling the next sub-expression.  If some
sub-expressions have been compiled before the "compile" function can have
its results (for that sub-expression) memoized (cached) so it looks like
the expression was compiled again but it really just read the saved result
of the last time it was compiled.  (done when storage is cheaper than
the computation of recompiling that expression)
Note that everything is an expression and the compiler is just a function.

Back to type checking, it can occur anytime before an expression is
evaluated, but it MUST occur or the expression can't be evaluated.  Type
checking ensures that the meaning of the expression doesn't break the
consistency of the system.

David Manifold <dem@tunes.org>
This message is placed in the public domain.