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

Platform Imports #535

Open
TimWhiting opened this issue May 23, 2024 · 0 comments
Open

Platform Imports #535

TimWhiting opened this issue May 23, 2024 · 0 comments

Comments

@TimWhiting
Copy link
Collaborator

One issue that we have is that the extern syntax while being very nice and flexible is still limiting.

For example you might want to change the implementation based on platform (windows / macos / linux) i.e. for system calls.

Or you might want to change the implementation based on runtime (js / wasm / c / c#). Right now we support the latter but not the former. For wasm you might want to use different apis when it is in a web context (i.e. http requests) versus wasm on the server.

You can do some of this currently by dipping into C code and using defines to distinguish. This is good.

However we still are missing something more fundamental. Take for example the libUV library. It definitely doesn't support JS, and doesn't support WASM either. But if you want to create a library that uses libUV on the desktop, but something else for WASM or JS than you run into issues (that are tricky to work around), since the imports are still there when you are targeting a different platform. The current workaround is to just have empty externs, and deal with warnings from the compiler saying that certain functions aren't implemented for the current backend (even if you never use those functions). This brings up the other problematic aspect - if you just use C defines, and don't support the function for wasm, you still need a stub that kills the process. This increases code size unnecessarily.

Ideally we would have something like:

pub module async implements async-stub
  import async-libuv for runtime.c
  import async-loop for runtime.wasm
  import async-js for runtime.js
pub interface module async-stub
// types
pub type mystruct
  i: int
pub fun hello(i: mystruct): ()

Which at type checking time would ensure that all of the imports implement the module's interface specified in async-stub (which would have common koka types, and function signatures).

And then at compile time we will know which backend we are targeting and select the appropriate import.

For system apis that might look like:

pub module file implements file-stub
  import file-posix for runtime.c; platform.posix
  import file-windows for runtime.c; platform.windows
  import file-js for runtime.js

Where both runtime and platform can be chosen.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant