Hi - I like the proposal (and have suggested this change in the past). Also, I think it would be worth writing down the field-er-ator version of record assignment by name and putting that somewhere accesible to users in case they want to make a custom version implementing the old behavior.
Cheers, -michael On 04/09/2014 01:46 PM, Tom Hildebrandt wrote: > All: > > Please consider and comment on the following proposed language change. > > Thanks, > Tom Hildebrandt > > > STATUS QUO > --------------- > Currently, the Chapel compiler automatically generates an implementation of > assignment for each record type defined in the input (including internal > modules and any standard modules used). The signature for each of these > assignments is > > proc =(ref a:R, b) > > where R is the type of the LHS argument. As you can see, the type of the RHS > argument is unconstrained. This is to support the semantics currently > described in the specification, in which assignment between two objects of > arbitrary record type is accomplished through a field-by-field copy where the > fields are selected by name. The layouts of the two records must be > compatible to the extent that assignment of like-named fields from the type > of the right-hand operand to the type of the left-hand operand is a legal > assignment. If not, a compile-time error is issued. > > Unfortunately, the above signature allows 'b' to bind to 'nil' and other > objects of class type. Since 'nil' cannot be assigned to a variable of > record type, that case must be captured explicitly and flagged as an error. > > PROPOSED CHANGE > ----------------------- > The implementation would be simplified somewhat if the above signature were > replaced with one that constrains the right-hand argument to be of the same > type as the left-hand argument: > > proc =(ref a:R, b:R) > > In that case, the operand on the right-hand side of a record assignment must > be coercible to the type of the left-hand operand. Since 'nil' cannot be > coerced to a record type, that case is automatically rejected. This proposal > would also reject the proposed support for assignment from class objects to > record object described in Section 16.9.2 in the specification. That section > would be removed. > > This change would mean that records were only assignment-compatible if the > right-hand operand is coercible to the type of the left-hand operand. Unless > a user-defined cast is supplied, the supported coercions are only from a > derived record type to a base record type. Field-wise (by name) assignment > between unrelated record types would be specifically prohibited. As an > example, the proposed change would cause the test case > $CHPL_HOME/test/classes/bradc/records/assignRecord3.chpl to fail. > > Aside from simplifying the implementation, the proposed change also enables > an optimization. When records are in the same inheritance hierarchy, the > implementation can arrange that they are layout-compatible. In that case, > the implementation can replace trivial assignment (assignments having no > side-effects) with the equivalent of a memcpy() call. > > Since assignment between class objects is already constrained in this way, > the proposed implementation brings the definition of record types and class > types into closer alignment. That can help programmers to understand and use > both classes and records effectively. Arguably, permitting assignment > between objects of unrelated record types could be confusing. However, the > likelihood of this is small, since resolution of the assignment will fail if > the type of the right-hand operand does not have fields with names covering > all the fields in the left-hand operand, and all of those assignments must be > valid. > > A further argument in favor of the change is that it appears this feature is > not relied upon, at least within the Chapel development team. Only the one > test case mentioned above fails due to the proposed change. > > PROS > ------ > * Simplifies the conceptual model > * Simplifies the implementation > * Enables the "trivial assignment" optimization > * Has limited negative impact > > CONS > ------ > * Eliminates field-by-field (by name) assignment between objects of unrelated > record types > * Eliminates the proposed class object to record object assignment semantics ------------------------------------------------------------------------------ Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test & Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees _______________________________________________ Chapel-developers mailing list Chapel-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/chapel-developers
