Project status

I am just writing down ideas. I have many pages of notes on things i may or may not want to put into Jasper.

At this point, the design is unfinished; there is no coherent concept of a language called 'Jasper', just a bunch of ideas towards such a proposal. There is no timeframe to actually implement this, and it most likely will never get finished.

To be clear, i repeat myself: there is no such thing as Jasper. Jasper has neither been designed nor implemented. These notes about 'Jasper' contain many conflicting proposals.

This document is very out of date and no longer serves as a good introduction to the evolving language proposal.

You may want to look at ideas-computer-jasper-whyJasper.

There are a bunch of other files in this folder with more details and notes on various parts of Jasper: ideas-computer-jasper.

The name Jasper refers to my favorite type of rock, Picture Jasper.

the jasper programming language (under construction)

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

Why Jasper? -- built around a powerful data structure: labeled graphs. -- referential transparency "by default" -- 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 Jasper, many punctuation characters mean something different if they are attached to another token as opposed to being surrounded by whitespace. For example, in Jasper,

  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

G-constructors are literals used to construct directed graphs (for technical notes on what we mean by directed graph, see [2]