SRFI 61: A more general COND clause

# SRFI 61: A more general `cond` clause

by Taylor Campbell

> > > This copy of the SRFI 61 specification document is distributed as part of the Racket package srfi-doc.

> > > The canonical source of this document is https://srfi.schemers.org/srfi-61/srfi-61.html.

## Status

This SRFI is currently in final status. Here is an explanation of each status that a SRFI can hold. To provide input on this SRFI, please send email to `srfi-61@nospamsrfi.schemers.org`. To subscribe to the list, follow these instructions. You can access previous messages via the mailing list archive.

- Received: 2005-01-04
- Draft: 2005-01-03--2005-03-04
- Final: 2005-07-21

## Abstract

This SRFI proposes an extension to the `cond` syntax to allow a more general clause, one that allows binding the results of tests as in the `=>` clauses and user-defined meaning of the success & failure of tests.

## Rationale

The present set of `cond` clauses is based on simple boolean testing. It is prohibitively inexpressive in that the condition part of a `cond` clause that uses `=>` may pass only a single value to the receiver, and it enforces a semantics whereby `#f` implies failure of the condition. Programmers frequently use different tokens to imply failure, such as in R5RS's I/O readers which return a distinguished 'EOF object' to denote failure, and a successful condition may produce more than one useful value. This simple extension allows any meaning of 'failure' to be assigned on a per-clause basis, and it also allows the condition to return multiple values to be passed to the receiver.

## Specification

The `<cond clause>` production in the formal syntax of Scheme as written by R5RS in section 7.1.3 is extended with a new option:

>       <cond clause> --->
>           ...
>         | (<generator> <guard> => <receiver>)

where `<generator>`, `<guard>`, & `<receiver>` are all `<expression>`s.

Clauses of this form have the following semantics: `<generator>` is evaluated. It may return arbitrarily many values. `<Guard>` is applied to an argument list containing the values in order that `<generator>` returned. If `<guard>` returns a true value for that argument list, `<receiver>` is applied with an equivalent argument list. If `<guard>` returns a false value, however, the clause is abandoned and the next one is tried.

## Examples

This `port->char-list` procedure accepts an input port and returns a list of all the characters it produces until the end.

>       (define (port->char-list port)
>         (cond ((read-char port) char?
>                => (lambda (c) (cons c (port->char-list port))))
>               (else '())))

Consider now a hypothetical `table-entry` procedure that accepts two arguments, a table (perhaps a hash table) and a key to an entry that may be in the table; it returns two values: a boolean that denotes whether or not an entry with the given key was in the table and, if it was, the value associated with the key. Also, a hypothetical `proj0` combinator (projection of argument 0) returns its 0th argument and ignores all others. One might conditionally branch to a certain body of code if the table contains the desired entry like so with the new type of `cond` clause:

>       (cond ...
>             ((table-entry <table> <key>) proj0
>              => (lambda (present? value)
>                   ...[VALUE is bound to the value of the entry]...))
>             ...)

## Implementation

The entirety of a syntax transformer for the new `cond` syntax is given here. It uses an auxiliary macro, `cond/maybe-more`, to simplify the construction of `if` expressions with or without more `cond` clauses. The code is in the public domain.

>     (define-syntax cond
>       (syntax-rules (=> ELSE)

>         ((COND (ELSE else1 else2 ...))
>          ;; The (IF #T (BEGIN ...)) wrapper ensures that there may be no
>          ;; internal definitions in the body of the clause.  R5RS mandates
>          ;; this in text (by referring to each subform of the clauses as
>          ;; <expression>) but not in its reference implementation of COND,
>          ;; which just expands to (BEGIN ...) with no (IF #T ...) wrapper.
>          (IF #T (BEGIN else1 else2 ...)))

>         ((COND (test => receiver) more-clause ...)
>          (LET ((T test))
>            (COND/MAYBE-MORE T
>                             (receiver T)
>                             more-clause ...)))

>         ((COND (generator guard => receiver) more-clause ...)
>          (CALL-WITH-VALUES (LAMBDA () generator)
>            (LAMBDA T
>              (COND/MAYBE-MORE (APPLY guard    T)
>                               (APPLY receiver T)
>                               more-clause ...))))

>         ((COND (test) more-clause ...)
>          (LET ((T test))
>            (COND/MAYBE-MORE T T more-clause ...)))

>         ((COND (test body1 body2 ...) more-clause ...)
>          (COND/MAYBE-MORE test
>                           (BEGIN body1 body2 ...)
>                           more-clause ...))))

>     (define-syntax cond/maybe-more
>       (syntax-rules ()
>         ((COND/MAYBE-MORE test consequent)
>          (IF test
>              consequent))
>         ((COND/MAYBE-MORE test consequent clause ...)
>          (IF test
>              consequent
>              (COND clause ...)))))

## Copyright

Copyright (C) 2004 Taylor Campbell. All rights reserved.

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.