[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Why would anyone want opacity?
| Date: Thu, 09 May 1996 17:18:40 -0400
| From: Matthias Blume <blume@CS.Princeton.EDU>
| Most garbage collected languages, including Scheme, enforce a policy,
| where pointers are opaque, i.e., we can't get at the actual bits of a
| pointer. This is a restriction, the purpose of which is to free us
| from the burden of having to deal with certain aspects of memory
| management explicitly, thereby freeing brain capacity and making it
| available for use by more interesting activities.
What is a pointer? Scheme has no such beast. Scheme has objects.
Implementations may represent objects as pointers, but that is
architecture-dependent, and pre-supposes an implementation, so it does
not apply to blackboard/pen-and-paper discussions.
As an aside, several _implementations_ allow poking at the bits of the
pointers that represent objects. It is extremely useful when building
hash tables and other system-level stuff.
| However, it *is* a restriction, an abstraction, an intellectual
| crutch. And so are: virtual memory, file handles, processes, you name
| it... Do you reject all those as well, because you don't like them to
| be ``imposed'' on you?
These are facilities that I may or may not use. Enforced static type
checking, by its definition is not optional. Neither Gerry nor I will
object to new facilities that provide abilities not previously
present, at most we will ignore them. We will reject facilities that
Gerry is not arguing against abstraction. He is arguing against
building spelling checkers into languages. They are useful, but as
For example, Scheme has this nice property that a LET is just
syntactic sugar for a combination with a LAMBDA expression as the
This is not true of ML because of typing. There are transformations
that I can make to Scheme programs that are illegal in the analogous
ML programs, only because of the static type checking.
Thus adding an ML-style type discipline would remove an ability that I
now have. In particular, I wold have a heck of a time writing some
macros because I would have to take into account whether the checker
would find them legal one way but not another. You call this freeing
me of something?
| Now, you might argue that types do not give you similar benefits, and
| therefore you don't like them. For me, and I suppose for many of the
| other folks who came to like them, types are a restriction, the
| purpose of which is to free us from certain aspects of managing
| semantic correctness. This also frees brain capacity, thereby helping
| us focus on the more important aspects of program design.
Static types do not add any new functionality. They remove the
ability to express programs that make perfect sense at the dynamic
semantics level, just because they do not make sens at the static
semantics level when you've imposed a particular type discipline.
If you find them useful for your thinking, you can use them, and you
are welcome to do so. I may even do so on occasion. However, they do
not add new concepts/ability in the dynamic semantics.
| I know, you think that types are actually hindering you in your design
| efforts. Apparently, different people think differently, because I
| found that often there is a remarkable coincidence between ``getting
| the design right'' and ``getting the types right''.
That must mean that you are only dealing with statically decidable
properties in your programs. How boring. :-)
| Nobody claims that type systems *guarantee* semantic correctness --
| just like GC cannot guarantee the absence of memory leaks. But both
| of them help, both of them are intellectual crutches. You just reject
| one kind of crutch -- why not go all the way then?
GC does not exist in pen-and-paper scheme. It exists in
Your argument is like saying the following:
Using a car imposes an abstraction on you. You are being inconsistent
by accepting this imposition while you do not accept restrictions to
freedom of speech.