OpenEuphoria

I think it is quite redundant to use different endings for

   end procedure
   end function
   end if
   end while 

etc...

with proper indentation, which I am sure we all use, one

   end

should be enough to end a loop or condition or function, etc, 
without any ambiguity.  

Bryan

2. Re: Can we simplify "end"?

• Posted by Bernie Ryan <xotron at bluefr?g.?om> Aug 07, 2007
• 577 views

Bryan So wrote:
> 
> I think it is quite redundant to use different endings for
> 
>    end procedure
>    end function
>    end if
>    end while 
> 
> etc...
> 
> with proper indentation, which I am sure we all use, one
> 
>    end
> 
> should be enough to end a loop or condition or function, etc, 
> without any ambiguity.  
> 

Bryan:


Then the interpeter would not know which end is being parse and

could not tell the difference with various end statements.

Bernie

My files in archive:
WMOTOR, XMOTOR, W32ENGIN, MIXEDLIB, EU_ENGIN, WIN32ERU, WIN32API 

Can be downloaded here:
http://www.rapideuphoria.com/cgi-bin/asearch.exu?dos=on&win=on&lnx=on&gen=on&keywords=bernie+ryan

Bryan So wrote:
> 
> I think it is quite redundant to use different endings for
> 
>    end procedure
>    end function
>    end if
>    end while 
> 
> etc...
> 
> with proper indentation, which I am sure we all use, one
> 
>    end
> 
> should be enough to end a loop or condition or function, etc, 
> without any ambiguity.  
> 
> Bryan

Definitely.
How many times have I changed a for loop to a while loop or back, procedure to
function or back, and forgotten to change that end marker? It makes for more
visual clutter, not clearer code.

Bach simply gets it right with its "with block ..." directives.

CChris

4. Re: Can we simplify "end"?

• Posted by Bryan So <sohim at y??oo.com> Aug 07, 2007
• 538 views

Bernie Ryan wrote:
> 
> Bryan:
> 
> 
> Then the interpeter would not know which end is being parse and
> 
> could not tell the difference with various end statements.
> 
> Bernie
> 
> My files in archive:
> WMOTOR, XMOTOR, W32ENGIN, MIXEDLIB, EU_ENGIN, WIN32ERU, WIN32API 
> 
> Can be downloaded here:
> <a
> href="http://www.rapideuphoria.com/cgi-bin/asearch.exu?dos=on&win=on&lnx=on&gen=on&keywords=bernie+ryan">http://www.rapideuphoria.com/cgi-bin/asearch.exu?dos=on&win=on&lnx=on&gen=on&keywords=bernie+ryan</a>


Bernie:

Not true.  If you ask those who are expert in writing language grammars, you
will know the interpreter/compiler actually knows which "begin" an "end" is
supposed to end.  Think about the C language.  "}" is equivalent to the various
"end"s in Euphoria.

Bryan

Bryan So wrote:
> 
> I think it is quite redundant to use different endings for
> 
>    end procedure
>    end function
>    end if
>    end while 
> 
I often find this very helpful:

procedure x()
    while test() do
        if x then
    end while
--      ^ expected to see possibly 'if' not 'while'
end procedure

Removing the end qualifiers would cause the error to be reported much later on
in the file, either on the next routine or data declaration (etc), or the end of
file.

The closer the error message to the actual error the better.

Regards,
Pete

6. Re: Can we simplify "end"?

• Posted by Derek Parnell <ddparnell at bi?pond.co?> Aug 08, 2007
• 534 views

Bryan So wrote:
> 
> I think it is quite redundant to use different endings for
> 
>    end procedure
>    end function
>    end if
>    end while 
> 
> etc...
> 
> with proper indentation, which I am sure we all use, one
> 
>    end
> 
> should be enough to end a loop or condition or function, etc, 
> without any ambiguity.  

If the language were being designed from scratch you might have a good arguement
there. However, we have to consider all the existing code that uses the extra
token. Remember that line endings don't mean a whole lot to the interpreter. So
when we type ...

   for i = 1 to 10 do
      foo(i)
   end for

   for j = 11 to 20 do
      bar(j)
   end for

the interpreter sees ...

   for i = 1 to 10 do foo(i) end for for j = 11 to 20 do bar(j) end for

and when we remove the extra tokens ...

   for i = 1 to 10 do foo(i) end for j = 11 to 20 do bar(j) end

So if the interpreter has to support both the existing syntax and the new
syntax, whenever it sees the phrase "end for" it now has to work out Am I at the
end of a for-loop or the beginning of a for-loop? To do that it has to look ahead
a bit, back track to the right place and finalize the for-loop.

This is not impossible, but with only the current syntax or only with the new
syntax then no look-ahead/backtracking is needed.

At least two other options are available to us to get around this.

Create a new token that means 'end of loop' such as 'stop', 'done' or some such.

   for i = 1 to 10 do
      foo(i)
   done

   while sequence(X) do
      bar(X)
   done

Or create a new token that can be used regardless of the type of loop being
ended.

   for i = 1 to 10 do
      foo(i)
   end loop

   while sequence(X) do
      bar(X)
   end loop

Both of these can co-exist with the old syntax and not introduce a significant
performance hit on the intepreter.

-- 
Derek Parnell
Melbourne, Australia
Skype name: derek.j.parnell

Personnaly it doesn't bother me to have to write the block type after end.
More I see it as as self documenting feature, when there is many level of block
even with indentation its easier to locate where each block ends this way as
sometimes the block may be more than one screen full of lines.

regards,
Jacques Deschênes



Bryan So wrote:
> 
> I think it is quite redundant to use different endings for
> 
>    end procedure
>    end function
>    end if
>    end while 
> 
> etc...
> 
> with proper indentation, which I am sure we all use, one
> 
>    end
> 
> should be enough to end a loop or condition or function, etc, 
> without any ambiguity.  
> 
> Bryan

8. Re: Can we simplify "end"?

• Posted by Jason Gade <jaygade at yahoo?c?m> Aug 08, 2007
• 580 views

jacques deschênes wrote:
> 
> Personnaly it doesn't bother me to have to write the block type after end.
> More I see it as as self documenting feature, when there is many level of
> block
> even with indentation its easier to locate where each block ends this way as
> sometimes the block may be more than one screen full of lines.
> 
> regards,
> Jacques Deschênes
> 
> 
> Bryan So wrote:
> > 
> > I think it is quite redundant to use different endings for
> > 
> >    end procedure
> >    end function
> >    end if
> >    end while 
> > 
> > etc...
> > 
> > with proper indentation, which I am sure we all use, one
> > 
> >    end
> > 
> > should be enough to end a loop or condition or function, etc, 
> > without any ambiguity.  
> > 
> > Bryan

Heh, usually I'll write a comment describing what I'm ending, be it function or
procedure or loop or whatever.

procedure do_something(object x)
    -- something
end procedure -- do_something()

"Any programming problem can be solved by adding a level of indirection."

anonymous "Any performance problem can be solved by removing a level of indirection." M. Haertel "Premature optimization is the root of all evil in programming."

C.A.R. Hoare j. }}}

I do it myself sometimes but not always.

j.d.

Jason Gade wrote:
> 
> jacques deschênes wrote:
> > 
> > Personnaly it doesn't bother me to have to write the block type after end.
> > More I see it as as self documenting feature, when there is many level of
> > block
> > even with indentation its easier to locate where each block ends this way as
> > sometimes the block may be more than one screen full of lines.
> > 
> > regards,
> > Jacques Deschênes
> > 
> > 
> > Bryan So wrote:
> > > 
> > > I think it is quite redundant to use different endings for
> > > 
> > >    end procedure
> > >    end function
> > >    end if
> > >    end while 
> > > 
> > > etc...
> > > 
> > > with proper indentation, which I am sure we all use, one
> > > 
> > >    end
> > > 
> > > should be enough to end a loop or condition or function, etc, 
> > > without any ambiguity.  
> > > 
> > > Bryan
> 
> Heh, usually I'll write a comment describing what I'm ending, be it function
> or procedure or loop or whatever.
> 
> }}}
<eucode>procedure do_something(object x)
>     -- something
> end procedure -- do_something()
> 
> --
> "Any programming problem can be solved by adding a level of indirection."
> --anonymous
> "Any performance problem can be solved by removing a level of indirection."
> --M. Haertel
> "Premature optimization is the root of all evil in programming."
> --C.A.R. Hoare
> j.

10. Re: Can we simplify "end"?

• Posted by Al Getz <Xaxo at aol.c?m> Aug 08, 2007
• 524 views

Bryan So wrote:
> 
> I think it is quite redundant to use different endings for
> 
>    end procedure
>    end function
>    end if
>    end while 
> 
> etc...
> 
> with proper indentation, which I am sure we all use, one
> 
>    end
> 
> should be enough to end a loop or condition or function, etc, 
> without any ambiguity.  
> 
> Bryan

Hi Bryan,


It is true that you can deduce logically exactly which 'end'
goes to which 'for', 'while', 'if', etc., which means that
the compiler can be made to do this.
The compiler, however, is not the only consideration here as
the program maintenance comes into play also.  It's still 
true that it can get confusing even when using the full
syntax "end for" instead of "end" but it does help a little.
Note that for really big sections of code we have to annotate
anyway:


for k=1 to 3 do
  if y=1 then
    x=CallMyFunction(()
    if z=2 then
      --next program line
      --next program line
      --next program line
      --next program line
      --next program line
      --next program line
      --next program line
      --next program line
      --next program line
      --next program line
      --next program line
      --next program line
      --next program line
      --next program line
      --next program line
      --next program line
      --next program line
      --next program line
      --next program line
      --next program line
      --next program line
      --next program line
      --next program line
      --next program line
      --next program line
      --next program line
      --next program line
      --next program line
      --next program line
      --next program line
      --next program line
      --next program line
      --next program line
      --next program line
      --next program line
      --next program line
      --next program line
      --next program line
      --next program line
      --next program line
      --next program line
      --next program line
      --next program line
      --next program line
      --next program line
      --next program line
      --next program line
      --next program line
      --next program line
      --next program line
      --next program line
      --next program line
      --next program line
      --next program line
      --next program line
      --next program line
      --next program line
      --next program line
      --next program line
      --next program line
      --next program line
      --next program line
      --next program line
      --next program line
      --next program line
      --next program line
      --next program line
      --next program line
      --next program line
      --next program line
      --next program line
      --next program line
      --next program line
      --next program line
    end if --if z=2
  end if --if y=1
end for --k

In the case of the long code body it always helps to annotate
to make it easier when we go to add some code.



Take care,
Al

E boa sorte com sua programacao Euphoria!


My bumper sticker: "I brake for LED's"

 From "Black Knight":
"I can live with losing the good fight,
 but i can not live without fighting it".
"Well on second thought, maybe not."

Al Getz wrote:
> 
> Bryan So wrote:
> > 
> > I think it is quite redundant to use different endings for
> > 
> >    end procedure
> >    end function
> >    end if
> >    end while 
> > 
> > etc...
> > 
> > with proper indentation, which I am sure we all use, one
> > 
> >    end
> > 
> > should be enough to end a loop or condition or function, etc, 
> > without any ambiguity.  
> > 
> > Bryan
> 
> Hi Bryan,
> 
> 
> It is true that you can deduce logically exactly which 'end'
> goes to which 'for', 'while', 'if', etc., which means that
> the compiler can be made to do this.
> The compiler, however, is not the only consideration here as
> the program maintenance comes into play also.  It's still 
> true that it can get confusing even when using the full
> syntax "end for" instead of "end" but it does help a little.
> Note that for really big sections of code we have to annotate
> anyway:
> 
> 
> for k=1 to 3 do
>   if y=1 then
>     x=CallMyFunction(()
>     if z=2 then
>       --next program line
>       --next program line
>       --next program line
>       --next program line
>       --next program line
>       --next program line
>       --next program line
>       --next program line
>       --next program line
>       --next program line
>       --next program line
>       --next program line
>       --next program line
>       --next program line
>       --next program line
>       --next program line
>       --next program line
>       --next program line
>       --next program line
>       --next program line
>       --next program line
>       --next program line
>       --next program line
>       --next program line
>       --next program line
>       --next program line
>       --next program line
>       --next program line
>       --next program line
>       --next program line
>       --next program line
>       --next program line
>       --next program line
>       --next program line
>       --next program line
>       --next program line
>       --next program line
>       --next program line
>       --next program line
>       --next program line
>       --next program line
>       --next program line
>       --next program line
>       --next program line
>       --next program line
>       --next program line
>       --next program line
>       --next program line
>       --next program line
>       --next program line
>       --next program line
>       --next program line
>       --next program line
>       --next program line
>       --next program line
>       --next program line
>       --next program line
>       --next program line
>       --next program line
>       --next program line
>       --next program line
>       --next program line
>       --next program line
>       --next program line
>       --next program line
>       --next program line
>       --next program line
>       --next program line
>       --next program line
>       --next program line
>       --next program line
>       --next program line
>       --next program line
>       --next program line
>     end if --if z=2
>   end if --if y=1
> end for --k
> 
> In the case of the long code body it always helps to annotate
> to make it easier when we go to add some code.
> 
> 
> Al
> 
> E boa sorte com sua programacao Euphoria!
> 
> 
> My bumper sticker: "I brake for LED's"
> 

An easy solution would be to say:

label this_loop
for i=1 to n do
-- many things
end this_loop -- or end "this_loop"

This enhances maintainability, enables changing loop types withou the usual
hassles, and the quoted syntax cannot break any existing code.
This would also pave the way for }}}
<eucode>exit "this_loop"</eucode>
{{{
 and kins.
Perhaps we cannot do without quotes around labels.
CChris