[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: a clarification and/or a small modification

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.



Thanks for the clarification. I took a second look at the expansion: 

  (define-syntax define-record-type
    (syntax-rules ()
      ((define-record-type type
	 (constructor constructor-tag ...)
	 predicate
	 (field-tag accessor . more) ...)
       (begin
	 (define type
	   (make-record-type 'type '(field-tag ...)))
	 (define constructor
	   (record-constructor type '(constructor-tag ...)))
	 (define predicate
	   (record-predicate type))
;; For some reason, I had read a 'type in this line. 
;; As is, we have the equivalent of a gensym here. Thanks. 
       ...))))

  (define (record-predicate type)
    (lambda (thing)
      (and (record? thing)
	   (eq? (record-type thing)
		type))))


Okay, the problem is that an internal DEFINE expands into a LETREC, 
so the BEGIN expansion above won't work. 

[This does the question whether we want an option. I modifed Andrew Wright's
 match package so that people who loaded the file could choose whether they
 wanted datatype or type semantics. In Scheme, very little speaks for the
 latter, but in soft-typed Scheme, the latter is what we must choose as a
 first-cut approximation.]

Why don't you stipulate that SRFI-9 implementors allow DEFINE-RECORD-TYPE
wherever DEFINE is allowed, but add that implementations may raise an error
for internal DEFINE-RECORD-TYPEs (I wish they could for internal DEFINEs). 
Then you could provide a reference implementation that raises an error. 

Thanks. -- Matthias