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
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.
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
- Named arguments are applied in the order they are given. This means that if
you positionally apply to an argument
fooand 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 + bcannot 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.
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.
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
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
nameis 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?
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
arg_name := T).
- This will be type-checked by the compiler, and so
Tmust be a valid subtype for the type inferred for (or defined for) the function being called.
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.