[r6rs-discuss] [Formal] Why are simple conditions so different from records

[AndrevanTonder]

---
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
Dependencies: None

Summary:
--------

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.

Discussion:
-----------

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

Recommendation:
---------------

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

Compound conditions could remain largely as they currently are, and so can the
convenience syntax (condition ----), etc.