This page is part of the web mail archives of SRFI 9 from before July 7th, 2015. The new archives for SRFI 9 contain all messages, not just those from before July 7th, 2015.
esl> I don't think the problem with internal record definitions is in esl> implementation complexity - it's in generativity. If you define esl> a new record type inside a procedure, it is natural to expect esl> the same record type each time you enter the procedure; otherwise esl> the objects you created before won't be recognized by record esl> type predicate: esl> ;; sample enumeration protocol for nonempty sequences: esl> (define (enumerate-stuff state) ;=> obj, {next-state or #f} esl> (define-record-type my-enum-state ...) esl> (if (eq? state #f) esl> ;; start enumeration esl> (values obj1 (make-my-enum-state ...)) esl> ;; continue enumeration esl> (let ((next-state (if (has-next? state) esl> (next-state state) esl> #f))) esl> (values (state-obj state) next-state)))) Actually, I hesitated to make the comment about internal defines until I realzed that the datatypes were already generative. I think generativity is one of those things well-meaining people simply disagree on. For me, I _want_ datatypes internal to procedures to be generative on procedure application. It just seems natural. If you rewrite enumerate-stuff without the MIT-define, it seems clear to me that the define-record-type belongs outside of the lambda and inside of the define: ;; sample enumeration protocol for nonempty sequences: (define enumerate-stuff (let () (define-record-type my-enum-state ...) (lambda (state) ;=> obj, {next-state or #f} (if (eq? state #f) ;; start enumeration (values obj1 (make-my-enum-state ...)) ;; continue enumeration (let ((next-state (if (has-next? state) (next-state state) #f))) (values (state-obj state) next-state)))))) -erik