Task { ... } macro is a beautiful lie

[arturaz]

This one is more philosophical, but I've stumbled on this multiple times:

def dependentTask: Task[Int] = Task.Input {
  println("side effects")
  ???
}

def myTask = Task {
   println("my side effects")
   val value = dependentTask()
   println(s"value is $value")
   value
}

You write code like this, it looks beautiful, but instead of

my side effects
side effects
value is ...

you get:

side effects
my side effects
value is ...

And that can be very subtle to catch.

Under the hood the macro just transforms it to (taskDep1, taskDep2).mapN { (dep1, dep2) => ... }, but the macro hides this transformation and I'm not sure that's a good thing.

Pros:

• it reduces barrier to entry
• using dependent tasks in if statements feels more natural

Cons:

• you expect side effects to work in one way, but the dependent tasks always run first
• if statements are a partial lie - they only conditional the results of the tasks, but the tasks always run

Thoughts?

[lefou]

TBH, it's not clear to me what you are asking.

Since tasks may be cached, it is inherent that the result may be produced in the past. Task inputs (= dependencies) are the way to capture dependencies instead of assuming that side-effects might produce inputs. Not relying on side-effects, but using return values (= (cached) task results) is the way to make the dependency graph robust and reasonable.

When writing task() (= task.apply()) you're accessing the result of a task. You also express a dependency to that task (that`s, why we need to have a macro in the first place). Having a dependency means, that dependency needs to run before. That's also, what the documentation tells you, e.g. here: https://mill-build.org/mill/fundamentals/tasks.html

Edit: I also think the issue title, while catchy, isn't correct. There are no lies involved. When you write dependentTask() you use one more parenthesis pair than at the definition side. It is short for dependentTask.apply(), which returns the result of the task. No one is lying to you. All we hide from you is the need to use API to explicitly add a task dependency. Since the dependency is definite (and obvious for a human), we hide from you the need to explicitly register it, as other tools like Gradle do.