5 ms·

Did they get rid of the whitelist of projects allowed to use native code (https://news.ycombinator.com/item?id=22821447 https://news.ycombinator.com/item?id=228

Did they get rid of the whitelist of projects allowed to use native code (https://news.ycombinator.com/item?id=22821447 https://news.ycombinator.com/item?id=22821447, https://news.ycombinator.com/item?id=17842400 https://news.ycombinator.com/item?id=17842400, https://news.ycombinator.com/item?id=16510267 https://news.ycombinator.com/item?id=16510267)?

brabel 3y ago
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?
- deleted 3y ago
  [deleted]
- josephcsible 3y ago
  The articles linked by each of those posts contain numerous references to "native modules" and "kernel code". In this context, those things mean the ability to call back into JavaScript from Elm. The ability to do this exists in Elm, but it's locked down so you can't use it.
  - Skinney 3y ago
    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.
aslilac 3y ago
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/Git.hs#L191 https://github.com/gren-lang/compiler/blob/main/builder/src/...
- codetrotter 3y ago
  Permalink https://github.com/gren-lang/compiler/blob/e665e521367eeedec016d70d167386c7cd145929/builder/src/Git.hs#L191 https://github.com/gren-lang/compiler/blob/e665e521367eeedec...
- k__ 3y ago
  lol, what did they smoke to think that's reasonable?!
  - iampims 3y ago
    It’s their language, they can do as they wish.
    - hu3 3y ago
      That doesn't make it any more reasonable.
    - paulddraper 3y ago
      No one is contesting the physical ability, just the wisdom.
- dopidopHN 3y ago
  Wild. Do you know why is that code here?
- adamrezich 3y ago
  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.
  - Skinney 3y ago
    Only on the first compile. It doesn’t perform this check when loading a package from the build cache.
- 3y ago
Skinney 3y ago
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.
- josephcsible 3y ago
  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.
  - Skinney 3y ago
    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.
- jgilias 3y ago
  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

brabel 3y ago

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?

deleted 3y ago
[deleted]
josephcsible 3y ago
The articles linked by each of those posts contain numerous references to "native modules" and "kernel code". In this context, those things mean the ability to call back into JavaScript from Elm. The ability to do this exists in Elm, but it's locked down so you can't use it.
- Skinney 3y ago
  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.

aslilac 3y ago

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/Git.hs#L191 https://github.com/gren-lang/compiler/blob/main/builder/src/...

codetrotter 3y ago
Permalink https://github.com/gren-lang/compiler/blob/e665e521367eeedec016d70d167386c7cd145929/builder/src/Git.hs#L191 https://github.com/gren-lang/compiler/blob/e665e521367eeedec...
k__ 3y ago
lol, what did they smoke to think that's reasonable?!
- iampims 3y ago
  It’s their language, they can do as they wish.
  - hu3 3y ago
    That doesn't make it any more reasonable.
  - paulddraper 3y ago
    No one is contesting the physical ability, just the wisdom.
dopidopHN 3y ago
Wild. Do you know why is that code here?
adamrezich 3y ago
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.
- Skinney 3y ago
  Only on the first compile. It doesn’t perform this check when loading a package from the build cache.
3y ago

Skinney 3y ago

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.

josephcsible 3y ago
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.
- Skinney 3y ago
  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.
jgilias 3y ago
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