feature request: true global variables

[krux02]

Most programming languages don't really understand what "global" means. The term gets misused a lot for something that is actually process local or something along the line. A true global variable should have one state across the globe as in planet, but still be mutable by anyone at any time. On different globes as in different planets, a new instance of this variables should be spawned. So Earth and Mars state is not synchronized. Trying to access a global variable while in space is of course undefined behavior.

I think a const const const is already pretty close to this concept, but it lacks mutability.

[stohrendorf]

Trying to access a variable in space should take the variable that's closest. This will have side effects, though, as information transfer is limited to the speed of light. But, in combination with #54, it may solve the problem of interstellar information transfer.

[MartinSStewart]

While I think this is a good idea, there's some nuance to consider.

For example, if you're using DreamBerd in 2006 (via https://github.com/TodePond/DreamBerd/issues/60) while on the surface of Pluto then depending on what month it is, you'd ever be reading/writing var var variables either to the Pluto namespace or some other planet in the solar system (it's possible for Mercury to be the closest planet depending on the orbits).

Additionally, since we already respect locale when it comes to string interpolation https://github.com/TodePond/DreamBerd#string-interpolation, I think it only makes sense that the global namespace should be account for your locale's language. For example, if I'm programming next to Saturn but my locale uses Swedish, then my var var variables would read and write from the "Saturnus" namespace, rather than "Saturn" as it would if my locale used English.

[stohrendorf]

I always assumed string interpolation is non-lazy, so once it is interpolated, it's a regular string, and can be transmitted without issue, no?

And regarding the proximity issue, you can always time travel (as you mentioned) to a time where Pluto is closest to your desired global namespace. I don't really consider this to be an issue, and surely someone will come up with a package/library that helps you pick the correct time with the desired location given as an input.

[gooddavvy]

@TodePond Will you add a global keyword?

[ThePython10110]

For example, if you're using DreamBerd in 2006 (via #60) while on the surface of Pluto then depending on what month it is, you'd ever be reading/writing var var variables either to the Pluto namespace or some other planet in the solar system.

Who says only planets count as globes? Why not moons and dwarf planets?