vickenty / perl-xs Goto Github PK

Review and make a list of SV, AV, HV methods that exist in XS, but are not yet supported.

Add support for glob values.

It might be possible to safely borrow string buffer of an SV if it is uniquely owned - reference count is 1 and there are no weak references. At least newly created SVs should allow this.

Wrap newAV and newHV.

There are four functions to call into Perl in XS, of which only one is currently supported.

• I32 call_sv(SV* sv, I32 flags);
• I32 call_pv(char *subname, I32 flags);
• I32 call_method(char *methname, I32 flags);
• I32 call_argv(char *subname, I32 flags, char **argv);

What would be the best way to represent different combinations of flags? Some of them are mutually exclusive, others depend on other flags.

A further improvement can be a macro that hides different ways to call a sub, and handles argument passing, something like:

call!(ctx, sub_sv, a, b, c);
call!(ctx, "Foo::name", a, b, c);
call!(ctx, sv->"name", a, b, c);
call!(ctx, sv->method_sv, a, b, c);

Allow blessing Rust values into Perl objects.

Allocate struct on the heap.
Construct a SV with a pointer.
Register destructor in the SV's magic table.

Add a wrapper for newCONSTSUB and add support for it to xs! macro.

xs! {
     package Foo;
     const FOO = "hello";
}

store for tied AV and HV needs to do refcnt_dec if tied object did not store the value. This is implemented, but not tested.

Objectives:

1. Export functions to perl which contain optional arguments.
2. Make argument handling more magical
3. Move toward more idiomatic rust conventions for function binding

At present, the xs! macro is unable to handle Option arguments which may be omitted by the perl caller.

I propose that we do away with the xs! macro_rules in favor of a procedural function attribute macro, similar to wasm_bindgen or the pyo3 crate.

Proposed syntax:

//lib.rs:
mod bar;
mod blah;
perl_base_module!("Foo")

//bar.rs
#[perl]
fn alpha (maybe: Option<Something>){}

//blah.rs
#[perl]
fn beta (definitely: Something){}

By doing this as a procedural macro, this will also improve the ability to perform smarter argument handling / coercion, including derive structs, optional context argument, etc.

The goal here is to have a perfectly ordinary rust function be callable from within perl with little or no special accommodation for the perl guts, at least in some circumstances.

Rust programs will print a message to standard output every time a panic happens in a program. We use panics to propagate perl croaks through rust part of the stack - this is internal detail and the messages produced are not useful to the user. These messages can be disabled by installing a custom panic handler.

Should it be installed globally from a module bootstrap routine, or locally every time a sub is called?

• Methods that wrap XS should quote and link relevant section of perlapi.
• Convenience methods that were added on top of XS need better, more complete documentation.
• Top-level crate documentation should describe library usage and give examples.