> Algol 68 has a "scope restriction". Roughtly speaking, at no time can > any value in a more global scope contain a pointer to anything of a less > global scope. There is no effective way to test this except as run-time > check. For the run-time check to be fast, pointers and such have to be > big -- the have to contain ont only the address of the thing pointed to, > but an easily-compared encoding of its scope. This has led most A68 > implementers to ignore scope checking. Violating it isn't something a > programmer does by mistake (not like indexing out-of-bounds, for > example). So it works pretty well for everyday use. > > But it does lead to an insecure run-time system. The user should at > least have the option to run in a secure mode. The two choices I seem to > be left with are to implement full scope-checking, or to allocate > everything that might be pointed to on the garbage-collected heap. As > far as I know, no one has seriously implemented this option in a > conventional programming language. > > Now one of the things that can be pointed to are labels; the pointers > are, effectively, activation records with goto's in their procedures. > The jump targets may, of course, be in procedure activations that have > already been exited.
I'm having trouble understanding here. What happens when such a jump target is used? > Presumably you guys are familiar with Scheme. Any solutions? We believe there is one remaining class of problems that C-- does not solve but should solve. This class includes: - Copying a stack - Splitting a stack into segments - Inserting handlers between segments of a stack Applications include - First class continuations as implemented in Chez Scheme - Perry Cheng's incremental garbage collector - Work-stealing thread schedulers - 'Parallel ready serial calls' as in Intel's Pillar language We're hoping to tackle this set of problems next summer, after the POPL deadline. Norman _______________________________________________ Cminusminus mailing list [email protected] https://cminusminus.org/mailman/listinfo/cminusminus
