How does it know where the blocks end?

Post #132,852 by ben_tilly 12/30/03 4:42:13 PM Reply	How does it know where the blocks end? Does it use indentation? Does it nest them? (So that BLOCK_C would be in BLOCK_B.) Does it assume that they don't nest? (So BLOCK_C is not in BLOCK_B but "Some more code" accidentally is in BLOCK_C.) Does it depend on cues that depend on the kind of block? (So an IF might naturally terminate at an unexpected ELSE while a simple block remains open...) It seems like a potentially confusing feature unless the rules are clear. If they are simple (eg it just assumes that when you close a named block then you close all other open blocks there) then it seems like a minor piece of syntactic sugar. Anyways my limited understanding was that PL/I had exactly this kind of DWIMery built-in, which is why people who disliked Perl tended to likewise dislike PL/I. Cheers, Ben "good ideas and bad code build communities, the other three combinations do not" - [link\|http://archives.real-time.com/pipermail/cocoon-devel/2000-October/003023.html\|Stefano Mazzocchi]
Post #132,854 by broomberg 12/30/03 5:01:35 PM Reply	It doesn't Space does not matter, I just did that to show you. Only on the final END does it matter. This sugar is meant for when there are multiple ends, one after the other, with no code in between being executed. And like I said, there are many things I like about it. But this threw me as a major danger.
Post #132,857 by ben_tilly 12/30/03 5:13:54 PM Reply	There must be SOME rule Obviously when it parses that code it inserts in the needed ENDs. My question is where and why it decides to insert them. If you don't (or can't) know that reliably, then this definitely is very dangerous since you will never be sure what that snippet will do. Ben "good ideas and bad code build communities, the other three combinations do not" - [link\|http://archives.real-time.com/pipermail/cocoon-devel/2000-October/003023.html\|Stefano Mazzocchi]
Post #132,870 by broomberg 12/30/03 6:23:38 PM Reply	Yup At the final named "END"
Post #132,874 by ben_tilly 12/30/03 6:38:27 PM Reply	So it nests blocks In your example, BLOCK_C is inside of BLOCK_B, and "some more code" is also in BLOCK_C (and hence in BLOCK_B). Seems sane enough. I just wouldn't name any ENDs. :-) (Logic that is nested deeply enough that removing the END statements seems like a big win has obvious problems - namely that it is nested too deeply for my sanity.) Cheers, Ben "good ideas and bad code build communities, the other three combinations do not" - [link\|http://archives.real-time.com/pipermail/cocoon-devel/2000-October/003023.html\|Stefano Mazzocchi]
Post #132,886 by broomberg 12/30/03 8:27:04 PM Reply	Breaks a coding practice of mine I ALWAYS comment the ending brace of blocks. So it would be natural for me to name the END statement. Which means I am open to breakage if I ever miss a name.
Post #132,908 by a6l6e6x 12/30/03 11:16:23 PM Reply	Re: How does it know where the blocks end? If the END is followed by a <statement-label> (before the semicolon), it closes that block and any unclosed interior blocks. If the END is not followed be a <statement-label>, it simply closes the preceding unclosed block. If a statement-label follows END, the END statement closes the unclosed group or block headed by the nearest preceding DO, SELECT, BEGIN, or PROCEDURE statement having that statement-label. It also closes any unclosed groups or blocks physically within that group or block; this is known as multiple closure. If a statement-label does not follow END, the END statement closes the one group or block headed by the nearest preceding DO, SELECT, BEGIN, or PROCEDURE statement for which there is no other corresponding END statement. [link\|http://publibfp.boulder.ibm.com/cgi-bin/bookmgr/BOOKS/ibm3l101/7.17?DT=19950506201638\|IBM Link]. Alex In every country and every age, the priest had been hostile to Liberty. -- Thomas Jefferson (1743-1826), US president

Welcome to IWETHEY!