dynamic & dynamic/decode vs unqualified types that I don't really understand.

[mjsir911]

hi!

this is a continuation of #4987

frankly, I think I'm a little bit confused about unqualified types in a mostly empty file with definitions like these:

https://github.com/Michael-Mark-Edu/bravo/blob/9ec7565fea973dac1192c266cd21c17cfeac256f/src/bravo/internal/bindings.gleam#L12-L18

@external(erlang, "bravo_ffi", "try_insert")
pub fn try_insert(
  tid: Reference,
  atom: Atom,
  key: k,
  value: v,
) -> Result(Nil, BravoError)

where are k/v coming from? are there any pointers to docs with regards to this kinda thing?

You're not supposed to use dynamic.from like that, that's why it was removed. Instead you'd be better off making your own types that precisely map onto the domain.

I'm not sure what this means when working with external functions like ets:lookup that return literally arbitrary data (#1717), some ets libraries touch on this, under "Why should I use Bravo over other libraries such as Carpenter?": https://hexdocs.pm/bravo/

@external(erlang, "ets", "insert")
pub fn insert(table: atom.Atom, tuple: #(dynamic.Dynamic, dynamic.Dynamic)) -> Nil

@external(erlang, "ets", "lookup")
pub fn lookup(table: atom.Atom, key: dynamic.Dynamic) -> List(#(dynamic.Dynamic, dynamic.Dynamic))

frankly, I don't understand how bravo's type system is working here: https://github.com/Michael-Mark-Edu/bravo/blob/main/src/bravo/internal/master.gleam

where is k and v coming from??? I'm obviously a lil bit confused about gleam's type system. at least oset uses k/v on the object definition

for building a generalizable ETS library, what types should I be using on the ffi?:

bravo uses the same un-qualified k & v types. I'm very confused: https://github.com/Michael-Mark-Edu/bravo/blob/9ec7565fea973dac1192c266cd21c17cfeac256f/src/bravo/internal/bindings.gleam#L20

gts does something similar: https://github.com/zunda-arrow/gts/blob/main/src/ets/internal/ets_bindings.gleam

I've seen some amounts of anytype or anything thrown around, I assume these were special escape-hatch keywords but maybe they are just the same kinda unqualified type that results in any kind of type being returned. how do that interact with the type system?

my question is basically: can I somehow shoehorn Dynamic onto all of this (like I have above) such that I can get typechecked erlang ffi interop (check that things are lists, strings, records, etc) when converting between a "black box" that is the erlang ets, but also have an escape hatch with dynamic for when I want arbitrary much-harder-to-qualify erlang data. like functions? gleam-lang/erlang#80 was created for atoms a long time ago, but is a patch to the stdlib required for every strict erlang type I want to be able to encode/decode? or maybe I have to optionally write some erlang code, with some type checks and create my equivalent:

@external(erlang, "gleam_stdlib", "identity")
pub fn cast(a: anything) -> dynamic.Dynamic

@external(erlang, "gleam_stdlib", "identity")
pub fn anytype(data: decode.Dynamic) -> anytype

perhaps even narrowing down the accepted & returned types for my specific context.

sorry for the ramble! Still learning quite a lot about the language and learning is a windy process

[mjsir911]

I found https://tour.gleam.run/functions/generic-functions which might be something although if I'm reading this properly, once a function with generic type params are used, that type is crystallized and it can't be treated as a different type?

[GearsDatapacks]

No, generic functions work as you would expect. They can be called any number of times with different argument types

[GearsDatapacks]

You are correct there. Those are generic types. k, v, anything which starts with a lowercase letter

[lpil]

Yup that's right, they're type parameters for a generic function. If you have not yet read the Gleam language tour def work through that. You'll have a much easier time once it has taught you all the features of the language.

The gleam/dynamic/decode module is how dynamic values are converted into well typed values, and it doesn't require changes to the stdlib to support any data type you define.

The dynamic type is typically not used for FFI. Instead one typically exposes Erlang or JS APIs that have types consistent with Gleam's type system, and then those functions are imported into Gleam as external functions.

[mjsir911]

what's the intended use for the dynamic module? It's a bit hard for interop-ing with the FFI and adding well-typed external functions when I'm working with functions like ets:lookup or erlang:binary_to_term, when the output could be anything without interfacing with the erlang VM to inspect type hints further, like with the dynamic module.

[lpil]

It's for data of unknown shape, so yes to binary to term, no to ets