In article
<wujsp0gz0y5.fsf_-_@wistaria.i-have-a-misconfigured-system-so-shoot-me> Peter
Ludemann <ludemann@inxight.com> writes:
> ark@research.att.com (Andrew Koenig) writes:
> > Here is a somewhat simplistic example. The following ML code defines a
> > binary-tree data structure where each node contains a value and is
> > either a leaf or has two subtrees:
> >
> > datatype 'a Tree = LEAF of 'a | TREE of 'a Tree * 'a Tree
> > But now suppose we want to be able to identify a specific subtree of a tree.
> > If I had gone to the trouble of creating a tree abstraction in C++, I could
> > identify a particular subtree by the address of its root. But there's no
> > corresponding facility in ML. Trees are values, and although one can
> > compare
> > them for equality, there is no notion of object identity.
> Absolutely correct and correctly so.
> If two things LOOK the same, then they ARE the same. It's called
> "referential transparency" and it's a Good Thing, as opposed to
> "pointers" which are a Bad Thing. Why confuse your life with "object
> identity"?
I think this paragraph, which argues against my local point, nicely proves
my global point, which I will admit is a little more subtle.
My original posting was a response to someone who said something to the
effect that languages without closures, lambda expressions, etc. were
inferior. So I gave an example of a problem I would like to be able to
solve that at least one such langauge does not make easy to solve.
The reply to that is ``You shouldn't be wanting to solve that problem;
not being able to do so is a Good Thing.''
And all I can say to that is ``Some people consider it a Good Thing,
and others do not.'' Which is exactly my global point.
> And why do you want to use the memory address for object identity to
> identify it --- an address can change during garbage collection. Why
> not use a time stamp of object creation? Oh, it's for efficiency
> reasons, you say ... ah-ha!
No, I did not say that. One reason, though, might be that the typical
textbook in classical data structures assumes object identity, so
that expressing such structures without it may require a substantial
translation.
And, although I did not say it before, efficiency sometimes does matter.
> But let's suppose that you really really really do need to identify a
> particular subtree. In other words, you want to NAME it. No problem:
> just create a dictionary (hash table) that maps names to subtrees.
> That'll let you have two differently named entries which might happen
> to have the same values. And it won't expose pointers. And it'll be
> efficient.
Yes and no. In a language that is completely referentially transparent,
generating the names can be a problem, because there is no way to define
a piece of code that represents the abstraction `Each time I build one of
these nodes, I want it to have a globally unique label.' The language
wouldn't be referentially transparent if I could write such a program.
So the knowledge of the labels now has to pervade the entire system.
I imagine that next you're going to say `But you can use monads to solve
that problem.' And indeed I can. Which only proves my point even more.
> Repeat after me: "if two things look the same and act the same, then
> they are the same". Don't depend on some hidden property (pointer) to
> differentiate them. If there are important differences, then don't be
> shy: bring them out in the open and NAME them.
Repeat after me: "Different programming cultures solve problems differently."
Don't assume that the whole world thinks the same way you do. If there
are important differences between how you think and how other people think,
don't be shy: bring them out in the open and NAME them.
But please do not assume that there is only one right way of thinking.
--
--Andrew Koenig
ark@research.att.com
http://www.research.att.com/info/ark
|