OK, please excuse me while I rant all over this post. See >>47 and >>49.
Independently of the validation required and now included in bbs.scm:posts-range, there is something I don't get. The only consumer of posts-range is filter-func in view-thread, and the only consumer of filter-func is templates.scm:format-thread with:
(filter-map (lambda (p) (and (filter-func p) (format-post board thread p))) posts)Therefore, filter-func's false return is acted upon while its non-false return is discarded by the 'and'. It might as well return false/true for selecting posts. The question then becomes, how on Earth was the current design of filter-func/posts-range chosen, with delete-duplicates, sort and member? Since *max-posts* is a small positive integer, the design that naturally offers itself is a vector of booleans of length (+ *max-posts* 1) initialized to all false. To compute posts-range once in the let* of view-thread, simply fold your flattened iotas, or your sequence of iota-producing lazy lambdas, with a pointwise vector true-setter. This completely eliminates the delete-duplicates+sort part which was quadratic, since duplicate elimination is now implicit in the construction. Filter-func comes down from linear via member to constant, since it simplifies to a vector-ref of a car. There must be some other piece I'm missing, because without it the current design of filter-func/posts-range seems very inefficient.