It is not just you

Post #132,794 by ben_tilly 12/30/03 1:48:50 PM Reply	It is not just you I'm guessing that an "end block" is a block that does final cleanup whenever you exit. I'm further guessing that it isn't named that in PL/I, and Barry is just calling it that because that is what it would be called in Perl. But I'm kinda fishing here, and wouldn't be very confident in that guess... 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,843 by broomberg 12/30/03 4:12:27 PM Reply	It's both of you Blocks are like code between {} in Perl. Given the following code: \nBLOCK_A:\n BEGIN;\n some code\n BLOCK_B:\n BEGIN;\n some code within block b\n END; /* unnamed end block - end the last block defined, ie: B\n BLOCK_C:\n BEGIN;\n some code within block c\n END; /* unnamed end block - end the last block defined, ie: C\n Some more code\n END BLOCK_A; /* Named end block /\n See how the ends balance the begins? Now look at this: \n\nBLOCK_A:\n BEGIN;\n some code\n BLOCK_B:\n BEGIN;\n some code within block b\n\n BLOCK_C:\n BEGIN;\n some code within block c\n Some more code\n END BLOCK_A; / Named end block */ \n When an END has a name, the compiler KNOWS which block you are ending. So it doesn't bother trying to balance opening and closing blocks. This code is perfectly legal. The BLOCKS can be part of inner procedures, flow control, part of "IF"s, etc. I'm leaving that out of the example to show the minimum amount of code. Feels dangerous to me.
Post #132,847 by drewk 12/30/03 4:24:01 PM Reply	Not what threw me ... you can are allowed not to ... After seeing your clarification, I assume you meant either "can" or "are allowed", but accidentally typed both things you were thinking. Either way, the named end block does look useful. === Implicitly condoning stupidity since 2001.
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!