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
[email protected]
https://lists.sourceforge.net/lists/listinfo/chapel-developers
