(Phrased colloquially: "The finger pointing at the Moon is not the Moon.")
Information about a given computer program may be found in its symbols (variable names) and its referents (values that variables are set to).
The referents may be set in source code (i.e. a string or other constant) and be visable/greppable at design-time -- and/or they may be set at runtime (and be non-greppable!)
The article is good; I have nothing against it, it makes an excellent point.
But if we look at what I've outlined above as three possible places for information (source symbol, source referent, runtime referent), then we observe that one of these possibilities is not covered by grep -- that is, runtime referent.
This leads to the question:
"What if grep could be used to search for runtime referents, aka runtime values of different variables?"
Well, in traditional compiled languages, we can't do that without significant monkeying with the language...
In interpreted and Lisp-like languages, yes, the above is possible -- but without being able to be very specific about the what/how/when of the runtime strings (or more broadly, values) to be grepped, doing the above could generate huge amounts of data and speed degradation, particularly if a value is set and reset multiple times in a long loop!
But could it be done? Definitely! Efficiently? Well, that's one of the questions! Deterministically? If random values are in play, probably not. With full code coverage so that values can be known from code paths not taken can be known? That scenario would be challenging to say the least.
Point is, it may be an interesting future language feature to consider in various scenarios, for future language designers...
"The ability to grep through all runtime referents, aka all runtime values, of all variables, for a given runtime of a program..."
Hmmm... now that I think about it, what if a language was created such that you could pass it a special flag, if you passed it this special flag, then variables would maintain their histories in memory (at great expense to performance -- this would be for debugging only!), and then you could grep that memory?
Yes, I know... given the pace of technology, there probably is some system or systems that might implement some aspect or aspects of this...
(Maybe the rr maintainers could be persuaded to implement some interface with grep, either pre or post program run, or maybe implment a timer where the user can grep their program for various strings at various time intervals...)
In C, the word referent is used for the thing a pointer points to. That's your main ungreppable run-time referent.
> "The ability to grep through all runtime referents, aka all runtime values, of all variables, for a given runtime of a program..."
It sounds entirely doable in a garbage-collected run-time. We "stop the world" and then run something similar to the marking pass of a full garbage collection cycle, which looks for matches for a pattern in the entire space of reachable objects. The routine could maintain a path from root pointer to object (easily done on the recursion stack) so that it's reported along with matches.
>"The routine could maintain a path from root pointer to object (easily done on the recursion stack) so that it's reported along with matches."
Yes, it definitely could!
For extra points (if the additional functionality is desired!), also create an API interface for this functionality for coding AI's, present and future, such that they can also perform this form of grepping automatically when needed, for example, when running/debugging a program they wrote, or are assisting a programmer with making changes to...
(Observation: There seem to emerge two different main patterns with respect to variable inspection... One is to set a watchpoint on a variable and stop the program when the variable changes.
Another would be to globally scan all variables (i.e. grep) at specific intervals (a form of a batch pattern) for specific strings/values, and all of that would be/could be -- settable by the programmer and/or an AI...)
Objects in heaps can be reached in more than one way. We don't want to traverse any object twice, because we will loop, so we must use the GC marked bit.
Yet! There is a way to report all the paths by which an grepped-out object is reachable.
Say we encounter an interesting object O for the first time, at path A B C. So we have A.B.C.O.
We keep objects A, B and C in a hash table. The hash table represents nodes we have visited, which are on the path to a hit.
Then say we encounter object B again, at path X Y Z B. B is a hit in our hash table, and so we report X.Y.Z.B.C.O as another hit for object O, without descending into B again.
The more broad understanding here is that in computer programming there is a difference between a symbol and a referent (https://open.maricopa.edu/com110/chapter/3-1-language-and-me....) AKA variable and its value.
(Phrased colloquially: "The finger pointing at the Moon is not the Moon.")
Information about a given computer program may be found in its symbols (variable names) and its referents (values that variables are set to).
The referents may be set in source code (i.e. a string or other constant) and be visable/greppable at design-time -- and/or they may be set at runtime (and be non-greppable!)
The article is good; I have nothing against it, it makes an excellent point.
But if we look at what I've outlined above as three possible places for information (source symbol, source referent, runtime referent), then we observe that one of these possibilities is not covered by grep -- that is, runtime referent.
This leads to the question:
"What if grep could be used to search for runtime referents, aka runtime values of different variables?"
Well, in traditional compiled languages, we can't do that without significant monkeying with the language...
In interpreted and Lisp-like languages, yes, the above is possible -- but without being able to be very specific about the what/how/when of the runtime strings (or more broadly, values) to be grepped, doing the above could generate huge amounts of data and speed degradation, particularly if a value is set and reset multiple times in a long loop!
But could it be done? Definitely! Efficiently? Well, that's one of the questions! Deterministically? If random values are in play, probably not. With full code coverage so that values can be known from code paths not taken can be known? That scenario would be challenging to say the least.
Point is, it may be an interesting future language feature to consider in various scenarios, for future language designers...
"The ability to grep through all runtime referents, aka all runtime values, of all variables, for a given runtime of a program..."
Hmmm... now that I think about it, what if a language was created such that you could pass it a special flag, if you passed it this special flag, then variables would maintain their histories in memory (at great expense to performance -- this would be for debugging only!), and then you could grep that memory?
Yes, I know... given the pace of technology, there probably is some system or systems that might implement some aspect or aspects of this...
rr comes to mind:
https://rr-project.org/
https://news.ycombinator.com/item?id=31617600
(Maybe the rr maintainers could be persuaded to implement some interface with grep, either pre or post program run, or maybe implment a timer where the user can grep their program for various strings at various time intervals...)
Anyway, good article!