dok/paradigm/layered-semantic

Dok principles

• Source code must be readable using the Dok IDE, but not neceassarly in plain text mode.
• Entire source code of the application and compiler are first class citziens (dok/paradigm/code-as-firsc-class-citizen)
• there can be different layers, for example: Actor model; BUD; Relational; etc…
• every layer can use the functionalities of lower layers
• every layer can decide how to analyze and compile the low-level layers
• There is a difference between an algoriths calculating the result of a function, and a system managing user inputs and system events.
• Dok analyze code, and it is not a live run-time environment like Lisp
• Dok is in part a declarative PL, and not a direct modification system like Smalltalk
• every DSL in Dok, and also Dok itself, is first analyzed and desugared
• an abstract interpretation pass is done before the compilation, and after some DSL compiler pass is done
• aggressive optimizations can be done running the code in production with instrumentation about profiling, and then recompiling it according the code usage pattern that were found in production

Dok and Dokmelody use:

• code analysis
• incremental code analysis during DEV
• continuosly build rules
• different and explicit DEV, TEST, PROD environments
• explicit build-rules

Progressive refinements

Dok is a layered programming language: a system is defined iterating layers of specifications, from high-level to low-level.

Brancheable code

Source code in Dok can “branch”: from the same higher-level source code can be derived different lower-level versions of the same code. In the Dok language and DokMelody IDE, code development is a first-class citzien.

Code transformation

Dok syntax is used for: analyzing and transforming source code and for representing with the same Dok syntax variaus DSL using different paradigms.

No runtime reflection

Dok does not use a sophisticated or powerful run-time OOP model like Smalltalk or Self, because the majority of analysis and metaprogramming is done at compile-time, using attribute-grammars (AG), working on the abstract-syntax-tree (AST) of the source code to transform. Dok instructions cannot be executed directly from an interpreter, because it is necessary at least one pass of code analysis, for managing forward references and desugaring it.

Colored functions

In paradigm/system-vs-functions there is the concept of function color. This concept can be layered/iterated:

• at first level there are pure functions returning always the same result given the same input. They can reused everywhere and composed freely. They are blue functions.
• at second level there are functions affecting the state of the system. They are red functions.
• if there is another upper level calculating a result using the previous level for calculations, then it is a red function, and for ith, the previosu level is a blue function.