Jevko (jeff-ko /หdอกสef.kษส/) is a versatile minimal syntax for encoding tree-structured information as human- and machine-friendly text.
It can be used as a building block for simple formats, languages, and notations across a variety of domains.
***
Profile run by https://mastodon.social/@djedr
#jevko #simple #minimal #syntax #tree #structured #information #data #encoding
| Home page | https://jevko.org |
| GitHub | https://github.com/jevko |
| Codeberg | https://codeberg.org/jevko-org |
| Support/Donate | https://xtao.org/s |
Jevko Vision: Total Intercommunication Of All Software Systems
This describes the vision behind Jevko, as formulated around 2021, and revised afterwards.
Syntax is so ubiquitous in software that it is taken for granted and often overlooked. Optimizing it is, for many reasons, not a very popular topic.
Refreshed https://jevko.org again!
Now with over 9000% more icons!
#jevko #website #refresh #emojis #icons #syntax #minimal #format #tree #information #text
Here is how it looks live, translated to #HTML and rendered.
Shows the interactively updated Table of Contents which doesn't have #React's problem of being unresponsive to adding and removing an extra header. All implemented in pure JS + JDAML as sugar for basically document.createElement. No #framework.
Been working some more on the #document #format. Added #interactivity. Now it's possible to use #JDAML in #JS also for runtime, not just build time.
I took all the problems described in this paper https://arxiv.org/abs/2310.04368 as challenges and implemented enough #features that they could be solved.
Also added some more #syntax #sugar -- paragraph inference and [=expr] syntax for substitution, to cut down on the nested brackets. I think it's looking good already.
What do you think?
Passive documents and active programs now widely comingle. Document languages include Turing-complete programming elements, and programming languages include sophisticated document notations. However, there are no formal foundations that model these languages. This matters because the interaction between document and program can be subtle and error-prone. In this paper we describe several such problems, then taxonomize and formalize document languages as levels of a document calculus. We employ the calculus as a foundation for implementing complex features such as reactivity, as well as for proving theorems about the boundary of content and computation. We intend for the document calculus to provide a theoretical basis for new document languages, and to assist designers in cleaning up the unsavory corners of existing languages.
Here is the rest of the demo and the output.
NB this prototype is implemented with surprisingly little code. I am not even using a #JS #parser here. Just translating the syntax tree to valid JS and calling eval to get a static tree which is then ran thru a #Znatchke to #HTML converter and rendered.
All possible thanks to the minimal nature of #Jevko -- it just doesn't get in the way. Which is just perfect for #prototyping!
Also been #experimenting with mixing some #JavaScript into it.
TBH I'd use #JDAML over #JSX in #JS any day.
Using \ as the delimiter makes it pretty easy to integrate into the syntax of JS. Also it adds some superpowers to JS for free, such as fenced strings.
How about something in between #Markdown and #HTML, but #simpler, more #flexible, and much easier to #parse than both?
Cooking that under #codename #Znatchke (after #tchotchke).
NB here is the #YAML #document from #hell [0] encoded in #JDAML.
I'm designing #JDAML to eliminate the risk of accidental interpretation. Unless a leaf value is clearly explicitly marked in a predictable manner, it will be interpreted as a #string.
So no #norwayproblem, no #sexagesimal or other weird number literals. No #anchors, #aliases, or #tags. No accidental non-string keys, no accidental numbers.
[0] as described by Ruud van Asseldonk in this article: https://ruudvanasseldonk.com/2023/01/11/the-yaml-document-from-hell
