Why are they called thunks?

[matthewmueller]

It seems like thunks are a core piece of Bass:

Bass is built around thunks. Thunks are cacheable commands that produce files and/or a stream of values.

Curious why they're called thunks? As a newbie functional programmer, I'm familiar with thunks only in programming languages where you have something like:

function add(one) {
  return function(two) {
    return one + two
  }
}
add(1)(2)

Is it the same concept? Where you have "thunk commands" like:

function pull(repo) {
  return function do() {
    // actually pull 
  }
}

[vito]

Bass thunks have the following properties:

• A thunk is a value representing a deferred (or lazy) computation (except it's a command to run in a container or a Bass module to evaluate, instead of a function body to evaluate).
• A thunk is always fully defined, takes no additional parameters, and always has the same result.
• A thunk's result can be cached forever (though it may still run again upon a cache miss/purge).

Note that these properties assume thunks are hermetic, i.e. they are are used as leverage to guide users towards hermetic builds.

These properties align with a 0-arity pure function, which Haskell calls a thunk, so I did too. I believe the most general definition of thunk is just being a 0-arity function, per Wikipedia:

// 'thunk' is a function that takes no arguments and, when invoked, performs a potentially expensive
// operation (computing a square root, in this example) and/or causes some side-effect to occur
const thunk = () => hypot(3, 4);

Using the same term for functions and commands running in containers is definitely a bit of a stretch, but it seemed worth drawing a parallel to indicate how prominent thunks are in Bass. (Way, way more common than 0-arity functions.)

I'm willing to change it if folks find it too confusing, but any new name would have to also be fun to say. 😁

[matthewmueller]

Ahh that makes more sense, thanks!

Note that these properties assume thunks are hermetic, i.e. they are are used as leverage to guide users towards hermetic builds.

I really like how you encourage these properties but don't enforce it.

Using the same term for functions and commands running in containers is definitely a bit of a stretch, but it seemed worth drawing a parallel to indicate how prominent thunks are in Bass. (Way, way more common than 0-arity functions.)

I think it will depend on your intended audience. It seems like the functional community will have no problem understanding and transferring these concepts to this new domain. The Docker community may need a glossary 🙃

I'm willing to change it if folks find it too confusing, but any new name would have to also be fun to say. 😁

Thunk thu thunk thunk 🎵