Wot if… I add X to my language?
| Implicit dynamic memory management | ||
| Persistence | ||
| Higher-order procedures/functions | ||
| “Procedures as values” | ||
| Why? | |||
| Safer | |||
| Easier | |||
| Best use of resources (tradeoff…) | |||
| Complexities | |||
| Automatic allocation easy enough | |||
| Garbage collection a big issue, however | |||
| Crucially, cost is now acceptable, when offset against improved productivity | |||
| Mark-Sweep | |
| Reference Counting | |
| Copying Collection | |
| Generational Collection | |
| Incremental Collection |
| The persistence of a value is | |||
| the length of time for which it is valuable to the on-going computation | |||
| E.g. sub-expression, block, fn invocation, package, program invocation, program lifetime, system lifetime | |||
| Orthogonal persistence | |||
| the persistence of data values is independent, or orthogonal, to all other properties of the value (such as type, constancy, naming) | |||
| Cf. trad. systems where ONLY files have long-term persistence | |||
| Write programs to install data | |
| Write other programs that at some later time access the data | |
| Programs may be prepared independently from one another |
| Store the heap on disk | |
| Transfer values between disk & memory as required | |
| Anything else? |
| Common place in functional languages | ||
| all tied up with referential transparency | ||
| Less common in languages with state that can be updated… | ||
| but can be used in very interesting ways... | ||
| let counter = { | |
| let val := 0 | |
| fn( -> int ){ | |
| val := val + 1 | |
| return val | |
| } | |
| } | |
| print( counter() ) | |
| print( counter() ) |
| Code and data traditionally held as very separate concepts | ||
| genetic programming etc is viewed as dangerous and esoteric | ||
| Programming environments however manipulate programs in various forms | ||
| is that not data? | ||
| and how complex are they…? | ||
| Largely caused by binding issues | ||
| exacerbated by separate domains for long and short term data storage | ||
Persistent Progr'mming Environments
| All data - including code - can live in one environment | ||
| All prog env. tools exist in the same env | ||
| compilers, window managers, editors | ||
| So what can we do now? | ||
| And what is the effect on our implementations…? | ||
| Step 1 | ||
| source code can contain links to complex manifest objects (cf. simple ints & strings) | ||
| Step 2 | ||
| redesign environment to handle this | ||
| Step 3 | ||
| find a HLL rep. for all run-time values | ||
| Step 4 | ||
| can drop concept of source vs. executable code | ||
| instead, one form, with different views | ||
| Result | ||
| simplicity of interpreted system (eg Basic) with efficiency of a compiled language | ||
| More exciting language features create lots of exciting problems for the language designers | ||
| More on persistence & hyperprogramming at | ||
| http://www-ppg.st-and.ac.uk/Publications | ||
| http://www-ppg.st-and.ac.uk/Publications/1992.html | ||