On Fri, 09 Jan 2009 16:16:00 +0000, Hendrik Boom wrote: > On Thu, 08 Jan 2009 23:01:20 -0500, Norman Ramsey wrote: > >>> 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? > > Well, first of all, you can only get to this state in a program that > violates the restrictions of the language, and has violated them well > before the goto is executed. So the language definition says what > happens in "undefined". But detecting this situation is expensive. I'd > like further execution to be other than "indescribable chaos", to quote > an early draft of the language definition. Given an activation record > on the heap, I suppose I could mark it when it has been exited, and then > test for this when I'm going to it. > > But barring a restriction like this, it would be interesting to allow it > -- the semantics would then be kind of like reusing continuations ins > Scheme.
OK. I'll prohibit goto's that go into terminated procedure activations. That seems like the cheapest way to eliminate this cause of indescribable chaos. To do it, a label will consist of a continuation (something to cut to) and a pointer to some heap object created on entry to a procedure containing labels. The heap object will contain a bit indicating whether the activation record is still active. The bit is set when a procedure involving labels is returns. A go to will test this bit. These bits will also have to be cleared in some kind of stackwalk as the goto terminates other activations between the jumper and the jumpee. goto's are rare. I can afford the cost. Problem solved, until I feel like implementing labels as Scheme-like first-class continuations. That can definitely wait; it isn't even in the language. -- hendrik _______________________________________________ Cminusminus mailing list [email protected] https://cminusminus.org/mailman/listinfo/cminusminus
