returns `as_string` of the current value

stop any further mutations of this element

NYI: UNDER DEVELOPMENT: The open/close/val features are tricky
for multi-threaded accesses. I think these should be removed
and added only to a closable variant of mutable fields to avoid
the extra checks and memory fences when accessing `open0`.

compare the value of this mutable field with an `expected` value. If it is bitwise
equal, replace the value by with the `modified` value.

If the value was replaced, return true, otherwise return false,

Note that bitwise equality may differ from equality defined by
`property.equatable.type.equality`. In particular, e.g., for `f64`, we have
`0.0 = -0.0` while both values differ when compared bit by bit.

For a reference type `T`, this operation will compare the internal representation
of the reference value, not the referenced value. In particular, this means that
references that are typically equal like `id String "Hello!"` and
`id String "Hello" + "!"` may be represented by distinct `String` reference
values.

Check that the mutate effect this was created with is still
instated in the current environment.

Different kinds of mutate will make different efforts for synchronization:

- for a thread-local `mutate`, this can be used only by the thread that instated
the `mutate`, no synchronization will be performed.

- for a `concur.blocking_mutate`/`concur.blocking_mutate_using_clock`, this will
use `exclusive` to ensure atomicity

- for a `atomic_mutate`, this will use an atomic compare-and-set operation.

compare the value of this mutable field with an `expected` value. If it is bitwise
equal, replace the value by with the `modified` value.

Independently of whether the value was replaced, return the original value. I.e.,
the value was replaced iff `result` is bitwise equal to `e`.

Note that bitwise equality may differ from equality defined by
`property.equatable.type.equality`. In particular, e.g., for `f64`, we have
`0.0 = -0.0` while both values differ when compared bit by bit.

For a reference type `T`, this operation will compare the internal representation
of the reference value, not the referenced value. In particular, this means that
references that are typically equal like `id String "Hello!"` and
`id String "Hello" + "!"` may be represented by distinct `String` reference
values.

Check that the mutate effect this was created with is still
instated in the current environment.

Different kinds of mutate will make different efforts for synchronization:

- for a thread-local `mutate`, this can be used only by the thread that instated
the `mutate`, no synchronization will be performed.

- for a `concur.blocking_mutate`/`concur.blocking_mutate_using_clock`, this will
use `exclusive` to ensure atomicity

- for a `atomic_mutate`, this will use an atomic compare-and-set operation.

creates a copy of the mutable field

dynamic_apply -- apply `f.call` to `Any.this`'s dynamic type and value

This can be used to perform operation on values depending on their dynamic
type.

Here is an example that takes a `Sequence Any` that may contain boxed values
of types `i32` and `f64`. We can now write a feature `get_f64` that extracts
these values converted to `f64` and build a function `sum` that sums them up
as follows:

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 hierarchy of types. So for Type values, dynamic_type is redefined
to just return Type.type.

read the current value of this mutable value.

If this is open, check that the mutate effect this was created with is still
instated in the current environment.

read the current value of this mutable value without any synchronization.

The read might be reordered resulting in an outdated or even an out-of-thin-air
result.

This will use the effect `concur.racy_access mutate.this` such that static analysis
of effects will detect and report code that uses racy accesses to mutable
variables.

Racy accesses are permitted only for types for which `mutate.this.atomic_access_supported T`
is true. This ensures that racy accesses do not yield crippled values such as an `i128`
consisting of lower and upper 64 bits that come from different values.

infix operator for put, OCaml/F#-style syntax

is this element open, i.e., can it be mutated?

NYI: UNDER_DEVELOPMENT: #7705 Proper synchronziation for accesses to this
flag and the mutable field is currently not ensured, the read_fences
are most likely insufficient

convenience prefix operator to create a string from a value.

This permits usage of `$` as a prefix operator in a similar way both
inside and outside of constant strings: $x and "$x" will produce the
same string.

update mutable field with new value

Check that the mutate effect this was created with is still
instated in the current environment.

update mutable field with new value without any synchronization.

The write might be reordered resulting in the new value becoming visible
to other thread earlier or later.

This will use the effect `racy mutate.this` such that static analysis
of effects will detect and report code that uses racy accesses to mutable
variables.

Racy accesses are permitted only for types for which `mutate.this.atomic_access_supported T`
is true. This ensures that racy accesses do not yield crippled values such as an `i128`
consisting of lower and upper 64 bits that come from different values.

unwrap this mutable value

update mutable field using a function of the old value

Different kinds of mutate will make different efforts for synchronization:

- for a thread-local `mutate`, this can be used only by the thread that instated
the `mutate`, no synchronization will be performed.

- for a `concur.blocking_mutate`/`concur.blocking_mutate_using_clock`, this will
use `exclusive` to ensure atomicity

- for a `atomic_mutate`, this will use a loop that performs `compare_and_swap`
repeatedly until the update was successful.

read the mutable value that is now immutable after it was closed for mutation.

string representation of this type to be used for debugging.

result has the form "<name>", but this might change in the future

There is no dynamic type of a type instance since this would result in an
endless hierarchy of types, so dynamic_type is redefined to just return
Type.type here.

Note: Typechecking is undecidable when 'type' is a type, Mark B. Reinhold, 1989
see: https://dspace.mit.edu/bitstream/handle/1721.1/149366/MIT-LCS-TR-458.pdf?sequence=6

Is this type assignable to a type parameter with constraint `T`?

The result of this is a compile-time constant that can be used to specialize
code for a particular type.


it is most useful in conjunction with preconditions or `if` statements as in


or

name of this type, including type parameters, e.g. 'option (list i32)'.

convenience prefix operator to create a string from a value.

This permits usage of `$` as a prefix operator in a similar way both
inside and outside of constant strings: $x and "$x" will produce the
same string.

NYI: Redefinition allows the type feature to be distinguished from its normal counterpart, see #3913

Get a type as a value.

This is a feature with the effect equivalent to Fuzion's `expr.type` call tail.
It is recommended to use `expr.type` and not `expr.type_value`.

`type_value` is here to show how this can be implemented and to illustrate the
difference to `dynamic_type`.