On Thu, 2009-09-03 at 10:39 -1000, Shiro Kawai wrote:
> From: Thomas Bushnell BSG <xxxxxx@becket.net>
> Subject: Re: why generative?
> Date: Thu, 03 Sep 2009 12:28:08 -0700
>
> > On Thu, 2009-09-03 at 09:19 -1000, Shiro Kawai wrote:
> > > In most programming languages programmers do give unique names
> > > to the different record types with same field specs.  I assume
> > > we can ask that much of work to the programmer's side if she
> > > wishes to have distinct types.
> >
> > In most programming languages programmers also give unique names to
> > different procedures.  Scheme is not like that, thank the stars.
> >
> > You are assuming that the only value of records is to be like C structs.
> > Feh!
>
> That's a misunderstanding.  I meant programmers *could* give
> distinct names to the types, especially globally defined ones,
> even if they could have anonymous types.   I believe Scheme
> programmers usually use globally defined procedures with
> distinct names even if they can have anonymous functions.

Excellent example.

I have no objection to allowing programmers to name their record types.

I think they should name them with define, in the same namespace as
everything else.

> The procedural layer gives you anonymous types.  Syntactic layers,
> both srfi-99 and r6rs, do ask you to name the record type.
>
> The default-generative make-rtd with opt-in nongenerative type
> with uid, as defined in R6RS, mandates you to *name* the type
> if you simply want to use locally-defined record types to group
> values; failing to do so tax you allocation of fresh type
> descriptors every time make-rtd is invoked.  Compare it with
> anonymous procedures without closing local variables; you can
> assume a decent implementation will lift the lambda and avoid
> allocating fresh procedures every time.

I'm not suggesting I like the r6rs records.  I think they're awful.  So
don't worry on that score. :)

Notice that lifting is explicitly allowed by r5rs by the thing which
says that the system can have two "different" procedures be eq? if it
can prove that they behave identically.  I think this might be the best
approach here too.

> But that problem is a kind of trade-off, as Will and I discussed.
>
> I see the separate namespace more serious problem.

Agreed!

Thomas