actor Test
fun foo(a: U32) =>
a = a + 1
I want test.foo(a) to modify a. Is this possible? Thanks
You can only modify vars at a class level. This is intentional because actors don't like in-place updates -- it really doesn't jive well with lock-free concurrency.
Functions, by default, have the box capability, which means that data manipulated by this function are read-only. To ensure that the function can mutate data, the method will need to be declared fun ref.
actor Main
var i: U32 = 0
fun ref foo() =>
i = i + 1
new create(env: Env) =>
env.out.print(i.string())
foo()
env.out.print(i.string())
Playground
Related
As I have realized up until right now the basic idea for functional reactive programming in Scala is to define a signal that extends the DynamicVariable class of Scala but I could not understand something written in explanation of that class it said:
DynamicVariables provide a binding mechanism where the current value is found through dynamic scope, but where access to the variable itself is resolved through static scope.
If I am not wrong, the dynamic scope is when a called function sees a variable from the scope of the caller program and the static scope is when it sees a variable from its own scope like the pseudo-code that follows:
let x = 1
func dynamic (y: Int) = y + x
func static (w: Int) = y + x
func main() = {
let x = 2
dynamic (3) //returns 5
static (3) //returns 4
}
So the question is how is the meaning of accessing the variable itself, and if it implies writing to it, how Scala prevent racing when some functions have each a copy and want to write to the variable?
In the following, dv1 is defined in the normal fashion, and is only accessible through the usual scope rules. The function checkDv1 sees dv1 because dv1 is defined in its scope.
val dv1: DynamicVariable[Int] = new DynamicVariable(42)
def checkDv1 = println( dv1.value )
However, when checkDv1 is invoked inside the withValue() dynamic scope, the value it gets back is different, as in it will be the newly bound value.
def testDv = dv1.withValue(41) {
checkDv1
}
checkDv1
testDv
checkDv1
So, the output from those three function invocations should be:
42
41
42
as the dynamic scope changes.
For your other question, a DynamicVariable has a binding within the context of a thread. When a new thread is created, the current binding is copied to the new thread, and they have no further interaction with each other. Hence, no race conditions.
DynamicVariable has very little to do with reactive programming, except that its behavior is well defined in a multi-threaded environment.
I'm learning Scala and I don't really understand the following example :
object Test extends App {
def method1 = println("method 1")
val x = {
def method2 = "method 2" // method inside a block
"this is " + method2
}
method1 // statement inside an object
println(x) // same
}
I mean, it feels inconsistent to me because here I see two different concepts :
Objects/Classes/Traits, which contains members.
Blocks, which contains statements, the last statement being the value of the block.
But here we have a method part of a block, and statements part of an object. So, does it mean that blocks are objects too ? And how are handled the statements part of an object, are they members too ?
Thanks.
Does it mean that blocks are objects too?
No, blocks are not objects. Blocks are used for scoping the binding of variables. Scala enables not only defining expressions inside blocks but also to define methods. If we take your example and compile it, we can see what the compiler does:
object Test extends Object {
def method1(): Unit = scala.Predef.println("method 1");
private[this] val x: String = _;
<stable> <accessor> def x(): String = Test.this.x;
final <static> private[this] def method2$1(): String = "method 2";
def <init>(): tests.Test.type = {
Test.super.<init>();
Test.this.x = {
"this is ".+(Test.this.method2$1())
};
Test.this.method1();
scala.Predef.println(Test.this.x());
()
}
}
What the compiler did is extract method2 to an "unnamed" method on method2$1 and scoped it to private[this] which is scoped to the current instance of the type.
And how are handled the statements part of an object, are they members
too?
The compiler took method1 and println and calls them inside the constructor when the type is initialized. So you can see val x and the rest of the method calls are invoked at construction time.
method2 is actually not a method. It is a local function. Scala allows you to create named functions inside local scopes for organizing your code into functions without polluting the namespace.
It is most often used to define local tail-recursive helper functions. Often, when making a function tail-recursive, you need to add an additional parameter to carry the "state" on the call stack, but this additional parameter is a private internal implementation detail and shouldn't be exposed to clients. In languages without local functions, you would make this a private helper alongside the primary method, but then it would still be within the namespace of the class and callable by all other methods of the class, when it is really only useful for that particular method. So, in Scala, you can instead define it locally inside the method:
// non tail-recursive
def length[A](ls: List[A]) = ls match {
case Nil => 0
case x :: xs => length(xs) + 1
}
//transformation to tail-recursive, Java-style:
def length[A](ls: List[A]) = lengthRec(ls, 0)
private def lengthRec[A](ls: List[A], len: Int) = ls match {
case Nil => len
case x :: xs => lengthRec(xs, len + 1)
}
//tail-recursive, Scala-style:
def length[A](ls: List[A]) = {
//note: lengthRec is nested and thus can access `ls`, there is no need to pass it
def lengthRec(len: Int) = ls match {
case Nil => len
case x :: xs => lengthRec(xs, len + 1)
}
lengthRec(ls, 0)
}
Now you might say, well I see the value in defining local functions inside methods, but what's the value in being able to define local functions in blocks? Scala tries to as simple as possible and have as few corner cases as possible. If you can define local functions inside methods, and local functions inside local functions … then why not simplify that rule and just say that local functions behave just like local fields, you can simply define them in any block scope. Then you don't need different scope rules for local fields and local functions, and you have simplified the language.
The other thing you mentioned, being able to execute code in the bode of a template, that's actually the primary constructor (so to speak … it's technically more like an initializer). Remember: the primary constructor's signature is defined with parentheses after the class name … but where would you put the code for the constructor then? Well, you put it in the body of the class!
Does Scala have an equivelent to golangs defer?
from:
http://golang.org/doc/effective_go.html#defer
Go's defer statement schedules a function call (the deferred function) to be run immediately before the function executing the defer returns. It's an unusual but effective way to deal with situations such as resources that must be released regardless of which path a function takes to return. The canonical examples are unlocking a mutex or closing a file.
Scala does not offer defer by design, however you can create it yourself by wrapping
your function in another function, passing an object which keeps track of functions to call.
Example:
class DeferTracker() {
class LazyVal[A](val value:() => A)
private var l = List[LazyVal[Any]]()
def apply(f: => Any) = { l = new LazyVal(() => f) :: l }
def makeCalls() = l.foreach { x => x.value() }
}
def Deferrable[A](context: DeferTracker => A) = {
val dt = new DeferTracker()
val res = context(dt)
dt.makeCalls
res
}
In this example, Deferable would be the wrapping function which calls context and
returns it contents, giving it an object which tracks defer calls.
You can use this construct like this:
def dtest(x:Int) = println("dtest: " + x)
def someFunction(x:Int):Int = Deferrable { defer =>
defer(dtest(x))
println("before return")
defer(dtest(2*x))
x * 3
}
println(someFunction(3))
The output would be:
before return
dtest: 6
dtest: 3
3
I'm aware that this can be solved differently but it is really just an example that
Scala supports the concept of defer without too much fuss.
I can't think of a Scala specific way, but wouldn't this be equivalent (though not as pretty):
try {
// Do stuff
} finally {
// "defer"
}
No. Go has this construct precisely because it doesn't support exceptions and has no try...finally syntax.
Personally, I think it invites a maintenance nightmare; calls to defer can be buried anywhere in a function. Even where responsible coders put the defers right beside the thing to be cleaned up, I think it's less clear than a finally block and as for what it lets the messy coders do... at least finally blocks put all the clean-up in one place.
defer is the opposite of idiomatic Scala. Scala offers monadic ways to control program flow and defer magic does not contribute at all. Monads offer a functional improvement over try...finally which let you
Define your own error handling flow
Manipulate defined flows functionally
Make a function's anticipated errors part of its signature
defer has no place in this.
I understand that Scala embraces immutability fully.
Now I am thinking a scenario that I have to hold some state (via variables) in a class or such. I will need to update these variables later; then I can revisit the class later to access the updated variables.
I will try to make it simple with one very straightforward example:
class A {
var x: Int
def compute: Int = {calling some other processes or such using x as input}
}
......
def invoker() {
val a: A = new A
a.x = 1
......
val res1 = a.compute
a.x = 5
......
val res2 = a.compute
......
}
So you see, I need to keep changing x and get the results. If you argue that I can simply keep x as an argument for compute such as
def compute(x: Int)
......
That's a good idea but I cannot do it in my case as I need to separate setting value for x and computing the result completely. In other words, setting x value should not trigger "computing" to occur, rather, I need to be able to set x value anytime in the program and be able to reuse the value for computation any other time in the program when I need it.
I am using a variable (var x: Int) in this case. Is this legitimate or there is still some immutable way to handle it?
Any time you store state you will need to use mutability.
In your case, you want to store x and compute separately. Inherently, this means state is required since the results of compute depends on the state of x
If you really want the class with compute to be immutable, then some other mutable class will need to contain x and it will need to be passed to the compute method.
rather, I need to be able to set x value anytime in the program and be able to reuse the value for computation any other time in the program when I need it.
Then, by definition you want your class to be stateful. You could restructure your problem so that particular class doesn't require state, but whether that's useful and/or worth the hassle is something you'll have to figure out.
Your pattern is used in a ListBuffer for example (with size as your compute function).
So yes, there might be cases where you can use this pattern for good reasons. Example:
val l = List(1, 2, 3)
val lb = new ListBuffer[Int]
l.foreach(n => lb += n * n)
val result = lb.toList
println(result)
On the other hand a buffer is normally only used to create an immutable instance as soon as possible. If you look at this code, there are two items which might indicate that it can be changed: The mutable buffer and foreach (because foreach is only called for its side-effects)
So another option is
val l = List(1, 2, 3)
val result = l.map(n => n * n)
println(result)
which does the same in fewer lines. I prefer this style, because your are just looking at immutable instances and "functional" functions.
In your abstract example, you could try to separate the mutable state and the function:
class X(var i: Int)
class A {
def compute(x: X): Int = { ... }
}
possibly even
class X(val i: Int)
This way compute becomes functional: It's return value only depends from the parameter.
My personal favorite regarding an "unexpected" immutable class is scala.collection.immutable.Queue. With an "imperative" background, you just not expect a queue to be immutable.
So if you look at your pattern, it's likely that you can change it to being immutable.
I would create an immutable A class (here its a case class) and let an object handle the mutability. For each state change we create a new A object and change the reference in the object. This is handle concurrency bit better if you set x from a different thread, you just have to make the variable a volatile or an AtomicReference.
object A {
private[this] var a = A(0)
def setX(x: Int) { if (x != a.x) a = new A(x) }
def getA: A = a
}
case class A(x: Int) {
def compute: Int = { /*do your stuff*/ }
}
After a few more months on functional programming, here is my rethinking.
Every time a variable is modified/changed/updated/mutated, the imperative way of handling this is to record such change right with that variable. The functional way of thinking is to make the activity (that cause the change) bring the new state to you. In other words, it's like cause effect stuff. Functional way thinking focuses on the transition activity between cause and effect.
Given all that, in any given point of time in the program execution, our achievement is the intermediate result. We need somewhere to hold the result no matter how we do it. Such intermediate result is the state and yes, we need some variable to hold it. That's what I want to share with just abstract thinking.
I'd like to have some basic knowledge of how deeply my function call is nested. Consider the following:
scala> def decorate(f: => Unit) : Unit = { println("I am decorated") ; f }
decorate: (f: => Unit)Unit
scala> decorate { println("foo") }
I am decorated
foo
scala> decorate { decorate { println("foo") } }
I am decorated
I am decorated
foo
For the last call, I'd like to be able to get the following:
I am decorated 2x
I am decorated 1x
foo
The idea is that the decorate function knows how deeply its nested. Ideas?
Update: As Nikita had thought, my example doesn't represent what I'm really after. The goal is not to produce the strings so much as to be able to pass some state through a series of calls to the same nested function. I think Régis Jean-Gilles is pointing me in the right direction.
You can use the dynamic scope pattern. More prosaically this means using a thread local variable (scala's DynamicVariable is done just for that) to store the current nesting level. See my answer to this other question for a partical example of this pattern: How to define a function that takes a function literal (with an implicit parameter) as an argument?
This is suitable only if you want to know the nesting level for a very specific method though. If you want a generic mecanism that works for any method then this won't work (as you'd need a distinct variable for each method). In this case the only alternative I can think of is to inspect the stack, but not only is it not very reliable, it is also extremely slow.
UPDATE: actually, there is a way to apply the dynamic scope pattern in a generic way (for any possible method). The important part is to be able to implicitly get a unique id for each method. from there, it is just a matter of using this id as a key to associate a DynamicVariable to the method:
import scala.util.DynamicVariable
object FunctionNestingHelper {
private type FunctionId = Class[_]
private def getFunctionId( f: Function1[_,_] ): FunctionId = {
f.getClass // That's it! Beware, implementation dependant.
}
private val currentNestings = new DynamicVariable( Map.empty[FunctionId, Int] )
def withFunctionNesting[T]( body: Int => T ): T = {
val id = getFunctionId( body )
val oldNestings = currentNestings.value
val oldNesting = oldNestings.getOrElse( id, 0 )
val newNesting = oldNesting + 1
currentNestings.withValue( oldNestings + ( id -> newNesting) ) {
body( newNesting )
}
}
}
Usage:
import FunctionNestingHelper._
def decorate(f: => Unit) = withFunctionNesting { nesting: Int =>
println("I am decorated " + nesting + "x") ; f
}
To get a unique id for the method, I actually get an id for a the closure passed to withFunctionNesting (which you must call in the method where you need to retrieve the current nesting). And that's where I err on the implementation dependant side: the id is just the class of the function instance. This does work as expected as of now (because every unary function literal is implemented as exactly one class implementing Function1 so the class acts as a unique id), but the reality is that it might well break (although unlikely) in a future version of scala. So use it at your own risk.
Finally, I suggest that you first evaluate seriously if Nikita Volkov's suggestion of going more functional would not be a better solution overall.
You could return a number from the function and count how many levels you are in on the way back up the stack. But there is no easy way to count on the way down like you have given example output for.
Since your question is tagged with "functional programming" following are functional solutions. Sure the program logic changes completely, but then your example code was imperative.
The basic principle of functional programming is that there is no state. What you're used to have as a shared state in imperative programming with all the headache involved (multithreading issues and etc.) - it is all achieved by passing immutable data as arguments in functional programming.
So, assuming the "state" data you wanted to pass was the current cycle number, here's how you'd implement a function using recursion:
def decorated ( a : String, cycle : Int ) : String
= if( cycle <= 0 ) a
else "I am decorated " + cycle + "x\n" + decorated(a, cycle - 1)
println(decorated("foo", 3))
Alternatively you could make your worker function non-recursive and "fold" it:
def decorated ( a : String, times : Int )
= "I am decorated " + times + "x\n" + a
println( (1 to 3).foldLeft("foo")(decorated) )
Both codes above will produce the following output:
I am decorated 3x
I am decorated 2x
I am decorated 1x
foo