Re: trace(1) bug
<snipped/>
> Apart from all that, a change as I suggest - recommend - would not break
> existing code because it wouldn't have passed the syntax checking thus far.
> But OK, if you must have it this - IMNSHO - inconsistent fashion, so be it.
> Euphoria is still a darned good language. If you want it to stay as it is, OK.
> If you want improvments then something is gonna have to change...
>
> AndyD
True. However, we have THREE concurrent and mutually inconsistent changes
available:
1/ allow predeclared variables to be used as indexes, which entails that they
are available beyond the loop itself, since they are not scoped;
2/ allow predeclared variables to have the same name as loop indexes, which
makes them invisible outside their procedure, sorry loop;
3/ allow for loop indexes to be visible beyond the end of their loop, till they
are recycled, so that they are still scoped.
Why can't you have all of them at the same time?
Because, if there is a predeclared variable distinct from a loop index of the
same name, it has to be available when it is not shadowed by the more local loop
index. As a result, the loop indexes would be hidden outside of their respective
loop.
And additionally, you have to choose whether you want a loop index to be scoped
or not; can't be both at the same time.
How can you have it both ways?
By having THREE separate constructs, one for when you want the loop indexes
visible beyond end of loop but still scoped, and one where you allow a
predeclared variable to take over. I agree with Derek on this. I just think that
using another loop keyword makes for clearer reading than "for with i=...".
I didn't forget the case where loop indexes are not scoped, because it is
already available as the while loop. Which leaves us with two options actually.
In order to minimise the risk of breaking code, I'd suggest to retain for "for"
a meaning almost identical to what it is now, ie with invisible loop indexes.
Since there is hardly a risk of confusion in allowing a predeclared variable with
the same name, ok for this extension.
The other construct, called "for with", "for_existing" or whatever, would, in
contrast, preclude predeclared variables _so as_ to enable accessing the loop
indexes as long as they are not recycled. Any predeclared variable would be
visible till the first for loop that shadows it; I'm not sure it would help, and
would not recommmend it.
Trying to combine both is bound to cause some confusion, offsetting the
benefits.
I think I have pushed a lot for improvements in the language, which clearly
needs some. But doing so in an inconsistent way would just ruin the whole thing.
Let's call a cat a cat and a dog, a dog, instead of trying to give them the ame
name and see what happens - which is imho what your solution amounts to.
Btw, I'm not too much concerned with bd coding - it will die on its own by not
being copied. I'm more concerned about decreasing the number of pitfalls when
some code is modified. This is where constructs whose behaviour depends on the
context - what you suggest - can bite you in very subtle ways. Having several
distinct constructs with constant behaviour certainly reduces the number of bugs
introduced when upgrading code - one-shot stuff will always work. More keywords,
but more certainty in assessing the coder's intent.
CChris
|
Not Categorized, Please Help
|
|
