Kotlin∇ tries to build a mathematically sound type system capturing the relationship between functions and fields. This design should be described more formally, but in short there are two approaches:
- The direct approach is to define
Fun<X>: Field<X> where X is a member of some algebra over the reals, equipped with the usual arithmetic operators. When applying an operator, it is evaluated eagerly and you get back X immediately. This is a shallow eDSL, evaluated eagerly.
- Another way is to treat the function as a member of a field whose elements are themselves functions, e.g.
Fun<X>: Field<Fun<X>>. Instead of returning X, operators return Fun<X> by default, which can be evaluated by using invoke(...): X (X and Fun<X> are both fields).
The second representation comes from finite field theory, which has important implications for expression parsing and language design. It would be useful to understand this connection more deeply.
References
Kotlin∇ tries to build a mathematically sound type system capturing the relationship between functions and fields. This design should be described more formally, but in short there are two approaches:
Fun<X>: Field<X>whereXis a member of some algebra over the reals, equipped with the usual arithmetic operators. When applying an operator, it is evaluated eagerly and you get backXimmediately. This is a shallow eDSL, evaluated eagerly.Fun<X>: Field<Fun<X>>. Instead of returningX, operators returnFun<X>by default, which can be evaluated by usinginvoke(...): X(XandFun<X>are both fields).The second representation comes from finite field theory, which has important implications for expression parsing and language design. It would be useful to understand this connection more deeply.
References