jevkalk VS treenotation.org

Compare jevkalk vs treenotation.org and see what are their differences.

Our great sponsors
  • SurveyJS - Open-Source JSON Form Builder to Create Dynamic Forms Right in Your App
  • WorkOS - The modern identity platform for B2B SaaS
  • InfluxDB - Power Real-Time Data Analytics at Scale
jevkalk treenotation.org
4 7
4 16
- -
9.1 0.0
8 months ago almost 3 years ago
JavaScript JavaScript
- -
The number of mentions indicates the total number of mentions that we've tracked plus the number of user suggested alternatives.
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.

jevkalk

Posts with mentions or reviews of jevkalk. We have used some of these posts to build our list of alternatives and similar projects. The last one was on 2022-11-03.
  • November 2022 monthly "What are you working on?" thread
    25 projects | /r/ProgrammingLanguages | 3 Nov 2022
    [1] Here's one of my tries: https://github.com/jevko/jevkalk
  • Jevko: a minimal general-purpose syntax
    5 projects | /r/programming | 25 Oct 2022
    Here is a toy language that uses Jevko as syntax that I've been hacking on a bit recently: https://github.com/jevko/jevkalk
    30 projects | news.ycombinator.com | 25 Oct 2022
    > is doing? It sure looks to me like it's asking whether a symbol (i.e. indivisible atom) ends with an equal sign, which is semantic gibberish.

    There are no symbols or indivisible atoms here.

    What's happening here is parsing. `jevkoToHtml` is a kind of parser-transpiler which operates on a syntax tree, rather than a sequence of characters or tokens.

    The syntax tree is the output of an earlier stage of parsing, done by the Jevko parser.

    So you can think of this as multi-pass parsing, by analogy with multi-pass compilation.

    At the same time as this second pass of parsing is happening, translation to HTML is happening as well.

    Hope this clarifies things!

    ---

    [0] To clearly see the point, here is a toy programming language which uses Jevko as its syntax: https://github.com/jevko/jevkalk

treenotation.org

Posts with mentions or reviews of treenotation.org. We have used some of these posts to build our list of alternatives and similar projects. The last one was on 2022-10-25.
  • Jevko: a minimal general-purpose syntax
    30 projects | news.ycombinator.com | 25 Oct 2022
    > concatenating them changes the label for [b] from "a" to "z\na", and perhaps more damningly, erases the whitespace before "z". But, since none of the alternative formats (except ndjson and I guess plain uninterpreted binary, ASCII, or Unicode) is closed under concatenation, maybe that's less important.

    Yes, being closed under concatenation is a feature I was aiming for and it indeed does bring with it this issue.

    Just something to have in mind when devising formats. A simple solution here is to disallow having anything other than whitespace in the suffix of a Jevko with > 0 children. Then, if a format converts these labels to keys in a map, trimming leading and trailing whitespace, there is no problem. This is how I did it here:

    https://github.com/jevko/easyjevko.js

    > I don't know if you saw the last time this topic came up I linked to https://ogdl.org/, which seems pretty close to a minimal rose-tree notation.

    Yes, I've seen OGDL before. It's pretty nice. A similar one is https://treenotation.org/

    I have experimented with indentation-based syntaxes myself, before settling on brackets.

    I have found them to be problematic, at least because:

    * For complex structures they become less compact.

    * A grammar that correctly captures significant indentation can't really be written in pure BNF. The way OGDL does it is this:

      [12] space(n) ::= char_space*n ; where n is the equivalent number of spaces (can be 0)
  • Syntax Design
    9 projects | news.ycombinator.com | 18 Oct 2022
    This reminds me a bit of Breck Yunits' Tree Notation (https://treenotation.org/). Both seem to have a ~totalizing energy. Maybe some common cause. :)
  • ELI5
    1 project | /r/treenotation | 14 May 2021
    Hi, I'm a programmer and I've used quite a few different languages in my career. I've never studied compilers or language design, however it has always interested me from afar. Also I've always had a strong preference for simple syntax, what sane person wouldn't? Anyway I've scanned over the https://treenotation.org/ site. I get the general gist, that this provides a tool to easily create languages that use tree notation. Unfortunately I still don't really understand how to use it. If there was tutorial that held your hand that would be really useful. I suspect there a large number of people like myself that would benefit from this. Perhaps at some point I'll role up my sleeves and do it myself, but I'm sure someone else could do a better job.
  • Google Docs will move to canvas based rendering instead of DOM
    16 projects | news.ycombinator.com | 12 May 2021
    > The way to fix this trend would be to reimagine the presentation layer of the browser as something other than a stack of hacks over hypertext, but so far nobody seems to have a good solution.

    About a decade ago I had the start of a Eureka moment on how to do this (back then — https://medium.com/space-net/spacenet-51aca95d49a2, nowadays https://treenotation.org/). It seems to me we've missed a sort of fundamental universal notation of the universe, which you can think of as "two-dimensional binary". I predict we will soon see a Cambrian Explosion of new formats and notations that are simpler and more interoperable with each other, and some will have the opportunity to build new great languages for rendering stacks.

  • Zig, Parser Combinators – and Why They're
    7 projects | news.ycombinator.com | 10 Mar 2021
    Awesome app. Do you plan on using it for anything in particular? Or are you just creating it as a passion project. It's totally cool.

    Learning about https://treenotation.org/ (linking this for other people, not for you, Breck :P), and I like what I see. My first impression was "Lisp, but with python indenting"

    > We no longer need to store our data in error prone CSV, XML, or JSON. Tree Notation gives us a simpler, more powerful encoding for data with lots of new advanced features

    This is the one thing I didn't understand! Tree notation seems equivalent to these. Like at a certain level, it's all just data. Now, the major benefit is that you're supposed to think differently about what you're doing when using tree notation. Would love to hear your opinion about this conjecture.

  • The Pretty JSON Revolution
    4 projects | news.ycombinator.com | 23 Feb 2021
    Lots of code examples here: https://jtree.treenotation.org/designer/

    And the source for that homepage is here: https://github.com/treenotation/treenotation.org

    Always open to PR!

What are some alternatives?

When comparing jevkalk and treenotation.org you can also consider the following projects:

easyjevko.lua - An Easy Jevko library for Lua.

x-spreadsheet - The project has been migrated to @wolf-table/table https://github.com/wolf-table/table

jevkostream.scm - (WIP) Streaming parsers for Jevko in Scheme

markup-experiments - A collection of experiments with Jevko and text markup.

edsl - Example of embedding TypeScript as an EDSL inside of another language

zhp - A Http server written in Zig

community - Features Jevko-related things created by various authors

binary-experiments - Experiments with various binary formats based on Jevko.

xabber - Root project for all Xabber related software projects

Glide - Glide programming language