arrdem/source
1
0
Fork 0
Code Issues 11 Pull requests Projects Releases Packages Wiki Activity

[NO TESTS] WIP

Browse source
This commit is contained in:
Reid 'arrdem' McKenzie 2021-08-23 10:51:41 -06:00
parent 7bff95fe32
commit 19303931bc
1 changed files with 4 additions and 5 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

9
projects/lilith/README.md
View file

@ -73,6 +73,7 @@ Make comments or perhaps more accurately document DSLs "first-class" and values
Lilith is a sketch at what if you took the ideas from literate programming (having fragments of text from which programs are composed) but deliberately DID NOT privilege the "source" for a "document" over the "source" for the "program". Lilith is a sketch at what if you took the ideas from literate programming (having fragments of text from which programs are composed) but deliberately DID NOT privilege the "source" for a "document" over the "source" for the "program".
Documents, DSLs and programs could be co-equal and co-resident artifacts. Documents, DSLs and programs could be co-equal and co-resident artifacts.
Users could define their own (textual) macros, DSLs with evaluation order and weaving of fragments together into multiple documents or indices.
To achieve this vision, Lilith uses a context sensitive block-prefixed syntax which SHOULD be uncommon enough not to involve collisions with other languages. To achieve this vision, Lilith uses a context sensitive block-prefixed syntax which SHOULD be uncommon enough not to involve collisions with other languages.
@ -80,11 +81,11 @@ Lilith is an [M-expression](https://en.wikipedia.org/wiki/M-expression) esque la
The meta-language is `!` prefixed M-expressions. The meta-language is `!` prefixed M-expressions.
At present the meta-language has two directives, `!def[<name>, <language>]` and `!import[<from>, ...]`. At present the meta-language has two directives, `!def[<name>, <language>]` and `!import[<from>, ...]`.
This Lilith implementation is bootstrapped off of Python, and provides two built-in languages, `lil` AKA Lilith and `py` AKA python3.
Lilith interpretation is actually dual (or potentially N) interpreter based. Lilith interpretation is actually dual (or potentially N) interpreter based.
When a given name is evaluated, its body or definition is evaluated in the given language. When a given name is evaluated, its body or definition is evaluated in the given language.
For instance, this snippet would define a pair of Lilith "foreign" functions in Python (`gt` and `sub`), which would then be used from the definiton of `fib`. This Lilith implementation is bootstrapped off of Python, and provides two built-in languages, `lil` AKA Lilith and `py` AKA python3.
For instance, this snippet would define a pair of Lilith "foreign" functions in Python (`gt` and `sub`), which would then be used from the definition of `fib`.
``` lilith ``` lilith
!def[gt, py] !def[gt, py]
@ -98,8 +99,6 @@ fib[1] = 1
fib[2] = 1 fib[2] = 1
fib[3] = 2 fib[3] = 2
!md[]
!def[fib, lil] !def[fib, lil]
lambda[[x] lambda[[x]
, cond[[gt[x, 1], , cond[[gt[x, 1],
@ -170,7 +169,7 @@ Being able to piggy-back off of the host Python interpreter has been good for a
- `let[]` - `let[]`
- `if[]` - `if[]`
The module/namespace/def system is clearly Clojure derived and worked out pretty well, but `!import` can't trigger code loading as presently factored. The module/namespace/def system is Clojure derived and worked out pretty well, but `!import` can't trigger code loading as presently factored.
## License ## License