This page is part of the web mail archives of SRFI 76 from before July 7th, 2015. The new archives for SRFI 76 are here. Eventually, the entire history will be moved there, including any new messages.
It seems to me that the SRFI specifies rather more than necessary. I would suggest that the procedural/reflection interface is enough, and that the various syntactical layers can be left to existing SRFIs (such as SRFI-9) and possible future SRFIs. Reasons: * PRIMITIVE/LIBRARY DISTINCTION BLURRED: The SRFI blurs the distinction between the primitive interface and library features. It implicity contains not only one but two library layers (explicit and implicit naming features). * CALL-WITH-VALUES precedent: While R5RS could have specified syntactic layers (such as RECEIVE and LET-VALUES) on top of call-with-values, this was not done. Why not, and are similar reasons not applicable here? * ARBITRARY OVERDESIGN: The specification of the syntactic interfaces attempt to provide some seldom-used features that seem to have been harvested from existing implementations yet still somewhat arbitrarily leaves out other useful, even fundamental features, such as constructing by field name and functional record update. Rather than trying to be everything to everyone, I am suggesting leaving out the syntactic layer altogether. * IMPLICIT IDENTIFIERS: The second syntactic layer breaks with RnRS tradition in specifying implicit identifiers. In addition, this would require a specification of how these identifiers interact with the hygienic macro system, which is not provided. * NAMING CONVENTION: Scheme language specifications have not in the past standardized naming conventions, and it is arguably not the place of R6RS to do so, especially when there are other record naming conventions already in widespread use. In conclusion, the procedural/reflection interface is economical, clean and simple. I suggest removing the syntactic libraries from the SRFI. Regards Andre I