I'm creating a programming language as a hobby, but I encountered a problem with designing its syntax. The problem is the conflict between the syntax for defining zero-argument functions and the syntax for reassignment operations. The function definition syntax is taken from Haskell, and looks like this:name arguments = expressionA zero-argument function would obviously have this form: name = expression. However, that poses a problem because, without context, the programmer could confuse such a definition with a reassignment operation (which has the same form, variable = expression).My solution is simple: ban functions with zero arguments. More precisely, such functions would now take a single value of the unit type as their argument. This is inspired by Scala, where functions that don't return anything, actually return () (of type Unit), which is a type with only one possible value that carries no useful information.The definition would then look like this:name () = expressionAnd a call would have the form name () -- note that '()' is not a parameter list, but rather the value of type Unit. The above definition relies on pattern-matching, as () is not the name of the argument, but the only form it can take.My question is whether such a design decision makes theoretical sense, and whether it would have some practical negative effects?
Banning zero-argument functions -- what problems could it cause in a hypothetical language?
language design;theory;type systems
I have decided to go through with this design decision for the following reasons:Such a convention is actually more consistent with the functional nature of the language. All functions are unary (accept a single argument) -- those accepting multiple arguments are simply curried, and those accepting none (as per this decision) actually accept the sole () value.Several functional languages already implement this convention, such as Ocaml (see the section How to define a procedure?), which gave me more confidence that it's not just a random hack I came up with.The decision itself allows for the interesting Haskell-inspired function definition syntax to be used, because the ambiguity between reassignment is removed (which is the original motivation for the decision, see the question).So the direct answer to the question is it doesn't not make sense theoretically, and has positive practical effects.