Better Arrayfire Expressions Syntax

[adamcavendish]

I am thinking of a better way of expressing arrayfire expressions in rust, however still needs some work on the design.

We can create macros describing an arrayfire expressions, like this:

let dims = af::Dim4::new(&[10, 10, 1, 1]);
let a = af::randu(dims, Aftype::F32)
let result = af::expression!(
    |expr, err| println!("'{}' Calculation failure, error: {}", expr, err),
    af::sin(1) / a + a);

let result = af::retry!(
    3,
    |expr, err| println!("'{}' Calcuation failure, error: {}", expr, err),
    af::retry_expression!(af::sin(1) / a + a));

Most of the time I'm quite bored with a lot of and_then appearing in my arrayfire-rust code, and creating a lot of disambiguation in expresstions.

However, the with the error appearing, generally people will:

1. print the error, save the state and calculated results and let it panic. Then, let other daemon scripts restart the program.
2. retry the calculation

[adamcavendish]

Probably similar methods can help clean up expressions into syntax like arrayfire-c / arrayfire-c++

[jramapuram]

This does alleviate a lot of the unwrap() calls all over the place. I like the idea.
One question about the retry mechanism: any reason we need an af:retry_expression! internally? Can't it be handled in the top level macro?

[adamcavendish]

Yeah, I think it'd be possible.

And another idea: setting up arrayfire context (but this might require a lot of work for elegant implementation, if not using global variables)

af::set_error_handling(|expr, err| println!("'{}' Calcuation failure, error: {}", expr, err));
let result = af::sin(1) / a + a;

[9prady9]

@adamcavendish & @jramapuram

I believe the elegant way would be to use something like Compiler syntax extension to parse expressions and process the tokens. I don't think we can do what we want with regular macros in efficient way. If you were referring to compiler plugin earlier, then we are on same page.

You can check out the roman numerals example in the link i provided above and we would have to do something similar in our case except that we would be handling expressions with symbols of type Array's or scalars and ArrayFire functions.

[adamcavendish]

Yep, we might fight for any great impl to make the macro work as expected and most efficient, either ordinary macros or compiler syntax extension.

[jramapuram]

@9prady9 : Can you provide a little code widget for what you would like to use the compiler syntax extension for? I'm guessing it will look something like:

af::register_error_cb(|err| println!("My err was {}", err));
af_parse!(sin(1) / a + a);  //where this macro is implemented via a parse tree

Is that what you had in mind? Any benefit in the parse tree over the simple macro?

Edit: I ask this because af (the c lib) implements a parse tree already, i.e (* or / before + or -, etc)

[9prady9]

@adamcavendish @jramapuram Yes that is similar to what i have in mind. But what i don't understand is how are we going to handle compound expressions in regular macros - the example we have been using sin(1)/a + a? I don't know everything about Rust macros, but i don't think that is possible using regular macros. @jramapuram what do you mean by af(c lib) ? the ArrayFire C-API ?

[jramapuram]

@9prady9 : yes the C library. One easy solution would be if restructured the operator overloads to return a Result<AfErr, Val> type and then do a match internally in the macro. This is of course the naive solution.

So something like this [this doesn't compile]

macro_rules! af_parse {
    ($e: expr) => {{
        match expr {
           Err(e) => //callback,
           Ok(v) => v,
        }
    }} 
}

The key here is that the expression will be evaluated outside and just passed into the macro.
But yea, not quite elegant.

One serious issue from the above is that if the first part does in fact return an AfErr we would be trying to pass that to another function, eg: sin(a) returned an AfErr which would be used in the operator+ which would not allow this. Would modifying the function prototypes to accept a Result<AfErr, Array> instead of an Array resolve this? (as we can directly return the error or just call the callback)

[9prady9]

Yes, they might resolve it but it is generally not a good idea to pass Result objects as input parameters to functions or operators - came to this conclusion after debating/reading a lot on rust user forums. Also, making the functions/operators accept result types will force the library to have two versions for each and every type of operator/function that takes regular Array and Result<Array,..> object, which is lot of redundant code and probably not a good design, especially if we have alternatives. These are the problems i see with using regular macros, hence my opinion of not using them for this situation. If we can't make it work with compiler plugin, we can resort to regular macros.

[jramapuram]

What about just returning an Array from all functions instead of the Result<AfErr, Array> but internally calling the callback when there is an error. This will create a natural breakpoint where the user can manage the error.

[9prady9]

That should work, but we have to do this change for all the functions in the library to be consistent.

[pavanky]

@arrayfire/rust-devel

I am bored and awake late on a weekend, so I started reading a bunch of things (including the options mentioned here).

Here are my thoughts:

• The way arrayfire is implemented, there are very few errors you want to recover from at runtime (for example an out of memory error / backend not available etc). Most other errors should abort the program with the proper message.
• The API in its current form is not going to get a lot of people to scientific programming in rust using arrayfire.
• A few other numerical libraries written in rust are simply ignoring the error handling.

Based on this, I think we should just get rid of returning errors for every function and have the following:

• A function to set an error handler for the rest of the program. If not explicitly set, the error function that panics when it sees an error.
• A function to get last error.
• A macro to handle the error within an expression.

Code would be something like this:

let id = af::set_error_handler(my_default_error_handler)
let a = af::randu(dims, Aftype::f32)
let b = af::sin(a) + 0.01

af_try!(af::set_backend(CPU), af::set_backend(CUDA))

Let me know what you guys think.

[pavanky]

I know this is going to break the API, but better break it now than later.