Consider using Elixir style maps instead of records in Gleam to erlang transpilation

[sidkshatriya]

Sorry if this issue has already been considered and definitively decided. In that case please feel free to close the ticket

I understand that gleam uses erlang style records extensively when transpiling to erlang.

Elixir uses erlang maps as a way to define structs. I think there are certain advantages to using maps -- when you see the key __struct__ while tracing you know for sure that it corresponds to an Erlang struct. The same cannot be said about records in erlang -- you cannot be totally sure if a tuple corresponds to a erlang record for sure. Also the keys in a map make understanding things much simpler during tracing/debugging. Whereas in a tuple you need to keep referring back to the record definition, especially if the record has many fields.

Is it too late to consider moving to the usage of maps in gleam transpilation? I'm guessing that maps are bit more resource hungry but there are ecosystem and debugging benefits to using them...

I'm sure a lot of the gleam user base will be coming from Elixir rather than Erlang. Currently to interoperate with Elixir better they might need to use something like https://github.com/QuinnWilton/strucord . We could avoid that entirely if gleam used maps under the hood instead of records. I have very little idea of how that will all work out practically as I've just started exploring gleam.

(I'm also taking the liberty of cc-ing @QuinnWilton in case there are any opinions on this topic -- Thanks in advance!)

[lpil]

Hello! Thanks for the suggestion. I agree that improving the interop story with Elixir would be greatly beneficial.

It's quite late to be making any large breaking changes to the core language, so we would need a clear reason to do so.

I see the following advantages

1. We could print label names as well as constructor names when debug printing
2. It would be easier to use Erlang or Elixir functions that use exclusively bare maps

and the following disadvantages

1. Gleam code would be mildly slower
2. Gleam code would use mildly more memory
3. We would no longer have record definitions which can be used from Erlang and Elixir to get the correct structure
4. It would be harder to use Erlang or Elixir code that uses records, including the common {ok, X} | {error, Y} records

I think the struct interop situation would not improve as much as you might want it to because while we would have a map, we would not have an Elixir compatible struct. A struct definition in Elixir also adds functions to the containing module, something we cannot do in Gleam as we can have as many custom types per module as you want.

While discussing this it would be good to also think about what other solutions might exist for this Elixir struct <-> Gleam record awkwardness. Perhaps some constructor functions in the generated Erlang

pub type Cat {
  Cat(name: String, age: Int, is_cool: Bool)
}

-module(mymod).

-export([catFromMap/1, catToMap/1]).

catFromMap(#{name => Name, age => Age, is_cool => IsCool}) ->
    {cat, Name, Age, IsCool}.

catToMap({cat, Name, Age, IsCool}) ->
    #{name => Name, age => Age, is_cool => IsCool}.

[inoas]

Is the autogenerated ´X_from_map´ and ´X_to_map´ still considered? Wouldn't this also make it pretty easy to create Elixir structs (from maps)?

> cat_map = :gleam_cat.cat_to_map(gleam_cat)
> struct(ElixirCatModule, cat_map)
%ElixirCatModule{name: "Jim", age: 99, is_cool: true}

... would this work?

[lpil]

I'm open to it, need some ideas and designs

[sdancer]

this is less general of a solution than exporting the metadata on each module for each type, allowing introspection and type safe transformations

[sidkshatriya]

Thanks for your reply. I like the generated constructor functions idea i.e. catFromMap, catToMap idea to reduce interop issues.

[lpil]

Great! Let's see if anyone else has any ideas and once we're happy we can make issues to implement anything we agree on

[TanklesXL]

I like the idea, though I have a couple questions:

• Would conversion functions like this be generated for every variant of a type?
• What do you do with name-only variants?
• What about type variants that have unnamed contents?

[inoas]

I think the closer we get to 1.0 the more important elixir interop is... Just my 2 cents: The easier it is to drop in Gleam into Elixir projects the more growth we might have there?

[sdancer]

two alternatives that would be good considering:

• add a new native type that the backend transpiles as maps
• add an attribute, so the struct is read/updated/written as a map

both would allow the programmer to decide what datastructure representation is better to their use case, being on par with erlang's exposed api (records and maps up to choose)

besides interop, another main benefit is that data upgrades are easier if the backing type is a map