Programs are running processes.
Seems like a weird definition to make, when in the next paragraph you declare that programs have no proper representation? Seems like you are trying to take on a very generic view of what a program is, but then by assuming it's a process you are actually narrowing it a lot. (And e.g. excluding kernels or Arduino programs, since those are not processes.)
guises
This would benefit from some examples, e.g. are you saying that the "C language" is a guise, and this editor could decompile a running process to C code on the fly?
Tags, views, and guises are all themselves programs
Ok so a guise is a program, what does it do? Does it translate e.g. a "C language string" to a program and back? What are the representations for programs? I feel like you have to choose some representation if you want programs to be transforming programs.
Seems like you are trying to take on a very generic view of what a program is, but then by assuming it's a process you are actually narrowing it a lot.
Yeah, that's very fair. I am trying to gesture to a very abstract generic view of objects within the computer beyond the strict definition of a process. I was really meaning to gesture to the fact that the text that represents a computer program is not that computer program, and do some extremely fuzzy vibe extrapolation on that idea.
This would benefit from some examples
I think the idea I'm trying to describe with "guise" is more nested and fuzzy than what you are thinking. A byte, or word, could be encoding an ascii character or an integer or a float, or some other kind of thing. So first of all, just that imposition of calling it an integer is giving it a guise. I don't imagine there are many places where you would want to be changing such a low level guise on the fly, but I'm sure it does happen. So all datatypes are guises, but this is generally at a much lower level than I would want to focus on most of the time.
Going slightly higher level you could think of a byte we determined is an integer. How do you want to look at and affect that integer? You might want to see it as an arabic numeral written on the screen. Maybe you want to see it as a bar in comparison to other bars representing other things. Maybe you want to see it as part of a heat map, that could be as part of a literal bitmap image. There are many conceivable ways of looking at that byte and none of them are more true than any other, it depends on the context of what you, or the program looking at the byte, is doing with that byte.
Another small step up to higher abstraction, maybe I have two floats. Are they coordinates? Viewing and moving them on a graph is surely an easy an obvious way of working with them if they are. That should be built in to the way a programmer can edit their program, not an external library that needs referencing. Or rather, the external library should be easily accessible from within the view if the programmer decides that they want to look at those two floats as coordinates for a moment for whatever reason. But in some other specific context those two floats may represent something completely different and it would make sense to represent and work with them in a completely different way.
There are so many possible guises that it wouldn't make sense to try to pull them out of a flat list, which is why the idea of tagging and building views would be some important.
If this seems like an idea that may be general to the point of uselessness, that is because it may very well be that. It is based on a great deal of my frustrations in my experiences programming. I don't want to claim that I think it could really be possible to make the idea sensible or implementable.
About the "C language", it could be a guise, but the way I'm imagining it it would be more likely that code snippits would be used as guises than a whole C language program. I think decompiling a running process to C code on the fly would fit within the idea of what Naloe is and does, but probably isn't something I would expect anyone to actually do in almost all circumstances. Idea 7 "Programs run differently depending on how closely you're looking at them. They run slower. Hooks put in to feed guises have a cost. This is explicit." certainly applies here.
I feel like you have to choose some representation if you want programs to be transforming programs.
No, this is one of the things I really like about the Naloe concept is that there is no true representation. The data and programs are transistor states in constant modification by processing hardware. That is what is really there. Anything on top of that is to help you, or other programs, understand and work with that computer and use it to accomplish other things.
It is true that at any given time you can only be looking at any given object with a fixed number of guises and those guises need to be chosen based on what the object is for, but you don't need to always see that object with the same guise. It is useful to have conventional guises but nothing should ever be fixed to one guise in all contexts, and most importantly, it should be easy to switch to guises that make sense for what you want to do without needless friction.
When I was younger and ever so slightly more idealistic I dreamed of making a programming editor that didn't suck. I was going to call it "Naloe" and provide many bacronyms to explain the name. In the nature of young idealistic programmers, I allowed the scope of the idea to creep horribly out of control. But I still love many of those ideas.
In responding to Is Building Good Note-Taking Software an AGI-Complete Problem?, I started typing out some of those ideas and it became so long I decided to post it as a stand alone post, so without further ado here is a list of ideas about Naloe, the first true program editor: