generated from coulomb/repo-seed
118 lines
4.6 KiB
Markdown
118 lines
4.6 KiB
Markdown
This is one of Quarkdown’s most interesting ideas.
|
||
It is not just “Markdown plus directives”; it is closer to a small document programming language embedded in Markdown.
|
||
|
||
**Core Idea**
|
||
|
||
In Quarkdown, function calls are the central extension mechanism. They use a dot-prefixed syntax:
|
||
|
||
```quarkdown
|
||
.sum {26} {16}
|
||
```
|
||
|
||
Arguments can be positional or named:
|
||
|
||
```quarkdown
|
||
.multiply {6} by:{3}
|
||
```
|
||
|
||
They can be inline, block-level, nested, chained, or given an indented body argument. Quarkdown explicitly presents functions as its key feature and groups them across layout, utility views, math/logical operations, control flow, file data, and document metadata. Source: [Quarkdown function-call syntax](https://quarkdown.com/wiki/syntax-of-a-function-call/).
|
||
|
||
**What Makes It Rich**
|
||
|
||
1. **Functions produce document content, not just scalar values**
|
||
|
||
A function may return text, Markdown content, layout structures, booleans, numbers, tables, etc. This is crucial: document generation and computation live in the same language.
|
||
|
||
```quarkdown
|
||
.if {.isadult age:{20}}
|
||
You're an adult!
|
||
```
|
||
|
||
User-defined functions are declared with `.function`, and their body is a lambda-like block:
|
||
|
||
```quarkdown
|
||
.function {greet}
|
||
to from:
|
||
**Hello, .to** from .from!
|
||
```
|
||
|
||
Source: [Declaring functions](https://quarkdown.com/wiki/declaring-functions/).
|
||
|
||
2. **Block arguments make functions feel Markdown-native**
|
||
|
||
Instead of forcing everything into parenthesized expressions, Quarkdown lets the final argument be an indented block:
|
||
|
||
```quarkdown
|
||
.box {Example}
|
||
This is the content of the example.
|
||
```
|
||
|
||
That is a very elegant move. It keeps prose readable while making structured composition possible.
|
||
|
||
3. **Chaining gives it pipeline ergonomics**
|
||
|
||
This:
|
||
|
||
```quarkdown
|
||
.pow {3} {2}::subtract {1}::sum {2}
|
||
```
|
||
|
||
is transformed conceptually into nested calls where each result becomes the first argument of the next call. That gives Quarkdown a pleasant Unix-pipe / method-chain feel without turning the surface language into JavaScript. Source: [Chaining calls](https://quarkdown.com/wiki/syntax-of-a-function-call/).
|
||
|
||
4. **Variables are functions too**
|
||
|
||
Variables are defined with `.var`, then accessed like zero-argument functions:
|
||
|
||
```quarkdown
|
||
.var {name} {Quarkdown}
|
||
|
||
Hello, .name!
|
||
```
|
||
|
||
They can hold simple values or block/layout content. There is also `.let` for scoped temporary variables. Sources: [Variables](https://quarkdown.com/wiki/variables/) and [Let](https://quarkdown.com/wiki/let/).
|
||
|
||
5. **It has real control flow**
|
||
|
||
Quarkdown has conditional functions like `.if` and `.ifnot`, plus loops like `.foreach` and `.repeat`:
|
||
|
||
```quarkdown
|
||
.foreach {1..3}
|
||
n:
|
||
The number is **.n**
|
||
```
|
||
|
||
The loop returns an iterable of evaluated results, so it behaves more like `map` than a pure side-effect loop. Source: [Loops](https://quarkdown.com/wiki/loops/).
|
||
|
||
6. **It has higher-order behavior**
|
||
|
||
Lambdas show up in custom functions, `let`, `foreach`, sorting, filtering, and table operations. Inline lambdas can be passed as arguments, for example in table filtering:
|
||
|
||
```quarkdown
|
||
.tablefilter {2} {@lambda x: .x::isgreater {20}}
|
||
...
|
||
```
|
||
|
||
Source: [Table manipulation](https://quarkdown.com/wiki/table-manipulation/).
|
||
|
||
7. **It includes typed-ish document values**
|
||
|
||
The docs list value types such as string, number, Markdown content, boolean, none, iterable, dictionary, range, lambda, size, color, and dynamic values. It is weak/dynamic enough to remain author-friendly, but structured enough to support meaningful diagnostics and reusable functions.
|
||
|
||
**Why This Matters For Markitect**
|
||
|
||
For Markitect, the lesson is not necessarily “copy Quarkdown syntax.” The deeper lesson is this:
|
||
|
||
Quarkdown treats document operations as composable functions with Markdown-native block bodies.
|
||
|
||
That maps beautifully to our direction:
|
||
|
||
- Markitect contracts could define allowed/expected processors as named document functions.
|
||
- Our fenced-block processors could grow into a function registry with capability metadata.
|
||
- Our dataflow pipelines could benefit from function chaining semantics.
|
||
- Our template/generation layer could distinguish pure deterministic functions, context-bound functions, LLM-backed functions, and unsafe external functions.
|
||
- Our diagnostics could be stronger than Quarkdown’s if every function call has provenance, declared inputs, permissions, and expected output type.
|
||
|
||
My take: Quarkdown’s function language is a very good inspiration for a future Markitect “document function layer,” especially if we keep it optional, markdown-close, typed enough for contracts, and integrated with our provenance/cache/access-control fabric.
|
||
|
||
|