[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.

   Date: Mon, 12 Jul 1999 13:01:14 -0500 (CDT)
   From: Matthias Felleisen <matthias@xxxxxxxxxxx>

   I would like to raise one question: 

     Why isn't define-record-type generative? 

It was intended to be.  The implementation is.  The third sentence
in the abstract

  Each new record type is distinct from all existing types, including
  other record types and Scheme's predefined types. 

was meant to indicate that DEFINE-RECORD-TYPE was generative.

   Unless I am overlooing something, a simple change in the implementation of

     (gensym 'type) 

   in place of 


   should give us the natural degree of genericity. It should also allows us
   to write DEFINE-RECORD-TYPE wherever we write DEFINE.

This won't make a difference.  The 'type argument is
saved in record types for the purposes of printing and/or
debugging.  The implementation itself makes no use of it.

Each use of DEFINE-RECORD-TYPE expands into a call to
MAKE-RECORD-TYPE which returns a newly consed type.  The
predicate for that type uses EQ? to compare a record's type
with the newly created type, which gives us genericity.

   (define-record-type :pare (kons x y) pare? (x kar) (y kdr))
   (define zzz (kons 1 2))
   (define-record-type :pare (kons x y) pare? (x kar) (y kdr))
   (pare? zzz))

  ---> #f

By `wherever we write DEFINE' I take it that you mean that
DEFINE-RECORD-TYPE should work as an internal DEFINE.  This
requires more than genericity.  The code produced by the
DEFINE-RECORD-SYNTAX macro violates the internal-DEFINE
requirement that evaluating the right-hand sides make no use
of the variables being defined.  It could be made to work,
but I don't think it is worth the extra complexity.

                                   -Richard Kelsey