Crate bridge_macros

Source
Expand description

TODO PC ISSUE #9 macro crate wish list

  1. The macro should fail if the structure of the docs is not as expected. e.g. Type/Namespace/…/Usage/Example/
  2. type aliasing, need a gensym type macro so I do not conflict with names.
  3. trybuild tests!
  4. worry about inlining, e.g. are the mechanisms in place to do the type conversions constant time, and inlined? or is there a way to make them so?
  5. can yet another crate solve the problem of housing typehandle/passingstyle/param/errorstrings/typedwrapper in the same place?
  6. EVERY macro doesn’t need the check for VarArgs, only signatures that have VarArgs, this can be addressed in the macro.
  7. Port tuple tests: https://github.com/sl-sh-dev/sl-sh/blob/83cd1c93d1eea726ba138a83610155bdbfcab7aa/src/builtins_types.rs#L628
  8. To avoid needing to do lifetimes, if the return value is one of the INPUT values have that marked in the annotation… OTHERWISE data may be copied! OR allow for simple lifetimes?
  9. VMError should not be new_vm
  10. Optional duplicates code. With the ownership model from SlFromRef, being the primary mechanism for crossing the boundary, it’s possible having Some and None blocks multiple times is not necessary.
  11. Support for slices? to avoid Vec allocation? Is it a big deal to only be able to accept Vec? The decision should at least be documented.
  12. SINCE WHEN is it a requirement like that it has to return VMResult or Option

Attribute Macros§

  • sl_sh_fn
    macro that creates a bridge between rust native code and sl-sh code, specify the lisp function name to be interned with the “fn_name” attribute. This macro outputs all of the generated bridge code as well as the original function’s code so it can be used by the generated bridge code.