Specification of the Dyna Language¶
How to read this specification¶
Organization¶
Notation¶
User comments¶
Coloring and formatting conventions¶
Cross-refs¶
Sidebars¶
Notifications¶
Links to examples¶
Links to issue tracker¶
Glossary/Index¶
Terms (i.e., ground terms)¶
Overview¶
Sets¶
Frozen terms¶
Full discussion in Frozen terms.
Dynabases¶
Overview¶
Assertions¶
Lambdas¶
Terms as dynabases¶
Updates¶
Update modes¶
Stability¶
Dynabase types¶
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¶
Declarations¶
Some documentation of currently implemented declarations is in Pragmas.
Type declarations¶
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¶
Standard library¶
There is currently some documentation in Builtins.