Possibly better loop construct, also labels+goto important and on the fly compiler idea.

[Skybuck Flying]

version 0.01 created on 17 october 2013 by Skybuck Flying.
(after having some experience with python which lacks repeat 
until/goto/labels and programming game bots)
(the exit conditions described below prevent having to use logic inversion: 
while BeginCondition and not EndCondition <- ugly logic for while loops, 
below construct should be cleaner: LoopBegin(True)  LoopEnd(True)  instead 
of While (True and not True) therefore below construct is more consistent 
all conditions evaluate to true to trigger it's affect, begin=true, 
end=true)

Possibly a better looping construct for programming languages.

To understand why the proposed looping construct is better than existing 
constructs we first have to analyze and describe the problems with current 
existing looping constructs:

Programming languages: C, Pascal, Delphi, Java, Phython have the "while" 
construct:

while Conditions do
begin


end

Logically this loop makes no sense assuming the following 
theory/assumptions/concepts about loops:

Either a loop is something that always enters and continues forever until 
otherwise specified (most basic form)

Or a more clean approach:

A loop has a starting condition, a ending/exiting condition and additional 
exiting/continueing options.

Therefore a more basic construction could be:


LoopBegin( EnterConditions )

    if Conditions then LoopBreak

    if Conditions then LoopContinue

    if Conditions then LoopsExit

LoopEnd( ExitConditions )


^ This integrates the while loop and the repeat until loop of C and Pascal 
into one construct saving the programmer
from having to fiddle around with code... changing while to repeat until or 
vice versa.

This hereby indicates problems with the while loop: it makes little sense to 
put the exiting conditions at the top.

These belong at the bottom or in the intermediate code.

One drawback of this proposed new structure is that it introduces unnecesary 
complexities but those could be optional.

A cleaner loop construct could be:

LoopBegin

    if Conditions then LoopBreak

    if Conditions then LoopContinue

    if Conditions then LoopsExit

LoopEnd


This allows the programmer to place the beginning and exiting conditions 
anywhere.

Ofcourse the entering conditions could simply be omitted and still lead to 
valid code so they could be optional as mentioned above.


The LoopBreak would cause the loop to proceed to it's exit point.

The LoopsExit would cause all nested loops to proceed to the main exit 
point.

The loopContinue would cause the loop to skip all code and proceed back to 
the start of the loop.

After a while I think programmers would get more used to these kinds of 
programming constructs and don't have to choose between while or repeat 
until.

Another syntax form could be:

BeginLoop

    if Conditions then BreakLoop

    if Conditions then ExitLoops

    if Conditions then ContinueLoop

EndLoop

To be more inline with the Pascal Syntax.


Computer languages should also support labels and the goto statement so that 
code recovery from failures is more easy:

Example:

while True:
    Step1:
        ...Code...

    Step2:
        ...Code..

        if ...Failure.. then
            GoTo Step1


    Step3:

        ...Code...

        if ...Failure... then
            Goto Step 2

    Step 4:
        ... Code...

        if ... Failure... then
            GotTo Step 0

    Step 5:
        ... Code...

        if ...Special... then
            GoTo step 10

Unfortunately python does not have labels and goto statements as far as I 
know which makes the writing the following code a bit more complex and 
slower:


while True:

    if Step = 1:
        ... Code ...
        Step = Step + 1

    if Step = 2:
        ... Code ...

        if ...Failure... then
            GotoStep1

        Step = Step + 1

    etc

^ unnecessary step variable introduced to mimic goto+labels, unnecessary if 
statements introduced to support it.

Current problem with intel instruction set is instructions have variable 
size, this prevents using the instruction pointer to simply jump to certain 
instruction addresses.
(It's possible but it's hard to know where the addresses are, the idea below 
could solve this):

One possible solution could be to introduce a "on the fly compiler".

It compiles the code "on the fly" and indicates to the programmer where 
certain instruction addresses are.

Then perhaps the programmer can write code as follows:

    ... Code1 ...

    ... Code2 ...

        if Failure then
            GoTo CodeAddress1

    ... Code3 ...

        if Failure then
            GoTo CodeAddress2

The code addresses could be shown on the left side just as line numbers.


Possible problems introduced: when instruction code addresses would be off. 
Either the programmer has to correct this, or the IDE/Tool could auto 
correct it.

Leading to slightly more clean code and might make programming in 
machine-like languages more popular, these languages would offer more 
flexible and more power, especially
for writing high performing and robust code.

Perhaps even self modifying code programming languages in the future for 
artifical intelligence/evolving computer programs/warfare bots/etc,
a fixed size instruction set would be preferred for such a beast.

Bye,
  Skybuck.