[#BOO-995] Add the "or" keyword semantic for for/while loops

Boo

Add the "or" keyword semantic for for/while loops

Created: 12/Apr/08 07:57 AM Updated: 14/Apr/08 09:16 AM

Component/s:

Compiler

Affects Version/s:

0.8.1

Fix Version/s:

0.8.2

Time Tracking:

Not Specified

Issue Links:

Related

This issue relates to:

~~BOO-988~~ optional 'else' block for 'for' and 'while' loops

This issue is related to:

~~BOO-996~~ Modify the for/while "else" semantic to use a new keyword: "then"

Testcase included:

yes

Description

« Hide

Allow "or" as in:

"""
No items!
"""
t = []

for item in t:
  print item
or:
  print "No items!"

"Or" executes its block of code only when the iterator (in for loops) or condition (in while loops) evaluates to empty or false, respectively, on the first test, i.e. before entering the loop. If control enters the loop, then the "or" block will not be executed.

"Break" and "continue" are valid within an "or" block. When no "then" block exists, they convey the same semantic, passing control to the statement after the or block. When a "then" block exists, "break" passes control to the statement after the "then" block, whereas "continue" passes control to the "then" block. The idea here being that if the iterator/condition is empty/false on a "continue", then exit the loop via the "then" block as if the loop were executing.

This pseudo-IL indicates the execution flow without a "then" block:

flag = false
goto cond
:body
flag = true
<loop_block>
:cond
if <cond> goto body
if flag goto end
<or_block>
:end

With a "then" block the pseudo-IL is as follows:

flag = false
goto cond
:body
flag = true
<loop_block>
:cond
if <cond> goto body
if flag goto end
<or_block>
:then
<then_block>
:end

All

Comments

Work Log

Change History

Sort Order:

Ascending order - Click to sort in descending order

[ Permlink | « Hide ]

Cedric Vivier - 13/Apr/08 07:57 PM - edited

list as List  #let's say it's a member of a class for a more common usage
    
for i in list:
    print "in"
or:
    print "or"

This code 'obviously' results in a NullReferenceException.
However I think the 'or' construct should handle this nicely, as this match the semantic (loop is not entered) and would allow shrinking the common scenario below :

if list is not null:
    for i in list:
    ...
else:
    ...

Thoughts?

[ Permlink | « Hide ]

Marcus Griep - 14/Apr/08 08:59 AM - edited

As in this pseudo-IL?

if <iterator> == null goto or
<enumerator> = <iterator>.GetEnumerator()
flag = false
goto cond
:body
  flag = true
  <loop_block>
:cond
  if <enumerator>.MoveNext() goto body
  if flag goto end
:or
  <or_block>
:then
  <then_block>
:end

If that's the case, I think it's a separate ticket. The real question is whether we should behave this way on null values. It wouldn't affect while, only the way in which for interprets a null iterator.

[ Permlink | « Hide ]

Cedric Vivier - 14/Apr/08 09:16 AM

Yes as in this pseudo-IL.
Imho this adds more value and potential usages to the 'or' construct while being consistent ('or' is executed when you do not enter the loop).
What do you think? Rodrigo? Avish?

Also I guess this doesn't deserve a separate ticket for itself, in some way it is still about the addition of the 'or' keyword which haven't been in a release yet, but do as you prefer of course.