[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Chicken-users] SRFI-9 vs. define-record vs. (copy)
From: |
felix |
Subject: |
Re: [Chicken-users] SRFI-9 vs. define-record vs. (copy) |
Date: |
Tue, 12 Nov 2002 21:42:10 +0100 |
User-agent: |
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020529 |
address@hidden wrote:
Currently SRFI-9 records and (define-record) records are
disjoint. Could they be made the same? I'd really love to have
(define-record-printer) for SRFI-9 records :-)
The code generated by `define-record' is more efficient than
the SRFI-9 stuff. I have to take a deeper look, but I'm not
sure wether it is possible to make the underlying machinery
the same without a) making Chicken's records slower, and
b) violating SRFI-9.
On the topic of records, the (copy) function is *too* deep - it copies
the record type as well as the record value!
(define-record x y)
(define a (make-x 1))
(define b (copy a))
a ==> #<x>
b ==> #<x> ;; but it's a *different* x
(x-y a) ==> 1
(x-y b) ==> error
(x? a) ==> #t
(x? b) ==> #f
Any suggestions on how this might be avoided?
The `copy' procedure (as much of the stuff in the `lolevel'
unit) should be taken with a grain of salt: it's more intended
for low-level hacks (like copying data from non-GC'd memory
back into the heap). I really should have taken a less generic
name. The problem here is that the symbol is copied too and
so doesn't keep it's uniqueness (I think there is something
in the manual about this). I will rename `copy' and introduce
a decent generic copying routine.
cheers,
felix