Senior thesis topic

[Robert Muller]

I have a student just finishing a programming languages class. The course is taught using OCaml and is mostly focussed on statically-typed PLs. The student is interested in doing a senior thesis in PL. I've asked him to take a look at Web Assembly. I'm wondering if there is a project to write a wasm back-end for the Elm compiler and if so, whether or not some piece of that project might be reasonable for a student to take on.

Thanks for any leads.

Bob Muller

[Evan Czaplicki]

Hi, thanks for reaching out!

We actually have some recommendations specifically for this type of student!

Would any of those projects be suitable?

About WebAssembly

One of the projects in that list, this one, actually breaks this down into plausible chunks of work.

This has been a topic on the #gsoc channel on the Elm slack recently, so here is the most relevant excerpt:

If the goal is to run in browser, the hard questions are (1) how to hook into DOM, (2) how to represent strings, and (3) how to deal with garbage. Folks on the Chrome team have strongly recommended against implementing (2) or (3) in a custom way though. 

Shipping a custom GC with every app seems very bad for a few reasons.

1. This will likely be quite a large artifact to ship with every page.
2. For the target Elm user, I know of no examples where performance as a bigger bottleneck than download size.
3. It is possible that GC will become a part of WebAssembly down the line.
   

In other words, the problem here isn't lack of will or manpower or creativity. I think it's just too early to seriously attempt the full project, and when it is time, it will require a lot of coordination with core developers. That means whoever does this will need to have a good working relationship with core folks, so even when it's time, it's not ideal for someone's first project in the Elm community.

Hopefully that info helps, and let me know if you have further questions!

Evan

--
You received this message because you are subscribed to the Google Groups "elm-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elm-dev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elm-dev/7f6f27c5-beaa-4713-aae1-d34ec86d2e22%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Evan Czaplicki]

One other note: I would be quite interested to learn more about efficient UTF-8 string implementations. 

I'm personally interested in creating very fast parsers. Some of my recent work was creating a Haskell parser that is significantly faster than parsec for the Elm compiler.

So when it comes to a UTF-8 string implementation, is it better to use flat arrays? If so, do people do GC tricks to copy substrings and free larger chunks? Is it better to use finger trees? If so, what does that mean for parsing libraries that want to backtrack? Is there some other data structure folks use? Etc.

I think there is a lot here, and it's quite interesting to me at least!

[Robert Muller]

Thank you Evan, this is interesting, we're going to take a look at that and will follow-up.

Bob

To unsubscribe from this group and stop receiving emails from it, send an email to elm-dev+u...@googlegroups.com.

[Mark Hamburg]

Another project that seems quite "doable" would be compiling Elm to Lua instead of JavaScript. The benefit here is that Lua is both very fast (LuaJIT runs circles around the JavaScript JITs) and very easy to embed elsewhere. Lua has first-class functions and garbage collection(*) so it should be just as reasonable a target for Elm as JavaScript. The downside is that there would be nothing for it to talk to in the way that Elm talks to the DOM. On the other hand, this could be a strong starting point for building a toolkit for using Elm to write native applications for non-web platforms.

Mark

(*) Though I think the optimal GC design for a pure language like Elm is likely rather different from what one needs for a language like JavaScript or Lua where you have lots of long-lived but mutable objects.

To view this discussion on the web visit https://groups.google.com/d/msgid/elm-dev/7823d464-5937-440b-957e-65d9a78d8d87%40googlegroups.com.

[Zachary Kessin]

I personally would be more interested in an Elm -> Erlang (Beam) compiler, and have had some thoughts on that.

Zach

ᐧ

To unsubscribe from this group and stop receiving emails from it, send an email to elm-dev+unsubscribe@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/elm-dev/7823d464-5937-440b-957e-65d9a78d8d87%40googlegroups.com.


For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "elm-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to elm-dev+unsubscribe@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/elm-dev/CAFdvD8X9x%2BD%3DzNheAKYifrpc0PKjn%3D%3Dt%2BLHuo_xJycnsrTTTYg%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--

Zach Kessin

Skype: zachkessin

+972 54 234 3956 / +44 203 734 9790 / +1 617 778 7213

[Evan Czaplicki]

Everyone thinks "Elm should compile to X" where X is a thing they like. Here is someone saying Go is the right one. Why not go through OCaml or C# or Java or or Scala or F# or Haskell or ES6 or C++ or Rust or node.js?

I cannot stop this in general, but please stop doing it on elm-dev. It's not relevant to OP and everyone here has heard this endless iterations of this idea. The hard part of supporting a domain is not the compiler. It is making a good ecosystem. Python is nice for scientific computing because of things like NumPy and SciPy, not because of whatever backend. Elm is nice for front-end because of the ecosystem, like the HTML library and the Elm Architecture, not the particulars of code generation. Just putting a typed functional language in a domain does not mean it will be fun and productive in practice!

So say we choose to go through Erlang. Great. Now the question is "how do you write a typed server with no side-effects that is (1) true to the spirit of Elm and (2) feels nicer than other server languages?" That's the hard question. Writing a backend is like 10% of what it takes to make a project like this worthwhile. And ultimately, the ideal form of a project like this has its own bespoke backend, going to assembly more directly, like this thread was about.

Hopefully I don't sound upset. I'm not! This whole "compile to X and it's done" oversimplification is just becoming a bit of a silly meme, and the explanation of why came out with some unjustified vigor ¯\_(ツ)_/¯

P.S. two important notes from What is elm-dev for? are about (1) "if you are suggesting other people do work" and (2) "lobbying for a change in prioritization". Further talk of "compile Elm through X" should move to slack or elm-discuss.

To view this discussion on the web visit https://groups.google.com/d/msgid/elm-dev/CA%2BDc4eFT%3DxwDeO4RPt5XTYcBYV7EFsn3GV5Pvq%3DP8cK%2B%3D-HWzA%40mail.gmail.com.