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