Re: trace(1) bug
Pete Lomax wrote:
>
> CChris wrote:
> > I have always been a little surprised at repeated "i = xxx"
> > lines in ex.err; I expect some are downright confused. The extra lines
> > would just go away.
>
> > Which solution is preferrable?
>
> IMNSHO: allow only *ONE* i per context.
>
> allow eg:
> }}}
<eucode>
> procedure x()
> integer i -- see point C:
> for i=1 to 10 do
> if i=5 then exit end if
> end for
> ?i
> for i=1 to 20 do end for
> ?i
> end procedure
> }}}
<eucode>
> A: to work (currently you get "attempt to redefine i"),
> B: to display either 5,20 or 5,21 (my preference is for latter),
> C: ditto whether i predefined or not,
> D: any ex.err lists one and only one i, per scope.
> E: any trace(1) screen "" "" "", except for:
> F: (erm?) trace screen allows inspection of callee i and other vars.
> G: whatever you do, you must still prohibit nested "for i=" loops.
> H: (doh) same deal for A:..G: with top-level code.
> I: top-level: for i=1 to 2 do end for integer i now craps out => "tough"!
>
> Obviously F: is a frill perhaps beyond the scope (no pun intended) of the
> immediate
> discussion.
>
> One caveat I can see is this:
> }}}
<eucode>
> if x then
> for i=1 to 10 do end for
> ?i -- OK
> else
> ?i -- //iff i not predeclared, may warrant a warning?
> end if
> </eucode>
{{{
> Though personally, I'm OK with run-time "has not been assigned a value" and
> no compile-time warning, there may be many others, YMMV, etc.
>
> Regards,
> Pete
The current issue is the discrepancy between what parser understands and what
interactive execution understands.
If the for loop is considered to be a scope, which has always been the case,
then both }}}
<eucode> integer i</eucode>
{{{
before and }}}
<eucode>integer i</eucode>
{{{
after
are valid. However, the docs say that a loop index must not be declared, which is
why the code you wrote doesn't work. I agre that it would be more logical to
amend docs to say "doesn't reuire to be declared" and let A live.
Displaying 21 (last value assigned to i) in B is a problem, because i is not
defined at the point you say }}}
<eucode>?i</eucode>
{{{
. Some C compilers allow the
index of a for loop to be valid and available after end of loop. have no problem
with this, but this is a change in the language, requiring perhaps some
discussion.
C results from A and B, no comment.
A and D contradict each other. If each for loo^p is a scope, then both the whole
scope variable (the integer i) and the active loop index i (if any) should be
displayed, but only these two.
So there is a problem with B:
* if there is no integer i, and program crashes after the for loop, ex.err xould
show the loop index i
* if there is an integer i predefined, then that i would show in ex.err. Not so
sure I like B, after all.
E is what I was concerned in the first place, so we agree there.
If there are both an integer i and a loop index i, the later shadows the former
and you cannot access it from inside the for loop, either in normal or traced
execution. I wouldn't mind doing something else, but that would be a big change
in the language. Probably a code breaker, and I don't see a lot of benefits.
G kid of results from A, agreed.
H must hold for consistency.
As I said, if we consider a for loop to be a full fledged scope, which it is,
then I is not consistent. I would be consistent with B, but see, there are subtle
issues in allowing potentially twovars with the same name to coexist past the end
of the for loop.
Thoughts, anuone?
CChris
|
Not Categorized, Please Help
|
|
