plaidgroup / plaid-lang

The Plaid Programming Language Tools
11 stars 1 forks source link

This semantics in constructor/initialization order and dependencies #23

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago
Here are the potential solutions that we came up with:

*-forbid this in field initializers
*-order of init for values in scope
-state change is same as construction
*-simultaneous assignment

Original issue reported on code.google.com by mhahn...@gmail.com on 24 May 2010 at 9:18

GoogleCodeExporter commented 9 years ago
The easiest of these solutions is to just forbid "this" in the constructor to 
avoid confusion.  If the programmer 
wishes to refer to a field that has just been (re)defined, they can simply 
refer to it by name.  If it has not been 
defined yet, we will search for the next innermost scope in which the name is 
defined.  Thus it becomes 
impossible to do something like:

state Test {
    var foo;
    var bar;

    method baz() {
        this <- Test with { var foo = bar; var bar = foo; };
    }
}

What the programmer might expect is for foo and bar to be swapped.  However, 
due to the order of 
initialization of fields and the way that we search the scope starting within 
the new state initialization, foo will 
be assigned to the old value of bar and bar will be assigned to the new value 
of foo (which is the old value of 
bar).  In this case, the programmer will need an extra variable to temporarily 
hold the old value of foo.

Original comment by mhahn...@gmail.com on 1 Jun 2010 at 7:33

GoogleCodeExporter commented 9 years ago
Forbidding use of 'this' in method constructors is actually harder than I first 
thought.  We would have to search 
through all of the subexpressions of a field declaration for uses of 'this' 
(because it's okay to use 'this' in method 
declarations).

Original comment by mhahn...@gmail.com on 1 Jun 2010 at 8:47