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

From: AndrevanTonder <andre>
Date: Thu Mar 15 11:16:00 2007

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
Received on Thu Mar 15 2007 - 11:15:22 UTC