This is old. Read [proj-oot-oot] instead.

OLD, OUT OF DATE: the oot programming language (under construction)

Lisp is a homeoiconic language built upon lists. Oot is a homeoiconic language build upon labeled (hyper multi reified) graphs.

Why Oot? -- built around a powerful data structure: labeled graphs. -- interface-based (or "attribute-based") type discipline -- constraint satisfaction -- readable, concise syntax -- memory managed. static typing, type inference. lazy evaluation. higher order functions. -- goal: the referential transparency, higher order functions, and type system of Haskell, the readability and convenience of Python

see [1] for more detail.

audience: general purpose. programmers.

statically typed. memory managed. type inference. lazy evaluation. higher order functions.

support for the following paradigms: imperative, oop, functional (referential transparency), logic, macros

priorities: power, readability, conciseness

syntax that compiles to cleaner core

primary data structure(s): labeled (reifiable) graph. this also provides a syntax for lists, association tables, arrays, trees, graphs, relations, structs, objects with managed attributes.

some goals:

implement the language in itself concisely
std idioms (to promote readability)
large base libraries
easily use/create libs in other languages
provide good API for IDEs to interact w/ compiler
single most-blessed implementation (with community contributing via Amendable Code group decision-making procedure)
a great standard library

tasks that could drive development

quick scripting!!
compilation and interpreting
CGI
desktop apps
version control
text editing, IDE
numerical analysis
web apps

some features:

significant indentation for syntax (optional, but recommended)
everything is first-class
partial function application
keyword arguments in function calls
default arguments in function calls
typeclasses ("interface types")
graphs provide unified syntax for container access, struct get/set, object managed properties, function application, operations on code
pattern matching (improved to match on types)
disjunctive types
exceptions
"with"
std lib handling common ops with functions, numbers, lists, associative tables, trees, graphs, strings, queues, files, networking, sets, relations, code parsing
type inference
default types for typeclasses
type tags used to select a default type
footnotes
(hygenic, except for pronouns) macros, function decorators
multiple graph "representations" allowed for underlying
todo: logic programming primitives
todo: concurrency primitives
unicode support
todo: resource handling support
todo: hook (extension modules for applications) support
"convenience mutation" within scope
pronouns
(hygenic w/r/t macros) unshadow
convenient regexs
multiple assignment, multiple returns, return assignment syntax symmetric with function passing syntax (permitting keyword and default return arguments)
delineated continuations
multiple entry points to each function that can operate as a concurrency synch barrier
semiglobals
core abstraction of handler trees; call tree (perhaps even a call graph?) instead of a call stack
reverse control mode, like exception propagation but not necessarily an interruption or error, and generalized; the executing code can send a message up the call tree which is then 'caught' by pattern matchers
modular type system integrated with logic programming
pluggable garbage collection, generalized to provide resource management (todo: or do we just need destructors for RAII?)
syntactic sugar to make common commandline oneliners concise
standard API to ask the compiler for things that an advanced IDE needs to do highlighting, tab-completion, indexing of a name, etc
todo: ML-like higher-order module system?
lazy
immutable data
annotations
todo: an object system?
multistage programming
implicit EOL (as if semicolons added by default)
interceptors (monads; 'programmable semicolons')
implicit 'main' like Python

anti features:

no custom precedence, to allow the reader to parse code without first resolving function definitions

some other design decisions:

"interface types" (typeclasses) everywhere (bad form to use "implementations types" rather than interface types)
everything is a graph
plenty of syntactic sugar
token-level hof operators to do things like "map" (?)
infix functions
no (or at least, not many) precedence levels
limited or no dynamic modification of code at runtime (basically, can't screw up the types), outside of eval
both "client's choice" and "my choice" types (universal and existential) ?
try for 3-5 letter reserved words and common lib fns

A single

Syntax

AnA?

General note on syntax

In some languages punctuation characters are also separators, so you aren't required to put a space before or after them, but in Oot, many punctuation characters mean something different if they are attached to another token as opposed to being surrounded by whitespace. For example, in Oot,

  x = 3

is not interchangable with

x=3

The '=' in "x = 3" is called "freestanding". The '=' in "x=3" is called "attached".

Basic function calling syntax

Put the function arguments to the LEFT of the function, separated by spaces.

Example: if f is a function that takes arguments x and y: y x f

You can pass keyword arguments using keyword=value. The order of keyword arguments doesn't matter. All keyword arguments must go to the right of all positional arguments.

Example:

  x = 3 [] lb="apple" ins
  x == ["apple"=3]

G-constructor syntax