OpenEuphoria

2. Re: loop do .. until end loop is surely incorrect!

• Posted by mattlewis (admin) Feb 24, 2011
• 2150 views

loop do  
  integer x = 3  
  until x = 3  
end loop  

The manual is a bit ambiguous. The until is really a part of the end loop statement. The docs should be clarified.

I still disagree. The body of the loop is its own scope. The loops beginning and ending are outside of that scope. The loop's test is part of either the beginning or ending statement of the loop.

while TRUE with entry do 
  integer x = 3 
entry 
  ? x 
end while 

Yes, you shouldn't write code like that. It's really no different than:

integer x 
if foo() then 
    x = 1 
end if 
? x 

Matt

4. Re: loop do .. until end loop is surely incorrect!

• Posted by bill Feb 24, 2011
• 2054 views

If what Matt says is the case then the construct should be:

loop do 
  ... 
  integer x = 3 
  ... 
until x=3 

no end loop, and scope ends at until. The declaration is incorrectly used at until x = 3.

This is counter-intuitive as the wording is to end loop which is what until x = 3 is.

Note: i's scope in for i .. end for ends with the exit from the loop.

If the loop is unrolled the code fails as there would be multiple redefinitions of the declared variable(s) in the resultant code. The scope would be lost along with the until - or rather the scope would have to be retained which means the loop cannot be unrolled.

Yet it should always be possible to unroll a loop.

One way declaration within a loop could work correctly is with a block:

loop do 
  ... 
  def integer x = 3 
  ... 
  end def 
  ... 
until .. 

But that is really to say: no declaration in loops.

6. Re: loop do .. until end loop is surely incorrect!

• Posted by _tom (admin) Feb 25, 2011
• 1938 views

I have been working on a re-write of the documentation on scope. Here are some ideas that I am getting so far.

The short form is that I intend to change the documentation so it does not say end loop defines the limit of scope--but merely finishes off the loop construct.

integer x = 10 
loop do 
    ... 
    x = x-1 
until x<=0 

It was described then as "having a distinctive form"-meaning not like a typical Euphoria construct. That was about one year ago.

It is characteristic of Euphoria that a keyword starts a construct, and end keyword completes it. So when loop finishes with end loop, no explanations are needed--it looks like correct Euphoria.

This is part of the charm of Euphoria; consistency and clarity (at the cost of some extra typing.) No invisible structure (Python) or squirrelly braces (C, Java) and special punctuation rules (Python, C, ... ) are needed.

Yes, I argued against the original design.

If you compare Euphoria to other languages you will notice that they have many "distinctive" features. Any one which is small and logical when it is explained to you. A lot of these distinctive features are clever, convenient, and truly useful; I think fans of Perl would argue this viewpoint. Put them all together and you end up with something that is a lot slower, a lot harder to learn and use than Euphoria.

This all starts to make sense when you view things in terms of space and then scope.

I define "space" as the area "where" you can type your own statements within a statement. The boundaries of space are reasonably clear by examination.

I define "scope" as "what" identifiers are visible in a space, and if they are visible in more than one space. This is more tricky, but the rules turn out to be logical and as always Euphoric.

The current design looks like this:

integer x = 10 
loop do 
    ... 
    x = x - 1 
until x <=0 end loop 

Arthur's presentation looks good:

integer x = 10 
loop do 
    ... 
    x = x - 1 
until x <=0 
end loop 

The idea is that end loop is not the terminus of scope, only the finish of the entire construct.

Viewing the loop in terms of space gives you:

integer x = 10 
 
loop do 
 ________________________ 
|                       | 
|  ...                  | 
|                       | 
|                       | 
| x = x - 1             | 
|_______________________| 
 
until x <= 0 end loop 

The box is the working space, the x<=0 is not part of this space, it is part of the loop construct.

Similarly:

for i=1 to 3 do 
 ________________________ 
|                       | 
|                       | 
|  ...                  | 
|                       | 
|                       | 
| x = x - 1             | 
|_______________________| 
 
end for 

The same pattern goes for something like a for loop. The i=1 is not part of the working space, it is part of the loop construct. The "x<=0" of the until is outside of the box, just like the "i=1" is outside of the box.

Scope is bounded by space and not the end keyword.

Block scope has weak boundaries--that is why a prior declaration can influence what is permitted within a block. Block scope is not up to the encapsulation ability of a routine.

integer x = 10            --1 
  
loop do                   --2 
 ________________________ 
| integer x = 10        | --3 
|  ...                  | 
|                       | 
|                       | 
| x = x - 1             | --4 
|_______________________| 
 
until x <= 0 end loop     --5 

If line3 is absent, line1 declares x and is used by line5 (This looks quite sensible.)

Allowing line3 creates problems and ambiguity.

1. If the box has a weak boundary, then line3 is redefining line1 (much too chaotic).
2. If the box has a strong boundary, how does line3 "get out of the box" to control line5?

For line3 to control line5, a special rule would have to be invented. Euphoria is a language that does not operate under special rules.

So if you leave out line1, running this example gives you a message that means the 'x' in line5 was not defined.

With both line1 and line3, running this example gives you a message that means you are trying to redefine 'x'.

If you are looking at a bigger box than I see, then yes, I can understand your viewpoint.

_______________________ 
| loop do               | 
|    integer x = 3      | 
|    until x = 3        | 
| end loop              | 
|_____________________  | 

This design is incompatible with the definition of space as I have defined it. My definition is simpler, so in Euphoria terms, "more correct."

-- one line if 
if x=1 then ... end if 
 
-- indented block 
for i=1 to 9 do 
    .... 
    .....      end for 

Old Pascal code was sometimes formatted in this fashion; Python does this as the only way. The Euphoria end for provides (comforting) redundancy.

loop do 
    integer x = 3 
    until x = 3 
end loop 

In a Fortran kind of thinking I can see how this is "misleading." The columns suggest structure that is not there.

8. Re: loop do .. until end loop is surely incorrect!

• Posted by useless Feb 25, 2011
• 1915 views

That's often bitten me, because if i am looping to scan thru a sequence of stuff, backing up or making another pass thru the same subsequence should be as easy as manipulating the loop variable. Cannot do this in Eu.

To be more on-topic of this thread, I considered a "until" to be a "goto" or "exit" or "escape" or "jmp". In this sense, "until" is part of the body inside the "loop-end_loop" construct.

useless

10. Re: loop do .. until end loop is surely incorrect!

• Posted by DerekParnell (admin) Feb 26, 2011
• 1805 views

loop do  
  integer x = 3  
  until x = 3  
end loop  

I cannot find this in the manual. Can you tell me where you can see this construct in the manual?

Maybe the manual should make it clearer what part is the 'loop boundaries' and what part is the 'loop body'.Something like ...

LOOPSTMT ::= LOOP_PREFIX LOOP_BODY LOOP_SUFFIX 
LOOP_PREFIX ::= 'loop' [ 'with' 'entry' ] [ 'label' STRINGLIT ] 'do' 
LOOP_BODY ::= STATEMENTS [ 'entry' STATEMENTS ]  
LOOP_SUFFIX ::= 'until' CONDITION 'end' 'loop' 

Is there something stopping you from moving the declaration outside of the loop body? ...

integer x = 3  
loop do  
  -- statements ... -- 
  until x = 3  
end loop  

"depend on syntax" ... like all the other programming languages do?

Actually the scope in Euphoria, just like other languages, is from the declaration to the end of the block that contains the declaration, which is just prior to the 'until' clause.

while TRUE with entry do 
  integer x = 3 
entry 
  ? x 
end while 

A better parser/syntax analyser could prevent this sort of thing from compiling. But are you surprised that it fails to run? In effect it is the same as ...

? x 
integer x = 3 

12. Re: loop do .. until end loop is surely incorrect!

• Posted by bill Feb 26, 2011
• 1676 views
• Last edited Feb 27, 2011

I disagree bill, and this is why.

The original code you posted was ...

while TRUE with entry do  
  integer x = 3  
entry  
  ? x  
end while  

which is the effectively the same as ...

while TRUE with entry do  
  integer x 
  x = 3 
entry  
  ? x  
end while  

And then if we rewrite the loop in terms of goto and labels we get something like ...

goto "entry" 
label "loop_top" 
if not TRUE then goto "loop_bottom" end if 
  integer x 
  x = 3  
label "entry" 
  ? x  
  goto "loop_top" 
label "loop_bottom" 

And then if we clear away the stuff which is never executed, we get...

goto "entry" 
  integer x 
label "entry " 
  ? x -- fails at this point 

Finally, if we reorder to reflect execution path and thus get rid of the goto statements...

  ? x -- fails at this point 
  integer x 

So I maintain that your code snippet is equivalent to referencing a variable before it gets its initial assignment.

It may be you are misunderstanding the "with entry" clause. By default, when the clause is omitted, entry into the loop body is at the point immediately after the "do" keyword. The "with entry" clause enables one to nominate a different entry point than the default one. Now most of the time, the default entry point is the most convenient one, but occasionally (such as the example you quote below) a different point of entry is convenient.

  public function find_all ( object x , sequence source , integer from ) 
    sequence ret = {} 
    while from > 0 with entry do 
      ret &= from 
      from += 1 
    entry 
      from = find_from (x , source , from ) 
    end while 
    return ret 
  end function 

Yes ... so what?

Yes, the 'from' parameter as called can have potentially any value.

Yes ... and that's a good thing, no?

Actually it will always point to an instance of x at this stage. That is why the "+= 1" is needed.

And what exactly do you mean by that? It should fail, and the failure should have what effect on the program?

By the way, the code above will fail if the initial 'from' is <= 0.

  public function find_all ( object x , sequence source , integer from ) 
    assert(length(source)>= from and from > 0, "out of range")  
    sequence ret = {} 
    integer nxt = from-1 
    while TRUE do 
      nxt = find_from (x, source, nxt+1) 
      if ! nxt then exit end if  -- better: exit when ! nxt* 
      ret &= nxt 
    end while 
   return ret 
 end function 

And I believe that this implementation is worse than the current one.

• Neither implementation changes the statement order.
• The "nxt = from-1" is a kludge because your code assumes that 'nxt' points to an instance of 'x' -- except for the first time through. The "from +=1" is not a kludge as it is the natural way to scan from the next element.
• The assertion is not required because the initial call to find() will fail in the same manner as the assertion if the 'from' argument is invalid. The "with entry" has nothing to do with validating the initial 'from' argument value.
• A 'while TRUE' to loop does not document a termination condition and seems to imply an infinite loop.

I like the 'exit when' idea as a neater syntax shortcut, and it has a good chance of being implemented one day.

A better parser can alert the coder about poor coding earlier than runtime, and that has got to be a good thing. And what do you mean by "dark corners"?

The "entry while" is not a pointless construct. I guess we will have to agree to disagree.

We cannot prevent many stupid coding practices regardless of how much we document stuff, and if coders try something dumb then its my guess that they will learn from their mistakes soon enough.

Euphoria is not a nanny language. It allows one to code in a style that the coder chooses.

bill, you are not being forced to use 'with entry'. If you don't like then don't use it. I don't like goto so I won't use it (unless forced to).

14. Re: loop do .. until end loop is surely incorrect!

• Posted by ArthurCrump Feb 27, 2011
• 1558 views

 for x=1 to 10 do 
  integer x---you can't do this here 
  x+=1 
  if x=3 then exit end if 
 end for 
<\eucode> 

16. Re: loop do .. until end loop is surely incorrect!

• Posted by DerekParnell (admin) Feb 27, 2011
• 1550 views

I understand what you are saying but I still don't agree. I'd say that "while from >0 do" suggests that but not "while from>0 with entry do" because the "with entry" clause tells you that the loop's entry is elsewhere.

But again, it is not mandatory. Don't use it if you don't want to. And if you find it in someone else's code, at least know know how its supposed to work so you should be able to still read the code.

The "with entry" clause was implemented to help reduce code duplication as it applies to that subset of loops in which the 'pre-iteration code' and the 'next iteration code' are identical. I'm sure you are all too familiar with the construct. For example, processing the lines in text files...

The 'old' way...

object line 
line = gets(F) 
while sequence(line) do 
    Process_the_Text(line) 
    line = gets(F) 
end while 

Alternatively ...

object line 
while TRUE do 
    line = gets(F) 
    if not sequence(line) then exit end if 
    Process_the_Text(line) 
end while 

The "entry" way ...

object line 
while sequence(line) with entry do 
    Process_the_Text(line) 
entry 
    line = gets(F) 
end while 

Of course this is just a simple example, but here are some longer examples from the standard library ...

while data[1] != -1 with entry do 
    jx = hash(jx, data) 
    ix = remainder(jx, size) + 1 
    cs[ix] = xor_bits(cs[ix], hash(data, stdhash:HSIEH32)) 
    hits[ix] += 1 
entry 
    for i = 1 to length(data) do 
        data[i] = getc(fn) 
    end for 
end while 

while sequence(result) with entry do 
    results = append(results, result) 
    from = math:max(result) + 1 
    if from > length(haystack) then 
        exit 
    end if 
entry 
    result = machine_func(M_PCRE_EXEC,  
                 { re, pHaystack, length(haystack), options, from, size }) 
end while 

while indx_a <= length(A) and indx_b <= length(B) with entry do 
    if not equal(A[indx_a], B[indx_b]) then 
        exit 
    end if 
entry 
    used_B[indx_b] = 1 
    used_A[indx_a] = 1 
    indx_a += 1 
    indx_b += 1 
end while 

18. Re: loop do .. until end loop is surely incorrect!

• Posted by DerekParnell (admin) Feb 27, 2011
• 1503 views

I can live with that.

I agree with you about the construct transformation, but I still don't believe it is the better style.

Let's leave this at the point where we agree to disagree.

Euphoria allows for various coding styles and practices, and not everyone will support all of those. However, I think that we should continue to allow coders to express themselves as they wish to. I fully expect that Euphoria will implement additional syntax that supports yet more coding styles. Time will tell which pieces of code survive.

20. Re: loop do .. until end loop is surely incorrect!

• Posted by mattlewis (admin) Feb 27, 2011
• 1519 views

  while <condition> with entry do 
    <block a> 
  entry 
    <block b> 
  end while 

  while 1 do 
    <block b> 
    if not <condition> then exit end if 
    <block a> 
  end while 

Yes, that's just as correct, functionally. I really prefer to stay away from while 1 do, since it serves (IMHO) to obfuscate the exit criterion inside the loop.

I think we're getting into a style/religious war on the level of proper brace position, however, and like Derek, I'll agree to disagree.

Matt

22. Re: loop do .. until end loop is surely incorrect!

• Posted by bill Feb 28, 2011
• 1464 views

Derek:

If you don't like the previous form consider this:

function find_all ( object x , sequence source , integer from )  
  if from > length(source) or from < 1 then  -- why let it crash?? 
    return {}           
  end if  
  sequence ret = {}  
  from = find_from (x, source, from)         -- it is called with from here 
  while from > 0 do  
    ret &= nxt 
    from = find_from (x, source, from+1)     -- with from+1 subsequently 
  end while  
  return ret  
end function  

This is clean and no kludges.

while TRUE with entry do   
  integer x = 3   
entry   
  ? x   
end while  

Your comments about how it is an error is fine if you reduce everything to jumps and labels.

Of course the code is incorrect.

But my point is that it is incorrect not because it reduces to use before declaration but because at the higher level it is a jump into scope.

I notice that in none of your examples do you attempt use of in-loop variables in the entry section. So really we are still at cross-purposes.

The fact is that it is almost certain that any such use however it was done would either produce run-time errors or would run and give incorrect results.

It is true I dislike the with entry clause and will not use it. I have no idea how good your other examples are as there is so little context.

Agree to disagree.