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.
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