In the past, while using Elm, if you wanted to support some browser API that Elm didn't support yet you would have to fallback to kernel code. What Elm wanted: a core package that provided this low-level kernel package that provided typesafety at the Elm level. But as we know, this was a pipe dream because you could never contribute to Elm unless it was from the Elm dictator itself, or from his inner circle of cool people.
It seems like Gren is already ahead of this. Gren has community members actively working on the Websocket API to provide a typesafe core package with Kernel bindings.
The question is: will Gren keep being open to contributors that can provide kernel code.
There are certain operations that only "kernel" packages are allowed to do. If that weren't the case, then this would indeed be little more than an obscure quirk.
Ah I see. So non-kernel packages do not have access to native modules at all? I believe in Elm native modules were still possible, just not publishing them to the package database. But in this case I guess you wouldn't be able to put a native module in a GitHub repository and then pull this in as a dependency, which is equally rubbish.
Elm doesn’t allow kernel code in externel packages. Gren is performing the exact same check, it’s just that Gren uses Git as a package manager and so has to do it in a different way.
Meet the new boss same as the old boss.
Its a shame really. Elm seemed so promising a few years ago. I still like the ideas behind the project but the history of Elm is not confidence inspiring.
that stuff gets run on every compile (transpile?)? yet it seems that any would-be forker could easily remove it? surely this must all be an elaborate gag or something.
- There are no changes since HEAD
- The commit is signed by Robin himself
...and for those interested in the code that does this
https://github.com/gren-lang/compiler/blob/main/builder/src/...