Elm syntax in elixir

I’ve been playing with Elixir and have read about/watched some tutorials on Elm. I’m liking both. Currently learning Elixir and when i’ve got that. I’m planning on using Elm too Elixir for the backend Elm for the client.

A suggestion… can we have Elm type checking in Elixir please. I come from a typed background (Delphi/C#) and find that this untyped coding is prone to all sorts of silly mistakes and confusion. So lets make it so you can use typing if you like (like Elm does). Thus if it compiles… then i’ll probably work.

May not be possible… but… if you don’t ask eh!

And… can we merge the too… Elm syntax producing Erlang? Take the best from both?


Now i’ve thrown my spanner i’m going to retreat and let those who know better shoot down my foolish thoughts.

1 Like

Hello @moatingodseye, I’ll let other people discuss this topic with you if they want, but there are several other threads where people have discussed this to great lengths here in the forum:

What do you think is missing or needs improving in Elixir

Elixir at Enterprise

And you’ll also find a lot of discussions about Erlang and Elixir having static typing around the Web.

There’s also a small project to achieve a static typed Elixir, I believe ( I think it’s somewhere in the ‘Your Libraries’ category).

Also, in case you don’t know about it, you may want to explore Dialyzer,

I’d like a Haskelish syntax and typesystem over BEAM as well, but I do not have the time nor the expertise right now to create such a thing.

But if you can live with ML-syntax and types alpaca might be worth a look? It’s a work in progress though and in an early stage.

Oh if you think C# and Delphi have good type systems then you need to learn OCaml or Haskell. :wink:

You ‘could’, and the FRP pattern in Elm would fit a genserver design well, but for anything else the API will be entirely different, at which point the Elm syntax is pretty… bleh. If you want a well typed syntax on erlang ‘now’ there is an in-dev but functional alpaca.

But no, Delphi and C# type systems are an utter joke, about as bad as Java’s as well…


I think you may be in the minority here :lol: you will find many prefer the Ruby style syntax, and I don’t know about anyone else but I personally dislike the syntactic significance of whitespace in other languages such as Python (and actually wish Elm was more like Elixir or Ruby).

Yick, nasty ruby syntax, that is the one big part that puts me off of elixir, the macro’s are the big reason I stay around though. ^.^

ML syntax is so much more readable to me, shorter, easier to follow, and usually (but not necessarily) typed! ^.^

A while ago I was playing with an Elm to erlang compiler Elmo, haven done much progress on it. Basically it just was getting the elm AST (before it being transformed into javascript) and then compile it to erlang modules (ADT were just tagged tuples), feel free to open an issue if you have questions on it. Havent implemented ports. So if you actually want to use Elm specifically or want to get your hands dirty with some compiler fun, take a look at it, otherwise if you are looking for something more usable my recommendation would be to use Alpaca instead.

1 Like

Oh and a few days ago the amazing @jmitchell started an Idris backend targetting Elixir (still work in progress) be sure to watch it if you like Idris.

1 Like
(*** Gaussian Elimination (from Sedgewick, Chapter 5) ***)

(*the first row with absolutely greatest head*)
fun pivotrow [row] = row : real list
  | pivotrow (row1::row2::rows) =
      if abs(hd row1) >= abs(hd row2)
      then pivotrow(row1::rows)
      else pivotrow(row2::rows);

(*the matrix excluding the first row with head p*)
fun delrow (p, []) = []
  | delrow (p, row::rows) =
      if Real.==(p, hd row) then rows
      else row :: delrow(p, rows);

fun scalarprod(k, []) = [] : real list
  | scalarprod(k, x::xs) = k*x :: scalarprod(k,xs);

fun vectorsum ([], []) = [] : real list
  | vectorsum (x::xs,y::ys) = x+y :: vectorsum(xs,ys);

fun gausselim [row] = [row]
  | gausselim rows =
      let val p::prow = pivotrow rows
          fun elimcol [] = []
            | elimcol ((x::xs)::rows) =
                  vectorsum(xs, scalarprod(~x/p, prow))
                  :: elimcol rows
      in  (p::prow) :: gausselim(elimcol(delrow(p,rows)))

fun solutions [] = [~1.0]
  | solutions((x::xs)::rows) =
      let val solns = solutions rows
      in ~(dotprod(solns,xs)/x) :: solns  end;

Erm… no thanks :lol:

Maybe I would feel differently if I spent more time with the language, but my initial gut reaction does not warm to it. Completely the opposite to how many feel when they experience Ruby or Elixir for the first time.

But if you like it - that’s what matters most for you. Everybody’s tastes are different - would be a boring world if we all thought the same or liked the same things.

o.O? Mine?

Oh that is gorgeous, but I notice that you are not putting the same code in ruby/elixir here, where it would be much longer and less readable. You picked a complex math example (Guassian Elimination eh?). :wink:

I just googled “simple program in ML” and that site was the first result.

Longer doesn’t necessarily mean bad, and how readable the code is will boil down to the individual user, their tastes, their cognitive differences, etc.

The beauty and power Elixir it fits nice Erlang. Erlang is dynamic typed, Elixir is dynamic typed.
See what ugly happen when you mix dynamic language with static typed VM => Clojure

If you like static typed ML langauges try F#. If you want Erlang actor model on F# try Akka.
With .Net Core you can run F# everywhere even on Linux :slight_smile:

1 Like

Thanks for noticing, @vic. It’s in the very early stages. The most I know it can do is generate a .exs which, when interpreted by elixir, prints Hello world to stdout (and also emits lots of warnings about unused variables…). My eventual goal is to have the option of implementing and proving properties in Idris and have those guarantees translate to a generated Elixir module.

For those unfamiliar, Idris has a dependent type system, which is more expressive than type systems in most other languages, including Haskell, OCaml, and Elm. The high-level idea is to let types be parameterized by values, say numbers, or even other types! Imagine if in Elixir you could make a MyEnum.t(5, Integer) type which says “any Enum.t of length 5 containing Integers,”. A compiler for such a language could then ensure no values which violate a type specification could ever possibly be used where they shouldn’t be. Amazingly it can provide those guarantees even for input data which only becomes available at runtime. In the MyEnum.t(5, Integer) example this would mean implementing code that inspects an Enum.t, verifies its entries are all the same type T and its length is n, and returns a value of type {:ok, MyEnum.t(n, T)} | :error. Ultimately it forces you to deal with edges cases up front so they don’t sneak up on you at run time.

Edwin Brady, the professor who maintains Idris, has some really interesting ideas about dependently typed state machines providing guarantees about communication protocols in distributed systems. I’ve been meaning to read his paper “State Machines All The Way Down”. An earlier one I have read called “Programming and Reasoning with Algebraic Effects and Dependent Types” demonstrates how to ensure file IO operations are all legal, given a typed specification of legal state transitions, e.g. a file must be closed after it is read (see section 2.2.5). The ideas are still relevant, but Idris and its libraries may have evolved enough that the examples no longer run.

I bet the same strategy could be applied to Elm. Idris provides a library for code generation from various intermediate representations produced by the compiler, so a good starting point would be checking if there’s similar tooling for Elm.

It may be impossible to extend Elixir/Erlang’s type system to dependent types, especially in a way that supports code reloading and message passing. But we can get a lot of guarantees about our code by generating it from a dependently typed program. Other languages that would be great to eventually support for the sake of safety offered by dependent types include Coq and Agda.


I’m invoking the Rich Hickey (riot?) act.

Please stop confusing familiar (aka easy) with simple and unfamiliar with “not simple”. :wink:
I know, like a broken record … (talk about antiquated metaphor).

FYI: Robert C. Martin incited another static vs. dynamic typing debate with his The Dark Path (twitter) and Types and Tests (twitter) blog entries.


I agree with that. I’m a ruby (mostly) dev, and Ruby’s syntax is very familiar for me now. But I can’t say it’s simple, because getting to Ruby from Python wasn’t easy at all. I still sometimes have trouble with namespacing, and some, one would think easy concepts. And that’s because they are not simple at all, one might say they are handy, or maybe even clever, but certainly ruby as a whole is not simple, not syntax. To be honest having optional parenthesis for methods calls is confusing as hell at first. Maybe if your first language was Ruby it’s syntax might be “easy” for you, but it’s only (what did @peerreynders wrote) because it’s familiar to you. But not because it’s easy. For me Python’s syntax makes so much more sense, and is so much easier… why, well because it’s one of the first languages I learned, and I used it for a very long time, thus it’s very familiar for me :wink:


I’m not confusing anything - ODL said I picked a complex math example and all I was trying to say is that I didn’t actually put much thought in ‘picking’ anything - I simply:

  • googled ‘simple ML program’
  • clicked on the first link
  • picked a random-ish chapter (one of the early ones so I couldn’t be accused of picking something complex from a later chapter :lol:)
  • then chose a bit of code that looked typical of what else was on the page.

I didn’t really care if the code was simple or complex, just something to reflect what the syntax was like :slight_smile: (and I only used the word ‘simple’ in the search term so I couldn’t be accused of purposely picking something complex on purpose :wink: If you are suggesting it’s overly complex or not indicative or the syntax, blame Google :stuck_out_tongue: :044: however you are also welcome to show code examples that support your notion that the syntax is ‘nicer’ :101:)

1 Like

Simple in what way though?

Simple to learn for beginners?
Simple to use?
Simple under the hood?
Simple, how?

I actually had an ‘interesting’ conversation relating to this with a fairly famous twit on twitter - he was trying to tell me Ruby wasn’t a good language for beginners. I was trying to tell him that for me, as a beginner, it was the best language - because all of the other languages I looked at (back then) actually put me off.

He couldn’t wrap his head around this - but for me it was crystal clear, Ruby was amazing because if I hadn’t found it I almost certainly would not have got into programming. So what good is a language if doesn’t exist? (i.e. all the other languages that I wouldn’t have been using because I wouldn’t have been programming.)

He got quite nasty - told me I should quit blogging! :flushed:

Ryan Bates came to my rescue :049:


Tell such people to piss off. ^.^

Everyone learns in their own way. After all I learned with assembly! :stuck_out_tongue_closed_eyes:

1 Like

I wish I had the brains to learn Assembly :lol:

I was tempted, but he had a strop and blocked me :043:

Nah, assembly is one of the most simple languages there is (not beautiful in my opinion, but simple), it is literally just a few things like a set of opcodes, some labels, and if you have a fancy setup some macro’s (C-like macro’s). I learned on one of the old Motorola chips. Modern x64 would be hell, don’t learn it. LLVM’s assembly is actually fascinating, it is worth learning to see how to have a fully immutable assembly language. :slight_smile:

Lol. ^.^

1 Like