Author here: doing this in any language is probably going to depend on some implementation details of the language repl, which may require dropping down to a level where you have access to these internals - for example, I can't think of a way you could achieve it in strict mode JS.

Python may well be able to do it with just the stdlib since it has excellent debugging capabilities, but Tcl is relatively weak. You might be able to do something with `tcl::unsupported::getbytecode` and checking the frame level, but this was just a throw-away novelty so I'm not particularly motivated to find out.

Alas, for JS function.caller on a getter isn't standard but will work everywhere and should do it.

I don't think it's that easy. If the context is making javascript output something different in it's REPL for just "foo" vs "console.log(foo)", there's other pieces you would need.

Like overriding a built-in type and getting function.caller into valueOf(). As far as I can tell, JS doesn't let you just tweak valueOf(), you would have to re-implement all of, for example, the String class.

Reimplementing whole classes wouldn't have been a problem, just replace the original ones with a proxy to a copy.

Luckily console.log calls are actually excluded from the callers stack, so the only way is to change console itself. Just as evil if you also intercept console methods logging and return the original ones, but less of a mess at least.

I believe the point is that the bytecode 'knows' the context the value will be delivered to, which is the interesting thing that separates this from most other languages. From the README:

    This is somewhat interesting. You can't use frames to differentiate between puts [schro] and schro, as they're both in the same frame. In fact, in the general case for a programming language, this is impossible - it would depend on using an oracle to predict what's going to happen to the value you return.

    Happily, in Tcl we can cheat! There are three vital points - 1. Tcl compiles lines passed into the repl to bytecode, 2. Tcl bytecode is a stack machine and 3. Tcl has a pointer to the current execution location in the bytecode (note that point 1 only became true in Tcl 8.6 (I believe) so this code won't work before then).