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

mwotton@cse.unsw.edu.au (Mark Alexander Wotton)
4 Jul 2003 00:08:09 -0400

          From comp.compilers

Related articles
[5 earlier articles]
Re: Compiler writers will love this language mwotton@cse.unsw.edu.au (2003-06-22)
Re: Compiler writers will love this language genew@mail.ocis.net (2003-07-02)
Re: Storage management, was Compiler writers will love this language joachim.durchholz@web.de (Joachim Durchholz) (2003-07-04)
Re: Storage management, was Compiler writers will love this language rodney.bates@wichita.edu (Rodney M. Bates) (2003-07-04)
Re: Storage management, was Compiler writers will love this language basile@starynkevitch.net (Basile STARYNKEVITCH) (2003-07-04)
Re: Storage management, was Compiler writers will love this language lex@cc.gatech.edu (Lex Spoon) (2003-07-04)
Re: Storage management, was Compiler writers will love this language mwotton@cse.unsw.edu.au (2003-07-04)
Re: Storage management, was Compiler writers will love this language blackmarlin@asean-mail.com (2003-07-04)
Re: Storage management, was Compiler writers will love this language stephen@dino.dnsalias.com (2003-07-17)
Re: Storage management, was Compiler writers will love this language monnier+comp.compilers/news/@cs-www.cs.yale.edu (Stefan Monnier) (2003-07-17)
Re: Storage management, was Compiler writers will love this language haberg@matematik.su.se (2003-07-17)
Re: Storage management, was Compiler writers will love this language lars@bearnip.com (2003-07-17)
Re: Storage management, was Compiler writers will love this language RLake@oxfam.org.pe (2003-07-17)
[2 later articles]
| List of all articles for this month |

From: mwotton@cse.unsw.edu.au (Mark Alexander Wotton)
Newsgroups: comp.compilers
Date: 4 Jul 2003 00:08:09 -0400
Organization: Mare's Nest Collective
References: 03-05-211 03-06-015 03-06-054 03-06-057 03-06-078 03-06-106 03-07-014
Keywords: storage
Posted-Date: 04 Jul 2003 00:08:09 EDT

On 2 Jul 2003 00:40:16 -0400, Gene Wirchenko posted:
>>It smells a bit undecidable to me. At least for the complete case, I think
>>this reduces to the halting problem.
>>
>> Object foo(Object x, Object y) {
>> if (halts(x)) {
>> return y;
>> } else {
>> return x;
>> }
>> }
>>
>>When do you release x's memory?
>
> if branch: yes, else branch: no.
>
> Your code would make sense to me if the return values were
> switched. Is that what you meant, or am I missing something?


The idea is that you can't statically determine whether or not you branch.
If you could, you'd have solved the halting problem.


x represents a (program,input) pair, and halts(x) tells you whether the
program given ever stops with the given input. Now I think about it a bit
harder, I've made it needlessly subtle: I'm using x in two ways, as the
program to be tested _and_ the object to be freed.


To be a bit more verbose:


Object foo(Program p, Input i, Object x, Object y) {
if (halts (p,i)) {
return x;
} else {
return y;
}
}


and also assuming that there are no other references to the objects x and y.


mrak


Post a followup to this message

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