add a pure keyword to functions

[inoas]

When reading Elixir in Action there was some notice box about Elixir being impure. I don't mind impurity but it would be great to know what you are working with.

So I'd love following pragmatic approach if it makes sense. Gleam's compiler cannot for FFI calls know if something is impure or not. So by default it should flag those as impure.

But the programmer could declare for FFI that they are pure.

A standard gleam function is marked as pure by the compiler pure if:

• it does not contain any function calls buth just expressions
• it contains function calls where all function calls are calling pure functions
  • these functions can be FFI functions, but then if those functions are not flagged explicitly as pure, then they are considered impure.
• otherwise it is marked as impure.

In consequence as of most of stdlib is unpure. But with a little work on the FFI calls and declaring those as either pure or impure explicitly we'd have a whole stdlib where people would know from the LSP if the whole call is pure.

I'd say - except for function's with todo where if no keyword is given a function is considered impure, if pure is given it is considered pure - purity is checked and inferred by the compiler, so if it is given explicitly by the programmer, a compile error will occur if purity declaration does not match.

pure fn foo() {
  todo
}

pub pure fn bar() {
  todo
}

impure fn quux() {
  todo
}

pub impure fn batz() {
  todo
}

pub impure external fn erlang_io_put_chars(text: String) -> Nil =
  "io" "put_chars"

pure external fn erlang_lists_maplist(callable: fn(a) -> b, list: List(a)) -> List(b) =
  "lists" "map"

The compiler could even flag hole modules as pure (if all functions are pure) and yield that into the generated documentation.

This way it makes it easier for the programmer to separate libraries and applications in parts that are pure such as algorithms/transformers etc. and parts that deal with side effects, and potentially keep the side effects very separated.

It might also help a lot with unit testing because pure functions are easier to test AFAIU.

[timjs]

This really is a lovely idea, but the story is a bit more complicated than this.

The problem starts with higher order functions. Take for example List.map. It depends on the function passed in, if the resulting call on map is pure or impure. Therefor, List.map needs to have some more complicated type, like (f: (a) -> p b, list: List(a)) -> p List(b), where the variable p denotes the (im)purity of the function. This is called effect polymorphism. So, (im)purity should be part of the type, and not an annotation on functions; and Gleam's type system would need to be extended with, what is called, an effect system.

More general effect systems exist. But if you'd only like to track (im)purity, this paper about Boolean effect polymorphism in the Flix language is exactly what you want.

[inoas]

I think giving the user the chance to annotate purity intention explicitly would be great.

At lowest level (ffi/native io calls) purity would be determined and carried throughout the compile process and the programmer could at the very highest level and only there declare purity and the compiler would tell them if they are right (though for logging and monitoring we might need exceptions?).

But I agree that it should be only required for ffi (in a potential gleam native it could know when io happens I guess?) and if not set always just imply impurity.

Would making pure/impure something you can mark functions with make the higher order problem / polymorphism problem any worse (from my shallow understanding, not?)

This feature could also be useful for say matcha templating and private functions that ate guaranteed to be side effect free:

See https://github.com/michaeljones/matcha/releases/tag/0.16.0

[lpil]

It would require a syntax that permits function to be parameterisable with effects, so the suggested syntax would not work.

[inoas]

counter argument to effects tracking - kind of:
`https://degoes.net/articles/no-effect-tracking´

[inoas]

And: I am also concerned about function declaration clutter:

imagined ‘bad’ examples:

- pub pure tailrec fn foo(f: fn(x) -> y) -> z
- pub external pure fn bar(f: fn(x) -> y) -> z

[lpil]

I think it would have to be more like this:

pub external type print(String) -> Nil with effects(Console) =
  "..." "..."

pub fn identity(x) -> x with effects() {
  x
}

pub fn apply(f: fn(x) -> y with effects(..z), a: x) -> y with effects(..z) {
  f(x)
}

I don't know what the syntax for custom types holding functions with effects might be.