Implement part 4 of my PhD thesis:
Every program can have effects that are left unspecified in the program itself, instead enacted by a "backprogram" to which it is the "foreprogram".
For instance, an abstract "standard output", or input via "typed holes". Thus the program never has to deal explicitly with a windowing system, or with interaction with the user, instead it displays objects (as in Genera or CLIM presentations, or which browser JS console.log is a pale pale mockup) and lets the environment do its thing.
SECURITY:
When a picture manipulation program needs an input, it asks for an abstract "picture" input from its backprogram. Which itself might ask ITS backprogram to open a file. All the manipulation program sees is a picture as input, a picture as output — its very type prevents any security issue. The first backprogram is not allowed to modify the state of anything, also ensuring its correctness and security, but it can invoke its own backprogram to select input and output files. It has no direct access to the filesystem and can't do anything malicious, yet has all the effects the user wants. The file selector is also restricted in what it can do, etc.
UPGRADABILITY
A backprogram can be shared or separately instantiated by many programs, and can be upgraded separately from those programs. Thus a program written in 2020 will still work unmodified in 2030 with access to newfangled capabilities of 10 years later, e.g. use a searchable distributed datastore with a VR input — without the initial program having to be modified at all, much less linked to new libraries, or having the security capabilities necessary to access those new resources. It's all done via backprograms.
Implement part 4 of my PhD thesis: Every program can have effects that are left unspecified in the program itself, instead enacted by a "backprogram" to which it is the "foreprogram".
For instance, an abstract "standard output", or input via "typed holes". Thus the program never has to deal explicitly with a windowing system, or with interaction with the user, instead it displays objects (as in Genera or CLIM presentations, or which browser JS console.log is a pale pale mockup) and lets the environment do its thing.
SECURITY: When a picture manipulation program needs an input, it asks for an abstract "picture" input from its backprogram. Which itself might ask ITS backprogram to open a file. All the manipulation program sees is a picture as input, a picture as output — its very type prevents any security issue. The first backprogram is not allowed to modify the state of anything, also ensuring its correctness and security, but it can invoke its own backprogram to select input and output files. It has no direct access to the filesystem and can't do anything malicious, yet has all the effects the user wants. The file selector is also restricted in what it can do, etc.
UPGRADABILITY A backprogram can be shared or separately instantiated by many programs, and can be upgraded separately from those programs. Thus a program written in 2020 will still work unmodified in 2030 with access to newfangled capabilities of 10 years later, e.g. use a searchable distributed datastore with a VR input — without the initial program having to be modified at all, much less linked to new libraries, or having the security capabilities necessary to access those new resources. It's all done via backprograms.
Much more, see my thesis. https://j.mp/FarePhD