[OT] Eternal programming

[Roman Suzi]

On Sun, 8 Jul 2001, Bengt Richter wrote:

>On Sat, 7 Jul 2001 17:55:56 -0700, "John Roth"
><johnroth at ameritech.net> wrote:
>>I don't see why it couldn't be of much more utility. The big problem is
>>performance, since you're talking about a two level interpreter. The last
>>time I saw anything quite that slow was a /360 running a 1410 emulator
>>running a 650 simulator.
>I am getting the impression there's a lot of OF's around here ;-)
>I remember when you could go to any IBM office and get an armload
>of system and programming manuals just for the asking. The 650 manual
>was the first computer manual I ever looked at ;-)
>
>>
>>Very interesting idea. The trouble is, I can't see it being really small.
>>Making it cleanly extensible seems to require some of the features that
>>support extendability, such as namespaces (Forth dictionaries), etc.
>>
>>Anyone want to work on it - either technically or politically?
>Well, the nuclear waste problem is probably the most eternal thing
>we've managed to create yet, so there ought to be application
>for 'Eternal' somehow with that ;-/
>
>Actually, I think there are people very concerned about the viability
>of digital archives from the point of view of survivability of
>the access methods and devices. I'd bet the Library of Congress has
>folks worrying about this.

I am glad to see biological examples. Eternal program is like seed
which could grow around small rightly built environment.

The problem, as I see it now, is scientific: which features
to include to the core. For example, if one want to do logic,
there is only one operation needed (i do not know how to call it in
English:

X    Y      X/Y
0    0      1
1    0      1
0    1      1
1    1      0

With this single operation you can build any boolean operation:

not X  ==  X/X
X and Y  == not(X/Y) == (X/Y)/(X/Y)
X or Y == (not X)/(not Y) == (X/X)/(Y/Y)

and so on!

I believe, that there is some set of operations which is as general as
Turing machine BUT is easily evolutionable into something practical.
The above means you need to implement only one operation and library
will create: AND, OR, XOR, NOT, ... whatever.

Same applies to arithmetics. Field operations need to be
supplied: x+y, -x, x*y, 1/x.

I think Eternal will also need strong text-processing capabilities.
Thus minimal DFA regex need to be built in. (this is beneficial to
core itself, because it will need some parser and the parser could be
available for program evolution as well.) Deterministic Turing machine
is DFA + potentially unbounded memory to play on.

It's really interesting reasearch which (probably) nobody has done
yet.

State of the Eternal machine could be comprised of a dictionary of
lists of strings (which are keys to the dictionaries or literals)
(Pythoner's thinking showing ;-) and interpreter will be just
executing elements from some list while not told to switch to another
one. Program could be self-modifying all the way, like in Lisp.

At first, only main interpreter loop entry exists, entry for the
interpreter EXEC, dictionary/list access operations, IO and
fundamental arithm. and logic things. ALL these could be replaced later by
more advanced versions from library.

def core_add():
  memory["STACK"][0:2] =  [int(memory["STACK"][0]) + int(memory["STACK"][1])]

memory = {
'EXEC': core_exec,
'MAIN': ['READ', 'EXEC', 'MAIN'],  # tail recursion need catching
'READ': core_read_input,
# ...
'ADD': core_add,
'IP': ['0', 'MAIN']
'STACK': [],
}

interpreter(input, memory) -> output


Sincerely yours, Roman Suzi
-- 
_/ Russia _/ Karelia _/ Petrozavodsk _/ rnd at onego.ru _/
_/ Sunday, July 08, 2001 _/ Powered by Linux RedHat 6.2 _/
_/ "The days of the digital watch are numbered" _/