All:
A recent discussion regarding the semantics of Chapel constructors w.r.t.
"const" fields makes it clear that we need a way of setting off
field-initialization from the body of a constructor.
This would involve new syntax -- applicable only within constructors -- to
specify an initializer list.
Please read the proposal (and alternatives) outlined below, and send me your
feedback.
Tom Hildebrandt
________________________________
The recently-introduced "with" keyword might be reused for this purpose. A
field-initializer list would consist of a "with" keyword followed by a
parenthesized, comma-separated list of field-initializer expressions. Each
field-initializer expression would contain a valid field name, followed by '='
followed by an initializer expression.
field-initializer-clause:
`with' ( field-initializer-list )
;
field-initializer-list:
field-initializer
| field-initializer-list field-initializer
;
field-initializer:
field-name = expression
;
Note that this syntax is different from the other use of "with" -- that one
involving applying argument-passing intents to scoped variables being passed to
a task block. Context can be used to distinguish the two forms: this form
appears in the context of a constructor definition while the other form appears
in the context of a parallel (begin, forall, coforall) construct.
When present, the field-initializer list would immediately precede the body of
a constructor. It would be disallowed in a non-constructor procedure
definition.
Under this proposal, given the class declaration
class C { var a:int; var b:real; }
a constructor that permits setting the value of field 'a' would look like
proc C.C(my_a: int)
with (a = my_a)
{
... // body of constructor
}
There are some old proposals for this syntax. In one, a special statement
"init;" would separate the field-initializer section of the constructor body
from the rest of the body.
proc C.C(my_a: int)
{
a = my_a;
init;
... // body of constructor
}
The problem I see with this proposal is that the meaning of '=' before and
after the "init" statement is different, and thus potentially confusing.
Before the "init" statement, '=' means initialization while after "init" it
means assignment.
A similarly weak proposal involved providing a constructor with two body
blocks. The programmer would just have to know that the first block supported
field initialization while the second contained the body of the constructor.
Because the first block is not visually distinguished from the second, it is
equally likely to be confusing.
A more recent proposal has been to reuse the "let ... in" syntax in the context
of a constructor to mean field-initialization. I think this is less suitable
than a "with" clause because the right expansion of a "let ... in" clause is an
expression (not a statement), and in its current use the variables declared in
the let clause are limited in scope to the "let ... in expression" as a whole.
This does not sit well with the idea that the values stored in fields will
persist for as long as the containing object does.
This is not a comprehensive list, and other proposals are welcome. In any
case, it will probably be some time before the initializer-list syntax is
needed/implemented.
THH
------------------------------------------------------------------------------
Want excitement?
Manually upgrade your production database.
When you want reliability, choose Perforce
Perforce version control. Predictably reliable.
http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
_______________________________________________
Chapel-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/chapel-users
