>From: Per Bothner <xxxxxx@bothner.com>
Subject: Re: why generative?
Date: Thu, 03 Sep 2009 12:46:37 -0700

> On 09/03/2009 02:46 AM, Shiro Kawai wrote:
> > From: xxxxxx@ccs.neu.edu
> >> For record types that are not defined at top level, it is
> >> unclear whether generative or non-generative definitions are
> >> more common.  My intuition says it's likely to depend upon
> >> individual programmers' preferred styles, so no general rule
> >> applies generally.
> >
> > Probably this point is our difference.  I often like to use
> > locally defined records to group values semantically, and
> > such record types should be non-generative to avoid overhead.
> > But that's a matter of personal preference, so I don't push
> > this use case particularly.
>
> Some implementations might want an extension to make-rtd or
> define-record-type that would allow defining methods as well
> as fields.  Or alternatively an implementation-specific
> function/syntax to do so.  (Kawa has a define-class form.)
>
> If so, then the method might refer variables in the lexical
> scope.  In which case the record-type would presumably need
> to be non-generative, since it needs to be to access the local
> closure.
>
> So for consistency I think the default should be generative.

I don't feel it inconsistent if the extended make-rtd behaves
generatively if the field specs including methods, and behaves
nongeneratively if the field specs in other cases.  It's
similar to have a local functions with and without closed variables;
I would assume decent implementations will lift local functions
without closed variables, so that new procedure instance won't
be created every time lambda form is executed.

By the way, what will happen if your extended make-rtd takes
methods *and* uid simulnateously?

--shiro