User defined tags and type-safe structs for domain modelling (Domo library)

Add proper encapsulation) I had some fun with solving similar issues in Elixir, and encapsulation and new types was the most interesting, finally kinda got solved with this (link to article with explanation)

https://github.com/timCF/calculus#calculus

And then I used Calculus to build functional programming library

https://github.com/tkachuk-labs/wonderland#wonderland

But at some point, I just realised that it’s easier just to use Haskell where all this kind of problems are solved many years ago)

It seems the Haskel was your tool of choice.

The Domo library is about flexibility - to give a possibility of type-safe structs in existing codebases written in Elixir.

Yeah) Once I had started with Haskell, I always wanted more - more newtypes, smart constructors, type classes, generics, dependent types, type families.. ohhh boyyy, it’s sooo huge unknown universe. Even after a year of Haskell production I think I know (understand) just around 25% of already existing stuff there, even if we exclude some overwhelming things related to Idris and Agda advanced type systems.

But regarding Erlang/Elixir I kinda gave up finally, it’s untyped languages anyway whatever you are doing with them. But it’s still cool to see people there are looking into type systems.

I think that library can work quite well. I don’t have any immediate remarks on it.

The main trouble is going to be social, not technical however. This effectively kind of changes Elixir (if I am understanding your Order.new! snippet correctly) and many people wouldn’t agree to adopt such a new syntax in their projects.

I also kind of gave up on the idea that the BEAM languages will have actual strong static typing for now (except maybe for Gleam that draws inspiration from Rust and thus from the ML languages as well; but it’s still figuring out its message sending interaction with the strong static typing IIRC… @lpil, am I off the mark here?).

What I do in my projects is just conservatively use as much pattern matching as possible without losing [a lot of] productivity.

Your idea is good but (a) introduces extra coding (the deftag thingies) and (b) a rather new syntax. IMO dedicated teams can make your library work for their process quite well but many others will choose not to.

If one day I have enough time and energy, I’d invest in a linter (likely as a part of credo) that could e.g. yell at you if you do this:

def do_business_stuff() do
  # ...
  Repo.insert(...)
  |> elem(1)
end

…which wrongly assumes success and blindly returns the second element of the tuple, ignoring the fact that the insert might fail and a Changeset be returned instead of the expected successfully inserted in the DB struct. (And I’ve seen Elixir code exactly like this one.)

But… that particular case could likely be covered with Dialyzer if you only add @spec to this function. Then Dialyzer could tell you that you are expecting a User to be returned but you could also get Changeset. So still not sure. As I said, just ideas that I might get to one day, life allowing (which it absolutely doesn’t for months now).

TL;DR: Looks pretty good but I am not sure it will gain traction with the requirements you put on your users.

We’ve got statically typed messages and processes working great! There’s a few options on the table currently, so now we’re figuring out which is best and what the API should be,

Thanks for kind words.

The Domo library suggests using additional syntax for making/pattern-matching of Tags and for defining type-safe structs.

I usually address the new concept adoption issue in a team with turning up the following idea - give it a try for half an hour, and if you definitely don’t like it it’s always possible to go with something else.

I am also looking to have typed structs in Elixir to be happy enough with the language, but the boilerplate necessary always put me off, and I just go with using pattern matching and guard clauses as much as possible, just like @dimitarvp.

What I am looking for is a cleaner solution:

defmodule AuthIt.UserProfile do
  @enforce_keys [
    id: is_integer/1,
    name: is_binary/1,
  ]
  defstruct @enforce_keys
end

But I guess that this will never be possible

One possible way to do this is with Domo in more declarative style like this:

➜  domo git:(master) cd example_app
➜  example_app git:(master) iex -S mix
Erlang/OTP 22 [erts-10.6.2] [source] [64-bit] [smp:8:8] [ds:8:8:10] [async-threads:1] [hipe]

Interactive Elixir (1.11.0-dev) - press Ctrl+C to exit (type h() ENTER for help)

iex(1)> defmodule AuthIt.UserProfile do
...(1)>   use Domo
...(1)>
...(1)>   typedstruct do
...(1)>     field :id, integer
...(1)>     field :name, binary
...(1)>   end
...(1)> end
{:module, AuthIt.UserProfile,
 <<70, 79, 82, 49, 0, 0, 31, 176, 66, 69, 65, 77, 65, 116, 85, 56, 0, 0, 3, 2,
   0, 0, 0, 63, 25, 69, 108, 105, 120, 105, 114, 46, 65, 117, 116, 104, 73, 116,
   46, 85, 115, 101, 114, 80, 114, 111, 102, ...>>, :ok}

iex(2)> alias AuthIt.UserProfile
AuthIt.UserProfile

iex(3)> UserProfile.new!(id: 1, name: "John")
%AuthIt.UserProfile{id: 1, name: "John"}

iex(4)> UserProfile.new!(id: "John", name: 1)
** (ArgumentError) Can't construct %AuthIt.UserProfile{...} with new!([id: "John", name: 1])
    Unexpected value type for the field :id. The value "John" doesn't match the integer type.
    Unexpected value type for the field :name. The value 1 doesn't match the binary type.
    lib/domo/struct_functions_generator.ex:20: AuthIt.UserProfile.new!/1

The field types in the field macro are from the usual @type spec.

If you may want to distinguish between different ids in the app, then tags come into play. With

deftag AuthIt.UserProfile.Id, for_type: integer

you can do the following: UserProfile.new!(id: UserProfile.Id --- 1, name: "John") and get the exception/error for UserProfile.new!(id: 1, name: "John") where 1 is not a tagged integer.

I come from a background of dynamic interpreted languages, all this compilers stuff is new to me, thus sometimes I get things in the wrong way.

This being said I like your declarative way example of using the example I gave, but this:

I just don’t get it, and this tags was what made me to not like Domo in the moment I saw it. I just don’t grasp them and they have a weird syntax.

That’s a good example and it’s something that I could see myself doing because I go 99% the way anyway (by using guards in new / create functions). Yours is a bit cleaner.