On Mon, 12 Mar 2007, Michael Sperber wrote:
> AndrevanTonder <andre_at_het.brown.edu> writes:
>
>> 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.
>
> Here's why they're different: Because of compound conditions, the
> record accessors won't be the condition accessors.
Do they need to be? Actually, are they? In other words, does the <accessor>
in define-condition-type work also on a compound conditions containing a
condition of the type being defined? The document does not say either way, and
I had assumed they didn't.
> (Similarly for the
> predicates, and possibly for the constructors.) This is why a little
> bit of scaffolding is needed.
Would conditions be so much more difficult to use without this scaffolding?
CONDITION-HAS-TYPE and CONDITION-REF could still have as concise an API as
they do currently, even if conditions are just records. The CONDITION
constructor syntax can also be implemented with the current API if simple
conditions are non-opaque records. But in that case I wouldn't even bother
with the CONDITION constructor syntax, since I could just say
(make-compound-condition (make-&message "displaced identifier")
(make-&syntax some-form some-subform))
which is concise enough. CONDITION-REF could have one of the the APIs
(condition-ref &syntax &syntax-subform), or
(condition-ref syntax? &syntax-subform)
in which case conditions can perfectly well even be opaque records.
With this, one could drop
make-condition-type
make-condition
define-condition-type
condition (syntax)
which would be a significant simplification.
> Also, in my experience, introspection
> is more common for conditions than for garden-variety records.
But currently condition types do not support the amount of introspection that
records do.
> There's also some other natural specialization, such as the fact that
> fields are always immutable,
This is not obvious to me.
> and that accessor names often don't
> derive straightforwardly from the type names.
...which is what (r6rs records explicit) is for, isn't it?
Are you sure that no-one will ever need
- condition types with custom constructor protocols
due to computed fields
- condition types with fields hidden by the library system
- opaque condition types
- sealed condition types
- nongenerative condition types
- mutable fields, for example to update a condition with new
information before rethrowing it
- the ability to apply a record pattern matching
facility to simple conditions
- the ability to use future extensions, tools, srfis, of
whatever nature that may be developed for records, also
on simple condition types?
I can think of various useful examples among the listed points.
Andre
Received on Wed Mar 14 2007 - 21:27:38 UTC