Functions?

Functions vs Methods?

In Concurnas, a distinction is drawn between the concept of functions and methods.

Simply put, functions are defined at root source code level, methods are defined within classes and have access to the internal state of instance objects of their host class (and any parent nestor classes if relevant), via the this and super keywords. Methods are covered in more detail here See Classes and Objects section. For now lets look at a simple example highlighting the distinction:

def iAmAFunction() => "hi I'm a function"

class MyClass(id int){
  def iAmAMethod() => "hi I'm a method, my class holds the number: " + this.id
}

Calling functions and methods?

Ordinarily, we require three things when calling a function, 1). the name of the function, 2). input arguments to qualify it's input parameters and 3). an understanding of the return type.

We can call our addTogether function defined previously as follows:

result int = addTogether(1, 1)

Also, we may use named arguments in order to call our function. This can often make method calls easier to read, especially where there are lots of arguments involved, some with default values some not etc. Named arguments do not have to be specified in the order in which they are defined in the function:

result = addTogether(a=1, b=1)
result = addTogether(b=1, a=1)

The above two calls to addTogether are functionally identical.

When it comes to calling (or invoking) methods, we need an additional component; an object to call the method on. To indicate that we are calling a function on a method, we need to use a dot ., for example:

class MyClass(state int){
  def myMethod(an input) => state += an; state
}

obj = new MyClass(10)
result = obj.myMethod(2)

//result == 12

If instead of whatever is returned from the method (if anything) we wish to return a reference to the object upon which we called the method, we can use the double dot notation: ..:

obj = new MyClass(10)
result = obj..myMethod(2)..myMethod(10)

//result == 22

The double dot notation .. is particularly useful when we need to chain together multiple calls on the same object and do not wish to do perform any sort of operation on the returned values from the intermediate method calls.

We can use named arguments when calling methods:

obj = new MyClass(10)
result = obj.myMethod(input = 2)

//result == 12

Input parameters?

Functions specify a comma separated list of input variables consisting of a name and type. Each input variable name must be unique. They may optionally be preceded by var or val:

def addTwo(var a int, val b int) => a+b

Default arguments?

Function input arguments may specify a default value to use in cases where the input argument is not specified by the caller. When this is done, the type of the variable does not have to be specified if you're happy for Concurnas to infer the input parameter type:

def doMath(an int, b int = 100, c = 10) => (an + b) * c

Then, when we call a function with default arguments, we do need to specify the arguments for which a default value has been defined:

res = doMath(5)

//res == 1050

Varargs?

Function parameters may consume more than one input parameter if they are declared as a vararg. A varag input parameter is signified by postfixing ... to the type of the parameter - note that this converts the input parameter to be an array if it's a single value type, or an n+1 dimensional array if it's already an n dimensional array. For example:

def stringAndSum(prefix String, items int...){
  summ = 0L
  for( i in items){
    summ += i
  }
  prefix + summ
}

We can call a function with vararg parameters we can pass as many inputs to the vararg component as we need, seperated via a commas as par normal function invocation arguments:

result = stringAndSum("the sum is: ", 2, 3, 2, 1, 3, 2, 1, 3, 4, 2, 4)

//result == "ths sum is: 27"

The vararg may alternatively be passed as an array type (or n+1 dimensional array as eluded previously):

result = stringAndSum("the sum is: ", [2 3 2 1 3 2 1 3 4 2 4])

//result == "ths sum is: 27"

It's perfectly acceptable to not pass any input to the vararg parameter, e.g:

result = stringAndSum("the sum is: ")

//result == "ths sum is: 27"

An n dimensional array type can be used as a varrag:

def stringAndSum(prefix String, items int[]){
  summ = 0L
  for( i in items){
    summ += i
  }
  prefix + summ
}

result = stringAndSum("the sum is: ", 2, 3, 2, 1, 3, 2, 1, 3, 4, 2, 4)

//result == "ths sum is: 27"

Nested functions?

Nested functions are appropriate in two cases:

1. It makes sense to break one's code down into a subroutine - for instance, in order to avoid what would otherwise be code duplication

2. One wishes for that sub function to only be callable within the nestor function - i.e. the nestor function is the only caller.

A nested function is simply a function defined within a function. The scope of that function is bound to the scope of the nestor function, it cannot directly be called by code outside of the nestor function. Example:

def parentFunction(apply int){
  result = 0L
  def dosomething(){
    result + (result + apply) * apply
  }
  //we wish to perform the above four times but avoid the code duplication, we also don't require any other code outside of parentFunction to be able to call it.
	
  result = dosomething()
  result = dosomething()
  result = dosomething()
  result = dosomething()
}

When it comes to using variables which are defined in the nestor function within the nested function, they are implicitly passed to the function but the nested function itself is defined as if it were separate from the nestor. For this reason, and by virtue of the fact that Concurnas uses pass by value for function arguments when calling functions the following is true:

def parentFun(){
  parentVar = 100
	
  def nestedFunc(){
    parentVar += 100
    parentVar
  }
	
  result = nestedFunc()
  assert result == 200
  assert parentVar ==100
}

We see above that although our nestedFunc has access to a copy of the value of the nestor variable parentVar (as it is implicitly passed into the function), changes made to that variable within the function do not apply to the one in scope of the parentFun.

But note that if we pass in an object, a copy of the reference to that object is passed to the nested function, so the behaviour is as follows:

class IntHolder(~an int)

def parentFun(){
  parentVar = IntHolder(100)
	
  def nestedFunc(){
    parentVar.an += 100
    parentVar.an
  }
	
  result = nestedFunc()
  assert result == 200
  assert parentVar.an == 200
}

As parentVar holds a reference to an object, the reference is copied, not the object itself, therefore the nestor function parentFun and nested function nestedFunc versions of the object referenced by variable parentVar are the same - they are shared.

Recursion?

Recursion is the process by which a function, either directly or indirectly calls itself. Concurnas permits function recursion (except for within GPU functions and GPU kernels). The classic textbook example of this being factorial number calculation:

def factorial(n int){
  match(n){
    1 or 2 => 1
    else => factorial(n-1)+factorial(n-2)
  }
}

res = factorial(5)

//res == 5

It turns out that the above, for any value of n greater than 2 performs a lot of unnecessary repetitive work in terms of calling factorial for values already previously calculated. There are far better ways of calculating factorial numbers (some of which don't use recursion at all). Here is a different recursion example more likely to be seen in the wild, a tree traversal:

open class Node

class Branch(~children Node...) < Node
class Leaf(~value String) < Node

def create(){
  Branch(Branch(Leaf("a"), Leaf("z")), Leaf("c"))
}

def explore(node Node){
  match(node){
    Branch => String.join(", ", (explore(n) for n in node.children))
    Leaf => "Leaf: {node.value}"
  }
}

tree = create()
res = explore(tree)

//res == Leaf: a, Leaf: z, Leaf: c

One thing to bear in mind with recursion is the fact that as we recurse, with every direct or indirect self call, we deepen the call stack. This is not a big deal if we recurse to a small degree, but if we are recursing a lot¹, then we will be eating up our call stack which may result in us running out of stack causing a java.lang.StackOverflowError exception to be thrown. It is for this reason that some organizations restrict the use of, or even outright ban the use of recursion.