[eyelidlessness]

I don’t know enough about Gleam’s implementation to say how applicable this is, but from a more general language design perspective… a keyword isn’t inherently imbued with special capabilities that a function call wouldn’t be. They’re semantically interchangeable for this use case, if the function can access requisite information about the underlying stack.

I’m not sure it’s possible to extrapolate any lessons for Python from this Gleam language feature or the chosen syntax.

[bobbylarrybobby]

That's the problem though: I think the thing that makes functions functions it that they operate on values alone (whatever “value” means in the context of the language — but it almost certainly doesn't include code or AST or anything like that), and don't care about, or even get to see, the particular expression that produced a given value. The thing that makes statements (or macros, or various other compile-time stuff) not-functions is that they don't just have access to values, but to the code as well, which lets them do stuff like print the expression that produced a value, which a function could never do (in most languages; I'm sure there are some out there, maybe a LISP or something, that attach the AST to expressions as metadata).

[eyelidlessness]

Right, and that strict definition of “function” is especially important in a language like Gleam. It may be less so in a language like Python where “function” is a much more malleable concept already. All the more reason I don’t think one could reasonably extrapolate lessons about the latter from syntax design decisions in the former.