Re: Storage management, was Compiler writers will love this language

On 4 Jul 2003 00:11:39 -0400, C posted:
>
> I am working on a similar scheme, however you get this problem
> when someone does something like...
>
> Wombat * externalProcedureUnknownToCompiler ( Wombat * );
>
> Wombat * undecidable ( void ) {
> Wombat * w = new Wombat;
> return externalProcedureUnknownToCompiler();
> }
>
> Now did the externalProcedureUnknownToCompiler() return
> a new Wombat variable or a copy of the reference to the
> Wombat it was passed? Plus has the nasty external callee
> squirreled away another copy of the reference somewhere?
> Both of these problems are clearly undecidable at
> compile time (due to lack of information.)
>
> [I guess the above is a variant of the Halting problem.]


No, you're in an even more constrained system. If you have code that
could do anything that can't be scrutinised by your compiler, you
really are stuffed.


The halting problem objection is based on knowing everything that can
possibly be statically known about your program, and _still_ not being
able to determine which branch will be taken.


> Just make the compiler clever enough to be able to spot when
> something is undecidable (and use a run time GC scheme) and when to
> use the normal scheme.


Better to state this the other way round, I think. A program to decide
if something is undecidable is itself undecidable. You can certainly
choose safe subsets, where it's easy to show that the compile-time
scheme is ok: just because you can't do something in every single
special case is no reason to give up on it in i general.


> [Ewwww: who ever designed that syntax should have nasty
> things done to them involving custard,


You can do nasty things with custard?
My education has been sorely lacking.


mrak

Return to the comp.compilers page.
Search the comp.compilers archives again.