# Flow Control - why no early returns

## Background
In my [previous post](https://blog.ek9.io/programming-language-modern-types) I outlined the need for a range of new modern **types** in
[EK9](https://www.ek9.io).

In this article I'll discuss the different forms of flow control. I will also introduce a couple of contentious ideas relating to unnecessary complexity in most languages; those being **break**, **label**, **continue** and **return**.

## Forms of flow control
There are broadly two categories of flow control in [EK9](https://www.ek9.io).
- Decision flow control
- Iteration flow control

### Decision flow control
This is the simple **if/else** and the **switch** construct.
These are described in [if/else](https://www.ek9.io/flowControl.html#if_elseif_else) and
[switch](https://www.ek9.io/flowControl.html#switch) on the EK9 site. Both of these are fairly similar to most languages. The **switch** has no **break** syntax and significantly you can use **switch** to return a value.

### Iteration flow control
Similar to most languages in the form of [**for loops**](https://www.ek9.io/flowControl.html#for_loop), [**while loops**](https://www.ek9.io/flowControl.html#while_loop) and [**do while loops**](https://www.ek9.io/flowControl.html#do_while_loop).

But again the most significant change is the lack of any **break** syntax to exit a loop early. The developer has to use a condition expression in the **while do/while** loop and must iterate through to the end in a 'for loop' (**WHAT!** you may think, but read on).

## Give me a **break**
In short, no I won't; at least not in the forms most languages use. The main reason why  **return**, **break**, **label**, **continue** or **goto** are **not** available is to reduce the possible processing paths a developer has to understand when looking at code.

Just think about it for a moment. If a function/method has multiple exit points you have to build a mental model of each of the processing paths. Many would say - hey I only do preconditions at the start and they are simple. Hmm -- take a look at a few code bases, that's not what people do. If they are all simple preconditions -- hey put them in a simple single if statement.

The original idea of [structured programming](https://en.wikipedia.org/wiki/Structured_programming) was really innovative at the time. There will be many *commentators* that think reverting to single entry, single exit is a retrograde step. I'd agree if all [EK9](https://www.ek9.io) was offering was this same old reheated soup from other languages.

**But it's not**, is going to try and attempt to ween developers away from just standard procedural/imperative code and more in the direction of a functional approach.

Now bear with me, don't huff and puff just yet. Given this a quick read first.

## Pipelines or 'fluent interfaces'
[Fluent Interfaces](https://java-design-patterns.com/patterns/fluentinterface/) are a sort of Object Oriented attempt at functional programming (a bit harsh maybe).

Why is this at all relevant to **for loops**, **break** and lack of **early returns**?

It's relevant because with [EK9 pipelines](https://www.ek9.io/streamsAndPipelines.html) you have all the **early returns**, **breaks** and **continues** you need; but in the form of new syntax (unless you have a Unix background then it's familiar).

### Filter
This is your **if** statement that either does or does not let data flow through the pipeline.

### Head, Tail, Skip
This is your **break**.

### Pipeline summary
The pipeline manages your state variables as they *stream* through the pipeline.
When you adopt [EK9 pipelines](https://www.ek9.io/streamsAndPipelines.html); you'll see that:

```
cat someList | filter by someCriteria | head 1 > stdout
``` 
Means you don't write **for** or **if** or **break**. You don't need any loop state variables, multiple nested loops and no **labels** to **continue** to.

This single construct from Functional programming is probably as significant as **Polymorphism** from Object Oriented programming.

There are lots of other **commands** in [EK9 Pipelines](https://www.ek9.io/streamsAndPipelines.html) for grouping, sorting, uniqueness, joining, mapping and collecting/reducing. Also even **teeing** off data from parts of the pipeline as it flows through (big Unix/Linux influence here).

## Exceptions
The *unspoken* flow control is the [**Exception**](https://www.ek9.io/exceptions.html). [EK9](https://www.ek9.io) uses these in a very limited way and they are 'unchecked' meaning you do not declare them on function or method signatures.

### Implementation details leaking out
If [Exceptions](https://www.ek9.io/exceptions.html) had to be declared (like some languages) then implementation details start to leak out (FileNotFoundException). It looks like you are accessing files in your implementation then. But what if you altered this implementation to read and write data from a remote system (what about those of Exceptions and then new networking Exceptions).

That's why EK9 only has unchecked Exceptions. In general it's only worth catching Exceptions if you can do something about the processing. A remote call to a web server could be retried a couple of times (that's reasonable). But not being able to write a file is pretty much it - what are you going to do to solve that?

By the way, Exceptions destroy the entire Pipeline processing if not caught!

### The Unset nature of data
EK9 prefers to return **unset** data, this is much easier to deal with. In pipeline processes it just gets omitted from the flow; in a sort of [Haskell MONAD](https://wiki.haskell.org/All_About_Monads) type manner.

## Summary
EK9 has traditional flow control, but it has been deliberately limited to enforce a more *structured* approach originally created by Böhm, Jacopini and  Dijkstra.

You may see this as a limitation, but I've found it forces more decomposition in to smaller functions and methods and the overall processing is much easier to understand at first glance.

The functional approach to collection processing again encourages smaller well rounded *pure* functions and a more declarative syntax. Basically you don't get bogged down in the detail.

The next blog post will discuss the thorny issue of **immutability** and take another key innovation from the Functional programming camp (**pure**). In EK9 it won't be
totally pure. I'm a pragmatic person and also like to bend the rules, so it will be **pure-ish**.