Why force function bodies to be single expression?

[danhowardms]

Hi all.

I just came across this project yesterday and found the concept really intriguing. Really like the type safety and immutable objects in particular. After tinkering in the sandboxes for a while, one thing I found unusual, compared to other languages that I use, was the restriction that function bodies must contain one single expression. I was curious whether someone could explain the reasoning behind this. Is it just something that makes things easier in the compiler? Or is there some deeper conceptual reason for the restriction? Or does it just encourage developers to use a particular 'style' of code?

It seems puzzling to me, especially given that in practice I've found that I can pretty much sidestep the restriction by moving multiple steps into a where block, then use the single expression in my function body basically like a return statement.

A very simple example below is this function for multiplying 2 complex numbers:

  fun multiply (a: Complex, b : Complex) : Complex {
    Complex(real, imaginary)    
  } where {
    real = a.real * b.real - a.imaginary * b.imaginary
    imaginary = a.real * b.imaginary + a.imaginary * b.real
  }

Is a function like that considered bad practice? Am I abusing the language in some way here?

[gdotdesign]

Hi, and welcome 👋

I was curious whether someone could explain the reasoning behind this.

It has a number of reasons:

1. Mint is a functional language (well sort of) so you cannot do imperative things - it's all about transforming input to output.
2. It simplifies type checking a lot since there is no need to track the type of the variable it's only set once.
3. I used Elm a while before creating Mint and it's the same there.

Is a function like that considered bad practice? Am I abusing the language in some way here?

Not at all, that's the reason it's there 🙂

---

Lately I'm favoring try blocks to where blocks (might deprecate them in the future):

fun multiply (a: Complex, b : Complex) : Complex {
  try {
    real = 
      a.real * b.real - a.imaginary * b.imaginary

    imaginary = 
      a.real * b.imaginary + a.imaginary * b.real

    Complex(real, imaginary)
  } 
}

Also there is an other discussion here that related to this (about to reduce the nesting and indentation) #180

Let me know if you need more information 👍

[danhowardms]

Hi Szikszai, thanks for the reply, very interesting, as is the discussion in #180

Your example does make me wonder though... in this case the inputs are all numbers, we're just doing some arithmetic, there are no errors that could be thrown, so the try{} block doesn't really serve any purpose at all, apart from 'artificially' making a 3 step function into a single expression. Wouldn't it be much easier If we could just do this:

fun multiply (a: Complex, b : Complex) : Complex {
  real = a.real * b.real - a.imaginary * b.imaginary
  imaginary = a.real * b.imaginary + a.imaginary * b.real
  Complex(real, imaginary) 
}

IE treat any function body as being implicitly wrapped in a try{} block (or as proposed in #180 a let{} block).

[gdotdesign]

Wouldn't it be much easier If we could just do this:

Yes, it's easier to read but my concern is that people would interpret that as imperative code.

IE treat any function body as being implicitly wrapped in a try{} block (or as proposed in #180 a let{} block).

It's worth exploring, it would not be that hard to create a branch for this.

The let block would work like this with a function:

fun multiply (a: Complex, b : Complex) : Complex let {
  real = a.real * b.real - a.imaginary * b.imaginary
  imaginary = a.real * b.imaginary + a.imaginary * b.real
} in { Complex(real, imaginary) }

[frnco]

Wouldn't it be much easier If we could just do this:

Yes, it's easier to read but my concern is that people would interpret that as imperative code.

IE treat any function body as being implicitly wrapped in a try{} block (or as proposed in #180 a let{} block).

It's worth exploring, it would not be that hard to create a branch for this.

The let block would work like this with a function:

fun multiply (a: Complex, b : Complex) : Complex let {
  real = a.real * b.real - a.imaginary * b.imaginary
  imaginary = a.real * b.imaginary + a.imaginary * b.real
} in { Complex(real, imaginary) }

I find let to be pretty confusing in most situations.

From my experience, one gets used to better encapsulating such things in functions. I might do something like:

fun realMultiplication (a: Complex, b : Complex) : Complex {
  a.real * b.real - a.imaginary * b.imaginary
}
fun imaginaryMultiplication (a: Complex, b : Complex) : Complex {
  a.real * b.imaginary + a.imaginary * b.real
}
fun multiply (a: Complex, b : Complex) : Complex {
  Complex(realMultiplication(a,b), imaginaryMultiplication(a,b))
}

That would probably be changed and refactored and stuff, but the main point here is that language constraints can be seen either as a source of frustration or as an incentive to explore new possibilities and become familiar with different patterns. This example may be a poor example for that, but by repeating this exercise many times I've many times come to the realization that there was a better, cleaner and more elegant way to structure my code.

In this example after looking more closely into the algebra ((x + yi)(u + vi) = (xu - yv) + (xv + yu)i) I believe I'd start by looking for ways to improve the actual structure of the Complex class/whatever itself. I'm not sure what is the best way to represent complex numbers (Probably a type but that's the part of Mint I'm still most unfamiliar with so I'll skip that), but I'd look for a smarter way to differentiate imaginary and real parts of the numbers and branches related to those parts. Probably an enum or something, this way I'd be able to use case to create branches for multiplying, updating or whatever. I was gonna include an example of that here but it got a bit big and I decided it would be better to have it as a sandbox so I could test it, so here it is: https://sandbox.mint-lang.com/sandboxes/J-Q_G8Qv04Eb2g

I think this is a good example of how making small changes to the structure of the data can meaningfully impact the code, most of the functions are related to either rendering or updating the state variables, only updateComplex, partialMultiplication and multiply are actually relevant, and even updateComplex pretty much only serves the purpose of making it easier to use reduce to combine the two multiplication steps, after this I'd probably look for a better way to do this so I could do away with the updateComplex function. Here the multiplication process follows a pretty straightforward path, when multiplying complex numbers there are two parts with different formulas, for each of those parts call a function passing which part you wanna multiply and both complex numbers (Could be a different function for each part, but I prefer branching on the root of a function), then update the relevant part of the resulting complex number. So, FOR each part, DO its multiplication and store the result. The Partial Multiplication is also pretty straightforward, just check which part is being multiplied and return its branch. The logic is very obvious, and very testable, as you can have individual checks for both the Real and Imaginary parts of the result, plus checks for the full result. It's also a bit less cryptic than the two lines having only real and imaginary being assigned some cryptic formula, seemingly being just a preparation for the actual task of the function (When in fact those two lines are the two halves of the function's actual purpose). I think this makes refactoring easier, reviewing of the formulas easier and testing easier, just to mention the most obvious benefits. Sure, the Complex bit could use some improvements on its structure, but on the matter of function bodies having a single expression this is quite sufficient to show how simple changes make it a non-issue while also making the code clearer, at least to some extent (Still not happy with that updateComplex function in the reduce but I can't think of a better way to do it, except for using Enums as the record fields which I believe is not possible).

This ended up quite long but I believe many concepts are presented in the documentation with insufficient code examples, and the one-expression-function is definitely among those. Functions should do one thing, a sequence of actions could be represented by piping or by a map or a reduce, for branching we have case and if, and in most cases it's not really necessary to use try or sequence or whatever, actually in my humble opinion having those in too many functions is a sign that either those functions are doing more than they should, or that the code could use some refactoring, probably including some changes in its structure.

[Sija]

FYI, this has been changed in #503