Priorities

[Anders Petersson]

Tril wrote:

>On Sun, 3 Jan 1999, Anders Petersson wrote:
>> >On Sat, 26 Dec 1998, Anders Petersson wrote (in unios@onelist.com):

>> It turns out that users are developers too.
>> I have a somewhat differing view of how this will be made possible. Instead
>> of compact application packages, programs are divided into smaller
>> components, each one independent. The application has one way it uses the
>> components by default, but anyone can use the components as building blocks
>> or tools to accomplish whatever he wants. This can be seen as some sort of
>> very high level programming, like all UNIX commands, but with a finer level
>> of control and more possibilities than in UNIX.
>
>Yeah, I agree.  The user builds a program (tool) specifically for the task
>at hand by constructing it out of small tools.  Similar to UNIX, except
>in our system this philosophy will be consistent system-wide, not just at
>the shell.  

Yes! Exactly what I think!

>A big difference is that the tool construction system IS 
>the programming language, user interface, and the low-level system is
>built with it, too.

I'm not sure... I've thought of something in that way, but not so totally
thoroughly. Would it really be convenient for the user?
By "low-level system", do you mean the actual control of the hardware? In
such case, I can't see how that can be done with any universal tool
construction system.

>> You're speaking about _language designers_. I'm not that. mOS limits itself
>> to the "public" design of the system - the language used is not dealt with.
>
>That's a major difference with UniOS and TUNES, since in tunes the system
>IS the language.  The object system is used to implement any language
>features or specific languages you need.  It seems like in UniOS, the
>objects are written in a language, but the language itself is not composed
>of objects.  Am I right?

You are right. In UniOS, as long as the platform-independence is preserved,
any language can be used. Anyway, I'm interested in the TUNES way, and I'd
love to hear how such a language could look. Maybe the Arrows language?

>> >* 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. 
>> 
>> This is just too *unrealistic* to be commented.
>
>Not if the source code was the "parent" (in mOS terms) of the binary, and
>was "notified" of changes in the binary...

1) I don't see a use for this in the first place.
2) It's easier to use assembler (or something else) to make changes in the
source than applying some patch directly to the binary - the source is
always there.
3) The mechanisms to translate changes into source code I fear would be
very hard to implement - only to get to argument #1.
4) Because of #1 and #3, knowing when a change is made doesn't help.

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

My thought was that if you can get change the binary after some
compile-time security check, you could break all kind of security measures.
More information (from this thread and IRC) has revealed that the TUNES
system would not be subject to such flaws.

I'm just trying to find weaknesses in your design, with a constructive
purpose.

>In tunes, since the source is around all the time, any time is compile
>time.  Compile-time security is all the security you need.  (See below)

Yah.

[type errors]
>> There must certainly be other errors than type errors. How about
>> communication failure, division by zero or missing hardware?
>
>Division by zero: well, for sure this is a type error; it's been a type
>error in current systems. It's a simple domain error, the domain of
>denominator of division excludes zero-- it is a type which does not have
>zero in it.  Therefore attempting to divide by zero is an expesssion which
>is incorrect.  It will never be evaluated if it is in a strong type
>checking environment. 
>
>I assume you are referring to missing hardware at boot time.  The boot
>sequence (hypothetically) includes an operation to "add driver for device
>to system."  This operation's type is only valid for working drivers.  So
>the driver is evaluated first, and if it decides the hardware is not
>working, it won't become a driver of the right type, and the "load device
>driver" operation will fail due to a type error.  This may seem contrived,
>but all errors can be made into type errors in this way -- by having all
>assumptions explicit in the argument types of operations.  To me, this
>seems to make the system a whole lot simpler: If type checks work, you can
>be sure the system is working properly!

Ok, if you see type errors in that way...
What advantage would this bring?

>What I was trying to say above is you provide the source for programs, and
>the system decides whether to compile or interpret the source.  That is,
>all code is run by the same program ("evaluator"), which is both a
>compiler and interpreter.  It can choose itself which to use, or you can
>tell it as an option.  In addition, each subprogram (function in the
>program) can be compiled or interpreted.  So the extent to which a program
>is compiled/interpreted can vary.

I see. This reminds me of an article I read in a Swedish paper on a team of
programmers that would try to make an adaptively optimizing compiler for
Java... resembling, not?

>[The following may not make sense, please ask for further clarification] 
>Whichever evaluator is implicit is the one that does the typecheck. That 
>way invalid type errors never occur in an environment explicitly and are 
>always caught "just in time." That's all I'll explain about that for now. 
>(explaining it fully involves reflection, and is the direction we need to 
>go, but some other time.)

It sounds like you have a clear idea about this language/system. But no,
that paragraph made no sense to me.