> If I were designing this thing, and were not constrained > to remain compatible with the features that have already > been piled on, I would remove the restriction by > eliminating the preferred constructor descriptors.
As long as we're contemplating changes, we might as well contemplate fixing the thing completely. I'm interested in what you would propose if not constrained. > I have investigated this matter pretty thoroughly, > and your claim above concerning the cost of safety > checking shows that you do not yet understand just > how fast the procedural layer can and should be. None of what you say is news to me. With regard to the safety check, I was talking about the extra load needed to extract the <magic> object for comparison from the generated closure in the unoptimized code. I'd forgotten that this can't be avoided in R5.96RS even for the syntactic layer unless the nongenerative clause is present, because of the requirement that two evaluations of the same define-record-type must otherwise produce different types. In any case, all of what you say is interesting and should be useful for compiler writers who wish to optimize certain controlled uses of the procedural layer. For those that don't want to build the various high-level record operations into their compilers or interpreters, along with the optimizations needed to eliminate the extra overhead, my point is that the syntactic layer should permit direct macro-generation of efficient code (that is, code on par with vector-based abstractions and amenable to the general-purpose inlining that many compilers already do). The R5.96RS syntactic layer permits this; the R5.97RS syntactic layer permits this when the parent-rtd clause isn't used; and your proposed extension would permit this if the <parent name> variable were immutable. I prefer that it be immutable regardless of whether the definition appears at the top level of a library or program body, since I quite often use record definitions internally. Kent _______________________________________________ r6rs-discuss mailing list [email protected] http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
