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.
Richard Kelsey <kelsey@xxxxxxx> writes: > I have several of questions about the 'opaque' > option. > > - Why are its effects limited to the reflective > procedures? Where else could the effects extend? I'm think I'm probably misunderstanding you. If the effects extended, to, say RECORD-ACCESSOR, you couldn't create a record accessor at all. > Should implementation-specific debuggers be allowed to inspect > opaque records? That seems a philosophical question. I don't think there's anything in the draft that would forbid this, or that there could or should be. The opacity just extends to portable programs. > It seems very un-Scheme-like to explicitly restrict programs and > implementations in this way. A program that runs in an > implementation that implements this restriction will get the same > result in one that ignores it. I think we generally tried to come up with a compromise between the two historical positions on this issue, which are "record types must be opaque" and "record types must be transparent." I'm unclear what the Scheme-like position here is. Procedures are opaque, too, and the same people that have argued historically that record types must be transparent have argued that procedures should, too. > - If this functionality is important, shouldn't there be a general > mechanism that would apply to procedures, ports, and other data > structures as well? Possibly, but it would fall outside the scope of this SRFI, I think. I'm sure this will come up in the discussion of the greater context. > - It seems unfortunate to have to specify opacity > when a record type is created. We punted on making the opacity mechanism more elaborate because we weren't sure additional functionality would justify the complexity and expected controversy. Maybe we were wrong. Can you suggest or point to an opacity mechanism that would straightforwardly solve your example problem? > Suppose I want to use a general queue package, say, that is > implemented using non-opaque records, but I want to hide the > internals. As it is, I must create my own opaque type that wraps > the general one. Yes. But why is that so bad? You have a box made of plexiglass. You don't want people too see inside, you throw a tarp over it. -- Cheers =8-} Mike Friede, Völkerverständigung und überhaupt blabla