This page is part of the web mail archives of SRFI 76 from before July 7th, 2015. The new archives for SRFI 76 contain all messages, not just those from before July 7th, 2015.
Many thanks for your comments!
Andre van Tonder <andre@xxxxxxxxxxxxxxxxxxx> writes:
> I list a few things that are unclear to me from the spec.
> Some may be omissions or rationale omissions, and some may be just my own
> blindness :-)
>
> - Why do the field /name/s in the procedural layer /not/ need to be
> distinct?
Because there wasn't any compelling reason to do so.
> I could see this feature causing lots of pain.
What kinda pain?
> - Are the syntactic layer <field name>s identifier literals (like ELSE)
> or implicitly quoted symbols?
Symbols. They simply become the field names when the call to the
procedural layer is made. I'll try to clarify.
> - Can <field-name> be reused for <accessor-name> or <mutator-name> as in
>
> (fields (x-coord (x-coord x-coord-set!))
>
> or, for that matter, can <field-name> be bound somewhere else in the
> program without breaking the record type?
Yes.
> - How does define-type bind <record-name> exactly? For example, in
>
> (define-type foo ....)
> (let ()
> (define-type foo ....))
>
> (type-descriptor foo)
>
> which type descriptor will be returned? For uniformity with internal
> defines, I would assume that internal define-types remain local and the
> toplevel FOO would be returned. Is this correct?
Yes.
> - Is the procedural layer type descriptor /name/ the same as the
> syntactic layer <record name>.
Yes.
> This would imply that <record name> is
> a symbol,
It's actually both---it becomes a bound name, and also, in quoted
form, becomes the name argument to the procedural layer.
> - Why do (sealed) and (opaque) have unnecessary parentheses?
For uniformity. These will probably change slightly with the next
revision.
> - Why is INIT! a binding form?
Because there were three of us in the room at the time, and two voted
for the present form, and one (moiself) voted for what you advocate.
I'll make this out as an issue.
> - In the (nongenerative <uid>) clause, why not have a <uid-expression>
> that can be evaluated.
Weeeellll ... I can dimly see all kinds of nasty uses here. I'll make
an issue out of it.
> - I do not understand the comment about the UUID namespace. The record
> type is nongenerative after all, whereas UUID is concerned with generativity
> (generating a never before seen ID).
> Specifically, what problems may I run into if I do not use a UUID, e.g.
> what is wrong with:
>
> (define-type point ...
> (nongenerative point))
Someone else might pick point, and if two occurrences you can't change
show up within the same program, you're hosed.
> - Why is generativity the default? I should think that normally, every
> time I run a program, I would like my types to be the same, especially
> if I read or write record values.
Because there's no way to make generativity *not* the default
syntactically.
> - Can I forward an unknown number of arguments to the parent?
No.
> - Will there be an external representation for records?
Probably not in this SRFI---we've got nothing planned.
--
Cheers =8-} Mike
Friede, Völkerverständigung und überhaupt blabla