Elixir, Types and Intentions

Hello,

I’ve been learning elixir for fun so far, I’ve a background in Scala/Ruby/Java/C#

I’ve been looking for something similar to enumerable data types in Elixir, cause at east all cool kids in the land of FP languages have some great syntax for that… I’d do something like this in Scala:

trait Priority 
case object Low extends Priority
case object Normal extends Priority
case object High extends Priority
case object Critical extends Priority

case class Task(title: String, priority: Priority)

val t = new Task("Buy eggs and bacon.", High)

I found this very helpful blog post about the same issue.
I think the most similar thing would be the module and behavior approach, but it seems as a big turn around to do that…

Anyway, it came up with a big existential doubt about what is right when it is about Elixir and its’ capabilities to compose its type system… at least simulate new types, I know structs are just syntatic sugar but I feel like every code is trying to do something like that, I mean simulate an extension of Elixir data types using it with pattern matching, protocols and/or behaviours, and after I watched this talk my feelings about it became stronger.

It’s a general question for this community, but I would love to hear from the core team:
Does Elixir give the power to programmers, by those features, to extend its basic type system? Would it be the language’s intention?

I’m very worried if I’m learning elixir concepts the right way.
Thanks

1 Like

why not just use atoms?

@type title :: String.t
@type priority :: :critical | :high | :normal | :low

@type task :: %{ :title => title, :priority => priority }

@spec new(title, priority) :: task
def new(title, priority) do
  %{ :title => description, :priority => priority }
end

alone these annotations don’t actually add any type safety but dialyzer can use them to provide a level of type safety

5 Likes

+1 on simply using a sum/union type(spec) based on atoms.

To learn more about success typing and dialyzer look here.

Hey, this is a better way to solve that problem, thanks! :heart:
Btw my question is a bit more abstract.

My personal take on it : YAGNI.

Elixir gives you Abstract Data Types through multiple mechanisms… and that is probably all you need. The rest you would handle through DSLs, or through different ways. If you really needs that much on new Datatypes… then you are probably doing something that Elixir and Erlang was not meant for.

But i may be completely wrong. I just do not see the use case.

(My personal background is in maths and Caml, so it am quite used to that kind of stuff)

My 2 Cents:

Much of the power of Elixir consists in it’s limited and fixed set of Data types. You’ve got the basic types and everything else is just a composition of those types. If you know how to operate on the basic types and any composition of those types, YOU CAN OPERATE ON ANY DATA YOU WILL EVER RECEIVE.

This is both hugely powerful and dangerous, as the man said “With great power comes great responsibility”.

Of course that statement above is true of every language ever, but Elixir makes it much simpler to actually create “universal” operators. While I am coming around to the advantages of typing, my opinion is that if you want really complicated strong typing, Elixir is probably the wrong language. There are just too many ways around to get around anything you create on top of the basics.

1 Like