Re: Functions without side-effects. Proposal
On Tue, 2 Sep 2008 13:43:20 CST, Zara <me_zara@dea.spamcon.org>
wrote:
<...>
Ruminations on a functional extension to C++
Juan Antonio Zaratiegui Vallecillo, a.k.a. Zara
zara@coit.es
Proposal for the adaptation of some ideas from functional programming
in order to improve C++ language.
** Rationale
<...>
** Definition
A function or class-member function will be considered with no side
effects if:
- All parameters passed to it are passed as const value or by const
reference.
... or pointer to const
- It will return only an object of the type expressed by its
signature or an exception, and void return value is not valid. The
return value will never be a POD pointer, but it may be a smart
pointer.
- It will not modify any global object.
- It will not access any volatile value anywhere.
- Any object it creates, will also be destroyed unless it is the
return value.
- It will catch no exception, any exception generated within will
flow seamlessly to the caller.
- It will only create local objects or smart/scoped pointers, apart
form the return value. The objects will be created through
constructors with no side effects, and the destructors will have no
side effects. Allocating memory for the object data is not a
side-effect, and neither destroying it in the destructor. There should
be some kind of system to verify that the destructor rids these
allocated data, but I don?t know if it should be easy enough to force
the uses of smart/scoped pointers.
- It will only call another functions or member functions with no
side effects.
- Any time it is called with the same parameters it will return the
same value (apart form run time exceptions related with memory
exhaustion)
I would now add:
- It may throw an exception
** Nomenclature
This is the hardest part. The best option seems to be to create a new
keyword to qualify this functions, for instance:
<...>
It seems to me that 'pure' could be the kwyword, as already used by
other people in this thread. I will use it for further references
<... rest of original document skipped>
** Use cases **
To clarify my intentions, I will now expose some use causes of 'pure'
function attribute:
1.- Functions that may be evaluated at compile-time, to subctitute
macros.
This is completely coveredby the 'constref' proposed in the ISO
committee, I will only note one case I would really love to see:
(Now)
#define ARRAYSIZE(a) (sizeof a /sizeof a[0])
(Desired)
template <typename T,size_t N>
size_t arryasizeof( T (&) [N]) pure {return N;}
2.- Less undefined behaviour
The usual division and modulus yields undefined behaviour when divisor
is zero.
Alternative pure operators could have a perfectly defined behaviour,
i.e.:
template <typename T>
T division(const T dividend,const T divisor) pure {
if (divisor==T()) {
throw div_by_zero_exception();
}
return dividend/divisor;
}
At run-time, dividsion by zero yields an exception, at compile-time if
divisor were the constant zero (via explicit expression, or through
intermediate 'pure' calculations), the compiler might issue a message
about the expression always throwing an exception.
3.- Creating a frame to work in multhreaded/multicored environments
One of the main aims of goog multi-x programming is minimizing the
locks between different threads. To achieve this, we may use the
suggested paradigm of using an objets volatile interface to lock it
and then access it through the usual const/non-const interface.
Pure functions then would be limited to work with non-locking objects,
thus giving us assurance of its non-locking nature.
For instance, we may have:
ObjectType some_thing;
volatile ObjectType some_other_thing;
ObjectType some_fun() pure {
return some_thing;
}
ObjectType some_other_fun(const ObjectType& object) pure {
return some_other_thing=object;
}
void thread_loop () {
for(;;) {
// lockless part
const ObjectType newObject=some_fun();
// probably locking part
static_cast<void>(some_other_fuin(newObject);
}
}
If need arises to share some_thing with other thread, it should be
retyped as 'volatile ObjectType', and the compiler would issue an
error, because some_fun cannot be pure.
This might give us an extra tool to build correct programs and check
them at compile-time.
I hope I made my intentions clear.
Best regards,
J.A.Zaratiegui a.k.a zara
zara AT coit DOT es
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]