Support for functional style

[PavelVozenilek]

Support for functional style

[jfecher]

Ante will definitely strongly support the functional style.

In fact, parameters are immutable by default already. Mutable parameters are accomplished with
the 'mut' modifier. At the call site the 'mut' is currently not required due to syntax concerns (consider a function that takes all mutable parameters, writing my_fun (mut par1) (mut par2) everytime is somewhat long-winded. There should preferably be a way to both indicate a mutable argument and do it concisely, I would love to hear your ideas because in my opinion my syntax above just does not blend well with the current syntax.

Global variables are also impossible to create or use currently, with the exception of argv and argc. The reason being that I just have not yet determined how they should interact with the rest of the language. Currently, I am leaning towards declaring them with the global modifier, eg. let global data = [0x32, 0x42, 0x00], or global data = []. Any function needing their use can "import" them with a python-esque statement: global data.

[PavelVozenilek]

The my_fun (mut par1) (mut par2) would be IMHO very useful. A hint what is going on, no need to dive deeply into the code or hope that the documentation is still valid. Alternative syntax could be e.g ! or ~ in front of the parameter symbol, but mut feels OK. Having modifiable parameter is a big thing, it deserves attention.

Possibly, the syntax could allow mutable access to some part of the parameter. Say S is a structure with members a, b and c. Function foo needs read access to the complete structure, modifies only a and b.

var S s
foo s<mut a, b>

To be useful compiler would need to statically verify this.

Is the parameter immutability "transitive"? I mean, does it protect whatever is reachable through it?

(To be clear: under immutable parameter I mean "not a mutable reference", that function doesn't change anything outside using it. Whether the function itself uses parameter as handy variable, I do not care.)

Global is not just about variables but also I/O access, sockets, calling ordinary functions, FFI, lot of things. Some languages use debugging related exceptions to this "no-global access" rule.

[jfecher]

Yes, the immutability is transitive. A function with some parameter x will not be able to modify x, any of its fields, any of those field's fields, etc.

I think the best way to implement a pure function would be with a new compiler directive ![pure]. These functions will not be able to call any non-pure functions, use global variables, or access a global state in any way (including I/O). This does, however present a new problem: now every function needs to be laboriously labelled pure or not to be checked correctly. The only solution I can think of would be to be the following:

Proposed module: Pure

module Pure
    pub ![pure], check_if_pure

import Ante

![compiler_directive]
fun pure: FuncDecl* fd
    check_if_pure fd ? Impure reason ->
        compErr reason

type PureResult =
    | Pure
    | Impure (Str, Loc*)

![onFuncCompileDone]
fun check_if_pure: FuncDecl* fd -> PureResult
     (implementation omitted)

Basically, (only) if imported, each function will be checked for purity after it is finished being compiled and tagged as pure by the function check_if_pure. Only functions explicitly marked ![pure] will throw an error if not pure. I think this would probably be the best way to implement such a feature. As for the implementation of check_if_pure, it can probably be split into several functions that are called when a function call is compiled, and if the called function is impure, so is the caller. If no such call is made, a separate function that executes onFuncCompileDone just checks a specific ctvar and marks the function as pure/impure based on that var with no need to iterate through the entire function.

For mutable parameters, I suppose the my_fun (mut par1) (mut par2) syntax may be for the best. It's not too long and it works well as a visual marker. There is also the : syntax for methods which modify the object. Normally, method-like calls would use the syntax obj.method arg1 arg2, but if the method requires a mut Obj then it would be called as obj:method arg1 arg2, which is much more concise than using mut, but is still noticeable visually. Although this distinction is already detailed in language.an I had been unsure about it for quite some time, but now I will put it on the todo list.

[jfecher]

I have to say, its quite pleasing whenever a new feature can be implemented so cleanly and efficiently using the compile-time features of Ante. It is, after all, the core feature of the language.

[PavelVozenilek]

Only few notes:

1. Being able to distinguish at the call site, whether I invoked pure or impure function, is IMHO the most useful information for the programmer.

2. Ability to annotate a whole module as "pure functions only", at one place somewhere at the top, compiler verified, would be handy.

3. Possibly the "pure" annotation could be also part of import statement ("I import only pure parts of this module"), although I am not sure whether it would that useful.