Re: leakproof - Mailing list pgsql-hackers

From Don Baccus
Subject Re: leakproof
Date
Msg-id CCB9FE29-BB81-4181-A883-EBD0C0E9FCAE@pacifier.com
Whole thread Raw
In response to Re: leakproof  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: leakproof  (Greg Stark <stark@mit.edu>)
Re: leakproof  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: leakproof  (Merlin Moncure <mmoncure@gmail.com>)
Re: leakproof  (Jeff Janes <jeff.janes@gmail.com>)
List pgsql-hackers
On Feb 19, 2012, at 5:42 PM, Tom Lane wrote:

> Robert Haas <robertmhaas@gmail.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
functionalprogramming. 

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'tread the earlier posts.  I assumed it meant "doesn't leak memory", which seems admirable and typical and not
needfulof 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








pgsql-hackers by date:

Previous
From: Stephen Frost
Date:
Subject: Re: Future of our regular expression code
Next
From: Greg Stark
Date:
Subject: Re: leakproof