The Nifty language — v0

Nifty is a small, statically typed language for native desktop apps. A .nf file describes state, logic and UI; nf build turns it into a native binary that uses the operating system’s own widgets (AppKit on macOS, Win32 on Windows, GTK on Linux).

v0 is the smallest language that can express a polished counter and todo app. Everything here is meant to stay; later versions add to it.

A complete app

struct Todo {
  title: string
  done: bool
}

state todos: [Todo] = []
state draft = ""

fn add_todo() {
  if draft != "" {
    todos.push(Todo(title: draft, done: false))
    draft = ""
  }
}

fn remaining() -> int {
  let count = 0
  for todo in todos {
    if !todo.done {
      count += 1
    }
  }
  return count
}

view Header(left: int) {
  row(align: .center) {
    label("Todos", style: .title)
    spacer()
    label("{left} left", style: .caption)
  }
}

window("Todos", width: 360, height: 480) {
  column(spacing: 12, padding: 20) {
    Header(left: remaining())
    row(spacing: 8) {
      text_field($draft, placeholder: "What needs doing?")
      button("Add", style: .primary) { add_todo() }
    }
    divider()
    for todo in todos {
      checkbox(checked: $todo.done, title: todo.title)
    }
  }
}

Projects and the nf tool

A project is a folder with a main.nf in it. Every .nf file in the folder and its subfolders is part of the app:

todo/
  main.nf
  ui/
    header.nf

• One namespace. The files share their top-level names, so a view, fn, struct or state declared in one file can be used in all of them. There is no include or import between files, and their order doesn’t matter, just as declarations within a file can come in any order.
• A name declared twice is an error, even in two different files, and the error points at both declarations.
• main.nf marks the project and must exist. Windows can be declared in any file.
• A subfolder with its own main.nf is a separate project, not part of this one. That includes the apps nf build writes into build/.
• A single .nf file given to a command, such as nf run demo.nf, is an app on its own, even when it sits inside a project folder.

project is a project folder or a single .nf file, and defaults to the current folder, so inside a project nf run and nf build need no arguments.

Lexical structure

• Source is UTF-8. Comments run from // to the end of the line.
• Newlines end statements. There are no semicolons. Inside ( ) and [ ] newlines are ignored, and a line ending in a binary operator continues on the next line.
• Identifiers: [A-Za-z_][A-Za-z0-9_]*. By convention values and functions use snake_case, and types and views use PascalCase.
• Keywords: state let fn view struct if else for in return true false.
• Integers: 42, 1_000. Floats: 3.14. A float needs digits on both sides of the ..
• Strings: "..." with escapes \n \t \" \\ \{ \}. {expr} inside a string interpolates any expression: "{count} of {total}".

Types

Types are inferred from initial values; write them only where nothing can be inferred, such as an empty list (state todos: [Todo] = []), parameters and return types.

There is no null. There are no implicit conversions; int and float do not mix.

Declarations

Top-level declarations may appear in any order.

state count = 0                       // app state; the UI updates when it changes
struct Point { x: float, y: float }   // or one field per line
fn area(w: float, h: float) -> float { return w * h }
view Badge(text: string) { label(text, style: .caption) }
window("App", width: 400, height: 300) { ... }

• state declares app-wide mutable state. Every view that reads a state value updates automatically when it is assigned. The compiler computes which widgets depend on which state, so an update touches only those widgets: no diffing, no virtual DOM.
• fn declares a function. Its return type defaults to “nothing”.
• view declares a reusable piece of UI with parameters, used like an element. Its parameters are values: a view shows what it is given and is rebuilt when that changes.
• struct declares a record type, constructed with named arguments: Todo(title: "x", done: false).
• window(...) declares a window. An app has one or more. window settings(...) names one, for open_window(settings) and close_window(settings).
• menu(...) declares a menu of the app’s menu bar; see Menus.

Statements

let total = a + b           // a local variable
count = 0                   // assignment to state, a field or a list element
count += 1                  // also -=, *=, /=
if x > 0 { ... } else if x < 0 { ... } else { ... }
for item in items { ... }
for index, item in items { ... }   // index counts from 0
for i in 0..n { ... }       // 0, 1, …, n - 1
return value
do_something()              // a call as a statement

• for index, item in items also names each item’s position, an int counting from 0.
• for i in start..end counts i from start up to, but not including, end; both are ints, worked out once before the loop starts. When end isn’t above start, the body doesn’t run. .. only appears here: a range is a loop form, not a value.
• The loop sets the index and the range’s counter each time round, so they can’t be assigned. The item of a list loop can, as described under expressions.

Expressions

From loosest to tightest binding:

• Calls take positional arguments first, then named ones: button("Save", style: .primary).
• A call may be followed by a trailing block on the same line: button("+") { count += 1 }. For layout elements the block holds children; for controls it is the action.
• .name is an implicit member: the value comes from the expected type, so align: .center means the center alignment.
• $place creates a two-way binding for controls that edit a value, and for built-in functions that report into state: text_field($draft), checkbox(checked: $todo.done), download(url, to: folder, progress: $percent, status: $status). The place must be state, or a for variable looping over state, optionally followed by fields and list items.
• Values are copied on assignment: after b = a, changing b leaves a alone. A for variable looping over a place is the exception: it stands for each element, so for todo in todos { todo.done = true } changes todos.
• Lists: [1, 2, 3], items[0], items.len(), items.push(x), items.remove(i).
• Built-in functions: download(url, to:, progress:, status:) saves a file from the web on a background thread, pause_download(id), resume_download(id) and cancel_download(id) control one, format_bytes(n) shows a size such as 1.5 MB, and pick_file, pick_files, pick_folder and pick_save_path ask the user for a path with the system’s file dialog, and open_window and close_window open and close a named window; see Built-in functions. Their names are reserved like element names.

UI

A UI block is a sequence of elements. if and for work inside it to show elements conditionally, once per list item, or once per count of a range. Element results are not assigned to variables; a view is a description, and the compiler builds and updates the native widgets.

Elements in v0

Text, titles and bound values can come from any expression and stay up to date. Layout numbers, styles, flags, the window title and placeholders are written literally, as in spacing: 12, style: .title, selectable: true and window("Todos").

align (cross axis): .stretch (default), .start, .center, .end. justify (main axis): .start (default), .center, .end, .space_between. surface: .none (default), .sidebar, .content, .card; see column.

Text styles map to each platform’s system text styles, so apps follow the system font and the user’s text size (Dynamic Type on macOS, Accessibility text size on Windows) without extra work. Apps follow dark mode on both platforms, and high contrast on Windows.

How the UI stays up to date

The compiler records which state each dynamic part of the UI reads, including state read inside functions it calls. When an action changes state, only the parts that read it are updated: a label gets its new text, and an if, for or view whose inputs changed is rebuilt in place. Showing the UI may read state but never change it; changes happen in button actions and through bindings.

Not in v0

Per-view local state, view parameters that are bindings, keyed for loops that keep unchanged rows, enums and match, closures as values, async work, networking, files, custom drawing. Each is planned; none is needed for the first apps. The syntax of the language features is already settled in Syntax decisions, rows 5–11, and What Nifty supports tracks where each one stands.

Syntax decisions

Rows 1–4 were settled by comparing this spec with an alternative sketch, and the draft’s form was kept in each case. Rows 5–11 settle the syntax of planned features before they are built, row 12 records a form added since, rows 13–23 were settled as the UI elements they describe were built, and rows from 24 on as downloads gained control. The reasoning is recorded so it isn’t relitigated.