It has to do with divorcing the type from the variable or symbol to which it is attached. This is primarily on the return type, and not the argument types.
Consider the C-like example you gave:
int add(int a, int b) { ... }
The problem with this syntax is we can't describe the type of this function without a name. You can't remove the add bit and still have it make sense. In C function pointer syntax is weird because of this:
typedef int (*add_type)(int,int)
This defines add_type as the desired type, but we still don't have an actual way to say what that type without the name.
The left-return type declaration limits us from speaking of function types. This problem has been amplified by lamba functions: those without names.
The right-return syntax allows you to talke about function types without needing a name. Consider, using Leaf syntax
defn add = (a : int, b : int) -> ( : int ) { ... }
The type of add is (a : int, b : int) -> ( : int ). It doesn't require any new syntax, and can be specified without a name.
The other problem with left-aligned types is due to a lack of separator for a type. It causes problems for parsing and user-defined types and variables.
If you have public protected int add there is a convention that the right-most value is the symbol name.
But what about arguments? add( int x, int y ) What if you want the type without the named arguments: (int, int). With extended type information though it becomes difficult to determine what is a type symbol and what is the argument symbol:
(large int, int const, int large)
The right-aligned types differ in introducing an explicit type separator, the : in your TypeScript example. I use the same character in Leaf. This explicit type separator greatly simplifies parsing and eliminates all sorts of ambiguities, such as those in C++, when dealing with type names.
This change in syntax is due to an inrease in the use of the functional paradigm. We need a clean and consistent way to talk about types separate from their variables.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
It has to do with divorcing the type from the variable or symbol to which it is attached. This is primarily on the return type, and not the argument types.
Consider the C-like example you gave:
The problem with this syntax is we can't describe the type of this function without a name. You can't remove the
addbit and still have it make sense. In C function pointer syntax is weird because of this:This defines
add_typeas the desired type, but we still don't have an actual way to say what that type without the name.The left-return type declaration limits us from speaking of function types. This problem has been amplified by lamba functions: those without names.
The right-return syntax allows you to talke about function types without needing a name. Consider, using Leaf syntax
The type of
addis(a : int, b : int) -> ( : int ). It doesn't require any new syntax, and can be specified without a name.The other problem with left-aligned types is due to a lack of separator for a type. It causes problems for parsing and user-defined types and variables.
If you have
public protected int addthere is a convention that the right-most value is thesymbolname.But what about arguments?
add( int x, int y )What if you want the type without the named arguments:(int, int). With extended type information though it becomes difficult to determine what is a type symbol and what is the argument symbol:(large int, int const, int large)The right-aligned types differ in introducing an explicit type separator, the
:in your TypeScript example. I use the same character in Leaf. This explicit type separator greatly simplifies parsing and eliminates all sorts of ambiguities, such as those in C++, when dealing with type names.This change in syntax is due to an inrease in the use of the functional paradigm. We need a clean and consistent way to talk about types separate from their variables.