FUN — Frequently Asked Questions

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.