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

Re: why generative?

This page is part of the web mail archives of SRFI 99 from before July 7th, 2015. The new archives for SRFI 99 contain all messages, not just those from before July 7th, 2015.



I wrote:

> There are two layers in the discussion.
> 
> (1) How to eliminate requiring separate global namespace.
> 
> (2) How to achieve programmer's convenience of making sure
>     (a) no extra construction of type descriptor occurs at
>     runtime, and (b) creating distinct types.

I've been proposing default-nongenerative behavior
because of two reasons - eliminating separate global
namespace(1) _and_ making it easier to use locally-scoped
nongenerative record types(2a).

Through the discussion, I realized (2a) is mainly a matter
of style and can be addressed by syntactic layer.  If there's
a way to eliminate separate namespace, I don't really advocate
to default-nongenerative behavior.  (I also feel "functional"
semantics of rtd cleaner, but that's just a hunch and I don't
have any concrete argument to back it up.)

In fact, srfi-99 per se doesn't require the separate namespace.
It is only required if one wish to implement r6rs compatible
layer.

So, if the way is shown to use nongenerative record types
without requiring a separate namespace in the current form
of srfi-99, I have no objection.

Here's one idea:

An implementation may extend make-rtd so that it can take
a symbol 'nongenerative and another symbol (name) in the
optional argument list.   Then make-rtd returns an RTD
that is semantically equivalent to another RTD with the
same field specs, parent rtd, opaqueness, sealedness,
and the name.  How to realize this equivalence is up
to the implementation; it can calculate a unique signature
and use it to distinguish rtds, it can memoize make-rtd
arguments, or it can use element-wise comparison.

Whether this option is described in the srfi document or not
is up to the srfi authors.  It may be possible to submit
another srfi that rides on srfi-99 and describe this
semantics.  What I'd like to suggest is to leave a room
explicitly to avoid separate namespace issue.

--shiro