Re: leakproof

On Feb 19, 2012, at 5:42 PM, Tom Lane wrote:

> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> Having now spent far too much time in bed with that patch, I'm feeling
>> like the concept that we are really looking for there is what some
>> languages call "pure" - that is, there must be no side effects,
>> whether by throwing exceptions or otherwise.
>
> Hmm, "pure" doesn't sound bad to me. Nice and short.
>

Technically, "pure" is stronger than "has no side effects":

http://en.wikipedia.org/wiki/Pure_function

Result can't depend on state (for instance, database contents), either. This is the typical definition used in functional programming.

gcc extends this to allow use of global variables in a "pure" function (the stricter definition is met by "const" functions). PG has "immutable", so a slightly weaker "pure" probably wouldn't be terribly confusing given the gcc precedent (probably across their family of compilers).

"D" adopts the stricter definition of "pure".

So there's some confusion around the term.

But …

I picked up this thread after "leakproof" was settled on and was curious as to what "leakproof" was supposed to be as I didn't read the earlier posts. I assumed it meant "doesn't leak memory", which seems admirable and typical and not needful of an attribute on the function declaration.

"pure" is definitely less confusing IMO, if it's congruent with the weaker sense of "pure" that's found in some languages/implementations.

----
Don Baccus
http://donb.photo.net
http://birdnotes.net
http://openacs.org