Re: leakproof

On Sun, Feb 19, 2012 at 6:20 PM, Don Baccus <dhogaza(at)pacifier(dot)com> wrote:
>
> 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.

I don't think that "pure" is sufficient to be leakproof. For example,
if I have a function which is pure but which takes an unusually long
time to evaluate for some unique pathological combination of
arguments, I don't think that it would be considered leakproof.

Cheers,

Jeff