From: William_J_G Overington (wjgo_10009@btinternet.com)
Date: Fri Mar 27 2009 - 07:03:36 CST
On Thursday, 26 March 2009, John H. Jenkins <jenkins@apple.com> wrote:
> First of all, I don't see why having a virtual machine
> programmed in as dedicated character code points is any
> better than having a virtual machine programmed via ASCII.
> It might be more compact, but from an implementation
> standpoint, that's about it's only advantage.
The sequence of characters is not stateful as regards what is text and what is software. There might be a partial exception in that string literals within software will be expressed by using Unicode characters and whether a character is in a string literal or not will be a stateful matter. For example, if a text document has an interactive illustration and the illustration displays some text as a prompt for user input or displays some text within the illustration.
> To show what you're up against, just look over the
> history of Java and remember that it started out with a
> major player in IT pushing it.
Java has been used to implement my telesoftware invention, both in Java TV and in the MHP system.
> And Java distinguishes the
> text used to write programs from the portable byte code used
> to implement them. You, on the other hand, are going
> against fifty years' experience in CS of making a
> distinction between the text used to write programs and the
> machine language used to execute it.
Well, I learned of the FORTH computer language many years ago and it has greatly influenced me at various times.
> You'll have to convince people to write editors or
> compilers/assemblers, debuggers, and so on.
Well, if there is interest in the idea, they may well write such items of their own volition.
> You'll have
> to get a set of experts together to hammer out the details
> of the architecture and syntax.
Well, if there is interest in the idea, they may well get together of their own volition.
> You'll have to determine how it will be displayed on systems that support it.
Well, that will need to be done, not necessarily by me.
> What is supposed to happen if the user has a regular
> font installed covering these code points?
That is why I am trying to get such a system into regular Unicode rather than keep it in a Private Use Area.
> How will the
> user distinguish cases where they want to *see* the code and
> cases where they want to *execute* it?
Normally it would be executed. Loading a file in editor mode would allow inspection.
> What happens if they don't want to do either?
Then do not use a portable interpretable object code enabled application package.
> What triggers execution, anyway?
The finish; command.
In the 7001 processor this is encoded as U+F7C7F finish; which is Alt 1014911 when keyed using Microsoft WordPad.
> What happens when execution stops?
The final display is left on the screen.
> What happens if execution *fails* to stop?
An animated illustration could run indefinitely.
> What happens if the code attempts something illegal like dividing by zero?
A good point. The system will need to have an exception handling facility. Thank you for drawing this to my attention.
> What will happen if this is embedded, say, in a URI or email or a file name?
I do not know at present.
> What happens if it's embedded in a word processing document?
It executes or displays the code, depending upon the view mode of the application.
> artwork?
I do not know at present.
> spread sheet?
I do not know at present.
> record in a database?
I do not know at present.
> instant message?
I do not know at present.
> Web page?
It executes.
> comment on a blog?
It executes.
> somebody's character name in an MMORPG?
I do not know at present.
> What are systems that don't support it supposed to do with it?
Gracefully ignore it.
> How will you prevent people from using it to write viruses,
> trojan horses, and other malware?
I do not know at present. However, if, say, the interpreter were implemented in Java, would Java security provide the necessary protection?
> Where does input come from?
Well, the 7001 processor has no user input. For a developed system implemented in regular Unicode, input could be from the end user or maybe some other source, such as a temperature sensor.
> Can it interact with a GUI?
I do not know at present.
> How do you display output?
The 7001 processor has just the putpixel(x,y,r,g,b); command at U+F7F77.
For a developed system implemented in regular Unicode, it would depend on what facilities the Unicode Technical Committee encoded.
> What is supposed to happen if you print it?
I do not know at present.
> Where is data stored?
In things such as a C or Java integer variable or array, or in a C or Java floating point variable or array, or in a C or Java character variable or array and so on.
> How will this interact with the various operating systems in existence?
They would be running an application program such as a text display program. I am thinking that if the operating system can use Adobe Reader then it could use an application that has a portable interpretable object code engine within it.
> How does it interact with the applications on those systems?
Well, as I envisage it at present, it should not need to interact with anything outside the application that is running it.
> There are a hundred other questions that will need specific answers.
Well, you are welcome to mention them.
> *Plus* you'll have to convince people to use it, and
> enough of them that you reach critical mass.
Well, maybe, maybe not. Maybe critical mass is already on the way to being achieved as a result of this thread and it is just a matter of time as people read this thread and think about it.
> Once that is done, you'll have to show that there is a
> practical reason why this has to be implemented in Unicode
> and convince the UTC and WG2 that such encoding as plain
> text is the best solution to the practical problem(s)
> involved.
Well, it would not need to be me that convinces the Unicode Technical Committee.
> By and large, any proposal for something which is not at
> least arguably "plain text" will not be favorably
> looked upon as a candidate for inclusion in Unicode. (N.B.,
> I said "arguably". Personally, I don't think
> this is even arguably plain text and is, at best, a solution
> in search of a problem, but I don't want to resurrect
> any of the past wars we've seen on certain candidates
> proposed for encoding.)
Well, I think that I have not claimed that it is plain text.
William Overington
27 March 2009
This archive was generated by hypermail 2.1.5 : Fri Mar 27 2009 - 08:44:18 CST