type

Builtin index · Collections & strings

result = type(x)

Input: x · Output: result

What it is

x is any value.

Overloads

One call shape — this function is not overloaded.

Examples

From the documentation, and run by the build -- the output and the figure below are what the engine actually produced. Simplest first.

words = ["banana", "apple", "cherry"]
print(sort(words))            # ("apple", "banana", "cherry") -- a List, lexicographic

nums = [3, 1, 4, 1, 5]
print(sort(nums))             # [1, 1, 3, 4, 5] -- a Vec, numeric

print(type(sort(words)))      # "list"

print(type(sort(nums)))       # "vector"

("apple", "banana", "cherry")
[1, 1, 3, 4, 5]
list
vector

from collections-strings

env = jsonify(3 + 4j)
back = parse_json(env)
print(env)          # {"type":"complex","re":3.0,"im":4.0}

print(type(back))   # complex

print(back)         # 3 + 4j

{"type":"complex","re":3.0,"im":4.0}
complex
3 + 4j

from file-io

env = jsonify(3 + 4j)
plain = replace(env, "\"type\":\"complex\",", "")
v = parse_json(plain)
print(plain)         # {"re":3.0,"im":4.0}

print(type(v))       # record

{"re":3.0,"im":4.0}
record

from file-io

i = 2
xs = [10, 20, 30]
print(i < length(xs) and xs[i] > 0)  # true -- short-circuiting guard

print(-1 mod 3)                       # 2 -- sign of the divisor

disp("disp, echo, writeline, and print are the same function")
echo("this line came from echo(...)")
writeline("and this one from writeline(...)")
print(type(3.5))                      # "number"

print(type("hi"))                     # "string"

print(shape([1, 2, 3]))               # [3, 1]

true
2
disp, echo, writeline, and print are the same function
this line came from echo(...)
and this one from writeline(...)
number
string
[3, 1]

from collections-strings

How it works

writeline is an exact alias of print; write is the same but without the trailing newline (Pascal/BASIC convention). type(x) -- the value's own type name, exactly the string this interpreter already puts in every "expected a number, found <type>" error message (Value::type_name). Added 2026-09-04 after finding there was NO type introspection in the language at all: a script could be handed a none, a string, a serial handle or a table and had no way to ask which it got, even though the engine names the type back at you the moment anything goes wrong. That asymmetry is the gap -- reusing type_name rather than inventing a second vocabulary means what a script reads and what an error message says can never drift apart.

From the note above this builtin in the interpreter, where the reasoning was written down as it was built.