External const

[Aloso]

Gleam currently has external fn and external type. However, it is difficult to access an external value. For example, to get the window object in Javascript, one must do:

external type Window

external fn get_window() -> Window = "" "(() => window)"

It would be much nicer if we could instead write:

external type Window

external const window: Window = "" "window"

[lpil]

That's an interesting idea! I can see how it would be useful with JavaScript. What would this do when compiling to Erlang?

I should note that the definition that uses an anonymous function may not work in modules that have another window in scope. I would recommend using globalThis or having a wrapper function in JavaScript.

[Aloso]

I can't answer that since I'm not familiar with Erlang.

One possibility is to only allow external consts when compiling to JS. Or is there a policy/requirement that every language feature must work with Erlang, because Gleam is first and foremost a BEAM language?

[lpil]

I think the language needs to be consistent across all targets as much as possible, so we would need to determine what it does on Erlang also. Erlang doesn't have importable constants, so we'd need to do something else there.

I'm going to turn this into a discussion as we've not got a firm design yet. Once we have that we can move back here.

[digitalcora]

Just discovered this since I was interested in making an "external constant" for Erlang. One possibility there would be to generate a function and an inline compile directive:

// example: can be a non-negative integer or the atom `infinity`
external type Timeout
external const zero: Timeout = "0"
external const infinity: Timeout = "infinity"

⬇️

-compile({inline, [infinity/0, zero/0]}).

infinity() -> infinity.
zero() -> 0.

You could also use a macro, but I think it would be a bit more complicated for the Gleam compiler to implement (the definition has to live in a separate hrl file and then you include it into each file that uses it).

[lpil]

There's no such thing as a constant in Erlang so it'd be at best "interpolate this string into the output of the compiler", which is error prone and not something I think we want to introduce for the sake of avoiding 1 function call.

[digitalcora]

Yeah, I can see how there'd be some complications there. But then, isn't that essentially what was proposed for JavaScript in the OP as well? To have something like external const window: Window = "" "window" but not allow arbitrary strings to be put in place of window seems like it would have the same problems. (And maybe what you are saying here is "Yes, it would, that's why this feature would need a very different design to be accepted", but I'm not sure if that is what you're saying 🙂)

[lpil]

Yes, the proposed design is not something I am in favour of. The fact people are using external functions today for string interpolation in generated code is regrettable and a mistake I made with the design.

[digitalcora]

Well, apologies for taking this discussion down a rabbit hole that wasn't very useful 😅 I'll keep thinking on the problem.

[lpil]

💜

[digitalcora]

New suggestion: external const which just does the same thing as external fn, but is treated as a constant by the compiler and is required to have no arguments.

external type Timeout
external const zero: Timeout = "myapp_ffi" "zero"
external const infinity: Timeout = "myapp_ffi" "infinity"

-module(myapp_ffi).
-export([infinity/0, zero/0]).

infinity() -> infinity.
zero() -> 0.

Advantages:

• doesn't try to invent a notion of "constants" in Erlang
• consistent with how Gleam already compiles normal constants to Erlang
• versus using an external fn directly, changing an external constant to an "internal" constant is a backwards-compatible change (if someone did this currently, code that called the old external fn with parens would be broken)

The main disadvantage is that you could do some wacky stuff with "constants" since they are actually a function call, which is a notable non-consistency with how Gleam constants work, though it's at least no worse than the native "constant" situation in Erlang.

It might also feel strange to apply this paradigm to JavaScript where actual constants exist and it might be preferable to use them over function calls (for performance reasons?). It could be made to work differently in JS, where instead of a function the name must refer to an exported value; external defs already work slightly differently between targets.

[lpil]

It's not possible to represent them because not all of the targets have that concept. There is no way around this and I think pretending that they do makes Gleam more confusing, not less.

An Erlang programmer will not be aided in writing FFI by having to learn what the Gleam version of what an Erlang constant is.

[digitalcora]

Then it doesn't sound like you're interested in adding the concept of external constants to Gleam at all, and perhaps this discussion should be "closed wontfix" 🙂 Or am I missing some way you'd still consider this?

[lpil]

I think the best way to think about additions is to first identify problems and then work backwards. I'm not interested in adding external constants in the abstract, but if there's a problem that can be solved with some design that fits that name, then I'm interested. I don't think having to write export const x => () => y over export const x = y is a problem, so it doesn't warrant adding complexity to the language.

[digitalcora]

I don't think that's really the problem I described, though... well, now that I've progressed a bit further, maybe I can provide a concrete example.

I have an external type ip.Address that is the Erlang type inet:ip_address(). This is defined as an untagged union of a 4-tuple or an 8-tuple of integers, so it's not possible to represent this as a single native Gleam type. Also, the integers have to be in specific ranges. So there's a parse function that goes String -> Result(Address, Nil) and everything's fine there.

There are some specific "special IP addresses" which it would be useful to provide as already-constructed values, so if you want to use one of those, you don't have to parse it or deal with a Result. For example the IPv4 "any" address, 0.0.0.0. Because these are "constants" in the same sense that Gleam constants are, I would like to provide them "as" a const, so the documentation and editor integrations and etc. will reflect this.

pub external const any_v4: Address = // somehow provide the Erlang value {0, 0, 0, 0}

What I could do instead, right now, is:

pub external fn any_v4() -> Address = "ip_ffi" "any_v4"

-module(ip_ffi).
-export([any_v4/0]).

any_v4() -> {0, 0, 0, 0}.

But this has some downsides:

• any_v4 is documented and understood by editors etc. as a function, though it is just a workaround to provide a constant value.
• If I change this to a non-external type later (maybe I decide I want to wrap it with an opaque type), even though it might now be possible to represent any_v4 as a Gleam const, I can't do that without it breaking existing code that's already calling any_v4() with the parentheses.

---

Sorry again for this back-and-forth... the way I read your comment from back when this was converted into a discussion, it sounded like you were already interested in adding this concept to the language, and were just looking for proposals on how it should work. Then again, that was ~18 months ago.

[lpil]

Those two downsides are downsides of the runtime rather than of Gleam. Modules are isolated things and code evolves over time, I don't believe there's a way to fit constants into that model unfortunately.

Sorry again for this back-and-forth... the way I read #1414 (comment) from back when this was converted into a discussion, it sounded like you were already interested in adding this concept to the language, and were just looking for proposals on how it should work. Then again, that was ~18 months ago.

Sorry, I was trying to explain why this is not a simple addition and how there would be significant drawbacks. I would be open to additions that solve problems in a way that is a good trade off for the given drawbacks.

[zwubs]

I was just about to create a discussion related to this topic, but found this old one! I'd completely forgotten just how much the Gleam language has changed and evolved over time. I'll preface this comment with the fact that I don't have much exposure to Erlang as a language, so my ability to discuss Erlang specific concepts might be severely lacking 😅.

I recognize that there's a lot of potential for the JS target with this, especially with the global window variable. But, I've been thinking about this and have a potential Erlang related problem that something like this could solve:

I've been utilizing const declarations to create defaults for records in an Erlang target Gleam project I'm working on. But, I ran into a record I'd created that had a field of type Dict. As things currently stand, I'm unable to utilize dicts in constants since dicts can only be created through calling a stdlib function. From this I looked at the stdlib to see how difficult/desirable adding a dict.empty constant would be, but quickly realized it wasn't possible. This led me to thinking about the ability to have external constants which would potentially allow for a constant empty dict to exist. And then I thought about the benefits to the JS target, and was glad to see some other people has similar thoughts here!

Now, obviously there are some work-arounds that I can utilize in my specific case to get around this:

• Utilize functions to return default record values
• Utilize an array of tuples instead of a dict

I'm not super excited about either of these work-arounds, but they would work. Utilizing functions instead feels like a lot of changes, and doesn't feel great that I was fine with all my other records until I got to this one. Now I would feel the need to change all of my other defaults for consistency because of this one instance. And the array of tuples solutions would potentially make my code a lot less performant/readable when compared to just using a dict.

So I guess my question would be, is this something that's at all desirable for Gleam? Are there some current philosophies in its design that a feature like this would go against? Would love to hear feedback on this and potentially caveats I might be missing! I know there are some intricacies with Erlang and this proposal that could make a feature like this tricky.

[lpil]

Any proposed design would need to support Erlang as well as JavaScript, because Gleam doesn't have target-specific features.