Maturity of the project

[wende]

Hi there!

I've been following this project for quite a while and I was thinking how mature it is in terms of being able to interpret a real Elm program.

I'm highly interested in using this project as a part of Elchemy (https://github.com/wende/elchemy) in case we wanted to ditch the entire reliance on Elm compiler - which right now is solely the type checking Changes introduced in 0.19 didn't touch us directly but very strongly disrupted the community (elm-install got affected and basically everyone trying to widen the borders of what Elm can do) and we're afraid it might be the time to take some strong measures

If this project was ready enough (or at least in a major part done) it'd be a great starting point to think about Elchemy's future in terms of being an independent yet compatible project in the relation to Elm

[joonazan]

The project is very stable as far as I've used it, as I haven't had to change it in a long time.

However, it does not support records. They should be very easy to add.

It also requires unique type names, so you'll have to rewrite type aliases before feeding them in.

So getting it to work for you would be easy. I still don't recommend it. The reason is that programming type inference in Elm is an uphill battle. With Elm 0.19 even more so.

I may make a better version in Idris in the future. If that would work for you, we can collaborate. I'll have to add error reporting, though, which is completely useless to me.

Is there a reason why you want to have exactly Elm's type system? I'd assume that an Elm-like language would be slightly different.

On 30 Aug 2018 1:18 a.m., "Krzysztof Wende" notifications@github.com wrote:

Hi there!

I've been following this project for quite a while and I was thinking how mature it is in terms of being able to interpret a real Elm program.

I'm highly interested in using this project as a part of Elchemy ( https://github.com/wende/elchemy) in case we wanted to ditch the entire reliance on Elm compiler - which right now is solely the type checking Changes introduced in 0.19 didn't touch us directly but very strongly disrupted the community (elm-install got affected and basically everyone trying to widen the borders of what Elm can do) and we're afraid it might be the time to take some strong measures

If this project was ready enough (or at least in a major part done) it'd be a great starting point to think about Elchemy's future in terms of being an independent yet compatible project in the relation to Elm

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/joonazan/elm-type-inference/issues/5, or mute the thread https://github.com/notifications/unsubscribe-auth/AL3sFF8PjJgMTissfV64JY-boMsGt43Aks5uVxNGgaJpZM4WSa-f .

[wende]

So getting it to work for you would be easy. I still don't recommend it. The reason is that programming type inference in Elm is an uphill battle. With Elm 0.19 even more so.

Elm 0.19 is the exact reason we decided to look for a replacement. Elchemy currently uses elm-make only to do the type-checking. If we had our own tool we could start thinking about getting independent; going our own direction.

I may make a better version in Idris in the future. If that would work for you, we can collaborate.

Idris is an amazing language. Even if we didn't use it, I'm sure that'd be a great learning tool to get more familiar with both Idris and type inference algorithms.

Is there a reason why you want to have exactly Elm's type system? I'd assume that an Elm-like language would be slightly different.

Currently, we try to stick closely Elm, just on a different platform. We want to add functionality atop of that eventually, but It'd be great to be able to still use all of the Elm libraries, as we do now. Especially with removing of native modules it'll be easier to reuse existing libraries. So the current, short-term goal is to make a superset of Elm. I think making Elchemy to Elm what Elixir is to Erlang would be the best comparison.

Going straight into complete independence would be a suicide for the project. We still want to be a nice bridge between both of the Elm's and Elixir's community. I think recent developments with 0.19 can make us even stronger in that.

[joonazan]

@wende It seems our use-cases are much more similar than what I imagined. It is my goal as well to be able to call into Elm code.

Do you have some system that replaces elm-package? I'm also interested in that, because elm-package.json is not a nice system for a server that compiles code.

During the last weeks I've been doing some experiments to find out how feasible it is for me to write a type inference with a proof of termination and an approximate proof of correctness. I see that as a more viable way to achieve correctness than testing. If the official compiler was correct, I could run an automated test that compares the results of it and my implementation, but the official compiler has infinite loops sometimes.

The first version may have low performance, but after it is ready, faster versions can be written that retain the correctness of the original. I'm especially interested in incremental type inference.

Have I understood correctly that you are currently first running type inference and terminating if it fails, otherwise proceeding by translating to Elixir?

Using a custom type inference, you could avoid parsing the AST twice. You could call into Idris through ports. (I'm compiling Idris to JS)

By the way, your logo looks like the word NO to finnish speakers (lowercase L interpreted as I).

[wende]

Do you have some system that replaces elm-package? I'm also interested in that, because elm-package.json is not a nice system for a server that compiles code.

We use elm-github-install. It allows us to specify a GitHub repository to download a library from. We do so with elchemy-core in every new Elchemy project.

It works by removing elm-package entirely from the equation and downloading the package straight from GitHub under available tags. Put aside sometimes being less than fully reliable and being a bit slower it is functionally way superior to the original elm-package install. For instance, its constraint solver works and can nicely state what packages are problematic - which cannot be said about the original one. So far the 0.19 news are relatively fresh so I'm not sure what is @gdotdesign's plan for the future of the project, but if he'll decide to discontinue we're ready to pick up from his great work and use it for Elchemy's needs.

As it relies solely on GitHub it works completely fine with libraries that are Elchemy/Elixir mixes. So the current state of things being: mix.exs and hex.pm for pure Elixir dependencies and elm-package.json with elm-github-install for Elm and/or Elchemy/Elixir dependencies.

---

Have I understood correctly that you are currently first running type inference and terminating if it fails, otherwise proceeding by translating to Elixir?

That's exactly correct. We use a rather hackish approach of first running elm-make on the entire project and exiting if it failed or continuing with our backend if it succeeded

https://github.com/wende/elchemy/blob/2f4aca0dbfe2504fef4fbc057988cb6914ccda40/elchemy#L101-L119

The whole pipeline would be:

1. Bash file with safety checks, incremental compilation, renaming utilities etc.
2. elm-github-install to resolve all of the dependencies
3. elm-make to check typing of all the project files
4. elm-ast to tokenize our code
5. elchemy to create a working Elixir output out of it.

That forced us to do some more hacky solutions like this one here: https://github.com/wende/elchemy-core/blob/918d15cda70fef7736a37befd9386715c1ae1f5e/elm/Elchemy.elm#L47-L49 To allow elm-make to think everything's fine. Then we replace all of the ffi calls with appropriate counterpart at compilation time. So ffi (as well as some other functions [1]) are actually macros (or pseudo-functions) rather than real functions.

---

Using a custom type inference, you could avoid parsing the AST twice. You could call into Idris through ports. (I'm compiling Idris to JS)

The speed is quite good so we didn't have to worry about performance that much, especially after we introduced incremental compilation. Platform independence and freedom to develop was much more of an issue. For instance running elchemy-live required to compile elm's compiler with GHCJS - so that we had to use a haskell to javascript compiler to compile an elm to javascript compiler to compile an elm to elixir compiler, you get the idea... And as you can see it doesn't work right now because Ellie's elm 0.18 CDN is no longer there. If we had a compiler entirely in Elm (or anything that easily compiles to JS) we'd have a web compiler out of the box for free.

---

By the way, your logo looks like the word NO to finnish speakers (lowercase L interpreted as I).

Good to know. I hope it doesn't connotate that badly

---

[1] The same way we were able to extend Elm's syntax by a record update function

record = {a = {b = {test = 1}}}
update3 .a .b .test (\a -> a + 1)
{a = {b = {test = 2}}}

Which is type checked by the compiler but executed as a macro on our end.

[joonazan]

I did not realize until now that you are self-hosting. Are you compiling Elixir to JS in the web version?

I'm not sure what is @gdotdesign's plan for the future of the project, but if he'll decide to discontinue we're ready to pick up from his great work and use it for Elchemy's needs.

I remember reading that 0.19 brings caching of builds and downloads in a common folder. That would allow me to just use the official tool, making a new folder for each compile request.

The same way we were able to extend Elm's syntax by a record update function

I want to resurrect the ability to write

let a = { x = 1, y = 2 }
in { a | z = 3 }

And as you can see it doesn't work right now because Ellie's elm 0.18 CDN is no longer there.

I did not know that there was an Ellie CDN. I have written my own mirror of package.elm-lang.org.

I also have my own compile server. It is so fast that compile times seem to be just a network roundtrip even though it's running on Google's cheapest VM. It probably currently uses their burst feature pretty hard where it borrows CPU time when it needs it. I have no idea to how many users this would scale.

[wende]

I remember reading that 0.19 brings caching of builds and downloads in a common folder. That would allow me to just use the official tool, making a new folder for each compile request.

Maybe. But it also disables installing packages that are not on package.elm-lang.org. So we're kind of back to the package whitelisting times with Elm

I want to resurrect the ability to write

let a = { x = 1, y = 2 }
in { a | z = 3 }

YES!!! We were thinking about writing an algebraic effects PoC and without any way of writing a type that can be dynamically extended and doesn't care for an order of composition it's not possible. Extensible records were one way to do it