03 Jan 1999 15:13:13 +0100
>>>>> "Anders" == Anders Petersson <email@example.com> writes:
>>> 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
My point of view is that type of parameters of a function is part of
the specs for that function. To me it's a special case of specs. If
you have a function `f' which takes one parameter `p' and you don't
specify the type of the parameter, it will checked at run time
depending on how you use the parameter (à la Smalltalk). But you can
provide a pre conditition whch says that p should be an integer. It
will allow the compiler/interpreter to optimise in the case it knows
the parameters you give fo f is an integer. But you could also say
that p should be positive and smaller than 50. In this case, the
compiler/interpreter can choose to store the parameter on 6 bits if it
thinks it is accurate. (Chances are it is more efficient to store it
on a multiple of 8 bits).
Anders> My version is: shit happens. No system (at least not ours)
Anders> can to 100% assure that code is valid.
Unless code is generated by the system from the specs. It should be
enough to have a few axioms that we know are valid.
Anders> It could be hardware failures or hackers. If someone
Anders> alters the code so the program doesn't care for security,
Anders> well, then you've got no security any more. I don't
Anders> believe in compile-time security.
>> 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.
I would rather say that every object as a meta-object describing what
it is. It is just a question of vocabulary, but when you are talking
about types, the temptation is great to think about flawed known
systems. In a more general way, I think that it is preferable to use
new words when we refer to new concepts, in order to avoid confusion.
Anders> There must certainly be other errors than type errors. How
Anders> about communication failure, division by zero or missing
>>> >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
>>> >not take down the system. As you say, this will probably
>>> involve a
>>> _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
Anders> Umm... I think you will have to elaborate if you want me
Anders> to understand. Or maybe this is as clear as it can get. I
Anders> hope not, for all of us.
I am not I have understood what >> (?) meant, but my vision is that
compiled forms of the abstract specs of a procedure are just an
internal representation created by the compiler/interpreter in order
to gain efficiency.