Promoting weak pointers

Michiel Helvensteijn <m.helvensteijn@gmail.com>
Thu, 11 Jun 2009 09:10:34 -0700 (PDT)

          From comp.compilers

Related articles
Promoting weak pointers m.helvensteijn@gmail.com (Michiel Helvensteijn) (2009-06-11)
Re: Promoting weak pointers fset.slb@gmail.com (Scott Burson) (2009-06-15)
Re: Promoting weak pointers andrew@tomazos.com (Andrew Tomazos) (2009-06-16)
Re: Promoting weak pointers m.helvensteijn@gmail.com (Michiel Helvensteijn) (2009-06-16)
Re: Promoting weak pointers m.helvensteijn@gmail.com (Michiel Helvensteijn) (2009-06-16)
Re: Promoting weak pointers m.helvensteijn@gmail.com (Michiel Helvensteijn) (2009-06-17)
Re: Promoting weak pointers bobduff@shell01.TheWorld.com (Robert A Duff) (2009-06-17)
[3 later articles]
| List of all articles for this month |

From: Michiel Helvensteijn <m.helvensteijn@gmail.com>
Newsgroups: comp.compilers
Date: Thu, 11 Jun 2009 09:10:34 -0700 (PDT)
Organization: Compilers Central
Keywords: linker
Posted-Date: 14 Jun 2009 19:08:31 EDT

Hi all!


In September, last year, I posted here asking your opinions on weak
pointers:


http://compilers.iecc.com/comparch/article/08-09-004


I apologize for not responding to any of them. I'm not sure why I
didn't. (At the time I must have thought a simple 'thank you' response
would not get through moderation.) But the responses were useful!
Thanks! We've decided to keep weak pointers around, if only to give
programmers a tool to break reference cycles. And there are other
uses.


Anyway, we have rethought our pointer system since then, and I would
like some opinions on a new issue.


To catch up: variables in Mist (the programming language) no longer
have reference semantics, as they did in the earliest version. The
"every variable is a pointer" idea seemed in retrospect to lack
elegance and scalability. For example, when copying an array, would we
have copied the pointers within, or the values within? There was no
right answer, since all variables were also pointers.


We have reverted to value semantics now. A pointer is now only a
pointer, with an address as its value. This makes the language more
predictable. We still do not allow pointer arithmetic, nor can you
compare pointers for anything other than (non)equality. We still have
strong and weak pointers. A strong pointer keeps its object alive and
shares ownership with other strong pointers. A weak pointer 'observes'
an object. It can be used to access the object and to test for its
existence. A short example of the syntax follows:


int^ sp <- new 42; // strong pointer to heap allocated integer 42
int` wp <- sp; // weak pointer to the same value
write(wp^); // dereferencing a pointer, writing "42"
sp <- null; // destructs the value 42; this is testable through wp


Ok then. The issue is: do we want to allow 'promotion' of a weak
pointer to a strong pointer? Obviously we want to be able implicitly
cast a strong pointer to a weak pointer. How else could an object
obtain a weak reference? But if we allowed programmers to obtain a
strong reference from a weak one (which is technically possible), the
lifetime of the object would be much more difficult to analyze.


We may want to offer the guarantee that a scoped variable will be
destructed at the end of the scope, while still allowing weak pointers
to it. If we allowed promotion, the object might be 'rescued' by a
strong pointer obtained from a weak pointer.


So the main question would be: Can anyone think of a use-case for
promotion of a weak pointer in which there is no obvious alternative?
I have already gone through some of the basics, like inserting/
removing elements from doubly linked lists (strong pointers left-to-
right, weak pointers right-to-left). There doesn't seem to be a
problem there, and the casting-one-way-only rule seems to fit nicely.
But there are probably things I haven't considered.


Thanks in advance for your reply!



Post a followup to this message

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