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

Re: Why would anyone want opacity?

In-Reply-To: Mitchell Wand's message of Wed, 8 May 1996 13:55:45 -0400

> Their code stops working.  Not only does their code stop working, it stops
> working in strange and unpredictable ways.  They are unhappy.

Sure, but your example used lists as the implementation.  Everyone
agrees that causes too much trouble, so far as I can tell.  What you
need is an example that shows why records that that have their own
types are not good enough unless they're also opaque.

Of course, such records are not a perfect solution.  Opaque records
are better, in some ways.  But opacity also has a cost -- or at least
some people seem to think so.  Isn't that why we've had so much
trouble agreeing on a record proposal?

There's a great deal of agreement on these issues.  I think
everyone realizes that abstraction is valuable and something
the language should support.  But there comes a point where
views diverge.  For example, Common Lisp has a "::" notation
for symbols that allows reference to the internal symbols of
a package.  Some people think that is absolutely unacceptable,
some think "::" makes it too easy, some that it's at most a
minor problem, and so on.

The fundamental divergence of views seems to be between those
who think abstraction should be _impossible_ to break (within
the language) and those who think the cost of making it 
impossible is greater than the benefits, given that much of
the same benefit can be obtained with something less extreme.
Some freedom, but not total freedom -- is that really so bad?

> The solution that was arrived at in the 70's was the concept of
> information hiding and abstract data types.  The point of this was 
> that it is insufficient to merely decree, as Jeff suggests that
> > students and other inexperienced programmers can stay out of trouble
> > just by not using record-{length,ref,set!}.
> Among other things, the student programmers (the clients of the ADT)
> probably need these operations for their own uses, 

Why?  After all, with opaque records, the students wouldn't _have_
these operations.  So clearly there's a huge range of cases where
students do _not_ need them.

> so they can't 
> simply be made illegal-- in our case, we probably don't want to make
> CAR illegal in student code. 

I think the case is rather different for CAR than it is for
RECORD-REF, as I tried to indicate in my earlier message.
For instance, a coding standard that rules out RECORD-REF
looks a lot more desirable than one that rules out CAR.

In any case, I didn't suggest making record-{length,ref,set!} 
illegal.  I just pointed out that programmers could stay out
of trouble by not using them.

> The arguments in favor of strong abstraction resemble in many ways the
> arguments in favor of strong static typing, and the objections to strong
> abstraction resemble those against static typic.

Which also suggests that further discussion will not make much

My own view of this is that there can be more than one kind of good
language.  There are some good languages that have strong static
typing, or strong abstraction, but there can also be good languages
that don't.

-- jeff