Re: OO versus RDB

Marshall wrote:

> Oh, certainly. The interesting question in my mind is how does
> one distinguish observable effects that matter from those
> that don't matter?

If you're in a language which deals in abstractions of state changes (ie. an imperative language, or a non-pure functional language) especially, all the observable effects matter. The uncertainty principle applies in spades. And I would pause to enquire, if an observable effect doesn't matter, why is it there ?

[ snippage about, presumably, debugging activities ]

> I have not observed that the use of "referential transparency"
> and "purity" is entirely consistent. If we go by what wikipedia
> says at the time of this writing, referential transparency means
> side-effect-free and pure, side-effect-free means no outputs
> other than return values, pure means return values depend
> solely on parameters.
>

Given that the Wikipedia entry for referential transparency is currently under dispute, I would tread carefully there (I can approve of the opening gambit - that an expression is referentially transparent if the body of the function can be replaced in line with no change to meaning - but it's not comprehensive enough for some, it seems).

> I also find it funny that *all* outputs are called "side-effects"
> regardless of whether they are of primary concern or not:
> it seems disingenuous to me to call the fact that
> "printf("hello, world\n");" writes to standard out
> a *side* effect. I mean, what is it to the side *of*?
>

Aside from 'printf("hello, world\n")' being a procedure call rather than a function (that a value is left lying in a register was, at least initially, just a happy (or otherwise) accident of the way C was implemented), if we assumed that the return value of printf() was some integer, then the emergence of text on an output device would be considered a side effect of obtaining the return value.

> Yes, this gets at another point that is often glossed over:
> what is an observable effect is entirely dependent on
> context.

Hmm. Explanation ? When is the net effect of a computation observable and when not ?

> Since that's true,

I'm not taking that step with you yet ;)

> it means that if we go by the
> above definitions, then if we have a pure function,
> whether it is referentially transparent is a matter of
> context! We could for example have an entirely pure
> program that performs no output (only returning a
> value at exit) and be able to run it on a virtual machine
> that writes to a log file at every function entry point.
> Is it referentially transparent?

Yes.

> From the viewpoint of the program itself, yes; from the viewpoint of the
> entire system, no.

This is an issue of the virtual machine, not of the function itself. Therefore the function is still referentially transparent.

> However if you point out to people
> that their definition of referential transparency is
> context dependent, some of them will get very angry.
>

I don't see why they would get angry; they would point out you were wrong though, explanation of your earlier assertion regarding context sensitivity of referential transparency notwithstanding.

> The fact that raising these points gets so many people
> so riled up indicates to me that not everyone is thinking
> entirely clearly about the issues, and that indicates that
> there are opportunities to advance the state of the art.
>

Hmmm. Received on Mon Jul 10 2006 - 01:47:40 CEST