Rescript-compiler: [proposal] introduce cpp style macros for FFI

[bobzhang]

Note macros/template languages are a leaky abstraction, however, it is really tedious to write those externals, here is my proposal, ship a cppo style pre-processor, however, the build system always ask users to check in the generated files, so yeah, it is leaky abstraction, but we don't try to hide it from users, from user side, it looks like written by human, from developer side, it is just a way of save typing and typos, for example:

#define EVENT(p, ty) external on_##p : (_ [@bs.as #p]) -> (ty [@bs.uncurry]) = "on" [@@bs.send.pipe: t]
EVENT(close, unit -> unit)
EVENT(beforeExit, unit -> unit  )

Which generates code below:

external on_close : (_ [@bs.as "close"]) -> (unit -> unit [@bs.uncurry]) = "on" [@@bs.send.pipe: t]
external on_beforeExit : (_ [@bs.as "beforeExit"]) -> (unit -> unit [@bs.uncurry]) = "on" [@@bs.send.pipe: t]

[OvermindDL1]

Useful, but tokenization macros can be 'surprisingly turing complete' if recursion is allowed, so unsure how like the C macros you want them to be. ^.^

Honestly, I'd say making a proper AST macro system would be best, but also more work, however I could imagine something like:

let%macro define_event p ty =
  let%quote quoted = external on_(unquote_inplace (string_of_ast p)) : (_ [@bs.as (unquote p)]) ->((unquote ty) [@bs.uncurry]) = "on" [@@bs.send.pipe: t]
  in quoted

define_event close (unit -> unit)
define_event beforeExit (unit -> unit)

Or something like that. Such a thing as this would be type safe even at macro generation time while also affording a rather tremendous amount of power, especially in such as opening a, say, typescript definition file and auto-generating an interface or so...

[bobzhang]

The application of such macro is just FFI, it is not designed to be generally useful.
When macros become powerful, people would abuse it, and we know, macro is leaky abstraction.

[email protected] At: 04/20/17 10:21:23" data-digest="From: [email protected] At: 04/20/17 10:21:23" style="">
From: [email protected] At: 04/20/17 10:21:23
To: [email protected]
Cc: HONGBO ZHANG (BLOOMBERG/ 731 LEX), [email protected]
Subject: Re: [bloomberg/bucklescript] [proposal] introduce cpp style macros for FFI (#1562)

Useful, but tokenization macros can be 'surprisingly turing complete' if recursion is allowed, so unsure how like the C macros you want them to be. ^.^
Honestly, I'd say making a proper AST macro system would be best, but also more work, however I could imagine something like:
let%macro define_event p ty =
let%quote quoted = external on_(unquote_inplace (string_of_ast p)) : (_ [@bs.as (unquote p)]) ->((unquote ty) [@bs.uncurry]) = "on" [@@bs.send.pipe: t]
in quoted

define_event close (unit -> unit)
define_event beforeExit (unit -> unit)
Or something like that. Such a thing as this would be type safe even at macro generation time while also affording a rather tremendous amount of power, especially in such as opening a, say, typescript definition file and auto-generating an interface or so...
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.

[yunxing]

A simple macros implementation is very useful for boilerplate FFI declaration.

Instead of implementing a new one, I wonder if it's possible to use existing libraries like cppo?

[bobzhang]

@yunxing I plan to provide a customized cppo (some features are not needed, like conditional compilation, and need add some new features)

[bsansouci]

My use case for this would be cross platform compilation:

#if NATIVE {
  include ReasonglNative;
}

#if WEB {
  include ReasonglWeb;
}

So really, all I need is this to be a commandline tool (like bspack) and I'd use the shit out of it.

@OvermindDL1 I would actually not mind if it was a _dead simple_ string replacement or something. Because that's 90% of what I need most of the time.

[ul]

As an alternative, we could design and implement tool which would expand external definitions with optional argument and multiple types of arguments (like for this https://nodejs.org/api/buffer.html#buffer_buf_fill_value_offset_end_encoding) into several regular externals. Because this case is more hard and error prone than example with events you've described, which could be done okay and quite robust by plain copy-paste and leveraging several editing feature present in any modern code editor.

Though both tools are quite orthogonal, both are good to have.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.