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.
Gren currently has three hard-coded platforms:
browser,nodeandcommon.The
commonplatform is really just a way of saying that you're platform agnostic. In practice, it means you cannot havegren-lang/browserorgren-lang/nodein your dependency tree. Code that targetcommon, however, can be used as dependencies innodeorbrowserprojects.The
browserplatform essentially means that you will havegren-lang/browserin your list of dependencies, and that you wont havegren-lang/nodeas a dependency.The
nodeplatform means the inverse.gren-lang/nodeis a dependency, andgren-lang/browseris 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.jsongren.jsonrequires you to specify which platform you're targetting using theplatformfield. 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/nodeas dependencies at the same time.For applications, we'll figure out the target platform based on your dependencies. Applications that include
gren-lang/browsertargets thebrowserplatform.Platform packages will probably define their own
Tasktagged union, which will be a superset of theTaskdefinition ingren-lang/core. They are also likely to make their own version ofPlatform.workerthat resolves their ownTasktype.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/browserandgren-lang/nodehas 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.