That way your code actually looks like "loop reading commands until you get a non-empty one and loop doing that until a 'quit' is requested". Not, "here is a block that I may or may not be using as a loop (please parse the rest of the block if you want to know), read a command, goto the top of the nearest surrounding loop (or naked block but not a conditional or do block) if the command is empty, otherwise go to the continue block (if there is one) or the top of the nearest surrounding loopish block, if a 'quit' was not requested". (:And for that, you use a "here's a do, please parse till the end to see whether I want to include a file, I want to turn a block into an expression or I want to use a looping construct"?
At least with a bare block you know you have a looping construct. With do you can have 3 totally different things. On top of that, several of your examples nest dos. I can understand that some people find bare blocks confusing - I indicated you could use a while(1) in front of it - but I fail to see that nested do constructs are easier than a bare block.
I would think that the major "problem" with my bare block is that the guard is at the end - but your do { } until suffers from the same problem.
Here's how I read my block:
-- Abigail
In reply to Re: crafting a decent CLI
by Abigail
in thread crafting a decent CLI
by PetaMem
For: | Use: | ||
& | & | ||
< | < | ||
> | > | ||
[ | [ | ||
] | ] |