FUN — Frequently Asked Questions

Yes. Since 2026-10-07 the hand-written-assembly path has an AArch64 backend, lib-asm-a64.fun, a sibling of the x86 lib-asm-pro. It is opt-in: Assembly = AssemblyA64();, so it never grabs the global Assembly and use-ing both backends stays deterministic. The encoding model is not x86's variable-length "append operand bytes": AArch64 instruction words are a fixed 32 bits, so a table value is <8-hex base word>|<slot>... and each slot shifts one operand field into fixed bits (register number, scaled offset, the bitmask immediate's N:immr:imms, the ADD/SUB imm12). Local labels and B/BL/B.cond are resolved in two passes. Covered: movz/movk/movn and mov aliases, add/sub immediate and shifted-register, logical ops, csel, loads/stores (offset, pre/post index, register offset, stp/ldp), branches, ret, nop.

Two things the x86 side never needed. First, an arch field per backend checked by Load(): choosing the wrong backend raises instead of silently executing foreign machine code (on aarch64 the old failure mode was SIGILL). Second, an _asm_flush(ptr, len) hook, because AArch64 I-cache and D-cache are not coherent; after bytes are copied into executable memory the backend must flush (libc/libgcc __clear_cache, falling back to cacheflush), and if no symbol is found it refuses to JIT rather than run stale bytes. Encodings were cross-checked byte-for-byte against the keystone/gas assembler (a 11407-instruction randomized differential: 10995 identical, 0 mismatches), and fun/test/tools/asm-a64-diff.sh re-runs that against gcc-aarch64-linux-gnu-as when installed. See The ARM64 machine-code layer is in.

No, and it is by design. Fun's low level puts capability ahead of foolproofing: arbitrary memory read/write (s.move(numericAddress), toNum(ptr:-1), fromByte), native calls (FFI / getapi), and executable memory with callbacks (lib-asm / NewJit / @toCallback) are all open to scripts. A source-reading essay puts it bluntly: the security boundary here is roughly zero, capability and risk share the same root, two sides of one design.

The author does not dodge it. The repo's SAFETY.zh.md sorts capabilities into NAT (native code execution), MEM (arbitrary memory), FSW/FSR (file write/delete/read), SRC (dynamic source loading) and ENV, and plans per-branch interception for a future fun.exe -safe. What has actually landed so far is only bounds checking (the MEM subset, 2026-09-14); the -safe switch itself is still a roadmap, not the status quo.

The stance is stated plainly: take C's functionality and expressive power first, and do not add chains for foolproofing; Fun is a window, C has no wall, only a difference of degree. The confidence comes from the path: self-taught assembly on DOS debug in 1999, following virus samples line by line, reversing bytecode, building the machine-level coordinate system first. The language grew out of that. See From assembly to Fun.

On Linux aarch64 it runs, with one gap. The interpreter, FFI, files, processes, networking, databases, crypto, regex and encodings all go through portable C libraries (libffi, libc, SQLite, libxml2, libcurl, OpenSSL, zlib, bundled PCRE) and behave the same as on x64, so there is no architecture code in them. The machine-code layer is x86-only. lib-asm and NewJit('#!asm ...') branch only on os and word size, never on cpu, so on aarch64 they still emit x86-64 bytes (the tables are a mapping of x86 text to x86 machine code, with operands appended as suffix bytes), and the result is SIGILL or, worse, nothing visible.

This is a deliberate honesty gap to close: add a CPU gate so non-x86 hosts raise a clear "not supported" instead of silently emitting wrong bytes, then grow per-architecture tables plus encoders (AArch64 is fixed-width 32-bit with operands shifted into bit fields, a different model), selected at runtime via 'host'.arg().cpu (which used to report cpu64 on aarch64 because the FPC macro was mis-spelled). lib-tcc is usable on ARM but its 2014-era arm64 backend needs smoke tests. LoongArch64 ranks below ARM and its real prerequisite is bootstrapping with FPC trunk 3.3.1. See Fun on ARM: only the machine-code layer is missing.

Because deleting one element in the middle is not a local operation. A set is one structure with two views: a positional CList (an array of pointers) and a name index in a CHash trie. Remove an element and the positions behind it must shift, so the CList and the trie's name table have to move in step. A mismatch shows up as the nastiest kind of bug: still found by name, but already off by index. The author's call is to keep that cost out of the language core and instead expose the raw CList pointer to libraries that really need it, letting them maintain the shift themselves.

So the built-ins registered on a set are only @count/@length, @has, @each, @add, @clone, @toJson: @add yes, delete no, and that is deliberate. The stdlib shows the route: in lib/lib-stack.fun, pop takes the CList data address with @count('ptr'), shifts with .move by the host word size, then shrinks with @count(-1). Rule of thumb: when some operation has no built-in, assume it was left out on purpose before adding a "complete" API; it may step on positional/named dual access, GC or reordering. See Things Fun deliberately does not provide.

Yes, and it is not a bug in either: the same Fun script can produce two results because the two RTLs differ. The project keeps a deterministic probe, fun/test/portability-probe.fun (all ?. prints, 75 lines), that uses only inputs free of time, randomness, paths and locale, so a snapshot from one compiler can be diffed against the other. On Linux/FPC it pins, among others: 2147483647 + 1 = 2147483648 (promotes, no wrap), -7 div 2 = -3 (truncates toward zero), round(2.5) = 2 (banker's rounding).

Handling order: first make the code not depend on the compiler (seed accumulators explicitly, use fun.intptr/fun.uintptr for pointers); only if that fails, isolate it in a {$IfDef FPC} platform branch and record it. Divergences fixed this way: FPC's AnsiString(variant) returns the Variant's own buffer while Delphi copies (CPcre needed UniqueString behind {$IfDef FPC}), and \uHHHH was only decoded inside {$IfDef Unicode} (non-Unicode builds kept the escape text; now they encode UTF-8). See One codebase, two compilers, two results.

No parser hook, no outline provider: it is Find All with one well-aimed regex. The expression sits in a plain-text sidecar next to funide.exe, funide.exe.presets; LoadFindPresets reads it line by line and each line becomes a menu item under the find box.

The 函数 preset has two branches joined by |. The first is a lexical guard for strings and comments (quotes by backreference, #*...*# blocks, # and // line comments, /.../ and %...% literals) wrapped in (*SKIP)(*FAIL), so a fun inside a string is never mistaken for a definition. The second branch matches a whole fun … end fun; or a class head, reusing subroutines (?1) guard, (?4) function, (?5) name. The find runs on TfSearch/CPcre, FUN's own PCRE 8. Each hit becomes a highlight; SetSearchHighlights also writes each hit's first line as a bookmark and calls RefreshTree, so the outline is just the search results projected onto the bookmark tree. The blue lens-shaped arcs are pure decoration, drawn in the ttAfter transient layer as a bezier forward and backward. Tradeoffs: the regex is brittle, the tree is per-line, nested functions are swallowed by the outer one, and the arcs are not a data structure. See Using a regex as an outline.

Two maps first: funide keeps the IDE layer in its own repo and links the language sources from a fun checkout at build time, so keep both the IDE tree and the layer copied into the language tree in mind. The whole IDE is about 5,300 lines of Delphi/VCL, and ide.pas holds almost everything.

Read in this order. funide.dpr is the one-page entry (FindIDE makes it single-instance via WM_DropFiles). Then the interface type block of ide.pas: TfIDE (the form), TfFiles/TfFile (documents, each with a per-line CRune[] table), TfEdit (SynEdit), TfTree (bookmark outline). The engine seam is just three objects: CdParser (a CParser) turns editor text into an AST, CdRunner (a CEnv2) runs it and buffers output, and the debugger is the hooks both override. Integration is a handful of overrides: OnParse(n) records fCodes[n.row] := n, echo caches output, trace/traced are the debugger. Then DoRun, then the debug hooks, then TfEdit/TfSearch and the three highlighters. A good first change: add a print inside CdRunner.trace and watch the AST go by, line by line. See Walking into funide: an IDE source-reading guide.

About 400 lines. funide does not spawn fun.exe: it compiles Fun's parser and interpreter into itself and drives them as libraries, so the debugger is just a few overridden hooks. CdParser.OnParse records each AST node by line number into one array slot per line, the index every highlight, breakpoint dot and stopped-line marker reads from. CdRunner.trace is called before each node runs, checks whether the current line has a breakpoint, and if so sets IsBreaked and waits in a while IsBreaked do DoEvents(true) loop (a message pump; the textbook frowns, it has worked for over a decade). Breakpoints and bookmarks are one byte per line in a single array; echo is redirected to the output panel.

The usual route, a debug-adapter protocol with JSON, IPC and compiler-emitted debug info, costs thousands of lines before the first breakpoint lights up. Going smaller: the author's Fun-written notepad-- is 301 lines (the editor surface is IE's contentEditable, highlighting is one regex file). z-data studio is 0 lines: it runs in the browser and borrows Monaco for highlighting and DevTools (F9 to run, then F12) for breakpoints, stepping, watch and profiling. The rule: whatever the platform already gives you, write none of it. See How small can a debugger be?

Yes. Fun itself opened on 2026-08-31; a month later, on 2026-09-30, its Windows desktop IDE funide went public under MIT at github.com/Funlang/funide (the repo was created on opening day but stayed empty for a month: the effort went mostly into the language, while the IDE side tidied a decade-old project into something others could clone, build and read). src/ide is about 5,300 lines of Delphi/VCL: ide.pas (engine glue + main form), ide.dfm (layout), the Fun/FD/regex highlighters, and a small debug skeleton.

It does not vendor a copy of Fun: funide.dpr links the units and PCRE sources from a fun checkout and drives the parser and interpreter as libraries (CdParser from CParser, CdRunner from CEnv2). So building needs a FUN checkout: sync-ide.bat copies the IDE sources into the right places, setenv.bat collects the machine paths, then make-2009.bat (Unicode) or make-2006.bat (ANSI) produces funide.exe next to fun.exe. Windows 32-bit only for now, and the three third-party pieces (SynEdit, VirtualTrees, PCRE 8) are not bundled. See funide open source: handing over the IDE too.

getJson(json: 2) makes the JSON scanner strict. It rejects the separator-grammar and lexical slips the lenient default tolerates: trailing/leading/duplicate/missing commas ({"a":1,}, [,1], [1,,2], [1 2]), a missing or doubled colon, ; or = used as a separator, single-quoted or backtick strings, @ dates, 0xff, nil, non-string keys, a closing bracket that does not match the container it closes, and any value trailing the top-level one. Strings must use double quotes and only RFC escapes. Numbers are deliberately kept lenient: .5, 03 and 1. are still accepted (real-world JSON contains them), and only a digit-less token such as . or - is rejected. Bare scalar roots (20, "hi", true, null) are legal. No extra pass is added: the strict string checks ride along the closing-quote scan and esc() is untouched, so lenient mode and FD parsing stay byte-identical. See JSON strict mode: take .5, reject the trailing comma.

The runtime version lives in one compile-time constant (src/core/version.inc), and two paths read it so they cannot drift: 'host'.arg() has a version field (numeric build stamp, YYYYMMDD), and N.time() for any N in 2010..2099 returns the same number — so a script can gate on it with an ordinary comparison, e.g. if 2010.time() >= 20250819 then … (this is what lib-ajax does). The human-readable release string (9.0) is the fun field of 'host'.arg(); a regression in lib-host-test.fun asserts the two numeric paths agree. version.inc is regenerated by a pure-Fun script, fun src/prj/fun/gen-version.fun [YYYYMMDD] [release] — no shell and no git, so the same command runs on Windows and Linux (defaults to today; pass an explicit date for a reproducible release). See Where does the version number come from?

FUN's = is deliberately loose: nil, 0, '' and false are all equal, '1' = 1, strings compare case-insensitively, and 1 = 1.0. That is handy for values read from the outside, but it cannot tell 0 from NULL — an ORM once bound every 0 and FALSE as SQL NULL because of it. When you need an exact test use eq(): true only when the logical type and the value both match (nil/0/''/false are distinct, '1' <> 1, 'ABC' <> 'abc', 1 <> 1.0). type() returns a portable logical type id, anchored to COM VARENUM (nil 0, integer 3, real 5, string 8, bool 11). Both apply to basic (non-object) values, and the loose = is unchanged. See How does 0 become NULL?.

You can start a thread (call pthread_create via getapi; on glibc before 2.34 the symbol lives in libpthread.so.0, not libc), but a thread is only safe if it never runs the same function as another one. FUN keeps a function's locals in one per-function store (CFunStack with a CVarStack per variable), using a level counter for recursion — so two threads inside the same function body trample each other. You also need FPC's thread-safe heap (cthreads), which locks every allocation and costs about 20% on single-threaded runs; since 2026-09-25 it is opt-in (./make-linux-x86_64.sh -dUseCThreads), so default builds are faster and drop the libpthread dependency.

That is why the Linux backend of lib-winsock is a single-threaded poll(2) loop that calls its handlers inline. For async without threads it offers Scheduler Post / After / Every. See Why this server has no threads.

Yes. Since late September 2026 libase registers an input builtin whose receiver string picks the mode — the read-side sibling of the ?. output operator: 'line'.input([prompt]) reads one line (line ending stripped), 'char'.input([prompt]) reads a single keypress (raw mode on a terminal), and 'all'.input([prompt]) reads everything up to end of input. On Linux it reads standard input byte by byte straight from fd 0, so piped input and a live terminal behave the same and no buffered byte is stranded for the next call; on Windows it reads lines through the RTL, in the build's string encoding.

Because FUN treats '' and nil as equal, a blank line and end of input are indistinguishable by the return value alone. Pass a variable as the second argument (or ok:) and it receives a flag: true when something was read, false at end of input — the reliable way to end a read loop. See For that hundred-million-dollar AI project!.

Yes, on Linux it runs headless. The web stack is lib-winsock-lnx: BSD sockets on libc with a single-threaded poll(2) event loop (HTTP/WebSocket and UDP servers, plus TCP/DNS clients), no window and no worker threads. On top of it, lib-jsonrpc-lnx is a JSON-RPC 2.0 service over HTTP on the route /JsonRpc/2.0; the Windows version was a lib-ui Form() driven by WSAAsyncSelect and a user32 message pump, while the Linux one just serves on the calling thread — one rpc.start() binds, listens and runs the loop until stop(). Dispatch is unchanged: define Rpc_<Method> members and onCall routes to them, with the standard error codes (-32700/-32600/-32601/-32602/-32603). lib-orm-rpc-lnx is the same thing with a database: class OrmRpc = JsonRpc() keeps the Rpc_Orm* protocol on SQLite, and OrmInit builds the ORM schema straight from the database via lib-ado-schema-lnx when the client does not send one. See The RPC server without a window.

FUN uses a lightweight reference-counting garbage collector: an object is freed when its reference count reaches zero — no generational mark-and-sweep, no concurrent GC. That keeps the runtime small, but it also means one missed release leaks. A real case fixed on 2026-09-18: CExp cells were allocated on every nil short-circuit and string-index read but never released (the receiving field was borrowed), so fun-zillio's rdb backend leaked about 0.7 KB per request and RSS grew linearly with request count; the fix reuses one preallocated cell per site. A related, non-leak hazard is denial of service: JSON/FD scanning is iterative, but releasing and cloning the tree is recursive, so thousands of nesting levels overflowed the stack — documents nested deeper than 512 levels now raise instead. See One CExp leaked per request, and 512 levels of nesting.

The FUN core repository was first open-sourced on 2026-08-31. Over the following couple of weeks the version went from v9.0 to v9.1 (11 releases, 84 commits), driven by a single main line: taking FUN from compiles on Linux to full-stack parity between Linux and Windows. The Linux side gained libffi, OpenSSL, zlib, PCRE, libxml2, libcurl, SQLite/ORM and libtcc, lifting module loadability from 0/59 to 48/59; pointer-width consolidation and a bounds-checking rework landed along the way. There are roughly 724+ regression cases in total, and about 90% of the codebase is open. See FUN tech overview: fifteen days since open source.

FUN is a tree-walking interpreter: a pure-interpreted fractal benchmark runs at about 2310 ms, roughly between Python and Perl — raw speed is not the pitch. When you do need performance, hot paths can sink to native execution. All four escape hatches were reproduced on Linux: FFI into C libraries, runtime C through the embedded TinyCC, x86_64 assembly on an mmap'd executable page, and JIT closures with bidirectional callbacks. The inline-assembly path measured 19.0 ms, about 120× faster, and the interpreter's own 55-item benchmark suite passes in full. See Four escape hatches: from 2310 ms to 19 ms.

Yes. A code block whose first line is #!asm is assembled at load time, alongside #!hex (raw machine code) and #!c (compiled at runtime by the bundled TinyCC); lib-asm/jit dispatches between them and the result is registered as a normal callable with an FFI signature such as 'ii:i'. The assembler is a table lookup: each normalized line is matched against asm-list.fd, so its ability is exactly what the table contains. It used to be 32-bit oriented, which is why #!asm was awkward on x86_64; the 2026-09-16 update harvested 1.74M instructions from 20 Linux binaries and added the 3250 most frequent x86-64 forms (REX registers, push/pop r12-r15, rbp frames, disp8 locals, RIP-relative lea), covering 90.7% of that corpus. Note there is no label or relocation pass: branches must be pre-assembled as a block or routed back into Fun through <name> callbacks. See 给查表汇编器补上 64 位.

It used to. FUN's value model stores integers in a 32-bit slot, so any address that travelled through fun.int lost its high half on x86_64/Win64: stack push/pop crashed, .move()/.movs() read or wrote the wrong memory, and getapi() with a bare address always faulted. The interpreter now reads and stores addresses at pointer width through asPtr/rawPtr and the fun.intptr/fun.uintptr aliases (the platform test lives in one place), and the builtin-registration and dispatch paths were converted too. 32-bit builds stay bit-identical, and the lib-stack, JSON cycle-detection and libase raw-memory paths were fixed along with it. See 64 位的地址，32 位的格子.

Strings are reference types. Assignment and argument passing copy the reference, not the buffer, so b := a; b[0] = 'H' also changes a. That is intended rather than a bug: lib-cstruct.fun's goBytes relies on a callback parameter being an alias of its caller's buffer, so no copy-on-write is added. Indexing follows the range documented in lib/lib-string.fun (0..N-1 from the front, -N..-1 from the end). An out-of-range read gives a safe default (nil for s[i], 0 for .toByte); an out-of-range write raises instead of corrupting the string header or the heap. Objects are freed by lightweight reference counting. A few primitives stay deliberately unsafe (s.move(numDest), toNum(ptr:-1)). See what happens when you go out of bounds.

A module is just a script, and use links it into the current scope: use 'lib-fd.fun' brings in its names, or use 'lib-fd.fun' as fd binds it to a variable as a namespace. A module is loaded only once and its top-level code runs only once, no matter how many places use it. Paths are resolved relative to the caller's directory first, then the lib\ and app\ directories next to the executable; the : prefix pulls an embedded resource instead of a file (for example use ':fd.bnf.fd'). Because use ... as binds a module to a variable, you can import the same module under different names in different scopes.

FD is a data format built into FUN. It keeps JSON's structure (nested keys and arrays) but uses an indented, Markdown-like syntax that is easier for humans and language models to read. It converts both ways with JSON through @toJson(fd: true) and getJson(fd: true); lib-json.fun wraps them as FD.Parse / FD.Stringify. Its distinctive trait is that it is self-describing: the specification fd.fd and the grammar fd.bnf.fd are themselves written in FD, and the parser is compiled from that grammar at runtime. See a data format that describes itself.

Yes. FUN runs natively on x86_64 Linux (the interpreter is built with Free Pascal and gcc). There is no separate installer: get the source from github.com/Funlang/fun and run src/prj/fun/make-linux-x86_64.sh. Two optional third-party pieces (PCRE 8 for regular expressions, Tiny C Compiler for runtime C / JIT) are not carried in the repo; if one is missing the build degrades with a notice instead of failing. On Linux the standard library provides platform-specific backends named *-lnx.fun. See one module, two backends and porting the FUN interpreter to Linux.

FUN is a scripting language, but its interpreter is written in Pascal and is built with either Delphi (32-bit Windows) or Free Pascal (FPC) (Linux, 64-bit Windows, ARM, including cross-builds). FUN was created to reuse Pascal resources: it can call modules and system APIs compiled in Pascal/Delphi, while remaining an independent dynamic language rather than a Pascal dialect.

Nuva is an earlier language by the same author (2006, preceded by TemplateScript in 2005); FUN is its successor, and the two are separate languages.

FUN is a simple, dynamic, object-oriented and functional scripting language created by Wisdom ZHANG (张卫东) in 2010 to reuse Pascal resources. It ships as a single fun.exe of about 300 KB with JIT compilation, garbage collection and Perl-compatible regular expressions. Read the overview and the manual.

Probably not. "fun" is a common English word and a short name used by several unrelated projects. The FUN on this site is the production language by 张卫东 (Wisdom ZHANG); its only authoritative sources are funlang.org and github.com/Funlang. See Which FUN? — authoritative sources.

Yes. FUN 9.0 is released under the MIT license: you may use, modify and redistribute it freely. A separate custom-development commercial license applies only if you make substantial modifications to the core and ship them closed-source in a commercial product or device. Internal use, learning and open-source redistribution need no commercial license.

Yes. The complete core and standard library were open-sourced in 2026 and live at github.com/Funlang/fun. You are welcome to fork it, build it and contribute.

Windows (32-bit and 64-bit), Linux, ARM and Windows CE. It runs as a standalone fun.exe or can be embedded as fun.dll, and the runtime has no external dependencies.

Download fun.zip (runtime + IDE, version 9.0), unzip it, and run fun-install.bat to register the .fun file association. Then double-click any .fun script, or launch the bundled IDE. See Quick start.

No. FUN has evolved continuously since 2010, grew out of the Nuva language (2006) and TemplateScript (2005), and has run in production for years, underpinning commercial software used in more than 130 countries. Version 9.0 is a mature release.

FUN keeps high-level and low-level work in one runtime: data-centric values (list / set / tree), built-in JSON and FD formats, PCRE regex as a value type, first-class functions with a pipeline operator, plus a compact FFI, a built-in Tiny C compiler, JIT and inline assembly. Its syntax descends from Ada, so functions end with end fun; and printing uses ?.. See feature highlights.