[r6rs-discuss] [Formal] Simplifying conditions
andre at het.brown.edu
Mon Nov 6 08:55:24 EST 2006
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 : major
Component : Conditions
Version : 5.91
Pages : 74-76
Dependencies: Possible usages elsewhere in document
Conditions can be simplified by following a well-understood object-interface
The rules for repeated fields seem to convey an intent
that conditions be thought of as objects implementing
more than one "condition type" interface. If so, why not make
a much simpler representation by following well-understood object
models, such as the Java model, as follows:
Think of condition types as "interfaces" and condition objects as objects of
anonymous type that "implement" these interfaces. Drop compound conditions and
drop the procedures "make-compound-condition" and "extract-condition", flatten
the fields eliminating repeats and list all the implemented interfaces
(= condition types) as part of the object. A condition object can then be
(make-condition list-of-types field-name obj ...)
(make-condition '(&message &who) ; implements two interfaces
'condition-message "phone me"
which can be represented internally as a list of types (interfaces)
and a flat alist of fields. The syntactic API for the
compound example in the document could be the more concise
(define v3 (condition (&c1 &c2) ; implements two interfaces
If downcasting to a particular interface is really required
(the analogue of the current "extract-condition") it can also
be easily implemented in this representation.
The suggested representation
- is simpler, since compound conditions can be dropped
- is more concise
- better expresses the "object implements interfaces/mixins" idea.
- gets rid of the current complicated semantics of repeated fields
- reproduces the practically and theoretically well-understood
"object implementing interfaces" idea in languages like Java.
The current wording does seem to convey an intent of trying
to approximate the "object implementing interfaces" idea. 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."
But this expresses the "object implementing interfaces" idea very
awkwardly in imperfectly. The above suggested encoding does it
better in my opinion and is easier to understand, especially
for people with prior exposure to object models similar to Java's.
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 descrioptions 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