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

Re: opaque record types

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