Gren is looking really interesting. Parameteric modules are a cool idea, working with concrete types while also fulfilling one of the roles of type classes is really nice. As a bonus, removing "comparable" and "number" will dispel some of the magic that I found confusing when I first started using Elm.
Awesome work, really looking forward for trying it out. Your changes make a lot of sense and are meaningful. I second that record updates will have a complete and nested expression syntax. That was always a annoyance to me. What about FFI ?
Also I am thinking that maybe keeping at least the keyword "type" with custom types and aliases might be more clearer as omitting it completely. Thank you for your work btw !
Parametric Modules seems like a great solution to add generalizability without complicating the language! Perhaps now we can finally have a wealth of safer primitives like a `Nat` type without losing interchangeability. One key point about why Elm doesn't have polymorphism isn't just that it's confusing in Haskell, it's that error messages *suck* in Haskell when dealing with polymorphic types... even when you aren't using the polymorphism of that type. The error messages are forced to become more vague and useless because you can't just say "I can't add an int to a string" but you have to say "I couldn't find a common interface between the int and string modules that happens to include an add function" or such.
I hope your solution to "what user operators should be allowed" ends up leaning more conservative. I really love the readability that Elm 0.19 gained by banning custom operators, I can jump into a totally unknown library and still know what's going on since functions are supposed to have, you know, _names_ that tell you what they do. "Defining how you add two money types together" could be done by inheriting plus from the underlying money's Int.... but allowing to override this means that I can make money + money do something _other_ than just adding (e.g. can't go below zero) so we're back to a single operator meaning different things in different contexts...
> but allowing to override this means that I can make money + money do something other than just adding (e.g. can't go below zero It's up to the user of the package (not the package author) to decide which `+` implementation to use. By default the `+` operator will be an alias of `Int.plus`, so if the user doesn't explicitly change that, that's what it will mean. As a reader of the code, you can always look at the import section of the module to see which implementation is in use. Also, you won't be able to add new operators.
"Allow type aliases to become opaque" I fell that the Elm way of making opaque types, e.g. `type Nonzero = Nonzero Int` already handles this beautifully, without adding any new language features. if you don't expose the `nonzero` constructor outside the module, it's effectively opaque, yet you can still destruct the Int in the function signatures throughout the module, allowing you to use the underlying Int the same way you would a type alias. Plus you get additional type safety, as unlike with a type alias, the compiler won't let you mix and match `Int` and `Nonzero` types by accident. I'm guessing with your planned "opaque type aliases" this would still be a problem (as that's what type aliases are) but only inside the module and not outside.
> I'm guessing with your planned "opaque type aliases" this would still be a problem (as that's what type aliases are) but only inside the module and not outside. Yes, but you can still use a tag to achieve type safety. The reason to allow type aliases becoming opaque is because I'm removing syntax for defining a custom type, as they are now structural instead of nominal. Removing this syntax means we'll need another way of define opaqueness, which is solved by allowing type aliases to become opaque. Net result is a simpler language.
If you're going to limit Ints to 32 bits, then consider adding support for the new Double and BigInt types in modern JS - which should be easy given parametric modules.
The point of limiting ints to 32 bits is because the underlying compile target will change _from_ JS and to Wasm. As in, JavaScript will no longer be a valid compile target. Supporting JavaScript's `BigInt` would (a) require a javascript runtime, which would rule out pure wasm/wasi runtimes and (b) be a bit complicated as you'd have to call out to the JS runtime on use.
@@robinheggelundhansen of course I didn't mean reaching out to a different runtime, in wasm you would have BigInt and 64-bit ints as well. I didn't realize that you would be dropping JS support in favor of WASM, I thought wasm would simply be added as a possible target.
What would be the benefit? You won't be able to call Deno API's directly from Gren code. I also believe Deno is NodeJS compatible, in which case you're free to use whatever runtime you prefer.
@@robinheggelundhansen they still have huge overlap but I don't believe they're designed to be compatible, Deno is a re-think of Node. What I meant is that you're allowing gren to be run in a node process, but since you can't call node-specific APIs (like you said), there is no cost to switching to the faster and safer runtime, Deno, which was built by a Node developer to solve Node's design mistakes. 🤷♂️
