binary-experiments VS easyjevko.lua

Compare binary-experiments vs easyjevko.lua and see what are their differences.

binary-experiments

Experiments with various binary formats based on Jevko. (by jevko)
Our great sponsors
  • SurveyJS - Open-Source JSON Form Builder to Create Dynamic Forms Right in Your App
  • InfluxDB - Power Real-Time Data Analytics at Scale
  • WorkOS - The modern identity platform for B2B SaaS
binary-experiments easyjevko.lua
2 5
0 0
- -
10.0 10.0
about 2 years ago over 1 year ago
JavaScript Lua
- MIT License
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.

binary-experiments

Posts with mentions or reviews of binary-experiments. 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
    > 1. It relies on later stages to do things like convert to native values or remove whitespace. As such an intermediary can't really "understand" the document very well. E.g., if you are using this syntax to express key/value then you can only know the keys if you know the whitespace rules that will be used to interpret the keys.

    From the point of view of Jevko, handling whitespace is a higher-level concern. Indeed, you typically will need additional rules to communicate effectively with Jevko.

    This is where you should specify a format (which should be standardized) that you use, e.g.:

    * https://github.com/jevko/easyjevko.lua

    Note: this is just a simple library I wrote recently that does the most straightforward thing imaginable. I haven't yet wrote a spec for the format.

    > 2. It reminds me more of XML than S-Expressions. If you are familiar with the ElementTree [1] representation of XML then these parsed examples become more familiar, just a prefix instead of suffix, and no attribute children.

    Yes, Jevko has the features of both XML and S-expressions (or neither, depending on how you look). It's supposed to be uniquely suitable for both markup and encoding of data/code in a simple way.

    > 3. Connecting whitespace and XML, I suppose this explains why so many XML formats ended up only using attributes for text values, and used tags and children only for nesting. Otherwise interpretation requires understanding how to interpret these mixed documents with unclear whitespace rules. But Jevko doesn't have attributes.

    A markup format built on Jevko can have the notion of attributes and rules for whitespace, e.g. see https://news.ycombinator.com/item?id=33334774 -- a nice thing about this particular format is that text nodes are explicitly specified, so you know exactly where your significant whitespace goes.

    The nice thing about attributes made with Jevko over XML attributes is that you could naturally make them extensible (which is a pain in XML -- if you want to turn your unstructured string value stored in an attribute into a tree you have a problem).

    > 5. I don't see any escaping rules so including literal [] seems... impossible? You can essentially deserialize the parsed value to reintroduce them, but that's weird and awkward, and only works with balanced brackets anyway.

    That's not correct. There are only 3 special symbols (delimiters) and they can all be escaped. It's all in the specification.

    > 6. No way to embed binary data, or otherwise uninterpreted data. JSON has the same problem. Base64 encoding things is yet another way in which the data is not interpretable by intermediaries.

    Indeed, Jevko is not a binary format. Although I've been experimenting with binary equivalents, e.g.:

    https://github.com/jevko/binary-experiments

    At some point I might go forward with one, but that's not the focus right now.

    30 projects | news.ycombinator.com | 25 Oct 2022
    Yes, S-expressions come in many flavors, some more minimal than others, some binary. They are all truly wonderful.

    The most wonderful to me are the simplest ones, and Jevko grows out of the same spirit as them.

    However, it does not attempt to be a new flavor of S-expressions and diverges in ways which to me are worth looking at. I hope it can appeal and be useful not only to minimalist syntax enthusiasts.

    BTW Some time ago I've been also experimenting with binary versions of Jevko, certainly with inspiration from both netstrings and Rivest's csexps:

    https://github.com/jevko/binary-experiments#asttolengthprefi...

    Since then I had some more ideas which I hope to get around to implementing at some point.

easyjevko.lua

Posts with mentions or reviews of easyjevko.lua. 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
    5 projects | /r/programming | 25 Oct 2022
    Now if you take the simplest possible format built on Jevko, e.g. https://github.com/jevko/easyjevko.lua which specifies the conversion of jevkos to Lua tables and strings then an empty jevko is always converted to an empty string. Empty tables or nulls are simply prohibited in this format.
    30 projects | news.ycombinator.com | 25 Oct 2022
    > 1. It relies on later stages to do things like convert to native values or remove whitespace. As such an intermediary can't really "understand" the document very well. E.g., if you are using this syntax to express key/value then you can only know the keys if you know the whitespace rules that will be used to interpret the keys.

    From the point of view of Jevko, handling whitespace is a higher-level concern. Indeed, you typically will need additional rules to communicate effectively with Jevko.

    This is where you should specify a format (which should be standardized) that you use, e.g.:

    * https://github.com/jevko/easyjevko.lua

    Note: this is just a simple library I wrote recently that does the most straightforward thing imaginable. I haven't yet wrote a spec for the format.

    > 2. It reminds me more of XML than S-Expressions. If you are familiar with the ElementTree [1] representation of XML then these parsed examples become more familiar, just a prefix instead of suffix, and no attribute children.

    Yes, Jevko has the features of both XML and S-expressions (or neither, depending on how you look). It's supposed to be uniquely suitable for both markup and encoding of data/code in a simple way.

    > 3. Connecting whitespace and XML, I suppose this explains why so many XML formats ended up only using attributes for text values, and used tags and children only for nesting. Otherwise interpretation requires understanding how to interpret these mixed documents with unclear whitespace rules. But Jevko doesn't have attributes.

    A markup format built on Jevko can have the notion of attributes and rules for whitespace, e.g. see https://news.ycombinator.com/item?id=33334774 -- a nice thing about this particular format is that text nodes are explicitly specified, so you know exactly where your significant whitespace goes.

    The nice thing about attributes made with Jevko over XML attributes is that you could naturally make them extensible (which is a pain in XML -- if you want to turn your unstructured string value stored in an attribute into a tree you have a problem).

    > 5. I don't see any escaping rules so including literal [] seems... impossible? You can essentially deserialize the parsed value to reintroduce them, but that's weird and awkward, and only works with balanced brackets anyway.

    That's not correct. There are only 3 special symbols (delimiters) and they can all be escaped. It's all in the specification.

    > 6. No way to embed binary data, or otherwise uninterpreted data. JSON has the same problem. Base64 encoding things is yet another way in which the data is not interpretable by intermediaries.

    Indeed, Jevko is not a binary format. Although I've been experimenting with binary equivalents, e.g.:

    https://github.com/jevko/binary-experiments

    At some point I might go forward with one, but that's not the focus right now.

    30 projects | news.ycombinator.com | 25 Oct 2022
    Now on top of that you can build a format that specifies what happens to whitespace, etc. Usually you'd want it trimmed if the prefixes mean keys in a map.

    The simplest format/library that does just that is this:

    * https://github.com/jevko/easyjevko.lua

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

    30 projects | news.ycombinator.com | 25 Oct 2022

What are some alternatives?

When comparing binary-experiments and easyjevko.lua you can also consider the following projects:

examples - Examples of information encoded with Jevko.

jevkalk - A Jevko-based interpreter.

specifications - Specifications related to Jevko.

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

yapl - YAml Programming Language

writing - A public place for unpolished technical writing.

jevko