> (make-engine open close in-transaction ref set delete range-remove range
> prefix-range hook-on-transaction-begin hook-on-transaction-commit pack
> unpack)
This is a write-once use-many expression, so it is not a good
candidate for keywords.
Per contra, I think it is an *excellent* candidate. The arguments are all procedures with no hope of distinguishing them at run time. If the programmer gets the order of the two hooks wrong, only testing against an actual database (hopefully not one with live data) will expose the error. With keywords (or one of their alternatives), the programmer is forced to state their intentions explicitly.
> (engine-in-transaction engine okvs proc [failure [success [make-state
> [config]]]])
This is another good candidate for keywords, although not as strong. Here if you want to specify success handling, you must specify failure handling even if you don't care. We simply guess in such APIs that special handling on failure is more probable than special handling on success, but what if we are wrong? An unadorned "raise" may not in a given framework be the right thing. I'm not carping about this because we have so many SRFIs that use this design, but it is suboptimal.
John Cowan
http://vrici.lojban.org/~cowan xxxxxx@ccil.orgStatistics don't help a great deal in making important decisions.
Most people have more than the average number of feet, but I'm not about
to start a company selling shoes in threes. --Ross Gardler