Andre van Tonder <andre_at_het.brown.edu> writes:
> The current model for compound conditions is unnecessarily complex. A simpler
> model is proposed.
While I tentatively agree that simplifications are possible, I don't
think they are desirable in the way you suggest.
> 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.
Unfortunately, it is not a very good match for the problems conditions
attempt to solve. Things get interesting when exceptional situations
occur that have several descriptions. These descriptions are attached
to the condition types. Conflating information across different
condition types, as you suggest, would be bad, especially as field
names are likely to be duplicate between condition types.
I have come to believe that the complicated way the `condition' syntax
deals with field names is both confusing and unnecessary. (I thought
it was a good idea at the time we designed it; I now have more
experience using the system.)
> - 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.
I think the easiest way to deal with these problems would be to (at
least implicitly) indeed distinguish "simple conditions" from
"compound conditions" and have a compound condition essentially be
represented by a list of simple conditions. In that case,
`make-compound-condition' would simply concatenate the lists, and
`condition-ref' could easily be specified unambiguously.
--
Cheers =8-} Mike
Friede, V?lkerverst?ndigung und ?berhaupt blabla
Received on Sun Nov 19 2006 - 13:46:35 UTC