☰
infix ||||>
infix ||||>
§(A type, B type, C type, D type, R type, a tuple (infix ||||>.A) (infix ||||>.B) (infix ||||>.C) (infix ||||>.D), f Function (infix ||||>.R) (infix ||||>.A) (infix ||||>.B) (infix ||||>.C) (infix ||||>.D)):Any => infix ||||>.R
§(A
type
, B type
, C type
, D type
, R type
, a tuple (infix ||||>.A) (infix ||||>.B) (infix ||||>.C) (infix ||||>.D), f Function (infix ||||>.R) (infix ||||>.A) (infix ||||>.B) (infix ||||>.C) (infix ||||>.D)):
Any =>
infix ||||>.RFunctions
create a String from this instance. Unless redefined, `a.as_string` will
create `"instance[T]"` where `T` is the dynamic type of `a`
create `"instance[T]"` where `T` is the dynamic type of `a`
Get the dynamic type of this instance. For value instances `x`, this is
equal to `type_of x`, but for `x` with a `ref` type `x.dynamic_type` gives
the actual runtime type, while `type_of x` results in the static
compile-time type.
There is no dynamic type of a type instance since this would result in an
endless hierachy of types. So for Type values, dynamic_type is redefined
to just return Type.type.
equal to `type_of x`, but for `x` with a `ref` type `x.dynamic_type` gives
the actual runtime type, while `type_of x` results in the static
compile-time type.
There is no dynamic type of a type instance since this would result in an
endless hierachy of types. So for Type values, dynamic_type is redefined
to just return Type.type.
This allows changing the order of function application: instead of
f(a,b,c,d i32) => a+b+c+d
t := (1,2,3,4)
r := f t.0 t.1 t.2 t.3
you can write
f(a,b,c,d i32) => a+b+c+d
t := (1,2,3,4)
r := t ||||> f
which often correponds more naturally to the data flow through the code.