[r6rs-discuss] [Formal] Why are simple conditions so different from records

[AndrevanTonder]

On Thu, 15 Mar 2007, Michael Sperber wrote:

> Andre wrote:

>> 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.

I would not look for named fields.  Instead, the API could be as in

    (condition-ref x syntax-violation? syntax-violation-subform)

where syntax-violation? is the predicate and syntax-violation-subform is the 
accessor  procedure of the desired subcondition.  This would work also for 
opaque record types.

>> 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.

I would not have them accessible by name.  In particular, I do not see a good 
reason for having condition constructors by field names and not record 
constructors.  If someone writes a SRFI in future to make records constructible 
by field names, that can be used, with the advantage of uniformity, if 
conditions are record types, but I don't see its necessity for r6rs. 
On the other hand, if the current approach is taken where simple conditions are 
not defined as records, then such a future SRFI, and possibly others, would not 
be usable for conditions.

>> 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.
>
> Go ahead then :-)

>>   - condition types with custom constructor protocols
>>     due to computed fields

   (define-record-type &invalid-number-of-arguments-error
     (parent &condition)
     (fields message)
     (protocol
       (lambda (c)
         (lambda (correct-n incorrect-n)
           (c (string-append "You supplied "
                             (number->string incorrect-n)
                             "arguments.  Please supply "
                             (number->string correct-n)
                             " arguments.")))))))

>>   - condition types with fields hidden by the library system
>>   - opaque condition types

   (library (credit-card)
     (import -----)
     ;; accessor is not exported
     (export &invalid-credit-card? make-&invalid-credit-card last-four-digits)

     (define-record-type &invalid-credit-card
       (parent &condition)
       (opaque #t)
       (sealed #t)
       (fields credit-card-number))  ; not exported

     (define last-four-digits -----))

>>   - sealed condition types

If the above &invalid-credit-card condition were not sealed, I believe there 
would be a security gap.  By the way, I am not advocating this as a good 
approach to security, but it gets the point across.

A better approach to security might be to only store the last four digits.  In 
this case, we get another nice example of the utility of a custom constructor 
procedure.

>>   - mutable fields, for example to update a condition with new
>>     information before rethrowing it

A condition may have a "history" field, where each handler might record its 
own identification or how it handles the condition before rethrowing it.

>>   - the ability to apply a record pattern matching
>>     facility to simple conditions

Using PLT match on records:

   (match simple-condition
     (($ &message text) ------)
     (($ &warning)      ------)
     (($ serious)       ------))

>>   - the ability to use future extensions, tools, srfis, of
>>     whatever nature that may be developed for records, also
>>     on simple condition types?

For example, tools for displaying record types, implementation flags for
choosing how record types are displayed, a future SRFI for constructing records 
by field label as in

       (point (x 1) (z 3) (y 2))

and so on.

Cheers
Andre