[r6rs-discuss] [Formal] Simplifying conditions
Andre van Tonder
andre at het.brown.edu
Tue Nov 7 15:45:52 EST 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
Conditions can be simplified significantly.
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> ...)
(make-condition (list &message &who) ; implemented condition-type interfaces
'condition-message "phone me"
The syntactic API could look as follows for the example in the draft:
(define v3 (condition (&c1 &c2) ; implemented condition-type interfaces
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.
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
- modify "make-condition" procedure as described above
- modify "condition" syntax as described above
More information about the r6rs-discuss