Specification of the Dyna Language

Introduction

What is Dyna?

Intended users

Key features

Relation to other work

How to read this specification

Organization

Notation

User comments

Coloring and formatting conventions

Cross-refs

Notifications

Glossary/Index

Terms (i.e., ground terms)

Overview

Primitive terms

Booleans

Numbers

Strings

Escape codes

Blobs

Compound terms

Functors

Single quotes

Positional arguments

Operator syntax

Keyword arguments

List syntax

Reserved functors

$ convention
$error
$null

Sets

Dynabases

Full discussion in Dynabases.

Gensyms

Frozen terms

Full discussion in Frozen terms.

Patterns (i.e., non-ground terms)

Variables

Variable names

Underscores

Non-ground terms

Types

Unification

Frozen terms

Dynabases

Overview

Items

Null items

Syntax for items

Brackets vs. parentheses

Quoting items with &

Evaluating terms with *

Assertions

Queries

Simple queries

Complex queries

Expressions

Aggregating queries

Accessors

Query modes

Some discussion of current approach is in Pragmas.

Lambdas

Terms as dynabases

Updates

Update modes

Stability

Dynabase types

Extensions

Const declaration

Snapshots

Inspecting and modifying dynabases

Abstract API

Command line interface

Graphical interface

Programming interface

Dyna programs

Overview

File format

Rules

Definition

Aggregation

Guards

Fixpoint semantics

Errors
Cycles
Stability
to nwf:

I think I really want the semantics of dynabase extension to be the same as the semantics of updates. This means that when you extend a dynabase, you don’t disturb randomness or cycles that are not transequents of your extension. Whether dynabases become new in an update is not answerable from within Dyna, I think, because the old dynabase can no longer be accessed; but it should be answerable from outside, e.g., d.e may be different before and after we update d.e.x += 1. This may be up to the implementation. (Certainly snapshots of those two are different.) But maybe two snapshots both before the update should be the same.

(All queries are against snapshots, so how do we actually get a live version of e? Maybe we can’t. Or maybe queries are not totally against snapshots after all – the snapshot is taken only to get the path to e but the thing that that path points to is live by default, so the recursive snapshotting doesn’t go all the way down. Anyway, if we do get two snapshots of e before and after, then they must be different in the sense that they get different results when we query them.)

See discussion of current implementation in When Things Go Wrong.

Gensyms

Head destructuring

Dynabase literals

Syntax

Ownership

Semantics

Declarations

Some documentation of currently implemented declarations is in Pragmas.

Type declarations

Evaluation declarations

There is currently some documentation in Syntax.

Default arguments

Visibility declarations

Const

Import

Syntax declarations

Declaring new aggregators

Declaration inference

Type inference on variables

Type inference on functors

Aggregator inference

Scripting commands

Include

Foreign function interface

Concrete syntax

Overview

Standard syntactic sugar

Default syntax table

Changing the syntax table

Printing

Readable printing

Prettyprinting

Standard library

There is currently some documentation in Builtins.

Generic operators and aggregators

Boolean operators and aggregators

Numeric operators and aggregators

Randomness

String operators and aggregators

Array operators and aggregators

Set operators and aggregators

Graph operators and aggregators

Other standard encodings

Analyzing program execution

$rule

$gradient

Voodoo items

Reflection

Controlling program execution

Storage classes

Priorities

Query costs and plans

Features for learning

Foreign dynabases

Files

Processes

Sockets

Servers

Appendices