TIC-80
TIC-80 copied to clipboard
trace errors when given empty args
Lua is a little strange about the dichotomy between nil and no value. In most cases they're treated to be the same, however in two specific cases (probably more, but two of note here), this isn't the case: passing arguments to C functions, and returning no value.
Normal lua isn't the cleanest about this either; tostring()
errors while print()
does nothing.
Ideally, I think that trace
should handle any input, including nothing, gracefully. As of now, trace()
is an error.
There's a few less explicit cases than trace()
though:
function noValue()
if false then
return 4
end
--implicitly runs a "return" with no
--value
end
trace(noValue())
errors, while
function noValue()
if false then
return 4
end
--implicitly runs a "return" with no
--value
end
someValue = no_value()
trace(someValue)
prints nil
This is a fairly obscure issue, but it caused me some headaches while debugging, so I figured I'd report it.
I like that most of our Lua functions have required arguments but in this case I could see making an exception and either:
- no output (but confusing if you were expecting something)
- blank output (hard to see if you were expecting something)
-
[no value]
or some such
I feel like some variant of the latter if we agree we should change this.
From a practical point of view, why would you purposely insert trace() (without arguments) in a program? It handles nil values ok so it's 'debug-friendly' in that way.
Calling trace()
is not the only way to call trace without arguments.
Returning a function either implicitly or with return
with nothing given returns "no value."
In a lot of situations, "no value" coerces to nil, but not all of them; notably, when passing "no value" to a c-defined function, like trace()
Because of this, it is sometimes possible to accidentally call trace
with no arguments.
Try running the first code example from the initial issue.
it is sometimes possible to accidentally call trace with no arguments.
This is what persuaded me we should fix this. Lua is weird. :)
Calling
trace()
is not the only way to call trace without arguments. ... Try running the first code example from the initial issue.
Yes, I realise that but you're calling it with arguments in both examples. The fact that the function argument returns a defective value in the first example isn't really trace()'s 'fault'... it can't print nil because the function hasn't returned nil (unlike in the second example where the variable has to be assigned something and ends up with nil). Maybe trace() should print 'no value' if it's passed something which isn't nil or any other valid value although I'm not sure if it's possible to detect such a scenario.
. Maybe trace() should print 'no value' if it's passed something which isn't nil or any other valid value
It's possible to detect no arguments - which is what the first case presents as. Either way this is an edge case.
@joshgoebel thanks for that. It's been a very long time indeed since I did any C programming (best part of 30 years) so my recollection of what's possible is sketchy to say the least.
I agree, I don't think it's worth anyone expending any effort in trying to 'fix' this.
It's been a very long time indeed since I did any C programming
We're talking about the Lua runtime here (calling into C), when I say detect arguments you just ask the Lua/C bridge "how many arguments was this function called with".
I don't think it's worth anyone expending any effort in trying to 'fix' this.
We aren't in agreement. :-) It's an edge case, but it's also a 1-2 line fix, so I'm not opposed.
The reason I even noticed this at all is because it came up for me at least once; I think that trace
being able to error during normal use, even uncommonly is a problem worth a single if-statement fix.
Ah, ok, definitely worth doing then!