5 ms·

Maybe a very dumb example: Suppose I get a pointer to an empty byte array. At the very start of the program I had a full byte array. I want to fill my empty arr

by Meai 14y ago

Maybe a very dumb example: Suppose I get a pointer to an empty byte array. At the very start of the program I had a full byte array. I want to fill my empty array with the stuff I had at the start. But now I have to rewrite my program so that I still have a reference to the "start" (=which is sort of a time, isn't it?), so that I am able to assign that pointer that data. Right now I'm in some function somewhere far far away in the source code. Basically: Jump back in time where I have all my data, references, whatever, work with that state and layout of the program and then jump back out to where I was. So it is sort of like not only modifying the state of the program that I'm going to create, but also modifying the state of the code that I'm creating. Basically the code itself is a program as well. I have made a gist which should illustrate it maybe a little better: https://gist.github.com/anonymous/24a43cd81843e79df52d https://gist.github.com/anonymous/24a43cd81843e79df52d

Smudge 14y ago
The way you describe it as "time" and "history" is confusing. In your gist, essentially you want to roll backwards, fetch the value you had in the previous layer of the stack, and then jump forward to your current execution, but with that reference in tow. So I think I get where you're going, but it doesn't seem very useful to me. The whole point of passing the reference when you need it is that you're giving your code some meaningful context. If any reference were accessible from any method, you'd essentially be dealing with a giant global context of everything. (Isn't that what singletons are for?)
- Meai 14y ago
  You are thinking way too much in terms of programming. What's wrong with global context? Your mind is one huge global context, and it seems to work fine. You fetch stuff all the time from one big pool. Sure, there's hierarchy in there. Just like in my example: Different times, different functions, they all provide hierarchy and structure to the times you can fetch data from.
  - catharsis 14y ago
    This sounds like state based programming. IIRC this was a moderately popular way of programming games in the past. The resulting code is somewhat monolithic however, hard to maintain.
dragonwriter 14y ago
It doesn't seem to be about time, you seem (by a conservative interpretation) to want to be able to access a the context from which a function was called from within the function: some languages allow you to do that nowm though quite often, even those in which it is possible don't have a direct and convenient mechanism in the language core or standard libraries, though the mechanism is implementable in the language, as in Ruby where Binding.of_caller doesn't exist, but can be implemented (http://extensions.rubyforge.org/rdoc/classes/Binding.html. http://extensions.rubyforge.org/rdoc/classes/Binding.html.) Perhaps you want even more access to environments elsewhere in the call stack; ISTR that there are languages now that allow that. Of course, doing stuff like that makes it much harder to reason about your programs than treating functions as sealed boxes that communicate via arguments and return values, which is one (but not the only!) reason why most languages deliberately don't make it easy to do.

by Meai 14y ago

Smudge 14y ago

The way you describe it as "time" and "history" is confusing. In your gist, essentially you want to roll backwards, fetch the value you had in the previous layer of the stack, and then jump forward to your current execution, but with that reference in tow. So I think I get where you're going, but it doesn't seem very useful to me. The whole point of passing the reference when you need it is that you're giving your code some meaningful context. If any reference were accessible from any method, you'd essentially be dealing with a giant global context of everything. (Isn't that what singletons are for?)

Meai 14y ago
You are thinking way too much in terms of programming. What's wrong with global context? Your mind is one huge global context, and it seems to work fine. You fetch stuff all the time from one big pool. Sure, there's hierarchy in there. Just like in my example: Different times, different functions, they all provide hierarchy and structure to the times you can fetch data from.
- catharsis 14y ago
  This sounds like state based programming. IIRC this was a moderately popular way of programming games in the past. The resulting code is somewhat monolithic however, hard to maintain.

dragonwriter 14y ago

It doesn't seem to be about time, you seem (by a conservative interpretation) to want to be able to access a the context from which a function was called from within the function: some languages allow you to do that nowm though quite often, even those in which it is possible don't have a direct and convenient mechanism in the language core or standard libraries, though the mechanism is implementable in the language, as in Ruby where Binding.of_caller doesn't exist, but can be implemented (http://extensions.rubyforge.org/rdoc/classes/Binding.html. http://extensions.rubyforge.org/rdoc/classes/Binding.html.) Perhaps you want even more access to environments elsewhere in the call stack; ISTR that there are languages now that allow that. Of course, doing stuff like that makes it much harder to reason about your programs than treating functions as sealed boxes that communicate via arguments and return values, which is one (but not the only!) reason why most languages deliberately don't make it easy to do.