Function Arguments

One of the biggest usability innovations of Enso is the set of argument types that it supports. The combination of named and defaulted arguments with a curried language creates a tool in which it is very clear to express even complex APIs.

Positional Arguments
Named Arguments
Defaulted Arguments
Optional Arguments
Splats Arguments (Variadics)
Type Applications
Underscore Arguments

Positional Arguments

Much like most programming languages, functions in Enso can be called with their arguments provided positionally. This is the simple case that everybody is familiar with.

Named Arguments

All arguments in Enso are defined with a name. Like all programming languages, this is necessary for that argument to be used. However, what Enso allows is for users to then call those arguments by name.

An argument is called by name using the syntax (name = value) (or one may also take advantage of the operator precedence to write name=value).
Named arguments are applied in the order they are given. This means that if you positionally apply to an argument foo and then try to later apply to it by name, this will fail due to currying of functions.
Named arguments cannot be used while using operator syntax. This means that an expression of the form a + b cannot apply arguments by name. However, when calling the operator as a method (a.+ b), the call-by-name syntax may indeed be used (a.+ (that = b)).

This is a great usability boon as in complex APIs it can often be difficult to remember the order or arguments.

Defaulted Arguments

Enso also allows users to define their functions with defaults for the function's arguments. This is very useful for complex APIs as it allows users to experiment and iterate quickly by only providing the arguments that they want to customise.

An argument is defined with a default using the syntax (name = default_val), which, as above, accounts for precedence rules.
Argument defaults are applied to the function if no argument value is provided by position or name for that argument.
Argument defaults are evaluated lazily if the function is lazy in that argument.
We provide a ... operator which suspends application of the default arguments for the purposes of currying.

Optional Arguments

There are certain cases where the type information for an argument may be able to be inferred by the compiler. This is best explained by example. Consider the implementation of a read function that reads text and outputs a value of a particular type.

read : Text -> t -> t
read text this = t.fromText text

You can use this function by explicitly providing the type information in either of the following ways:

val1 = read '5' Int
val2 = Int.read '5'

This, however, is often tedious, especially in contexts where this information could be inferred by the compiler. We can re-write read as follows:

read : Text -> (t=t) -> t
read text (this=this) = t.fromText text

This allows users both to provide the argument explicitly or leave it out. In the case where it is not provided, the compiler will attempt to infer it from usage. If this is impossible, an error would be raised.

Enso provides a syntactic sugar for the t=t syntax. The above code can be written instead using ?.

read : Text -> t? -> t
read text this? = t.fromText text

Splats Arguments (Variadics)

Enso provides users with the ability to define variadic functions, or splats functions in our terminology. These are very useful for defining expressive APIs and flexible code.

These work for both positional and keyword arguments.
They are defined using the syntax name..., where name is an arbitrary argument name.

The actionables for this section are:

Work out how (and if) this can interact with currying.

Do we even want this?

Type Applications

There are sometimes cases where the user wants to explicitly refine the type of an argument at the call site of a function. This can be useful for debugging, and for writing ad-hoc code. Much like the named-arguments in applications above, Enso also provides a syntax for refining types at the application site.

To refine an argument type by name at the application site, use the := operator (e.g. arg_name := T).
This will be type-checked by the compiler, and so T must be a valid subtype for the type inferred for (or defined for) the function being called.

Underscore Arguments

Enso provides the _ argument as a quick way to create a lambda from a function call. It obeys the following rules.

Replacing any function argument with _ will create a lambda that accepts an argument and passes it in the place of the underscore. All other function arguments are applied as normal.
This works both by name and positionally.
When a function is provided multiple _ arguments, they are desugared left to right as the arguments would be applied to the function definition, creating nested lambdas.

5.3 KiB Raw Blame History