Women in Technology

A functional method should not be allowed to modify objects it did not create or obtained from other method as a return value. See example below: a method adding a number to each member of an array of integers

"Traditional approach"

void addNumber(int[] arr,int n)
{
for(int i=0;i {
arr[i]+=n;
}
}

"Functional" approach:

functional int[] addNumber(int[] arr,int n)
{
int[] arret=new int[arr.length];
for(int i=0;i {
arret[i]=arr[i]+n;
}
return arret;
}

Only functional methods may be called from functional methods, and I/O probably must be very limited for functional methods.

This corresponds to concept of modern functional languages that use monads (their way to define sequentiality) on the top level where I/O is allowed, and "regular" functions called from within monadic level that are prohibited to do I/O and any other action assuming sequentiality (a very rough description though).

Absence of side effects gives big advantages in simplifying garbage collection. Only objects referenced via return statement need to be kept; the rest of objects that might have been created by the method can be disposed of immediately upon method termination (reduces background GC job). Functional methods may even run in parallel thus giving alternative to threading. A thread running in functional mode can be safely terminated (destroyed), and an upper level method should just catch this as an exception. If object(s) a method returns are created by the method, they are not referenced from anywhere and thus can be moved safely to compact the heap.

This suggestion is drawn from my personal experience when I tried to create a straightforward implementation of JVM, and from some other Internet sources.

Dimitry Golubovsky

dimitry at golubovsky dot org