Even worse, it checks the git history to make sure that...

- 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/...

lol, what did they smoke to think that's reasonable?!

It’s their language, they can do as they wish.

That doesn't make it any more reasonable.

No one is contesting the physical ability, just the wisdom.

Permalink https://github.com/gren-lang/compiler/blob/e665e521367eeedec...

Wild. Do you know why is that code here?

that stuff gets run on every compile (transpile?)? yet it seems that any would-be forker could easily remove that stuff? surely this must all be an elaborate gag or something.

Only on the first compile. It doesn’t perform this check when loading a package from the build cache.

Correct me if I'm wrong, but that code seemingly only applies to kernel packages, i.e. packages which are made by the gren team [1]

Seems more like a check to make sure the version of the JS is compatible with the version of gren than anything else.

[1] https://github.com/gren-lang/compiler/blob/e665e521367eeedec...

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.

Edit: EdwardDiego's answer clarified this for me

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.

That's only for their "kernel code" though, right? Huh, yeah, looks like it bans non-Elm(Gren) code [0].

And found a great bug where it broke their own code. [1]

[0]: https://github.com/gren-lang/compiler/blob/main/docs/kernel_...

[1]: https://github.com/gren-lang/compiler/issues/203

It baffles me why anyone would fork Elm just to recreate one of it’s greatest mistakes.

Not even recreate, make the same mistake but even more intensely. It's impressive, in some ways.

I think this is an unfair opinion of Gren.

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.

That’s the plan

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.

No. In fact I added some code that still enforces this with the Git-based package manager.

I know a lot of people got burned by this when Elm added this enforcement, and that seeing it here in Gren can cause a lot of eyerolls.

However.

The greatest feature of the language is the absence of mutation and user-defined exceptions, and managed side-effects. Making the kernel code api accessible to everyone would introduce those things to the language, and my memory from the pre 0.19 days of Elm tells me that this made for a worse experience overall.

One of the problems with this limitation is the lack of bindings to core web api’s. We’re actively working on adding more APIs here. LocalStorage was contributed by an external contributor. Contributors are also working on a HttpServer and a WebSocket API now.

And that’s another «change» worth noting when comparing with Elm. We have scheduled releases (June and December) and are more open to contributions.

Why couldn't you make it just a warning, or even require a command-line flag for it? As it is now, even trying to write and test a PR for any such code requires modifying the compiler.

The kernel code API is quite… unfinished. It isn’t documented, it performs no validation and it crashes the compiler when written incorrectly. It really isn’t ready for general use. It’s also expected to break in the next few releases.

I will have to revisit kernel code at some point in the future, probably when looking into WASM (which will break all uses of kernel code), but I have other, more important, features to add first.

As the sibling commenter says, maybe it’s worth reconsidering the approach somewhat?

As in, I do get the reasoning, but there are valid situations where one might need to do this for their own reasons. So maybe there’s some way to make it clear that you shouldn’t be doing this, yet still narrowly allow it. A non-default CLI flag, a scary compilation warning, maybe needs to use some special keyword to use code like that. Like how you need to use ‘unsafe’ in Rust to interact with C code directly.

Otherwise, thank you for working on this! An Elm inspired language that’s open to community development is something the world needed :-D

Yeah. I understand the need for this, but I’m also very hessitant to break guarantees on mutation and other side effects. It’s a tricky problem.

It will be looked at pre 1.0.

> my memory from the pre 0.19 days of Elm tells me that this made for a worse experience overall

My memory tells me that 0.19 literally killed the language.

As is often the case with one's memory, it bears a grain of truth but distorts reality. I've been using Elm 0.19 for side projects and enjoy it.

Regardless of the details here: Thank you so much for taking the time to come here and explain your decisions, without getting offended or overly defensive.

Those links you provided seem to have nothing to do with "whitelist of projects allowed to use native code". Can you be more specific about what you're referring to?

The articles linked by each of those posts contain numerous references to "native modules" and "kernel code".

To be fair: you can definitely call JS from Elm/Gren using ports, which exposes the JS world as an async service you can call. This seperation means you lose none of the guarantees of the language, while being able to communicate with the outside world. Kernel code is completely unprotected, and would allow mutations, exceptions and side-effects in "Elm world".

The main problem with ports is that (1) it's an async API, which can be awkward for certain operations and (2) you cannot define a package that contains ports.