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
_______________________________________________
r6rs-discuss mailing list
[email protected]
http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
