You get undef, that's part of the reason we added an undef concept (it's a value that isn't a value, though if you treat it like an int I believe it is zero, like a string and you get "").
I think that is a giant design mistake since you are pushing the discovery of an error to some place else in the program, potentially very far from where the error occurred.
The person you replied to asked what the behavior was when you access an offset of an array that doesn't exist and you are giving me an example of dereferencing a null pointer.
The array access should error out on the line that it happens.
The dereference could print a line of the last assignment, but this isn't what was being talked about.
I don't see the array access as any different than a null pointer dereference, in both cases you are asking for something that isn't there.
In Tcl, stuff just gets auto expanded on assignment and returns "" (I think) on dereference. We chose to return undef. I'm not sure what the problem is.
You seem bound and determined to not hear that tcl auto expands arrays as needed. There are no bounds. So there is no error to catch.
We just thought it would be clever to return undef if you were out of bounds, which tcl code would see as "" which is what you'd get in tcl. But Little code could actually tell you are past the end.
In my mind, which many have argued isn't the best, it's a reasonable design.
You keep trying to push backwards to a design point where arrays are fixed in size at declaration and that is not how tcl (or Little) works.
There is no null, only undef. It's not a value, there is no value that means undef. We implemented by stealing the high order bit from the reference counter that tcl uses for garbage collection. If it is set, the variable undefined, if it isn't, it's a normal variable.
I thought that was clever given that tcl's reference counter was signed and it only uses positive values. So we made it unsigned and got the bit for free.
What happens if you call a Tcl function with an undef argument? Is this running Tcl code on a slightly different runtime, or do they interop in some other way?
In Tcl, everything is a string. The string rep of undef is "" so Tcl gets "" but doesn't know that it is undef.
So yeah, there is some sloppiness there. Tcl tends to use "" as sort of a null or undef so lots of stuff just works but no promises on that.
This is sloppy simply because the Tcl die hards (are there any left?) refused to see the value of undef, a value for a variable that said there is no value. We used it all over the place, there clearly is value. They didn't see that, Little never got pushed back into the Tcl source base so Tcl never thought about undef.
It is what it is, we live in an imperfect world. I tried.