Name is TBD; Joss for now.

Inspiration

Worse Is Better: A long essay onLisp, programming languages, and what we can do to make lisp bettertoday. Not much of this has been realized.

Learnable programming: Designing a programming system for understanding programs.

Programming as Theory Building:We should architect a programming system that respects such a model.Programming reflects the act of building up a programmer's knowledge,and programs contain both the ideas behind some software developmentpractice and the results of the practice - that is, they produce bothfunctions that encode models of the world and runnable code that canabstract over such models. I think there is space for a pedagogicalcirriculum based on developing functional programs: we accumulatefunctions in some function store, and continue to iterate on them - ordevelop new functions - to accumulate knowledge, because the best way tolearn something is to do it and to demonstrate that it works.

Computers and Creativity · Molly Mielke: What do people want to use their tools for to express themselves?

Mindstorms. Logo. Hungarian method. Let the user both build from firstprinciples and dissect the interfaces they've been given.

Today's journal has some useful thoughts here.

Build on top of NixOS: existing command line programs can be dispatchedto, but those without a "JOSS" interface don't 'feel good' to use; mightbe able to leverage 'nushell' information to get some of thisautomatically as JOSS. Building on Linux is super important for scale,though.

Tracery: Graphics language for students.

Goals

• Strong and secure type system. Static types are excellent and helpprogrammers, but they should stay out of the way as much as possible.
• Practical to program in. Programmers shouldn't have to dig into types,macros or system guts to grok things.
• Offload as much codebase management, tech debt, refactoring work tothe system as you can.
• No default concrete syntax - the language can use whatever syntaxyou'd prefer. The concrete syntax used in this document is going to bethe s-expression based syntax provided with the language

Codebase Management

Forget about files, modules, all of that garbage. A Joss system is a bagof functions. The end user pulls types and tools out of that bag to usein their programs. The system should recommend these tools to the enduser as frequently as possible.

Program Exportation

To export a program from Joss is to provide a single Joss function toexport. This creates a program tree and exports a database that containseverything in the program tree. Any functions that aren't used justdon't show up in the tree, so there is no notion of codebase bloat.

TODO Version Control

This is a big problem

Projections

Projections are mappings from the Joss AST to concrete syntax. A defaults-expression based projection is provided. Another name could be\`syntax\`, but \`projection\` sounds much cooler.

Once a projection is defined, error messages should print with respectto that projection as well.

Exceptions

Types

Statically typed; makes heavy use of row polymorphism. Supports typeinference of course. Users should not have to write types for mostthings. This gives programmers incredible flexibility while preserving astrong type system.

Primitives

Numbers

Support arbitrary precision arithmetic. End-user programmers should nothave to worry about numbers at all. Make the number type as flexible aspossible.

Strings

I would like to discourage language users from using strings wheneverpossible; how can this be done while still retaining practicality? Maybeabstracting this idea of custom deserializers to make types look nicecan also be leveraged in this way? Or guaranteeing that strings cannot be used inline?

Enumerations

Pair

Number

Function Types

Syntax is inspired by Racket's contract system

(-> number bool)
(-> (mapping number string) number)

;; named function
(function add-nums (a1     a2) ;; name, arg1, arg2
          (->      number  number number) ;; optional contract
          "Add two numbers together." ;; optional docstring
          (+ a1 a2)) ;; function body

;; having the docstring in the function body gives us lots of information:
;; - we're guaranteed that it's affiliated with the function
;; - can compute edit distance from other purpose statements to identify similar functions

;; alternative for signature
(function ([a1 string] [a2 number])
          )

;; anonymous function
(function (a1 a2)
          (+ a1 a2))

(function get-keys (mp)
          (->      )
)

;; can add types to functions after the fact in different contexts to 'concretize' them
(: add-nums (-> number number number))

Expressiveness Requirements

Algebraic Data Types

This is syntactic sugar for adding a tag to a union type!

(type Name (name 'a 'b 'c 'd)
  (map 'a 'b
       'c 'd))

Desugared, this looks like

(type (name 'a 'b 'c 'd)
  (map 'a 'b
       'c 'd
       "__type": "Name"))

TODO Flexible Map

(type (map 'a 'b 'c 'd ..)
  (pair
   (pair 'a 'b)
   (pair 'c 'd)))

TODO Mapping

All keys are of the same type; so are all values.

(type (mapping 'a 'b)
  )

List

(type (list 'a)
   (OR (pair 'a (list 'a))
       #empty))

Array

(type (array 'a)
  (mapping 'number 'a))

Boolean

(type bool
  (or #true #false))

TODO Tuple

(type (tuple 'a 'b  'c ...)
  (pair 'a (pair 'b) ...)