HigherOrderCO/Bend

Bend does not check that functions are used with the right arity

Opened this issue · 2 comments

data Array 
  = (Value x)
  | (Array a0 a1)

Array.foldl fn init (Value x) = (fn x init)
Array.foldl fn init (Array a0 a1) =
  (Array.foldl fn (Array.foldl fn init a0) a1)

main = (Array.foldl
          (@x @acc (+ x acc)) 
          // 0 // arity mismatch! uncomment for a program that finishes with `3`
          (Array (Value 1) (Value 2)))

The above program calls Array.foldl with two arguments instead of three, but the compiler doesn't catch that and instead expands the program somehow (can be seen with -d which I don't know how to read)

We allow partial applications by design.
Since the language is also not typed (constructors and pattern matching are just disguised lambda terms) we also don't know if you're passing a valid argument or not.

We could make functions with explicit arity (and not directly lambda encoded) require the right number of arguments to be passed. This means that users would need to write eta-reducible partial applications like @x (Array.foldl A B x), which would get optimized to remove the lambda during compilation.

I'll think about it

Ah! Alright, sorry for the confusion. This felt like a missed behaviour because I swear I saw the arity mismatch error somewhere. But that was probably when defining multiple functions of the same name, or calling ADT constructors or something.

I'm fine with this behaviour of allowing partial application by default, but I think it would be equally fine to be strict about it and let frontend language authors do

myFn = @a @b @c ...

instead of

myFn a b c = ...

if their language was to allow partial application.