[r6rs-discuss] [Formal] Provide a way to define nongenerative records without specifying <uid>
On Nov 26, 2006, at 8:25 AM, Michael Sperber wrote:
>
> Abdulaziz Ghuloum <aghuloum_at_cs.indiana.edu> writes:
>
>> Provide a way of defining nongenerative records without having to
>> specify a specific <uid>. The macro expander can generate the <uid>
>> for me if I don't care about what the <uid> is. I recommend using
>> (nongenerative #t) to mean just that: a nongenerative record
>> definition. (nongenerative <uid>) still means a nongenerative
>> record with the specific <uid>.
>
> While this is intruiging, there are some questions in corner cases.
> I'm not really an expert on generativity, so please excuse me if any
> of the following are too stupid:
>
> - If macros expand into a record-type definition with (nongenerative
> #t), do I get a new record type every time? (I'm assuming yes.)
Yes. It will generate a new unique name for you instead of you having
to type it.
> - If I `eval' the same form (up to eq?) containing a record-type
> definition, do I get a new record type every time? (I'm also
> assuming yes.)
Yes.
> While the answers may seem obvious enough when thinking about the
> expansion process, they may be less obvious when actually using
> `define-record-type' casually, for example by doing simple abstraction
> using macros.
It depends I guess. In all my years of coding using Chez Scheme, I
always let the system generate the names for me. Never once did I need
to specify the uuids. That's all.
> I'm also a bit worried about the fact that, while the current
> explicit-naming layer is fully implementable using `syntax-rules',
> this addition would (I think) destroy that property. I know you don't
> care about this, but others may.
You are correct that I don't care. :-) Syntax-case is in the standard.
I mean, I can always define my own define-record macro that does exactly
what I want. I just felt that a little #t might go further than that;
and that it may be beneficial to others too.
Aziz,,,
Received on Sun Nov 26 2006 - 09:02:31 UTC
This archive was generated by hypermail 2.3.0
: Wed Oct 23 2024 - 09:15:00 UTC