Priorities

[Laurent Martelli]

>>>>> "Anders" == Anders Petersson <anders.petersson@mbox320.swipnet.se> 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
    >>> one?

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
    Anders> hardware?

    >>> >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
    Anders> should
    >>> >not take down the system.  As you say, this will probably
    >>> involve a
    Anders> 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.

    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. 

Laurent