Language Design – Problems with Banning Zero-Argument Functions

language-designtheorytype-systems

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 = expression

A 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 () = expression

And 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?

Best Answer

Sure, that makes sense theoretically. Especially in functional languages, having a function that takes no input is weird. Though I would encourage you to prevent declaring parameterless functions, not prevent them in your type system.

Consider parameter binding. If you have a unary function and bind a parameter to it, you would have a parameterless function even though you did not declare it. Having a special case to add a dummy parameter seems not great (but perhaps unavoidable).

Just using a different declaration operator than the equal sign seems like it would also be a viable alternative to deal with potential confusion (though parameterless functions will have impact elsewhere in the language).

Related Solutions

Language Design Rule – Negative Consequences

You've already created at least one inconsistency, and a particularly damning one at that - treating functions differently from other values. A function declaration is conceptually the same as binding a variable to an anonymous function, but you're asserting that "regular" variables don't get hoisted while function declarations do. So...

f()
function f() { /* ... */ }

Works, but...

f()
var f = function() { /* ... */ } // Pretend this is anonymous function syntax

Doesn't. (And if you don't allow passing functions around like any other value, your language is horribly crippled.) Next, what happens if a function is redefined?

f()
function f() { /* definition 1 */ }
...
function f() { /* definition 2 */ }

If you treat this as an error, you're once again rejecting functions as values. There's no reason you shouldn't be able to do:

var f = function() { /* def 1 */ }
f = function() { /* def 2 */ }

So let's assume you'll allow the function to be redefined. How do you deal with lexical scoping?

function f() { /* definition 1 */ }
function bar() {
    f()
    function f() { /* definition 2 */ }

If you hoist definition 2 to the top of bar's scope, you end up with this:

function f() { /* definition 1 */ }
function bar() {
    function f() { /* definition 2 */ }
    f()

Which means you can never call the outer definition from a nested scope unless you give the inner function a different name. Moreover, in any other language, the meaning of the above program is independent of the choice of name for definition 2. The hoisting rule changes the meaning depending on whether there's a name collision or not. On the other hand if you don't hoist definition 2 to the top of bar, you've broken your own rule.

Is duplicate syntax for defining named functions a bad language design decision

I think that having two constructs that mean the same thing but look different should be kept to an absolutely minimum in a language. Any duplication increases how difficult it is to read (and thus write/modify code in ) your language. Eliminating all duplication is unavoidable in a language that can create arbitrary constructs (for example, the equivalence of iteration vs recursion).

So in this case, I think it could be designed better here. A single way to define functions makes the most sense to me. In this case, it sounds like the two scala statements you have actually do have slightly different implications, which again is probably not good design (probably best to have something clear that states what the differences, like a keyword).

In fact, you can apply this principle not only to named functions, but to any function. Why have any difference in defining named functions and anonymous functions? In Lima, functions are always defined like this: fn[<arguments>: <statements>]. If you want it to be "named" you can assign it to a variable: var x = fn[<arguments: <statements>], and if you want to pass it in to another function anonymously: function[fn[<arguments: <statements>]]. If you want it hoisted, make it constant const var x = fn[<arguments: <statements>]. The single form makes it obvious that they mean the same thing.

Best Answer

Related Solutions

Language Design Rule – Negative Consequences

Is duplicate syntax for defining named functions a bad language design decision

Related Topic