I'm trying to understand the lifetime of an owned class, when being used in a user-defined iterator. Consider the following code :
var a = new owned C();
var b = new owned C();
a.i = 2;
forall (a1,b1) in zip(a,b) {
b1 = a1;
}
forall (a1,b1) in zip(a,b) {
writeln(a1, " ",b1);
}
class C {
var i : int;
iter these() {
yield 1;
}
iter these(param tag : iterKind) where tag==iterKind.leader {
yield 1;
}
iter these(param tag : iterKind, followThis) ref
where tag==iterKind.follower {
yield i;
}
}
Compiling and running this code gives the following error
(08:54)$ chpl test.chpl --warn-unstable
(08:54)$ ./test
test.chpl:25: error: attempt to dereference nil
(08:54)$ chpl --version
chpl version 1.19.0 pre-release (2c10dbe)
It isn't clear to me when the class is being deinit-ed here. If I replace the owned with a shared, this example works as expected. More interestingly, changing the first loop to
forall (a1,b1) in zip(a.borrow(),b.borrow()) {
allows the code to work as well. In what cases is an argument automatically coerced into a borrowed instance?
I'm pretty sure this is a bug. I'll have a look.
In what cases is an argument automatically coerced into a borrowed instance?
Right now, when:
when calling a method on it (the this argument will be a borrow)
when passing to an argument of type C or borrowed C (which mean the same).
when passing to a totally generic function argument.
I'm not sure if we're going to keep rule 3 or not. But that's not the problem in your case - rather the problem is that some compiler-introduced code implementing the forall statement taking away the owned value. That's a bug.
Related
How to get template function from so/dll?
I tried:
Library libdll;
T abc(T)();
static this()
{
libdll = Library("libs/libdll.so");
abc = cast(typeof(abc)) libdll.loadSymbol!(typeof(abc))("dll.abc");
//abc();
}
But then the type of abc is determined as void.
I get error in the compilation:
Error: expression `cast(void)dlsym(this.handle, toStringz(cast(const(char)[])m))` is `void` and has no value
m - is the mangled name of dll.abc.
Templates in D are a compile-time-only construct, and don't exist in sos/dlls. Specific instances end up in the so, but only those that are used there. In other words, if you have this code in the so/dll:
module dll;
T abc(T)() {
T result = void;
return result;
}
void use() {
auto var = abc!int();
}
You should be able to get dll.abc!int.abc (mangled name _D3dll__T3abcTiZQhFNaNbNiNfZi) from the so/dll.
If you want to call abc with some other type, like abc!string, you're out of luck - the code just doesn't exist.
That covers the feasibility. If you only want a specific instance you know has been instantiated, there's another issue at work here, which is the use of typeof(abc). Again, abc is a compile-time thing, and doesn't have a type. The compiler, confusingly, returns void for typeof(abc), giving you the error message is `void` and has no value.
abc!int is a function, and does have a type (pure nothrow #nogc #safe int()), so using that should work. As hinted at above, the name would be dll.abc!int.abc (it's an eponymous template, hence the repeated name).
TL;DR: If you want a specific instance of the template, and that has been instantiated in the so/dll, this code should work (but has not been tested):
Library libdll;
T abc(T)();
static this()
{
libdll = Library("libs/libdll.so");
abc = cast(typeof(abc!int)) libdll.loadSymbol!(typeof(abc!int))("dll.abc!int.abc");
abc();
}
I noticed that I get the same effect if I define this trivial function:
fun double ( i: Int ) = i*2
and if I define a variable and assign a lambda (with an identical body) to it:
var double = { i : Int -> i*2 }
I get the same result if I call double(a) with either declaration.
This leaves me confused. When is it needed, recommended, advantageous to define a variable as a lambda rather than define a function to it?
When is it needed, recommended, advantageous to define a variable as a lambda rather than define a function to it?
Whenever you have the choice of either, you should use a fun declaration. Even with a fun you can still get a first-class callable object from it by using a function reference.
On the JVM, a fun is significantly more lightweight, both in terms of RAM and invocation overhead. It compiles into a Java method, whereas a val compiles into an instance field + getter + a synthetic class that implements a functional interface + a singleton instance of that class that you must fetch, dereference, and invoke a method on it.
You should consider a function-typed val or var only when something is forcing you to do it. One example is that you can dynamically replace a var and effectively change the definition of the function. You may also receive function objects from the outside, or you may need to comply with an API that needs them.
In any case, if you ever use a function-typed property of a class, you'll know why you're doing it.
First, if I understand you right, your question is "Why are functions first-class citizens in Kotlin -- And when to use them as such?", right?
Kotlin functions are first-class, which means that they can be stored in variables and data structures, passed as arguments to and returned from other higher-order functions. You can operate with functions in any way that is possible for other non-function values. (see here)
As stated in the docs, one use case are higher-order functions. As a first step, I will leave the wikipedia link here: https://en.wikipedia.org/wiki/Higher-order_function
Basically, a higher-order function is a function that takes functions as parameters, or returns a function.
This means that a higher-order function has at least one parameter of a function type or returns a value of a function type.
Following a short example of a higher-order function that receives a parameter of function type (Int) -> Boolean:
fun foo(pred: (Int) -> Boolean) : String = if(pred(x)) "SUCCESS" else "FAIL"
This higher-order function can now be called with any (Int) -> Boolean function.
The docs also state ... [can be used] in any way that is possible for other non-function values.
This means that you can, for example, assign different functions to a variable, depending on your current context.
For example:
// This example is verbose on purpose ;)
var checker: (Int) -> Boolean
if (POSITIVE_CHECK) {
checker = { x -> x > 0 } // Either store this function ...
} else {
checker = { x -> x < 0 } // ... or this one ...
}
if (checker(someNumber)) { // ... and use whatever function is now stored in variable "checker" here
print("Check was fine")
}
(Code untested)
You can define variable and assign it lambda when you want change behaviour for some reason. For example, you have different formula for several cases.
val formula: (Int) -> Int = when(value) {
CONDITION1 -> { it*2 }
CONDITION2 -> { it*3 }
else -> { it }
}
val x: Int = TODO()
val result = formula(x)
If you simply need helper function, you should define it as fun.
If you pass a lambda as a parameter of a function it will be stored in a variable. The calling application might need to save that (e.g. event listener for later use). Therefore you need to be able to store it as a variable as well. As said in the answer however, you should do this only when needed!
For me, I would write the Lambda variable as followed:
var double: (Int) -> Int = { i -> //no need to specify parameter name in () but in {}
i*2
}
So that you can easily know that its type is (i: Int) -> Int, read as takes an integer and returns an integer.
Then you can pass it to somewhere say a function like:
fun doSomething(double: (Int) -> Int) {
double(i)
}
In the following code, I'm trying to create a "function pointer" and an array of functions by regarding function names as usual variables:
proc myfunc1() { return 100; }
proc myfunc2() { return 200; }
// a function variable?
var myfunc = myfunc1;
writeln( myfunc() );
myfunc = myfunc2;
writeln( myfunc() );
// an array of functions?
var myfuncs: [1..2] myfunc1.type;
writeln( myfuncs.type: string );
myfuncs[ 1 ] = myfunc1;
myfuncs[ 2 ] = myfunc2;
for fun in myfuncs do
writeln( fun() );
which seems to be working as expected (with Chapel v1.16)
100
200
[domain(1,int(64),false)] chpl__fcf_type_void_int64_t
100
200
So I'm wondering whether the above usage of function variables is legitimate? For creating an array of functions, is it usual to define a concrete function with desired signature first and then refer to its type (with .type) as in the above example?
Also, is it no problem to treat such variables as "usual" variables, e.g., pass them to other functions as arguments or include them as a field of class/record? (Please ignore these latter questions if they are too broad...) I would appreciate any advice if there are potential pitfalls (if any).
This code is using first class function support, which is prototype/draft in the Chapel language design. You can read more about the prototype support in the First-class Functions in Chapel technote.
While many uses of first-class functions work in 1.16 and later versions, you can expect that the language design in this area will be revisited. In particular there isn't currently a reasonable answer to the question of whether or not variables can be captured (and right now attempting to do so probably results in a confusing error). I don't know in which future release this will change, though.
Regarding the myfunc1.type part, the section in the technote I referred to called "Specifying the type of a first-class function" presents an alternative strategy. However I don't see any problem with using myfunc1.type in this case.
Lastly, note that the lambda support in the current compiler actually operates by creating a class with a this method. So you can do the same - create a "function object" (to borrow a C++ term) - that has the same effect. A "function object" could be a record or a class. If it's a class, you might use inheritance to be able to create an array of objects that can respond to the same method depending on their dynamic type. This strategy might allow you to work around current issues with first class functions. Even if first-class-function support is completed, the "function object" approach allow you to be more explicit about captured variables. In particular, you might store them as fields in the class and set them in the class initializer. Here is an example creating and using an array of different types of function objects:
class BaseHandler {
// consider these as "pure virtual" functions
proc name():string { halt("base name called"); }
proc this(arg:int) { halt("base greet called"); }
}
class HelloHandler : BaseHandler {
proc name():string { return "hello"; }
proc this(arg:int) { writeln("Hello ", arg); }
}
class CiaoHandler : BaseHandler {
proc name():string { return "ciao"; }
proc this(arg:int) { writeln("Ciao ", arg); }
}
proc test() {
// create an array of handlers
var handlers:[1..0] BaseHandler;
handlers.push_back(new HelloHandler());
handlers.push_back(new CiaoHandler());
for h in handlers {
h(1); // calls 'this' method in instance
}
}
test();
Yes, in your example you are using Chapel's initial support for first-class functions. To your second question, you could alternatively use a function type helper for the declaration of the function array:
var myfuncs: [1..2] func(int);
These first-class function objects can be passed as arguments into functions – this is how Futures.async() works – or stored as fields in a record (Try It Online! example). Chapel's first-class function capabilities also include lambda functions.
To be clear, the "initial" aspect of this support comes with the caveat (from the documentation):
This mechanism should be considered a stopgap technology until we have developed and implemented a more robust story, which is why it's being described in this README rather than the language specification.
I am a groovy beginner.
I am confused that whether 'def' is used.
def str = "hello"
print str
vs
str = "hello"
print str
From this example. the result is same.But I wonder if they are different.
And are there other situations are different?
Second example is only valid if you are working with scripts. See 3.2 Script class here.
Without def variable is stored in Script's binding, and works as a "global" variable in that script.
If you define variable with def it will be a local variable of Script's run method, and follow all rules of local variable. This difference doesn't really matter if you work with one script.
Difference can be illustrated with following snippet:
def closureA = { println(a) }
def closureB = { println(b) }
a = "I'm global"
def b = "I'm local"
println(a) // prints "I'm global"
println(b) // prints "I'm local"
closureA() // prints "I'm global"
closureB() // throws groovy.lang.MissingPropertyException: No such property: b
Here I first declare 2 closures (anonymous functions). Note, that at declaration time neither a nor b is declared, and therefore not accessible for closures. It's fine.
Then I call println directly after declaration, and in that case I'm in the same scope with both a and b. I'm able to print their value.
Next I call closures. Both closure check local scope, and if variable is not found there, they check bindings. And here is the difference: a is accessible, while b - not.
I am trying to understand how you return non-primitives (i.e. types that do not implement Copy). If you return something like a i32, then the function creates a new value in memory with a copy of the return value, so it can be used outside the scope of the function. But if you return a type that doesn't implement Copy, it does not do this, and you get ownership errors.
I have tried using Box to create values on the heap so that the caller can take ownership of the return value, but this doesn't seem to work either.
Perhaps I am approaching this in the wrong manner by using the same coding style that I use in C# or other languages, where functions return values, rather than passing in an object reference as a parameter and mutating it, so that you can easily indicate ownership in Rust.
The following code examples fails compilation. I believe the issue is only within the iterator closure, but I have included the entire function just in case I am not seeing something.
pub fn get_files(path: &Path) -> Vec<&Path> {
let contents = fs::walk_dir(path);
match contents {
Ok(c) => c.filter_map(|i| { match i {
Ok(d) => {
let val = d.path();
let p = val.as_path();
Some(p)
},
Err(_) => None } })
.collect(),
Err(e) => panic!("An error occurred getting files from {:?}: {}", pa
th, e)
}
}
The compiler gives the following error (I have removed all the line numbers and extraneous text):
error: `val` does not live long enough
let p = val.as_path();
^~~
in expansion of closure expansion
expansion site
reference must be valid for the anonymous lifetime #1 defined on the block...
...but borrowed value is only valid for the block suffix following statement
let val = d.path();
let p = val.as_path();
Some(p)
},
You return a value by... well returning it. However, your signature shows that you are trying to return a reference to a value. You can't do that when the object will be dropped at the end of the block because the reference would become invalid.
In your case, I'd probably write something like
#![feature(fs_walk)]
use std::fs;
use std::path::{Path, PathBuf};
fn get_files(path: &Path) -> Vec<PathBuf> {
let contents = fs::walk_dir(path).unwrap();
contents.filter_map(|i| {
i.ok().map(|p| p.path())
}).collect()
}
fn main() {
for f in get_files(Path::new("/etc")) {
println!("{:?}", f);
}
}
The main thing is that the function returns a Vec<PathBuf> — a collection of a type that owns the path, and are more than just references into someone else's memory.
In your code, you do let p = val.as_path(). Here, val is a PathBuf. Then you call as_path, which is defined as: fn as_path(&self) -> &Path. This means that given a reference to a PathBuf, you can get a reference to a Path that will live as long as the PathBuf will. However, you are trying to keep that reference around longer than vec will exist, as it will be dropped at the end of the iteration.
How do you return non-copyable types?
By value.
fn make() -> String { "Hello, World!".into() }
There is a disconnect between:
the language semantics
the implementation details
Semantically, returning by value is moving the object, not copying it. In Rust, any object is movable and, optionally, may also be Clonable (implement Clone) and Copyable (implement Clone and Copy).
That the implementation of copying or moving uses a memcpy under the hood is a detail that does not affect the semantics, only performance. Furthermore, this being an implementation detail means that it can be optimized away without affecting the semantics, which the optimizer will try very hard to do.
As for your particular code, you have a lifetime issue. You cannot return a reference to a value if said reference may outlive the value (for then, what would it reference?).
The simple fix is to return the value itself: Vec<PathBuf>. As mentioned, it will move the paths, not copy them.