Re: leakproof

Поиск
Список
Период
Сортировка
От Don Baccus
Тема Re: leakproof
Дата
Msg-id CCB9FE29-BB81-4181-A883-EBD0C0E9FCAE@pacifier.com
обсуждение исходный текст
Ответ на Re: leakproof  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы 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>)
Список 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 по дате отправления:

Предыдущее
От: Stephen Frost
Дата:
Сообщение: Re: Future of our regular expression code
Следующее
От: Greg Stark
Дата:
Сообщение: Re: leakproof