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.

 

[Skybuck Flying]

One final example plus further analysis to be perfectly clear what fine code
would look like and why it's adventage:

At the bottom I come to the conclusion that the proposed loop construct with
begin and ending conditions has merit after all ! =D

LoopBegin

if not BeginningCondition then LoopBreak

...Code...

if EndingCondition then LoopBreak

LoopEnd


This gives programmer full control over if the loop should be a while loop
or a repeat until loop.

Should it have a beginning condition ?

Should it have a ending condition ?

Both can be writting without having to change the main loop statement block:

Begin

End

Also both kind of while/repeat until functionalities can be integrated.

It also allows to seperate logics, from begin/enter and end/exit.

There is one little problem with the above code:

the not, this is still logic inversion.

It could have been written as follows

if LoopSkipCondition then LoopBreak

However that's not convenient.

Therefore this posting must conclude that a special loop construct is
usefull:

LoopBegin( EnterCondition )

LoopEnd( ExitCondition )

This would have allowed the code above to be written as:

LoopBegin( BeginningCondition )

LoopEnd( EndingCondition )

^ No logic inversion needed.

So this construct has merit after all.

Bye,
Skybuck.

 

[Steven D'Aprano]

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

That's a very ... interesting ... statement.

Oh look, your post was cross-posted to no fewer than four newsgroups.
What a surprise!

 

[Peter Cacioppi]

You know, I'd heard somewhere that Goto was considered harmful.... trying to remember exactly where....

 

[Skip Montanaro]

You know, I'd heard somewhere that Goto was considered harmful.... trying

to remember exactly where....

I can't tell if you were kidding or not... Just in case:

http://en.m.wikipedia.org/wiki/Considered_harmful

(can't grab the [2] & [3] links on my phone)

Skip

 

[Peter Cacioppi]

yes it was a joke, apparently not a good one

You know, I'd heard somewhere that Goto was considered harmful....

trying to remember exactly where....

I can't tell if you were kidding or not... Just in case:

http://en.m.wikipedia.org/wiki/Considered_harmful

(can't grab the [2] & [3] links on my phone)

Skip

 

[Peter Cacioppi]

Cmon, Skip, assuming everyone gets the "considered harmful" reference falls under the "we're all adults here" rubric.

 

[Mark Lawrence]

You know, I'd heard somewhere that Goto was considered harmful.... trying to remember exactly where....

Yep, but it's used throughout the CPython code for error handling,
nothing wrong with that as it's crystal clear that you're going to one
place for one purpose. Contrast that with its use in spaghetti code
where you're leaping around like a naked person on an ant hill.

--
Roses are red,
Violets are blue,
Most poems rhyme,
But this one doesn't.

Mark Lawrence

 

[Mark Lawrence]

Cmon, Skip, assuming everyone gets the "considered harmful" reference falls under the "we're all adults here" rubric.

Context, context everywhere.... trying to remember exactly where....

--
Roses are red,
Violets are blue,
Most poems rhyme,
But this one doesn't.

Mark Lawrence

 

[Chris Angelico]

Yep, but it's used throughout the CPython code for error handling, nothing
wrong with that as it's crystal clear that you're going to one place for one
purpose. Contrast that with its use in spaghetti code where you're leaping
around like a naked person on an ant hill.

How bad can it be?

http://xkcd.com/292/

ChrisA

 

[Mark Lawrence]

How bad can it be?

http://xkcd.com/292/

ChrisA

Love it

See also http://matplotlib.org/xkcd/index.html ???

--
Roses are red,
Violets are blue,
Most poems rhyme,
But this one doesn't.

Mark Lawrence

 

[Peter Cacioppi]

Just because the CPython implementation does something doesn't mean that thing is something other than risky/tricky/to-be-avoided-if-possible. Python (and it's implementations) exist so that ordinary people can avoid doing risky stuff.

I'm not critiquing the CPython implementation here, I'm pointing out that some languages are just better than others for most projects. Working in a higher level where gotos aren't needed is the right call most of the time.

 

[Dave Angel]

Just because the CPython implementation does something doesn't mean

If you're going to drop messages in here with no context, you'd be
better off just putting it in a bottle and tossing it into the sea.

Include a quote from whomever you're responding to, and we might
actually take you seriously. And of course, make sure you don't delete
the attribution.

 

[Bernhard Schornak]

Skybuck Flying schrieb:

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

Why?

...
dec rcx
jbe 1f
0:some
code
to
perform
...
jmp 0b

p2align 5,,31
1:continue
with
something
else
...

This code triggers one penalty if RCX was zero or negative (it jumps directly
to label 1 after the penalty for the wrong assumption "not taken" passed by),
or two penalties if RCX was positive - one for the 2nd assumption is "taken",
one for the finally taken conditional jump.

The same applies if you moved the condition check to the end of the loop, but
you could not catch negative numbers / zero without executing the code in the
loop at least once.

There is no general rule which construct should be preferred. In the end, the
one suiting your needs might be the best choice. On the other hand, no one is
able to predict which code might be generated by a specific HLL-compiler.


Greetings from Augsburg

Bernhard Schornak

 

[Skybuck Flying]

Because it's logical.

If the exit condition was placed on the top, the loop would exit immediatly.

Instead the desired behaviour might be to execute the code inside the loop
first and then exit.

Thus seperating logic into enter and exit conditions makes sense.

Bye,
Skybuck.

 

[Peter Cacioppi]

Dave said :

"Include a quote from whomever you're responding to, and we might
actually take you seriously. And of course, make sure you don't delete
the attribution. "

This forum is working for me. One of the more frequent and sophisticated posters emailed me saying he appreciates my contributions.

I'm sorry I'm putting in a bustle in your hedgerow (just a little bit sorry) but I've got 20 balls in the air right now and I haven't got around to configuring a proper client for this feed. The default Google Group client isnotoriously cruddy with quotes attribution.

Some readers can discern context from the previous posts. That's sort of what the word context means. But I understand this skill isn't universal.

If it makes you feel better, I'm mostly lurking/learning and just posting on areas where I have expertise.

Thanks for letting me off with a warning officer, I'll do better next time.

 

[Terry Reedy]

The default
Google Group client is notoriously cruddy with quotes attribution.

So don't use it. Get any decent newsreader, such as Thunderbird, and
access the list at news.gmane.org as gmane.comp.python.general.

 

[rurpy]

So don't use it. Get any decent newsreader, such as Thunderbird, and
access the list at news.gmane.org as gmane.comp.python.general.

Peter, you can ignore Terry's "advice" if Google Groups works for you.
There are a small number of Google haters here who seem larger due to
their obnoxious noisiness.

I've been using Google Groups to post here for many years and with a
little care it is usable without annoying anyone except a few drooling
fanatics. All access methods have pros and cons (and I've posted here
about many of TB numerous cons) so if the usability tradeoff favors
GG for you (or anyone else) I recommend you not be intimidated by
the anti-GG goon squad.

 

[Chris Angelico]

Peter, you can ignore Terry's "advice" if Google Groups works for you.
There are a small number of Google haters here who seem larger due to
their obnoxious noisiness.

I've been using Google Groups to post here for many years and with a
little care it is usable without annoying anyone except a few drooling
fanatics. All access methods have pros and cons (and I've posted here
about many of TB numerous cons) so if the usability tradeoff favors
GG for you (or anyone else) I recommend you not be intimidated by
the anti-GG goon squad.

As soon as we hear of people automatically blacklisting any posts that
come from Thunderbird, I'll believe you that they're on par. Until
then, no matter how courteous you might be in your use of GG (which
still makes you part of an extremely small minority), you still have a
fundamental downside in that your message simply won't get to
everyone.

As to "without annoying anyone except a few drooling fanatics" - I
wouldn't count myself among those fanatics (do you count me there?),
but the GG issus (mainly with regard to quoted text) DO annoy me, and
very much. Just because I don't flame people or throw tantrums doesn't
mean I don't mind.

ChrisA

 

[Terry Reedy]

Peter, you can ignore Terry's "advice" if Google Groups works for you.

Rurpy: My advice was real advice (what I do) given in response to
Cacioppi's complaint 'notoriously cruddy'.