On 2009-04-29 22:54:20 -0400, "Robert Jacques" <[email protected]> said:
On Wed, 29 Apr 2009 21:25:32 -0400, Michel Fortin
<[email protected]> wrote:
That's basically why I suggested adding scope constrains back then. To
implement swap safely, you need to know that the scope of the pointer
you are assigning to is always smaller or equal to the scope of the
memory block you're feeding them with.
Here's a new syntax for expressing contrains I've been thinking about:
void swap(scope int* x, scope int* y)
scope(x = y && y = x) // caller enforces that y is assignable to x
and x to y
{
scope(x = t && t = y) int* t;
// y assignable to t and t to x; also imply that
// x is assignable to y, which holds against previous constrains
t = y; // valid since scope(t = y)
y = x; // valid since scope(y = x)
x = t; // valid since scope(x = t)
}
Perhaps with simple escape analysis, the compiler could infer the scope
constrains of local variable t so you don't have to write it everywhere.
You know, the implementation of swap is really a bad example, since
using a template works fine:
void swap(T)(ref T x, ref T y) {
T t
t = y;
y = x;
x = t;
}
You know, all functions could be made templates and it'd solve all our
problems. Why aren't we doing that?
Seriously, templates can't be the answer to everything. What if you
wanted swap as a member function of a class, and want to override it in
a derived class? We need a system that works with non-templates too.
Object a;
Object b;
shared Object c;
swap(a,b); // Okay
swap(b,c); // Error, template instantiation swap(local object, shared
object)
In the case of my function with constrains you'd get something alike:
swap(b,c); // Error, 'swap' wants c (shared Object c)
// to be assignable to b (local Object b) which isn't allowed.
Basically, you can't copy a scope variable to another scope variable
inside a function (because they may not be of the same scope and/or
ownership) unless the signature includes a constrain signaling the
assignement, which is then evaluated at the call site.
Here are some specific issues:
1) You seem to assume that different ownerships are interchangable.
They are not. Even if the data layout and member signatures are the
made to be the same, shared objects must maintain sequential
consistency (i.e. memory fences).
1a) Limiting object signatures to being identical makes it hard for
library writers to make a class that can be both allocated on both the
shared and local heaps.
Where am I assuming that? How? Perhaps I'm not understanding something
of your proposal, but I don't see how adding scope constrains breaks
shared objects.
You say you want "scope" to be the super-type of all, which means that
it should accept both local and shared variables, am I right? If that's
the case I was right to write variable as being scope in my swap
function, so it can accept everything.
2) You shouldn't rely on escape analysis to determine your function
signature. It essentially forces you to do whole program static escape
analysis, if you want to do it right, which is implausible. Consider
recursive and member functions. What's the proper signature? And this
isn't even considering the composability and forward referencing issues.
That I certainly agree with. (And I never suggested escape analysis to
determine the scope of function arguments, only local variables inside
the function.)
--
Michel Fortin
[email protected]
http://michelf.com/
