AndrevanTonder <andre_at_het.brown.edu> writes:
> 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.
Yes and yes. The documentation for `condition-ref' explicitly
mentions the compound-condition case. The documentation for the
accessors defined by `define-condition-type' says nothing to restict
them to simple conditions. I'll try to make it clearer for the next draft.
> 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.
Maybe, but would actually give away the advantages of using records,
as you always have to look for the named field. An association list
would be more appropriate in that case.
> 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))
Given that the fields are accessible by name, I prefer that
construction also uses the names.
> which is concise enough. CONDITION-REF could have one of the the APIs
>
> (condition-ref &syntax &syntax-subform), or
> (condition-ref syntax? &syntax-subform)
This I don't understand. Could you elaborate a bit?
>> There's also some other natural specialization, such as the fact that
>> fields are always immutable,
>
> This is not obvious to me.
You see anything to mutate them :-)
> 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 only speak for myself, where I'm pretty sure.
> I can think of various useful examples among the listed points.
Go ahead then :-)
--
Cheers =8-} Mike
Friede, V?lkerverst?ndigung und ?berhaupt blabla
Received on Thu Mar 15 2007 - 09:15:36 UTC