As one of the only remaining members of the old-guard who proposed the
assignment between records by field name concept in the first place, I'm
fine with the proposal being made here; and it has the benefit of matching
the change we made for compiler-generated record comparisons recently, if
I'm keeping my facts straight.
Note that if we wanted to maintain assignment by field name, we could
potentially change the compiler-introduced signature to:
proc =(ref a:R, b:value)
(which I think is the abstract base class of all records, similar to
'object' for classes) which would have the benefit of causing things like
'nil' to no longer dispatch to this assignment. But I'm not actually
going to advocate we go this route at present.
-Brad
On Wed, 9 Apr 2014, 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
