Re: For loops
CChris wrote:
>
> The various branch targets are resolved in the parser, which handles delayed
> jumps by scanning a sequence at each block exit and backpatching when the
> branch is ripe. The backend doesn't see anything new, as the EXIT opcode
> is being emitted.
Yep, I did essentially the same thing in ooeu.
> Of course the optional param could be restricted to be only a label. In the
> simplest cases, this is probably overkill, but is theoretically true and
> safer, as CB already emphasized. The resulting code simplification would
> be marginal, since a single routine handles the optional parameter in the
> parser.
>
> Everything works as expected AFAICT.
>
> I didn't implement the "by" clause of the do loop because it is enough
> to put its contents at the end of the loop body, so it seemed redundant.
> Unless there's a refined semantic hue I didn't get.
Well, the reason I like this is that it's very clear, and you're less likely
to forget to increment the loop at the end and result in an accidental
"while 1 do " type of bug. I think it's nice because it's immediately
clear to the reader as to how the loop is meant to function. The body of
the loop is reserved for doing work, not incrementing. When you have a
loop where the incrementing isn't well defined (i.e., there are multiple
ways to move to the next value, or whatever) then you can fall back to
using a while-loop.
> Only possible issue: variables named "label", "until", "next", "retry"
> or "exif" will need a rename. "label" is allowed only right after a
> do/then header end marker. And a so much steeeeeeeeeeper learning curve,
> I'm sure.
Yeah, this is always a concern when adding to the language.
Matt
|
Not Categorized, Please Help
|
|
