Custom platforms

Gren currently has three hard-coded platforms: browser, node and common.

The common platform is really just a way of saying that you're platform agnostic. In practice, it means you cannot have gren-lang/browser or gren-lang/node in your dependency tree. Code that target common, however, can be used as dependencies in node or browser projects.

The browser platform essentially means that you will have gren-lang/browser in your list of dependencies, and that you wont have gren-lang/node as a dependency.

The node platform means the inverse. gren-lang/node is a dependency, and gren-lang/browser is not.

It's not possible to add new platforms in Gren, which makes sense, as the only way to add new API's is through kernel code, which can only be used in gren-lang/* packages anyway.

But if proposals like #218, #371 and #372 are implemented, we could lift this restriction, enabling people to create platforms for iOS, Android or even something like Cloudflare workers.

Changes to gren.json

gren.json requires you to specify which platform you're targetting using the platform field. In the future we might remove this field for application type projects, and change it to accept a boolean for package type projects.

For packages, the field will specify if the current package is a platform or not. The user can only ever have one platform as a dependency, so if you specify your package to be a platform, it means the user cannot have your package and gren-lang/browser/gren-lang/node as dependencies at the same time.

For applications, we'll figure out the target platform based on your dependencies. Applications that include gren-lang/browser targets the browser platform.

Platform packages will probably define their own Task tagged union, which will be a superset of the Task definition in gren-lang/core. They are also likely to make their own version of Platform.worker that resolves their own Task type.

Allow platform-less applications

We'll also allow users to create applications without relying on any platform. This would essentially limit you to create "functions" to be embedded in other javascript applications. Might be a good fit for simple scripts, plugins or even for a function-as-a-service runtime like AWS lambda.

Introducing platform APIs

One major advantage built-in platforms like gren-lang/browser and gren-lang/node has is their access to kernel code. Custom platforms built using the changes laid out in this API would essentially be limited to ports for introducing platform-native APIs.

Implementing a safe alternative to kernel code is out of scope for this proposal, but it's something I've been thinking of for a while. Don't be surprised if language proposal on this topic shows up in the future.

Start by reading this proposal alongside issues #218, #371, and #372, which it identifies as prerequisites. Trace how gren.json currently handles the platform field and how gren-lang/browser, gren-lang/node, and gren-lang/core define platform behavior. Done would require an agreed implementation of custom, platform-less, and platform API behavior.