Dokmelody

A federated system for programming and sharing information

22 Oct 2023

A small step

This small piece of Dok code is compiling and running:

data Int [

]

data A [
  :^ This is the definition of `A` data type

  fun f::Int {
    return 0
  }

  variant ../B [
    :^ `A/B` is a subtype (i.e. variant) of type `A`

    fun f::Int -override {

      : This is a normal comment, inside the code of `A/B.f`

      return 1
    }
  ]

  variant ../C [
    fun f::Int -override {
      return 2
    }
  ]
]

var a::A
assert a.f == 0

var b::A/B
assert b.f == 1

var c::A/C
assert c.f == 2

The syntax of Dok is rather regular, in the hope it can be also extensible with DSL. So conventions are:

  • the first element is always the statement or the data declaration
  • [ ... ] is used for declaring data/values
  • { ... } is used for declaring instructions to run
  • type names are hierarchical, e.g. the type B has full qualified name A/B, and it is a subtype of A
26 Sep 2023

A new beginning

In this blog I will document the development of Dokmelody.

Dokmelody is both a programming language (Dok), a knowledge-base (Doknil), an IDE (Tuttology) and a way for pubblishing information on the internet (Dokmelody).

I started the implementation of Dokmelody using Common Lisp, because it is a very fun language to use, thanks to its interactive REPL.

Instead of Git, I’m using Sapling, because it a lot easier to use. Sapling can freely push/pull from/to ordinary Git branches, so I can collaborate with other programmers using Git. GitHub repository is the reference repository.

For the documentation, I’m using DITA, because I like the way you can navigate in documentation.

I decided to use the Rc Plan9 Shell instead of a more standard Unix Shell like Bash, because it is simple to use and it has a sane default behavior.

I decided to use a redo build system, respect a traditional “make-like” approach, because it is a very natural and powerful top-down specification of the build tasks. This approach is more similar to normal code, because every part of a build is like a function that can call other functions.

I selected a MIT License, respect a LGPL-v3+, because it makes more sense for a programming language using many macro. The details about the decision are described in ADR-003: Use MIT and CC-BY-4.0 licenses: