[r6rs-discuss] [Formal] Simplifying conditions

From: Andre van Tonder <andre>
Date: Tue Nov 7 15:46:25 2006

I had corrected and simplified the original posting a bit, not realising that
it already appeared. In any case, the following should be a slightly easier
read than the original, so I post it anyway:

Name : Andre van Tonder
Email : andre at het.brown.edu
Type : simplification
Priority : medium
Component : Conditions
Version : 5.91
Pages : 74-76
Dependencies: Possible usages elsewhere in document

Summary:
--------

Conditions can be simplified significantly.

Description:
------------

The current model for compound conditions is unnecessarily complex. A simpler
model is proposed. It avoids compound conditions and the attendant field
priority complexities of the current draft.

The model can be built by thinking of a condition as consisting of

     - a set of implemented condition-types (e.g., list with no duplicates)
     - a flat field-name -> value mapping (e.g., alist with no duplicate names)

This is essentially the Java model if we read "interface" for "condition-type"
and "object instance" for "condition". The Java interface model is very simple
and well-understood. It has the additional virtue of being well-established.

This model would allow one to

    - drop compound conditions completely
    - get rid of the complicated field priority semantics

A condition object can then be created as

    (make-condition <list-of-types> <field-name> <obj> ...)

For example

    (make-condition (list &message &who) ; implemented condition-type interfaces
      'condition-message "phone me"
      'condition-who "mother")

The syntactic API could look as follows for the example in the draft:

    (define v3 (condition (&c1 &c2) ; implemented condition-type interfaces
                 (x "V3/1")
                 (a "a3")
                 (b "b3")))

If the ability to downcast to on of the implemented condition types is
required (the analogue of the current "extract-condition") it can be easily
implemented in this representation. It can be done in a way that also allows
subtypes to be obtained if required, which extract-condition does not do.

The current draft seems to try to approximate this idea, but does so in a way
that is broken. I quote:

   "Each type-field-binding must contain field bindings for all
    fields of condition-type without duplicates. There is an
    exception to this rule: if a field binding is missing, and the
    field belongs to a supertype shared with one of the other
    htype-field-bindingi subforms, then the value defaults to
    that of the first such binding in the condition form."

This is inelegant.

The current specification has several further issues, which
would fall away if the model were simplified as above:

   - It is not clear if the type of conditions is the recursive type

      <condition> ::= (make-condition ---)
                   / (make-compound-condition <condition> ...)

     which would allow make-compound-condition to be nested,
     or the alternative non-recursive type

      <simple-condition> ::= (make-condition ---)
      <condition> ::= <simple-condition>
                   / (make-compound-condition <simple-condition> ...)

   - If the recursive type, then "condition-ref" is not fully specified in
     case of repeated fields, since it is not specified if the
     search for the first field is e.g. depth-first.

   - Same for "extract-condition" if the type is recursive above.

Suggestion:
-----------

As in above text:

    - drop "make-compound-condition".
    - drop complex descriptions of field priorities.
    - drop "extract-condition", unless downcasting ability is a
      requirement, in which case I would preferably use a different name
      for it.
    - modify "make-condition" procedure as described above
    - modify "condition" syntax as described above
Received on Tue Nov 07 2006 - 15:45:52 UTC