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

Re: Revision of SRFI 76 available - questions and comments

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.

Andre van Tonder <andre@xxxxxxxxxxxxxxxxxxx> writes:

>  Some miscellaneous issues: 
>  > - I've changed the syntax of the OPAQUE and SEALED clauses to carry a
>  >   boolean operand.
>  I notice this operand is evaluated at runtime.  I am not too familiar 
>  with the issues involved, but I suspect these attributes may 
>  be useful for compile-time analysis of allocation and optimization
>  strategies, which may become more difficult with this choice. 

Yes; I'll restrict the operands to #t and #f literally.

>  > - I've changed the semantics of field-id to always be local to the
>  >   specified rtd, rather than global.  This makes it easier to later
>  >   extend the abstractions to multiple inheritance, should anyone ever
>  >   want to do so, and leaves less room for ambiguity.
>  I cannot find where this explained in the document.

It's in the specification of RECORD-ACCESSOR, specifically the

>> Note that it is an error even if the procedure's argument is of a
>> parent type from which the selected field was inherited.

>> [...]

>> If it is a symbol s, the field named s from the fields argument to
>> make-record-type-descriptor is selected.

If you have suggestions on making it clearer, I'd be more than happy
to incorporate them.

>  > 
>  > - The field names passed to MAKE-RECORD-TYPE-DESCRIPTOR are now
>  >   required to be distinct.
>  I think the sentence beginning with "If more than one field has the given name"
>  in the document is in conflict with this statement.

Well, not in conflict, but certainly nonsensical and confusing.  I'll
remove the sentence.
>  Also, I cannot figure out from the document if parent fields may be 
>  repeated in a child.

They may be.  I'll clarify.

>  Finally, I think an specification is still missing for the visibility 
>  of the various defined bindings in the various 'expression's 
>  occurring in the syntactic layer.  

Yes.  More thinking needs to be done here, but I'm glad we both seem
to agree there's been progress.

Cheers =8-} Mike
Friede, Völkerverständigung und überhaupt blabla