Hello Vitali: I appreciate your feedback.
We have already considered the "ctor" keyword to introduce constructor definitions because -- as you point out -- it is then legal to use syntax that does not conform to the syntax for a standard procedure definition. Your idea of omitting the 'with' keyword and parentheses is worth considering. The motivation for adding them to the syntax was to visually distinguish the initializer-list from the body of the constructor. But in your proposal, the appearance of the field-initializers before the opening bracket of the constructor body does that well enough. So far, I have received only two external responses on the topic, so I have to give them equal weight. Please encourage others to add their opinions to the discussion. Sincerely, Tom Hildebrandt Chapel Team ________________________________________ From: Vitali Baumtrok [[email protected]] Sent: Monday, October 20, 2014 11:24 AM To: [email protected] Subject: Re: Proposal: New syntax for the initializer-list in constructors Hi, the keyword 'with' confused me at first. What if the procedure has a return type? But then, it CAN'T, because it's a constructor. May I propose that we define the constructor with the keyword 'ctor' instead of 'proc'? Wouldn't it not only ease the readability, but also the work for the compiler, because now it can expect certain things after the keyword 'ctor'? Maybe then we could ommit the keyword 'with' and the brackets and so reduce syntax noise? ctor C ( a:int, b:int ) this.a = a, this.b = b { writeln ( "C created" ); } ctor C this.a = 1, this.b = 1<<7 {} Or the initialisation is a sequence of statemets: ctor C this.a = 1; this.b = 1<<7; {} But I'm not completely against the 'with' keyword or the brackets, if the compiler and tools need it. This is just some brainstorming of mine. Vitali Baumtrok ------------------------------------------------------------ Gesendet: Mittwoch, 17. September 2014 um 23:35 Uhr Von: "Tom Hildebrandt" <[email protected]> An: "[email protected]" <[email protected]> Betreff: Proposal: New syntax for the initializer-list in constructors 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[https://lists.sourceforge.net/lists/listinfo/chapel-users] ------------------------------------------------------------------------------ Comprehensive Server Monitoring with Site24x7. Monitor 10 servers for $9/Month. Get alerted through email, SMS, voice calls or mobile push notifications. Take corrective actions from your mobile device. http://p.sf.net/sfu/Zoho _______________________________________________ Chapel-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/chapel-users ------------------------------------------------------------------------------ Comprehensive Server Monitoring with Site24x7. Monitor 10 servers for $9/Month. Get alerted through email, SMS, voice calls or mobile push notifications. Take corrective actions from your mobile device. http://p.sf.net/sfu/Zoho _______________________________________________ Chapel-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/chapel-users
