[HN Gopher] Elm Compiler Written in Elm
___________________________________________________________________
Elm Compiler Written in Elm
Author : otobrglez
Score : 119 points
Date : 2021-07-12 08:41 UTC (1 days ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| mjaniczek wrote:
| Hello! Author here. Didn't expect to land on HN before the
| compiler is actually useful - Oto, you'll pay for this! :)
|
| Feel free to ask me anything about the project, although bear
| with me - I'm learning compilers/... on the go, didn't study them
| or anything.
| rishav_sharan wrote:
| I really would love to have this compiler have a llvm backend. I
| like the idea of a small FP language with amazing error messages.
| Haskell is too big and complex for me.
| mjaniczek wrote:
| I've briefly looked at LLVM and how to interface with it but
| back then I didn't find much else than some C++ Builder API.
| I'd hope for some textual format that I could give to LLVM as
| an input. I assume it exists and that I've just been googling
| wrong :) Would definitely appreciate some pointers in that
| regard.
|
| Other than that my best bet for native binaries is most likely
| compiling to C or GraalVM (which already exists as an
| experimental backend in elm-in-elm via Truffle!)
| MobiusHorizons wrote:
| As the other comment says, LLVM has a text based IR. But you
| may also want to look into QBE which is simpler and lighter
| weight than LLVM but has a similar text interface so you
| could start with that to get up and running, and then add
| support for llvm later.
| lioeters wrote:
| To save anyone else a search:
|
| QBE: Compiler Backend - https://c9x.me/compile/
|
| QBE vs LLVM - https://c9x.me/compile/doc/llvm.html
| adjav wrote:
| The textual representation is known as the LLVM IR (the
| reference is at https://llvm.org/docs/LangRef.html). My
| understanding (as purely an amateur enthusiast) is that
| generally using a higher-level builder, like the ones for C++
| or OCaml, is recommended, but that it's entirely possible to
| generate the IR directly.
| pentlander wrote:
| Roc is trying to fill this space: https://www.roc-lang.org/
| leshow wrote:
| AFAIK Elm can't actually write to the filesystem, how does the
| compiler get around that? Or has Elm changed such that it can
| work outside the browser now?
| mjaniczek wrote:
| I use ports to write to the filesystem. There is a small amount
| of JS that initializes Elm, which runs in Node and has the
| ability to write to the filesystem.
|
| Of course if you'll be running elm-in-elm in the browser, you
| won't be able to do that. But there are more interesting things
| to do with a compiler in the browser :)
| k_bx wrote:
| Ports let you communicate with Elm from pure js, for example
| here's the cli wrapper for node https://github.com/elm-in-
| elm/compiler/blob/master/cli/index...
| yladiz wrote:
| Serious question: how popular is Elm? I've recently seen some
| tutorials showing up and anecdotally know some friends that have
| played around with it, but I haven't seen any job postings for it
| and so I'm wondering if it's just hyped up or if there is real
| demand for Elm developers professionally.
| gampleman wrote:
| I write Elm full time, so there are definitely jobs out there.
|
| That said, I suspect that given how fun the language is to
| write, supply probably outpaces demand a bit. Which is actually
| good, in the sense that for many companies adopting a somewhat
| less mainstream language one of the main concerns is "will I be
| able to hire for this?", which generally the answer is "yes,
| especially for more senior positions".
| pd-andy wrote:
| Neither, really. I'd say it has the largest community out of
| the various compile-to-js statically typed FP langs, at least
| with an explicit front-end focus.
|
| - PureScript has a small but passionate community, one of the
| biggest players in that community laid off their whole ps team
| so that doesn't bode well.
|
| - ReasonML fractured into ReScript but left half the Reason
| community behind, it's a confusing space to navigate now.
|
| - GHCJS...
|
| Most (perhaps even all) of the job postings end up on the elm
| slack (rather than, say, reddit or other more visible places).
|
| There was some controversy with the release of 0.19 a couple of
| years ago, and general contempt (in the wider community, not
| inside Elm) for the way the language is developed and run which
| means there isn't a great deal of buzz about it outside of
| those already using it.
| aranchelk wrote:
| > PureScript has a small but passionate community, one of the
| biggest players in that community laid off their whole ps
| team so that doesn't bode well.
|
| I wouldn't let that dissuade anyone. Even if support
| diminishes, the language is feature complete, and FFI is so
| stupidly easy you can freely co-opt JS libs as needed.
| egeozcan wrote:
| If you don't have the urge to jump off a hill when you see
| heavy pragmatism, Typescript is very popular and well
| maintained. My experience is only positive.
|
| I was also wondering, does Blazor work with F#? That could
| also be an option. Not a front-end focused language but a
| front-end focused framework, so, there's that.
| sanatgersappa wrote:
| Yup. Try https://fsbolero.io/ . Follows the Elm
| Architecture.
| johnday wrote:
| I truly believe TypeScript is the only true way forward for
| frontend web programming.
|
| Now what we _really_ need is a functional dialect which
| compiles to TypeScript...
| cnasc wrote:
| > Now what we really need is a functional dialect which
| compiles to TypeScript...
|
| Why would it be beneficial to have TS as an intermediate
| representation? It turns into JS anyway, and there are
| already statically typed functional languages that
| compile to JS.
| johnday wrote:
| It would massively simplify the job of proving the upper
| language more correct. It may also be possible to proxy
| the type system in order to make use of existing tooling.
| fpoling wrote:
| TypeScript or Flow for that matter sucks at using
| functional style with immutable data types. There are
| ESLint plugins that allows to enforce immutability with
| plain JS objects, but still lack of syntactic sugar or
| union types makes the experience much worse then in
| functional languages.
| RobertKerans wrote:
| https://github.com/tc39/proposal-record-tuple
|
| Only stage 2, so whether it'll get through to next stage
| is up in the air, will depend on interest (compare to
| Temporal which started fairly slow but has gained huge
| momentum recently and is now at stage 3 and engine
| testing level) but it's encouraging.
| johnday wrote:
| Perhaps what we need is a dialect which compiles to
| typescript and supports (or better, enforces) the
| immutability you suggest.
| toastal wrote:
| TypeScript has a bunch of holes in it because it needs
| tight compatibility with JavaScript. While a pure
| functional style may be possible, it isn't first-class or
| ergonomic or as expressive, and won't cut it for many.
| Are there first-class function composition infix
| operators? Is pattern matching algebraic data types often
| the easiest way to write code? Is IO managed? With a
| language like Elm and others in the ML family, functional
| style is the only game in town, not just the in-house
| convention, and it's easier to have people using a
| similar style if it's ergonomic. Even if you're willing
| to give up managed IO OCaml and Reason are going to suit
| this programmer better than TypeScript. I would not be
| surprised if a lot of the fp-ts crowd is merely
| tolerating this as a comprise.
| johnday wrote:
| I didn't say we should use Typescript, I was suggesting a
| FP dialect which compiles to typescript.
| pd-andy wrote:
| Oh yeah I knew I was forgetting one, F#/Fable seems really
| popular among F# devs, but it doesn't seem like it's
| picking up any traction for FE devs that aren't already in
| that community.
|
| Typescript encourages and is generally more conducive to a
| different style of programming. That's OK (in fact, clearly
| it's more than OK given its popularity) but it's not really
| the sort of thing I want to be writing. I think it's
| _worse_ if you commit to something like fp-ts or the
| fantasyland stuff, personally.
| samhh wrote:
| Oh damn, who laid off their PS team? First I've heard of
| that.
| pd-andy wrote:
| Lumi:
| https://twitter.com/hdgarrood/status/1412833319348314121
| xfer wrote:
| There is also clojurescript which is fairly popular. I am not
| a large fan of using these for websites since they have their
| own heavy runtime that needs to be shipped. ReasonML did
| fairly well in this aspect but there is still a baggage.
| mjaniczek wrote:
| The #jobs section on the Elm Slack is quite alive.
|
| Can't speak for the community as whole, but there is at least
| some demand: the company I'm working for is actively hiring Elm
| devs for at least two teams at this moment :)
| wolfadex wrote:
| We have a team at Square that uses Elm and I've made a few
| commits. They've been working on their app for around 18 months
| now.
|
| I find it slightly funny because I also write Svelte at work
| and that app is public facing so it gets public attention but
| the Elm app is internal facing so the public will never see it.
| Also helps that Svelte uses its own name in the code it
| generates. Which is why I try to promote Elm myself. To semi-
| quote @SvelteSociety "@Square, a >$100 billon company, uses
| @elmlang."
| toastal wrote:
| There was a sizable rift after Elm's 0.19 version. Removing
| synchronous FFI, especially to existing browser APIs that
| haven't been rewrapped with a new API by the core team caused a
| lot of individuals and businesses to migrate mainly to
| PureScript, Reason, and/or Typescript--myself included. Couple
| with community hierarchy issues, lack of development/roadmap
| transparency, rotting merge requests to the core libraries
| (security, bugfix, and performance issues), and community
| libraries, Git hosting, and identity tied solely to Microsoft's
| GitHub accounts, it's not something I personally could
| recommend. I do however think it's a great learning language--
| especially for first-time functional programming--but I would
| be very hesitant in your assessment for production if you need
| to scale to use browser APIs, i18n, l10n, etc. or like/need the
| ability to fork and contribute to the core.
| brainbag wrote:
| I've been a fan of mint-lang; although it's early, it's
| clearly intended to be like Elm: The Good Parts. Also fearing
| a small but helpful community that welcomes contributions,
| which is the polar opposite of my experience with Elm.
| myth_drannon wrote:
| Looks like the language was created by elm-ui author.
| jfmengels wrote:
| There are several things named elm-ui. It's the author of
| a different library than what is usually understood when
| someone refers to elm-ui (which is https://package.elm-
| lang.org/packages/mdgriffith/elm-ui/late...)
| toastal wrote:
| For more context, I believe Luke Plant summed it up best in
| "Why I'm Leaving Elm"
| (https://lukeplant.me.uk/blog/posts/why-im-leaving-elm/).
| This title should be searchable on Hacker News for even more
| discussion.
| girishso wrote:
| I've been writing Elm professionally for the past 2.5 years on
| a large project. The language is a pure joy to use,
| unparalleled refactoring experience. Yes it's a small
| community, but there's many jobs posted on Elm slack.
| onethought wrote:
| It's quite parallel to typescript (strict) refactoring, isn't
| it?
| weavie wrote:
| I suspect not. With Typescript even with strict typing,
| mutating state is still possible (I believe, correct me if
| I'm wrong..). This adds an extra layer of complexity to the
| refactoring process.
|
| With Elm, mutation is impossible - everything goes through
| the update loop. There are no escape hatches. This does
| mean you have to jump through a number of hoops to use FFI.
| It can be a pain at times, but does make for much easier
| refactoring.
| [deleted]
| razze wrote:
| Honestly, it's nothing alike. Refactoring in Elm is
| different, as the compiler will tell you if you did the
| correct thing when refactoring. The typescript compiler can
| only do a fraction of that, even if you type your stuff
| correctly.
|
| Needing to type stuff in elm is mostly optional too. The
| compiler will still check it for you anyway.
| mrweasel wrote:
| There where an article recently regarding Humios use of Elm:
| https://www.humio.com/whats-new/blog/why-we-chose-elm-for-hu...
|
| Using job postings isn't really that useful. If they where any
| indication then the two only language in existence would be
| Java and C#. That depends on where you live of cause. E.g.
| there are plenty of Python jobs around where I live, but they
| aren't frequently posted on the regular job sites. I'd suspect
| that Elm jobs are posted where Elm developers are to be found.
| yakshaving_jgt wrote:
| I write Elm and I hire Elm (and Haskell) programmers. It works
| great for our business so we're going to continue doing that.
| Ciantic wrote:
| I like it! I gather now you can compile Elm in the browser? It
| allows many things, similarly as F# with Fable, which allows to
| compile F# code in browser without a server.
|
| Ability to compile code in browser allows to do sandboxes, or
| tools that otherwise would require a server.
| mjaniczek wrote:
| As pd-andy says, it's not finished yet, but yes you're right,
| that's one of the things it will enable: interpreting Elm code
| from within Elm - an eval function of sorts.
| pd-andy wrote:
| I think the project is a while off of being properly usable. I
| think it's mostly written with Node in mind, but shouldn't be
| too difficult to swap out the Fs bits for browser-specific
| code.
| tpoindex wrote:
| eie.io would be an awesome domain name for this project. Too bad
| it's already parked by a squatter as a "premium name". (For non-
| native or non-Western English speakers, it's a line from the
| children's song "Old McDonald Had a Farm".)
| forgotpwd16 wrote:
| Premium names aren't squatted but designated as such by the
| central registry. For the TLDs .ac, .io, and .sh those are
| previously unavailable short domains that are now released to
| public and auctioned by Divido, the company that has set up the
| site you see.
| neolog wrote:
| > EIEIO ("Enhanced Implementation of Emacs Interpreted
| Objects") provides an Object Oriented layer for Emacs Lisp,
| following the basic concepts of the Common Lisp Object System
| (CLOS). It provides a framework for writing object-oriented
| applications in Emacs.
|
| https://www.gnu.org/software/emacs/manual/html_node/eieio/
| astrange wrote:
| Also relevant to compilers, it's a fence instruction in
| PowerPC:
|
| > eieio (Enforce In-Order Execution of I/O) instruction
|
| > Ensures that cache-inhibited storage accesses are performed
| in main memory in the order specified by the program.
| de_keyboard wrote:
| Very cool! However, could they not compile the Haskell Elm
| compiler to JS using GHCJS and then write Elm bindings for it?
| mjaniczek wrote:
| One thing to note is that writing the compiler in Elm instead
| of just compiling the Haskell compiler to JS allows us to
| expose bits of the compiler as an Elm library.
|
| I mean, being able to bootstrap is nice and nerdy and so on,
| but I believe exposing the parser, optimizer, type inference
| etc. as standalone functions will be the most impactful aspect
| of the repo, in terms of enabling better tooling in the Elm
| ecosystem.
| pd-andy wrote:
| The compiler written in Haskell relies on some extensions
| and/or optimisation tricks that make it not possible to compile
| with GHCJS. The 0.18 compiler (or maybe it was 0.17) was
| compiled with it though, it was what Ellie (third-party online
| playground) used.
| raffomania wrote:
| One of their stated goals is to show people how to write a
| compiler in Elm, and another is to allow programmers familiar
| with Elm to hack on the Elm compiler without needing to learn
| Haskell.
| lisardman wrote:
| Sad that they have to put a massive "Non-goals" full of emojis so
| the main Elm team does't feel threated. A languange doesn't lose
| anything with an extra compiler - a competing compiler is
| actually what Elm needs right now.
| vanderZwan wrote:
| I don't see how the emojis have anything to do with that
| section, since they're all over the readme anyway. Aside from
| that: what they're stating is that they "don't want to and
| aren't planning to divide the community into multiple Elm
| derivatives, and will actively try to prevent that". Not
| dividing the community is not the same thing as threatening the
| main Elm team. And for a smallish language like Elm it makes
| sense to me that they want to keep everyone on the same team.
| tester89 wrote:
| I assume it's a reference to
| https://lukeplant.me.uk/blog/posts/why-im-leaving-elm/
| lisardman wrote:
| To give a bit context, Elm main team has been defensive
| against forks. They are preventing development of features
| they don't think worth to them. It's not possible to publish
| packages with low-level access without Elm main team
| approval. The compiler even has built-in DRM about that. My
| point is more compilers is exactly what Elm needs to
| flourish. C has several compilers. Python has even"jython".
| That doesn't make a language community weaker.
| otabdeveloper4 wrote:
| We may live to see the day, hopefully, (a long time ago in
| a galaxy far, far away) where language designers join the
| 1970's and learn about open standards.
|
| Their mind will be blown, probably.
| [deleted]
| square_usual wrote:
| > It's not possible to publish packages with low-level
| access without Elm main team approval. The compiler even
| has built-in DRM about that.
|
| Not calling you out or anything, but could you give a
| reference on that? I'm curious about what they're doing
| with a "DRM" in the compiler.
| [deleted]
| [deleted]
| lisardman wrote:
| > Not calling you out or anything, but could you give a
| reference on that? I'm curious about what they're doing
| with a "DRM" in the compiler.
|
| Check tester89 link - it's the description about the
| state of Elm right now. Author's experience matches my
| personal one.
| prophesi wrote:
| This[0] is actually a better reference; the official post
| by Elm's creator on how accessing "native" code used to
| work, and how it now works.
|
| Essentially, the compiler only allows packages published
| by two official Elm Github organizations to include
| native code. I'm not sure what the process is if a key
| "native" feature is missing, as this limitation also
| drove me away from the language.
|
| [0] https://discourse.elm-lang.org/t/native-code-
| in-0-19/826
| cies wrote:
| > Elm main team has been defensive against forks
|
| What does that mean?
|
| I know they have a strict vision of what features are
| better left out, and in a way I wish more langs'd be vocal
| about that. Go does the same and they seem to get a lot of
| praise for it.
|
| Just like in Go, the Elm team only allows some features to
| be used by their own (std-) libraries. This, again, is a
| design choice.
|
| No group was hurt enough to "fork" Elm. PureScript can be
| seen as a close relative that is less restrictive.
| donatj wrote:
| Go is open to forks and PRs though. It's more "we've got
| a vision, but we'll hear you out". Elm is full cathedral,
| Elm comes down from the gods with no input or
| transparency into the decision process.
|
| The Elm developers have a history of ostracizing people
| who even mention the possibility of forks from the
| community; tester89 posted a link with a lot of good
| context.
|
| They take a very heavy handed and adversarial stance to
| development. I had just started getting into Elm when the
| news of .19 basically breaking everything and the core
| team just brushing off peoples cries and it soured me on
| the entire language.
|
| When pre-v1 Go broke things, `go fix` was there to at
| least try and help.
| yakshaving_jgt wrote:
| > basically breaking everything
|
| This is unnecessarily dramatic, and far from the truth.
| antew wrote:
| There was a similar project to `go fix` with elm-upgrade
| (https://github.com/avh4/elm-upgrade). We migrated a
| ~100k LOC app at work from 0.18 to 0.19 and while it was
| tedious, the compiler really has your back and makes it
| easier.
|
| We weren't bit by the removal of native/kernel code, but
| it definitely turned a lot of people away that may have
| been committed to Elm before.
| girishso wrote:
| True that.
|
| We also ported our Elm codebase from 0.18 to 0.19. It
| took us almost a week working almost 24/7 across two
| timezones to make the damn thing compile again. Did not
| see the UI for the entire week, but once it compiled it
| (mostly) just worked like nothing had changed (that's
| after 429 files changed, 16422 insertions(+), 12116
| deletions(-)).
|
| My colleague took notes of the progress at https://gist.g
| ithub.com/mordrax/efcd34739ed56bb64d2b12d2401b...
| savanaly wrote:
| Wow! Apologies if this is answered in those notes but my
| quick question is: Did you make extensive use of
| Debug.todo to cordon off sections of the app that
| wouldn't compile in order to work on and "see" the other
| sections in the meantime? That's what I do on my small
| elm apps, e.g. put whole features or functionality behind
| Debug.todos.
| girishso wrote:
| I might be wrong but I think Debug.todo was introduced in
| Elm 0.19. But in any case we were not aware of it at the
| time and didn't use it. Btw Debug.todo is amazing and we
| do use it now sometimes.
| mjaniczek wrote:
| I remember hearing Mordrax speak about the upgrade, quite
| herculean!
|
| At our company it was much less drastic. At the time we
| had about 35kloc of Elm and it took me one evening of Vim
| macro frenzy. The trickiest things we encountered were an
| elm/http API change and temporarily vendoring packages
| that didn't yet upgrade themselves.
| b3morales wrote:
| From the gist:
|
| > We have until Friday 7th September to upgrade to Elm
| 0.19.
|
| I'm completely ignorant about the transition, but I'm
| curious what the source of this deadline was. Would you
| mind expanding?
| girishso wrote:
| Basically business didn't see any benefits of spending
| time on the upgrade, time that could be used to
| improve/add features to the product.
| cies wrote:
| Sounds like Go's cathedral has a nice little bazaar in
| front, once a year, only for those who applied and were
| grated. In other words: better marketing.
|
| I'm not defending Elm team members being rude. But when I
| look at Elm I see a much better designed language than
| Go, run by a much smaller team. Elm changes quite minor
| things in pre-1.0. Go forgot that polymorphism is cool,
| nulls are bad, etc. Now Go wants to fix some of that, but
| that would create a new notion of idiomatic Go that it's
| std lib is not in sync with.
|
| To some extend this is a fate all popular languages
| befall. Look at Java for some sci-fi, or even better C++.
| andrewzah wrote:
| I know you're not trying to replace the official Elm compiler,
| but that's precisely what is needed. I really, really wanted to
| like Elm but the way it's managed is horrible and antithetical to
| the idea of Open Source software. With the current compiler I
| wouldn't touch Elm with a 39.5" pole, even if Elm is a joy to
| work with.
| savanaly wrote:
| One's attitude towards Elm directly correlates with the degree
| to which one likes to dig into and tinker with the internals of
| their tools and frameworks and rearrange things. Unfortunately
| that means it's a hard sell around HN-- in a way it's
| antithetical to "hackers". But I don't think it's antithetical
| to John Carmack's proverbial "engineer"-- someone who wants to
| do what they can do with what they've actually got. Elm lets me
| do what I want to do, exceedingly efficiently and makes it fun,
| and that should make it a good choice for plenty of projects.
| andrewzah wrote:
| I don't buy this argument.
|
| I am also someone who just wants to get shit done. I've never
| had an issue with php, c#, ruby, crystal, go, rust, haskell,
| erlang etc's compilers/interpreters in terms of letting me
| get what I want done. Yeah, I haven't actually forked or
| patched those compilers but neither have they been hostile to
| their users.
|
| The reason I would use literally any of those except Elm is
| that the maintainer(s) of Elm act like they're Steve Jobs.
| How can I "get things done" if I'm being told "oh no, you're
| not allowed to do <standard-thing-X>, we've decided that only
| us on the Elm team can do that". With other languages, I'm
| not worried about a version bump pulling the rug out under
| me, effectively trapping me in the ecosystem unless I want to
| rewrite everything in a different language. That is also
| directly the opposite of being productive and getting things
| done.
|
| There is nothing about an autocratic "you're holding the
| compiler wrong" governance model that makes any part of a
| language itself more efficient or fun. Plenty of other
| languages are as (or more) efficient and fun as Elm, but
| without the patronizing and condescending attitude of "you're
| not as smart as us, so do as you're told, and no you can't
| discuss this with us". There is no way I could justify the
| risk of adopting elm professionally given the entire rest of
| the programming language world... doesn't do this. Let me be
| the one who decides to shoot my own foot off; even Rust (a
| language pitched on memory safety) allows this with unsafe,
| etc.
|
| If one wants to control everything exactly and go against
| almost every other language and most F/OSS projects, then
| just... make proprietary/source-available software. F/OSS is
| a give-and-take, and nearly all of us have taken far more
| than we've given.
|
| And I don't know what John Carmack's "proverbial engineer"
| is, but I think just about any engineer would prefer to be in
| control of their tooling and not at the whims of maintainers.
___________________________________________________________________
(page generated 2021-07-13 23:02 UTC)