Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Extend support for function calls #46

Open
FL03 opened this issue Feb 18, 2024 · 0 comments
Open

Extend support for function calls #46

FL03 opened this issue Feb 18, 2024 · 0 comments
Assignees
Labels
bug Something isn't working macro Any additions or improvements to procedural macros rust Improvements or additions that update the Rust code
Milestone

Comments

@FL03
Copy link
Owner

FL03 commented Feb 18, 2024

The autodiff procedural macro correctly evaluates logic contained within the macro but cannot handle previously defined logic. Specifically, invoked functions and undefined method_ calls both fail to provide the system with enough information to process the contained logic.

Example

Writing the logic for the sigmoid function within the macro works.

use acme::autodiff;

fn main() {
    let (x, y) = (1_f64, 2_f64);
    assert!(autodiff!(x, 1.0 / (1.0 + (-x).exp())) == 0.1049935854035065);
}

However, invoking a function (or even non-described methods) fails to evaluate correctly since the parsed input fails to store any meaningful information about the function.

use acme::autodiff;
use acme::prelude::sigmoid;

fn main() {
    let (x, y) = (1_f64, 2_f64);
    assert!(autodiff!(x, sigmoid(x)) != 0.1049935854035065);
}

Methods

Traditional macro libraries and methods seem to lack explicit support for engaging with these objects. At initial glance, the problem may require using lower-level Rust libraries to interact with the compiler but support for this is also limited.

Extracting the logic from the SourceFile

One approach would be to use the span of the expression to locate the resource and extract the required information.

Option 2: Rewrite the logic as a #[proc_macro_attribute]

#[gradient]
pub fn multiply<A, B, C>(a: A, b: B) -> C 
where 
    A: std::ops::Mul<B, Output = C> 
{ 
    a * b 
}

By writing a #[proc_macro_attribute] any implemented functions could have a gradient function automatically generated. One of the primary issues with this is that we still run into the issue at hand when any external logic is invoked at any point within the function definition.

Option 3: Create an additional generator which rewrites the function as a closure

@FL03 FL03 added enhancement New feature or request rust Improvements or additions that update the Rust code macro Any additions or improvements to procedural macros labels Feb 18, 2024
@FL03 FL03 added this to the v0.3.0 milestone Feb 18, 2024
@FL03 FL03 self-assigned this Feb 18, 2024
@FL03 FL03 pinned this issue Feb 18, 2024
@FL03 FL03 added bug Something isn't working and removed enhancement New feature or request labels Feb 18, 2024
@FL03 FL03 modified the milestones: v0.3.0, Future Apr 4, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working macro Any additions or improvements to procedural macros rust Improvements or additions that update the Rust code
Projects
None yet
Development

No branches or pull requests

1 participant