Actors impl can easily lead to multithreading issues

I think the way ask & tell are impl they can lead to unwanted behaviour, i.e. say we have an actor that can calculate the max of a list. We would expect the actor to be called with a readily available list, but a call like:

actorRef.tell(_.max(calcMyList(...)))

means that the actor thread will also have to calculate the list.

The correct way to call it would be:

val l=calcMyList(...)
actorRef.tell(_.max(l))

but this can easily be missed by the developer writing the code, leading to slow throughput of the actor (because it is also calculating arbitrary lists, not just their maximums)

More silly code could lead to unpredictable behaviour:

var i=0
actor.tell(_.addOne(i))
while true do i+=1

// what will be the arg value to addOne?

Is there a solution to this? Maybe if:

actorRef.tell(_.max , calcMyList(...)) 

where the tell and ask methods take a FunctionN and then separately by-value their arguments like

class ActorRef...:
   def tell[A](f:Function1[A,Unit],arg1:A) ...

Start by reviewing the ask and tell implementations referenced in the issue, then trace how closures and their captured arguments are executed. Compare the proposed separate-argument API with the current behavior and determine the intended safety guarantees. Done means an agreed API design that prevents caller-side computation and mutable-value races, with corresponding coverage identified.