[gambit-list] Error and value handling style question (long)

Christian christian at pflanze.mine.nu
Wed Jan 18 08:47:00 EST 2006


I've got a general Scheme programming style question. Since there may
be different preferences around a particular Scheme implementation,
I'm asking here. Actually, depending on the decision on which style to
choose, I would vote for an efficiency improvement in gambit (see more
below on keyword arguments).

Especially since scheme is using runtime type checking, there are
frequently "error cases" when accessing data structures, i.e. the data
to be read is not available or has the wrong type. There are multiple
approaches to handle this:

a) call the current error handler, which usually transfers control to
   a captured continuation.

b) (optionally) call a user-provided function instead, which may do
   the same. (i.e. the error function is lexically provided instead of

c) return a special value (optionally user-provided), which the caller
   has to check for.

With solution a, the user has to install a new error handler if he
wants to catch this, which is both tedious and relatively expensive.

Solution b improves upon this by using the more efficient (and
slightly less inconvenient) approach of providing the error handler
through a lexical parameter instead of a dynamic parameter. But,
unless also a success handler can be given, the user still has to use
call/cc to differentiate between success and failure.

Solution c may be the one looking as the most efficient, and most
simple from the perspective of the writer of the library. But the
library user then always needs to check the error values, it's a
duplication of branches (first, there are branches in the library code
to decide upon the value to be returned, then there have to be
branches to dispatch upon them). Maybe with a nice pattern matching
language, that issue at least doesn't appear to be a problem on the
surface anymore? (But there may also be cases where multiple kinds of
errors can happen--how to solve this, provide multiple special values
as arguments? Or, introduce an error object hierarchy instead, where
the caller can ask (exception? value) and handle depending on the
result (errors as first-class values). Of course returning errors or
other items meant to make the caller dispatch on them, might interfere
with storing those objects validly into the data structure (example:
hash tables). (How do other languages (Haskell?) solve this?))

There is also the case, where the library wants to return multiple
values. The implementation of R5RS values/call-with-values in Gambit
is basically a tuples approach (afaik the same approach as taken by ML
and Haskell). This makes it more elegant (in my opinion) than Schemes
which require continuations to expect exactly the number of values
being returned to them, since it's more flexible ("normal" generic
one-value handling Scheme code can handle them). But since they
allocate memory (I think ML can optimize that away partially), this is
not very efficient. And, this is intertwined with the above question
of how to dispatch on data errors: a function should have a way to
return to different places, some of them taking multiple values, some
of them one, some of them none ("manual CPS style").

For these reasons, I think I would happily dispense with
multi-value-bind (expect for compatibility reasons) and provide the
continuations manually. My only issues with this are:

- I want that to be as "standard" as possible (syntax-wise), over all
  of my code and as much as possible other people's code.  This means,
  using the same function naming conventions and the same ordering of

- Using keyword arguments may make it easier to achieve that goal:
  something like:
  (foo-bar/baz value
           on-success: (lambda (bar baz)
                         ... )
           on-error: (lambda (error-object)
  could be used as a standard approach.
  But this is (currently) not very efficient in Gambit: for one, the
  keyword parsing code doesn't seem to be very fast, and worse, it
  prevents the compiler from doing inlining (and maybe other
  optimizations?) in block-compilation mode.

- Does specifying two (or maybe more) such continuations necessarily
  require multiple closure allocations (unless optimized away in
  block-compilation mode)? That would make it possibly slower than the
  allocate-a-values-tuple approach in some cases.

- Instead of using keyword arguments, settle on a function naming approach:

  Using the with- naming as hint that this function will take a
  success continuation as it's second argument, and optionally an
  error continuatoin as third:
    (with-foo-bar a-foo
	(lambda (bar) ...)
	(lambda (error-object) ..))

  Without the with-, expect it to take an optional error continuation
  as the second argument, and optionally a success continuation as
    (let ((bar (foo-bar a-foo
                        (lambda (error-object) ...)))) ..)
    (foo-bar a-foo
             (lambda (error-object) ...)
             (lambda (bar) ....))
  as the user desires.

Below, I've pasted an excerpt of a library I'm working on for handling
Gambit syntax objects, which finally gave me the motivation to ask
about this style question here.

(Maybe writing such libs could be made easier with the help of some
macros, once a 'standard' is decided.)

Thanks for your suggestions

(define (syntax-pos syn) ;; combined line/col
  (vector-ref syn 3))

(define (make-syntax-error message)
  (lambda (erroneous-object)
    (error message erroneous-object)))

(define identity (lambda (v)

(define (syntax-line syn
		     (error (make-syntax-error "syntax-line: no position info:"))
		     (success identity))
  (cond ((syntax-pos syn)
	 => (lambda (pos)
	      (success (+ 1 (bitwise-and pos 65535)))))
	 (error syn))))

(define (syntax-col syn
		    (error (make-syntax-error "syntax-col: no position info:"))
		    (success identity))
  (cond ((syntax-pos syn)
	 => (lambda (pos)
	      (success (+ 1 (quotient pos 65536)))))
	 (error syn))))

(define (with-syntax-line/col syn
			      (error (make-syntax-error "with-syntax-line/col: no position info:")))
  (cond ((syntax-pos syn)
	 => (lambda (pos)
	      (success (+ 1 (bitwise-and pos 65535))
		       (+ 1 (quotient pos 65536)))))
	 (error syn))))

More information about the Gambit-list mailing list