iodata

[michallepicki]

To integrate with Erlang modules and libraries that perform IO operations in an efficient manner, I think the stdlib could have some kind of "opaque" iodata type.

iodata in Erlang is defined as:

-type iodata() :: iolist() | binary().
-type iolist() :: maybe_improper_list(byte() | binary() | iolist(), binary() | []).

This type and module could be similar to Gleam's string_builder and mostly provide easy way to build up iodata and not much else.

[michallepicki]

A slightly related thought, for functions that only serve as "type casting" like RawValue.forget and similar, maybe there could be an erase version of external function definition - so that sesterl type checking is performed, but function calls are omitted at erlang code generation. I don't think the erlang JIT can erase such cross-module calls that do nothing because erlang assumes modules can be hot-reloaded.

forget(x) -> x. definition could be automatically generated and would be present in resulting module anyway for usages when compiler couldn't erase the call (like using that function in higher order functions).

Edit: But maybe it's not worth it and such function calls are not affecting performance in any way, I didn't measure - feel free to ignore

[gfngfn]

Thank you for your suggestion! I agree with the idea of introducing an opaque type that represents Erlang’s iodata(). I will use Gleam’s string_builder as a reference.

for functions that only serve as "type casting" like RawValue.forget and similar, maybe there could be an erase version of external function definition - so that sesterl type checking is performed, but function calls are omitted at erlang code generation.

Yes, I also agree with that. We can probably realize such functionalities by:

• developing an optimization phase that runs before generating Erlang code using techniques related to the partial evaluation (e.g. binding-time analysis), or
• introducing a kind of statically-typed macros based on the theory of multi-stage programming.

Since I currently develop Sesterl in a dogfooding way and the software I am writing by using Sesterl is not so large and thereby not suffering from performance problems, I tend to postpone the improvement about performance-related language features. Anyway, however, I will keep it in mind. Thank you!