[UR] local storage inside function

[nicolasboulay]

It could be great to have local storage that are unique by function call site (like Lustre does).

This reduce the need for dynamique memory and it's much easier than doing it by hand. This is also great for real time application, or application that refuse dynamic memory (for security, safety or speed reason).

[pnkfelix]

have you considered expressing this via a macro?

[nicolasboulay]

No, i'm new to rust. Maybe if the macros control a call site, this could be possible to allocate a memory at the beginning and use it after.

Macro looks complex, a little bit as the template in C++. Is it a new langage or an extension of normal rust langage to be executed at compile time ?

[pnkfelix]

@nicolasboulay my thinking was that the function call sites would use be a macro invocation that would expand into the code for allocating and passing along the state you want.

But this may not be as easy as I originally thought, since I hadn't considered how to allocate the per-call-site storage. (Also, I'm not familiar with Lustre, so I might be misinterpreting what your feature request actually is. You may want to consider providing a bit more information, i.e. a concrete example of a piece of code showing how you'd be forced to write X today, and how you would write X after adding this feature.)

As for your question, the macro system is still a volatile feature of rust. There is macro_rules! for doing macro-by-example that is sort of like Scheme syntax-rules style macros. There is also a procedural macro system that landed recently (#11151) that I am less familiar with.

[alexcrichton]

I think that we have this today in the form of local_data and its related macros:

use std::local_data;
fn foo() {
    local_data_key!(foo: uint);
    local_data::get(foo, |val| { ... });
    local_data::set(foo, 4);
}

And the key foo is scoped to just the function that it was defined in.

I'm closing for now, but please feel free to reopen if I misunderstand!

[zkamsler]

I have done a little reading on Lustre, which is a dataflow language. It does not have functions as such, but rather 'nodes' that can store some local variables as well as the previous values of parameters and outputs. Data is not local to the call site as such, but rather to the node in the graph. (http://rw4.cs.uni-saarland.de/teaching/esd07/papers/lustre.pdf)

As such, it should be relatively straightforward (if tedious) to achieve a similar effect by making a struct with the desired data, and making a method on that. As long as there are no cycles, calls to other nodes can be represented by nesting structs.

@alexcrichton, it is not what you thought it was, but I am not sure it is anything that needs to be specifically added to Rust.

[alexcrichton]

Sounds like I shouldn't have closed it!

[nicolasboulay]

For example in signal processing, pid controller is quite common code : ( https://en.wikipedia.org/wiki/PID_controller )

double pid(double e, double P, double I, double D){
static double i, past_error;
err = e-s;
i += err;
d = error - past_error;
past_error = error;
return P_e+I_i+D*d;
} //P I D are fix parameter

It's not possible to reuse this code. Typical code will need to allocate "i" and "past_error" "somewhere"', before the call.

double pid(double e, double P, double I, double D, double * I, double * past_error){
err = e-s;
(_i) += err;
d = error - (_past_error);
(past_error) = error;
return P_e+I(_i)+D*d;
}

The code is more complexe, it add some data management in some init fonction.

[steveklabnik]

I'm pulling a massive triage effort to get us ready for 1.0. As part of this, I'm moving stuff that's wishlist-like to the RFCs repo, as that's where major new things should get discussed/prioritized.

This issue has been moved to the RFCs repo: rust-lang/rfcs#795