Post #132,776
12/30/03 11:24:00 AM
|
Is it just me?
If you name an "end" block you can are allowed not to end any of the inner blocks. I can't parse that. And I'm not just being comma police here, I don't get what you're saying.
===
Implicitly condoning stupidity since 2001.
|
Post #132,794
12/30/03 1:48:50 PM
|
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
12/30/03 4:12:27 PM
|
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
12/30/03 4:24:01 PM
|
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
12/30/03 4:42:13 PM
|
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
12/30/03 5:01:35 PM
|
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
12/30/03 5:13:54 PM
|
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
12/30/03 6:23:38 PM
|
Yup
At the final named "END"
|
Post #132,874
12/30/03 6:38:27 PM
|
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
12/30/03 8:27:04 PM
|
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
12/30/03 11:16:23 PM
|
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
|
Post #132,841
12/30/03 4:10:33 PM
|
I took it:
If you name an ending "END" block... You absolutely *must* end inner blocks before the "END" block.
-- [link|mailto:greg@gregfolkert.net|greg], [link|http://www.iwethey.org/ed_curry|REMEMBER ED CURRY!] @ iwethey
[insert witty saying here]
|
Post #132,844
12/30/03 4:13:40 PM
|
I wish
Not only do you not have to name them, you don't have to code them.
|
Post #132,936
12/31/03 7:44:28 AM
|
Feels very old-fashioned.
Not surprising, I guess, given the age of the language :-). I wouldn't be surprised if the parser has some horrible rules to deal with this nicety.
Wade.
Is it enough to love Is it enough to breathe Somebody rip my heart out And leave me here to bleed
| | Is it enough to die Somebody save my life I'd rather be Anything but Ordinary Please
| -- "Anything but Ordinary" by Avril Lavigne. |
|
Post #132,937
12/31/03 8:04:05 AM
|
Hand code baby
No YACC or LEX here.
|
Post #132,938
12/31/03 8:09:05 AM
|
... and I thought of that, too.
Yet I didn't post it. Hmm.
You can get some truly funky language features when you hand-code a compiler. My current favourite is my web-scripting language, [link|http://yceran.org/qomposr.|Qompose]. Due to the way they're declared and scanned for, variables can have almost any character in their names. :-)
Wade.
Is it enough to love Is it enough to breathe Somebody rip my heart out And leave me here to bleed
| | Is it enough to die Somebody save my life I'd rather be Anything but Ordinary Please
| -- "Anything but Ordinary" by Avril Lavigne. |
|