1. Can we simplify "end"?
- Posted by Bryan So <sohim at y??oo.com> Aug 07, 2007
- 669 views
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
- 649 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
3. Re: Can we simplify "end"?
- Posted by CChris <christian.cuvier at agr?culture.gouv.fr> Aug 07, 2007
- 635 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 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
- 614 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
5. Re: Can we simplify "end"?
- Posted by Pete Lomax <petelomax at bluey?nder.co.u?> Aug 08, 2007
- 604 views
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
- 604 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
7. Re: Can we simplify "end"?
- Posted by jacques deschênes <desja at globe?rott?r.net> Aug 08, 2007
- 637 views
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
- 650 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."
9. Re: Can we simplify "end"?
- Posted by jacques deschênes <desja at ?lobe?rotter.net> Aug 08, 2007
- 617 views
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
- 595 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."
11. Re: Can we simplify "end"?
- Posted by CChris <christian.cuvier at agr?culture.gou?.fr> Aug 08, 2007
- 615 views
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