This page is part of the web mail archives of SRFI 76 from before July 7th, 2015. The new archives for SRFI 76 contain all messages, not just those from before July 7th, 2015.
I am not sure that nontrivial field initialization contributes /necessary/ complexity.
Having said that, the paradigm for field initialization seems wrong to me. It imposes arbitrary limitations which I believe to be simple to overcome in an alternative design suggested at the end of this post.
But first, the problems with the current approach: * It arbitrarily limits the kinds of computations that can be performed during initialization of a field. For example, one cannot reuse intermediate results needed for more than one field. Each field has to be recomputed from scratch from the inputs. * It has the wrong granularity. A common use case it cannot handle is a consistency check of the arguments before computing the individual fields. A related use case is where the constructor has optional arguments, where the number of arguments need to be determined before computing the fields. * A record type definition declares an implicit constructor procedure. However, the actual body of the procedure is interspersed with other syntactic elements, which seems gratuitously complex to me. * The design requires record declarations to be a new binding form. Apart from the lack of economy this entails, this binding form has an somewhat unusual, and therefore guaranteed to be confusing to many, scoping rule. * There seems to be a more powerful and simpler alternative: Alternative Suggestion: Instead of having a separate <init expression> for each field, one could simply have an <expression> for the constructor, which should evaluate to a procedure that returns the computed fields (using VALUES, for example). This would solve all the above problems. The overall gain in power and simplicity would be, in my view, significant. Regards Andre