---
This message is a formal comment which was submitted to [EMAIL PROTECTED], 
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.




_______________________________________________
r6rs-discuss mailing list
[email protected]
http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss

Reply via email to