+ (define (segment-more-than-time? segment)
+ (time< time (time-segment-time segment)))
+
+ ;; We could switch this out to be more mutate'y
+ ;; and avoid the O(n) of space... is that over-optimizing?
+ (match segments
+ ;; If we're at the end of the list, time to make a new
+ ;; segment...
+ ('() (cons (new-time-segment) '()))
+ ;; If the segment's time is exactly our time, good news
+ ;; everyone! Let's append our stuff to its queue
+ (((? segment-equals-time? first) rest ...)
+ (enq! (time-segment-queue first) proc)
+ segments)
+ ;; If the first segment is more than our time,
+ ;; ours belongs before this one, so add it and
+ ;; start consing our way back
+ (((? segment-more-than-time? first) rest ...)
+ (cons (new-time-segment) segments))
+ ;; Otherwise, build up recursive result
+ ((first rest ... )
+ (cons first (loop rest)))))
+ (set-schedule-segments!
+ schedule
+ (loop (schedule-segments schedule)))))
+
+(define (schedule-empty? schedule)
+ "Check if the SCHEDULE is currently empty"
+ (eq? (schedule-segments schedule) '()))
+
+(define (schedule-segments-split schedule time)
+ "Does a multiple value return of time segments before/at and after TIME"
+ (let ((time (time-segment-right-format time)))
+ (define (segment-is-now? segment)
+ (time= (time-segment-time segment) time))
+ (define (segment-is-before-now? segment)
+ (time< (time-segment-time segment) time))
+
+ (let loop ((segments-before '())
+ (segments-left (schedule-segments schedule)))
+ (match segments-left
+ ;; end of the line, return
+ ('()
+ (values (reverse segments-before) '()))
+
+ ;; It's right now, so time to stop, but include this one in before
+ ;; but otherwise return
+ (((? segment-is-now? first) rest ...)
+ (values (reverse (cons first segments-before)) rest))
+
+ ;; This is prior or at now, so add it and keep going
+ (((? segment-is-before-now? first) rest ...)
+ (loop (cons first segments-before) rest))
+
+ ;; Otherwise it's past now, just return what we have
+ (segments-after
+ (values segments-before segments-after))))))
+
+(define (schedule-extract-until! schedule time)
+ "Extract all segments until TIME from SCHEDULE, and pop old segments off"
+ (receive (segments-before segments-after)
+ (schedule-segments-split schedule time)
+ (set-schedule-segments! schedule segments-after)
+ segments-before))
+
+(define (add-segments-contents-to-queue! segments queue)
+ (for-each
+ (lambda (segment)
+ (let ((seg-queue (time-segment-queue segment)))
+ (while (not (q-empty? seg-queue))
+ (enq! queue (deq! seg-queue)))))
+ segments))
+
+
+\f
+;;; Request to run stuff
+;;; ====================
+
+(define-record-type <run-request>
+ (make-run-request proc when)
+ run-request?
+ (proc run-request-proc)
+ (when run-request-when))
+
+(define* (run-it proc #:optional when)
+ "Make a request to run PROC (possibly at WHEN)"
+ (make-run-request proc when))
+
+(define-syntax-rule (wrap body ...)
+ "Wrap contents in a procedure"
+ (lambda ()
+ body ...))
+
+;; @@: Do we really want `body ...' here?
+;; what about just `body'?
+(define-syntax-rule (run body ...)
+ "Run everything in BODY but wrap in a convenient procedure"
+ (make-run-request (wrap body ...) #f))
+
+(define-syntax-rule (run-at body ... when)
+ "Run BODY at WHEN"
+ (make-run-request (wrap body ...) when))
+
+;; @@: Is it okay to overload the term "delay" like this?
+;; Would `run-in' be better?
+(define-syntax-rule (run-delay body ... delay-time)
+ "Run BODY at DELAY-TIME time from now"
+ (make-run-request (wrap body ...) (tdelta delay-time)))
+
+
+;; A request to set up a port with at least one of read, write, except
+;; handling processes
+
+(define-record-type <port-request>
+ (make-port-request-intern port read write except)
+ port-request?
+ (port port-request-port)
+ (read port-request-read)
+ (write port-request-write)
+ (except port-request-except))
+
+(define* (make-port-request port #:key read write except)