[r6rs-discuss] [Formal] Why are simple conditions so different from
andre at het.brown.edu
Sat Mar 10 16:22:26 EST 2007
This message is a formal comment which was submitted to formal-comment at r6rs.org, following the requirements described at: http://www.r6rs.org/process.html
Name : Andre van Tonder
Email : andre at het.brown.edu
Type : simplification
Priority : minor
Component : Condition objects
Version : 5.92
The interface for simple conditions is different from that of records
but redundantly reproduces much of the functionality of records. Consider
making the interfaces more similar or even dropping simple conditions as a
separate concept and instead using a record hierarchy for them.
Simple conditions, like record types, have named fields and single inheritance.
As such, the API for defining these types, constructing instances and
accessing fields has to reproduce much of the same functionality. However, the
interface is different. For example,
- Record type field names are for informational purposes only, whereas
condition field names are actual symbolic labels that are used
- Make-condition-type takes a list of symbols, whereas
make-record-type-descriptor takes a vector of symbols.
- Define-condition-type has a subset of the functionality of
define-record-type. Yet the syntax of the former is different
from that of the latter.
In fact, I see no good reason why the ability to have custom constructors,
accessors, explicit and implicit naming APIs, control over introspection,
opacity, finality, etc., should be denied a designer of a condition hierarchy
given that these features are already available for other user-defined types.
It seems that simple conditions could perfectly well be a record type hierarchy
under a common root /record/ type.
An API for compound conditions would of course still have to be separate.
Consider making interfaces of simple conditions similar to that of records.
Better yet, drop simple conditions and consider implementing the condition
hierarchy as a hierarchy of record types with common parent /record type/
condition. In this way, all of the infrastructure available for records,
including custom constructors, explicit and implicit naming interfaces,
introspection, etc., would become available for new condition
Compound conditions could remain largely as they currently are, and so can the
convenience syntax (condition ----), etc.
More information about the r6rs-discuss