diff options
Diffstat (limited to 'docs/book/INTEROP.html')
| -rw-r--r-- | docs/book/INTEROP.html | 54 |
1 files changed, 25 insertions, 29 deletions
diff --git a/docs/book/INTEROP.html b/docs/book/INTEROP.html index 306de70..339e9c7 100644 --- a/docs/book/INTEROP.html +++ b/docs/book/INTEROP.html @@ -7,7 +7,7 @@ <!-- Custom HTML head --> - + <meta name="description" content=""> <meta name="viewport" content="width=device-width, initial-scale=1"> <meta name="theme-color" content="#ffffff"> @@ -178,27 +178,39 @@ <p>! This section is a <strong>draft</strong>. Many important details have yet to be ironed out.</p> </blockquote> <p>A major goal of Puck is <em>minimal-overhead language interoperability</em> while maintaining type safety.</p> +<h2 id="the-problems-of-interop"><a class="header" href="#the-problems-of-interop">The problems of interop</a></h2> <p>There are three issues that complicate language interop:</p> <ol> -<li>Conflicting memory management systems, i.e. Boehm GC vs. reference counting</li> -<li>Conflicting type systems, i.e. Python vs. Rust</li> <li>The language of communication, i.e. the C ABI.</li> +<li>Conflicting type systems, i.e. Python vs. Rust</li> +<li>Conflicting memory management systems, i.e. tracing / reference counting vs. ownership</li> </ol> -<p>For the first, Puck uses what amounts to a combination of ownership and reference counting: and thus it is exchangeable in this regard with Nim (same system), Rust (ownership), Swift (reference counting), and many others. (It should be noted that ownership systems are broadly compatible with reference counting systems).</p> -<p>For the second, Puck has a type system of similar capability to that of Rust, Nim, and Swift: and thus interop with those languages should be straightforward for the user. Its type system is strictly more powerful than that of Python or C, and so interop requires additional help. Its type system is equally as powerful as but somewhat orthogonal to Java's, and so interop is a little more difficult.</p> -<p>For the third, Puck is being written at the same time as the crABI ABI spec is in development. crABI promises a C-ABI-compatible, cross-language ABI spec, which would <em>dramatically</em> simplify the task of linking to object files produced by other languages. It is being led by the Rust language team, and both the Nim and Swift teams have expressed interest in it, which bodes quite well for its future.</p> -<p>Languages often focus on interop from purely technical details. This <em>is</em> very important: but typically no thought is given to usability (and often none can be, for necessity of compiler support), and so using foreign function interfaces very much feel like using <em>foreign</em> interfaces. Puck attempts to change that.</p> +<p>For the first, Puck is being written at the same time as the crABI ABI spec is in development. crABI promises a C-ABI-compatible, cross-language ABI spec: which would <em>dramatically</em> simplify the task of linking to object files produced by other languages (so long as languages actually conform to the ABI). It is being led by the Rust language team, and both Nim and Swift developers have expressed interest in it, which bodes quite well for its future.</p> +<p>For the second, Puck has a type system of similar capability to that of Rust, Nim, and Swift: and thus interop with those languages should be a straightforward exchange of types. Its type system is strictly more powerful than that of Python or C, and so interop requires additional help. Its type system is equally as powerful as but somewhat orthogonal to Java's, and so interop will be a little more difficult.</p> +<p>For the third: Puck uses what amounts to a combination of ownership and reference counting: and thus it is exchangeable in this regard with Rust. Nim and Swift, by contrast, use reference counting: which is not directly compatible with ownership, as attempting to use an owned type as a GC'd reference will immediately lead to a use-after-free. Puck may have to explore some form of gradual typing at linking-time to accommodate making its functions available for use. Using functions from GC'd languages, however, is perfectly doable with the <code>refc</code> type: though this may necessitate copying object graphs over the call boundary.</p> +<p>There is additional significant work being put into the use of Wasm as a language runtime. Wasm allows for - among other things - the <em>sharing</em> of garbage collectors, which means that any garbage-collected language compiling to it can simply use the primitive <code>refc</code> type to denote a garbage-collected reference. This does not, however, immediately work off the bat with ownership: as ownership necessitates certain invariants that garbage collection does not preserve. There is active research into fixing this: notably RichWasm, which retrofits a structural type system with ownership atop Wasm. Such extensions necessitate the runtime environment to implement them, however, and so Puck may have to explore some form of gradual typing for the broader Wasm ecosystem.</p> +<h2 id="usability"><a class="header" href="#usability">Usability</a></h2> +<pre><code class="language-puck">use std.io +use rust.os.linux +use nim.os.sleep +... +</code></pre> +<p>Languages often focus on interop from purely technical details. This <em>is</em> very important: but typically little thought is given to usability (and often none can be, for necessity of compiler support), and so using foreign function interfaces very much feel like using <em>foreign</em> function interfaces. Puck attempts to change that.</p> +<pre><code class="language-puck">@[form(this-function)] +pub func this_function() = ... +</code></pre> +<p>A trivial concern is that identifiers are not always the same across languages: for example, in Racket <code>this-function</code> is a valid identifier, while in Puck the <code>-</code> character is disallowed outright. Matters of convention are issues, too: in Puck, <code>snake_case</code> is preferred for functions and <code>PamelCase</code> for types, but this is certainly not always the case. Puck addresses this at an individual level by attributes allowing for rewriting: and at a language level by consistent rewrite rules.</p> <p>...todo...</p> +<hr /> <p>Existing systems to learn from:</p> <ul> <li><a href="https://doc.rust-lang.org/reference/abi.html">The Rust ABI</a></li> -<li>https://www.hobofan.com/rust-interop/</li> +<li><a href="https://www.hobofan.com/rust-interop/">rust-interop</a></li> <li><a href="https://github.com/eqrion/cbindgen">CBindGen</a></li> -<li>https://github.com/chinedufn/swift-bridge</li> -<li>https://kotlinlang.org/docs/native-c-interop.html</li> -<li>https://github.com/crackcomm/rust-lang-interop</li> -<li>https://doc.rust-lang.org/reference/abi.html</li> -<li>https://doc.rust-lang.org/reference/items/functions.html#extern-function-qualifier</li> +<li><a href="https://github.com/chinedufn/swift-bridge">swift-bridge</a></li> +<li><a href="https://kotlinlang.org/docs/native-c-interop.html">Kotlin C interop</a></li> +<li><a href="https://github.com/crackcomm/rust-lang-interop">rust-lang-interop</a></li> +<li><a href="https://doc.rust-lang.org/reference/items/functions.html#extern-function-qualifier">extern in Rust</a></li> <li><a href="https://github.com/yglukhov/nimpy">NimPy</a></li> <li><a href="https://github.com/yglukhov/jnim">JNim</a></li> <li><a href="https://github.com/PMunch/futhark">Futhark</a></li> @@ -228,22 +240,6 @@ </div> - <!-- Livereload script (if served using the cli tool) --> - <script> - const wsProtocol = location.protocol === 'https:' ? 'wss:' : 'ws:'; - const wsAddress = wsProtocol + "//" + location.host + "/" + "__livereload"; - const socket = new WebSocket(wsAddress); - socket.onmessage = function (event) { - if (event.data === "reload") { - socket.close(); - location.reload(); - } - }; - - window.onbeforeunload = function() { - socket.close(); - } - </script> |