Priorities

[Laurent Martelli]

>>>>> "Tril" == Tril  <dem@tunes.org> writes:

    Tril> Not if the source code was the "parent" (in mOS terms) of
    Tril> the binary, and was "notified" of changes in the binary...

    >> >* 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 problem is that you can rely on that no sane person would
    >> edit binary code with a honest purpose.

    Tril> To tweak it?  I think there are a lot of people who like
    Tril> messing with code at an ASM level.  As Fare always says, "if
    Tril> we don't support it, someone else will add it in the system,
    Tril> and make our system useless."  It's the user who decides
    Tril> whether or not they need to mess with binary code.  If they
    Tril> don't, the feature can be removed from their system.

Yes, of course, anybody can make its system unsecure. But he will have
to know what he is doing. Just when you are root on Unix, you can
really mess around, but since you're root, you're supposed to know
what you're doing.

    >> There must certainly be other errors than type errors. How
    >> about communication failure, division by zero or missing
    >> hardware?

    Tril> Division by zero: well, for sure this is a type error; it's
    Tril> been a type error in current systems. It's a simple domain
    Tril> error, the domain of denominator of division excludes zero--
    Tril> it is a type which does not have zero in it.  Therefore
    Tril> attempting to divide by zero is an expesssion which is
    Tril> incorrect.  It will never be evaluated if it is in a strong
    Tril> type checking environment.

I think that we can extend the notion of type checking withh the one
of preconditions. Division by zero is a precondition failure. When you
are talking about type here, I understand real numbers or
integers. And 0 is both anyway. But we could talk about R*, but I
don't think there's a relation of type between R* and R. It has rather
to do with sets. That's why I think that the notion of preconditions
is more general, and therefore preferable.

	[...]


    Tril> We can say that the "evaluator" abstracts the mechanism of
    Tril> running a program.

I like this term. It's definetly better than "compiler/interpreter" :-)

And I fully agree on all you said about compiling and interpreting. 
But I'll just add a few little words :

	Compiling is merely an optimisation of interpreting.

Laurent