Syntax Request: defining named values in current block

[Namek]

In Mint we cannot define named values besides of where, sequence, parallel or try blocks. It's not practical to use sequence since it makes a different return type, a Promise.

Example

I have the following Elm code:

addNextBridge leftBridges acc =
    case leftBridges of
        [] ->
            acc

        (Bridge connectionCount orientation idx1 idx2) :: restBridges ->
            let
                dir1 =
                    directionFromIsland mapWidth idx1 idx2

                dir2 =
                    dir1 |> oppositeDirection

                sizes1 =
                    dir1 |> directionToConnectionSizes connectionCount

                sizes2 =
                    dir2 |> directionToConnectionSizes connectionCount
            in
            addNextBridge restBridges (increaseIsland idx1 sizes1 acc |> increaseIsland idx2 sizes2)

In Mint, the only place where one can define values such as dir1, dir2, sizes1 or sizes2 is in the where block AFTER function definition. However, it is not possible to do it after any case in a case block.

By rewriting from Elm to Mint, this is as far as I went to:

addNextBridge = (leftBridges : Array(Bridge), acc : Array(Island)) : Array(Island) {
  case (Array.at(0, leftBridges)) {
    Maybe::Nothing => acc
    Maybe::Just bridge =>
      addNextBridge(leftBridges |> Array.slice(0, Array.size(leftBridges)), acc)
  }
} where {
  helper = (bridge : Bridge, acc : Array(Island)) : Array(Island) {
    increaseIsland(bridge.idx1, sizes1, acc) |> increaseIsland(bridge.idx2, sizes2)
  } where {
    dir1 = directionFromIsland(width, bridge.idx1, bridge.idx2)
    dir2 = oppositeDirection(dir1)
    sizes1 = directionToConnectionSizes(bridge.connectionCount, dir1)
    sizes2 = directionToConnectionSizes(bridge.connectionCount, dir2)
  }
}

The first bad is the lack of array destructuring but it's covered in this issue: #177

The second is lack of local recursion: #179

But the main point here is that one cannot define values in block that would use them. Even a workaround does not seem to exist since nested where blocks does not seem to compile. And even if it would work then values may not be closured, I suppose.

Benefits from having named values would be:

1. readability by avoiding repetition and too big expression nesting
2. performance by avoiding recalculation of the same state

I have no proposal for a syntax yet, though.

[gdotdesign]

Yes this is something Elm has but Mint doesn't but the same thing can be achieved with a try block since it returns the last expression.

This is how I would structure it (might not be correct):

fun addNextBridge(leftBridges : Array(Bridge), acc : Array(Island)) : Array(Island) {
  case(leftBridges) {
    [] => acc /* This works currently because it just does an equality check */
    =>
      case(leftBridges[0]) {
        Maybe::Nothing => acc
        Maybe::Just bridge =>
          try {
            restBridges = 
              Array.slice(1, Array.size(leftBridges))

            dir1 =
              directionFromIsland(bridge.mapWidth, bridge.idx1, bridge.idx2)

            dir2 =
              oppositeDirection(dir1) 

            sizes1 =
              dir1 
              |> directionToConnectionSizes(bridge.connectionCount)

            sizes2 =
              dir2 
              |> directionToConnectionSizes(bridge.connectionCount)

            addNextBridge(
              restBridges,
              acc
              |> increaseIsland(idx1, sizes1) 
              |> increaseIsland(idx2 sizes2))
          }
      }
  } 
}

I find myself using this a lot where I need some temporary variables, and I don't really use where any more as well.

I'm not opposed having a different language feature for this but it would make the language more complex.

[Namek]

Thanks!

I find myself using this a lot where I need some temporary variables, and I don't really use where any more as well.

try is counter-intuitive on first sight. My first contact with it was: "it resembles throwing errors but I just want to write error-less code so I'll ignore it". Maybe we should have a let block (which does not allow to catch errors)?

[bbugh]

Hi! 👋 I'm excited for Mint because Elm is GTBAE. Thanks for all of your work on it.

try is counter-intuitive on first sight. My first contact with it was: "it resembles throwing errors but I just want to write error-less code so I'll ignore it". Maybe we should have a let block (which does not allow to catch errors)?

I haven't spent a lot of time with Mint yet, so I may be confused, but this really threw me. Having to declare variables after they're used in the function body is confusing imo. I agree that having a let block that just does value setting rather than synchronous error captures would be very nice.

[gdotdesign]

Hi! 👋 I'm excited for Mint because Elm is GTBAE. Thanks for all of your work on it.

Thanks 🙂 Wasn't familiar with GTBAE had to look it up 😄

I've been thinking about this for some time now and this is what I came up with:
try sequence and parallel can be merged into a single construct let where you can specify the behaviour: let, let in sequence and let in parallel. Errors would be handled as is now.

Having only one construct would be easier to understand for newcomers, also implementation wise try sequence and parallel is 90% the same.

What do you think?

[bbugh]

My meager understanding of Mint suggests that that would be useful (assuming that the standalone let as you described would allow us to define functions with the variables defined before the body)!

Would let in sequence and let in parallel replace the sequence and parallel keywords?

[gdotdesign]

Would let in sequence and let in parallel replace the sequence and parallel keywords?

Yes and try as well.

[Namek]

@gdotdesign I've wrote a lot of Mint code since then and I've found myself to having multiple nested try blocks just for declaring variables. if -> try -> case -> try -> if -> try. Indentation becomes twice larger than needed. Would be cool to not have it at all until one wants specifically parallel:ize or to catch errors. I also think the sequence should be the default so I wouldn't have to declare a useless variable to log something to the console (with Debug.log).

So, to summarize: I would expect to declare variables directly in the function body, if/else blocks and in the case blocks. The try/catch would be additional indent, same with parallel.

To see an example of too much indentation because of try blocks, see https://github.com/Namek/hashi-mint/blob/master/source/Generation.mint#L311

[gdotdesign]

So, to summarize: I would expect to declare variables directly in the function body, if/else blocks and in the case blocks. The try/catch would be additional indent, same with parallel.

I feel the same sometimes, I think its worth exploring, though it might not be possible since everything returns a single expression.

To see an example of too much indentation because of try blocks, see https://github.com/Namek/hashi-mint/blob/master/source/Generation.mint#L311

I'm assuming that you have the same code in Elm, did you have the same issue there as well?

I also think the sequence should be the default so I wouldn't have to declare a useless variable to log something to the console (with Debug.log).

I don't understand this, you don't need to declare a variable to use Debug.log:

try {
  Debug.log("A")
  Debug.log("B")
  Debug.log("C")

  "Some return value"
}

[gdotdesign]

This is now possible since 0.17.0, so I'm closing this.