10 ms·

Jevko: a minimal general-purpose syntax

68 points by memorable 4y ago

bokumo 4y ago
A minimal general purpose syntax for what? I followed the link and read the page, but I’m still not sure what the point is!
- gnulinux 4y ago
  For anything? Say you build your own language, but don't want to write a parser for it (people who write tons of prog langs know that syntax is the most boring part (for some, I'm sure some people love it)) so you can borrow this, it gives you a syntax tree, and you just continue from there.
- eterps 4y ago
  > A minimal general purpose syntax for what? Apparently for the same things as with XML/JSON/TOML. > I followed the link and read the page, but I’m still not sure what the point is! According to the website: > It has no data types, no semantics, no underlying model of cons cells or anything similar. It’s as close to pure generic syntax as it gets. > So at the lowest level Jevko is a minimal formal specification for flexible trees of text. For its simplicity it seems quite powerful to me. I don't see it replacing JSON/markdown or even TOML. But is seems trivial to implement on very low-level, older, less bloated, or less powerful systems.
  - djedr 4y ago
    This is correct. Every time I've written or otherwise dealt with JSON/XML/etc. I wished I was dealing with something simpler, so I created it. If I had Jevko as a full-fledged alternative to JSON or XML, supported by tools, etc., I'd pick Jevko in a heartbeat. I like minimalism. Some people like it too, so perhaps Jevko can serve them well. There are many good reasons. > But is seems trivial to implement on very low-level, older, less bloated, or less powerful systems. Indeed, this is THE feature and a realistic application. I hope! For a naive unrealistic vision that I sketched out some time ago see: https://github.com/jevko/writing/blob/main/2022-01-13-vision.md https://github.com/jevko/writing/blob/main/2022-01-13-vision...
- saurik 4y ago
  If it was "for" something wouldn't it no longer be general purpose?...
tpoacher 4y ago
I appreciate your effort, but your explanation on the first page is too abstract to the point that I read to the end and still didn't know exactly what Jevko is and how to use it. E.g. you introduce "Subjevko" as if it's known knowledge. Also, the singular link to "examples" on that page, which is what I really want to see first, was broken. My advice: for every point you make have a single, simple, illustrative example right below the explanatory text (or better yet, right above it!).
- djedr 4y ago
  Thank you for your feedback. Can you clarify? What is the "first page" that you are referring to? Can you paste a link to it along with the broken examples link? This Hacker News submission features the blog post under this URL: https://djedr.github.io/posts/jevko-2022-02-22.html https://djedr.github.io/posts/jevko-2022-02-22.html Clearly, you are not talking about this page, as that contains multiple links rather than a singular link. Perhaps you are talking about the specification which is here: https://github.com/jevko/specifications/blob/master/spec-standard-grammar.md https://github.com/jevko/specifications/blob/master/spec-sta... (linked from the blog post) and here: https://jevko.org/spec.html https://jevko.org/spec.html (linked from jevko.org) All three link to Jevko examples here: https://github.com/jevko/examples https://github.com/jevko/examples but all these examples links seem to be correct on my end. I agree about the importance of examples, and I try to lead with them on jevko.org and jevko.github.io (which are the front pages of Jevko -- possibly I should merge them into one). However a formal specification is not necessarily the place to put the leading examples. This is also where the Subjevko rule is defined. It isn't quite introduced as "known knowledge" -- the purpose of a specification is to define the unknown, more or less from the ground up. This is also why specifications tend to get a little abstract. Jevko's spec is no exception. This should be in line with expectations of authors of tools such as parsers, validators, generators, or other kinds of processors, for which the spec is the authoritative reference. It is not necessarily the best first place to look for explanation, if you are approaching from a more casual side. I agree that from that side a clear picture of what Jevko is and how it can be used is still lacking. I certainly should add more examples and explain the concepts with analogies. So I appreciate the essence of your advice and hope I'll manage to improve on that.
Trufa 4y ago
Interesting, I'm wondering where something like this could be useful.
- eterps 4y ago
  There are a couple of examples here: https://github.com/jevko/examples https://github.com/jevko/examples
- deleted 4y ago
  [deleted]
Nullabillity 4y ago
I wish we could stop making up new languages in 2022 that use unenclosed strings...
- User23 4y ago
  There are no strings in this language.
  - Nullabillity 4y ago
    The first example on https://jevko.org/ https://jevko.org/ contains plenty of strings.
    - User23 4y ago
      No, it contains a tree of text objects, which aren’t strings. Now the language that the Jevko parser is written in will probably store that text tree using strings, but that’s a statement about the parser implementation and not the formally specified Jevko language, which, as I said, has no strings. For example, a Common Lisp hosted Jevko parser implementation might choose to represent Jevko text objects as symbols.
      - Nullabillity 4y ago
        A "text object" is just an overly verbose name for... a string. Which doesn't necessarily have to be called a capital-s String in your chosen language, atoms/symbols are also forms of strings.
        User23 4y ago
        If you like confused and muddled understanding of types, why not just insist it’s all bit vectors? Every data type you can name is just a form of bit vector after all.
        gnulinux 4y ago
        You're not understanding. These are not strings. These are symbols. Say in python you write `a = b`. Are "a" and "b" strings? No. In these examples what you're referring to as strings are just meant to be symbols like "a" and "b". It just so happens that the implementation uses "String" data type to represent them. Other examples: in XML when you write `<abc></abc>` is "abc" a string? In s-expressions (or lisp) when you write `(if a b)` are "if", "a" and "b" strings?
eterps 4y ago
Found an example where it is used as markup: https://github.com/jevko/jevkodom.js/blob/master/test.js#L6 https://github.com/jevko/jevkodom.js/blob/master/test.js#L6
- eterps 4y ago
  If I understand correctly adding 'sub tags' requires an additional level of square brackets on siblings. I.e. when adding a bold tag on 'world!': p [Hello world!] Changes it to: p [[Hello ] b[world!]]
  - eckza 4y ago
    If you see this, and you like it: Elm's HTML DSL is similar, and really nice. Every HTML tag (except for `text`) is an implementation of the base function `node`, which is: node : String -> List Attr msg -> List Html msg -> Html msg So in the base library, the `p` tag is implemented as p : List Attr msg -> List Html msg -> Html msg p = node "p" Which means that in Elm, the above content would look like this: p [] [ text "Hello ", b [] [ text "World" ] ] i.e., every HTML tag can accept as parameters: - A list of attributes - A list of child tags I've found it to be very elegant to work with; and with a good auto-formatter, it's really easy to build complicated HTML without losing your place and dropping a closing tag.
    - djedr 4y ago
      Certainly! The advantage of a Jevko-based format over the above is that it has the simplicity and elegance parameters (IMO) cranked up to maximum! ;) Now, for the tool support...
  - djedr 4y ago
    Nice find and you understand correctly! ;) This is one way. I've experimented with many others. Some semi-documented here: https://github.com/jevko/markup-experiments https://github.com/jevko/markup-experiments Some ways don't need additional level of nesting, but it's a trade-off. In the end something like the way you linked is my favorite, because it's very simple. It also gives you explicit control over your text nodes. Attributes can also be added in many ways, but I think I prefer them simply looking like child nodes, except with `=` appended to attribute name: p [class=[sth] [content]] Technically you can mix attributes and elements this way, but it does no harm.
zokier 4y ago
I don't understand the whitespace handling here, it seems very underdefined? Taking the example from github page (abbreviated): first name [John] last name [Smith] address [ street address [21 2nd Street] ] why isn't it equivalent to this json? { "first name ": "John", "\nlast name ": "Smith", "\naddress ": { "\n street address ": "21 2nd Street" } } somehow the whitespace is instead implicitly magiced away, but that isn't defined in the grammar anywhere as far as I can see?
- User23 4y ago
  I wondered this too. Magic behavior is the opposite of what I’d want from Jevko. At that point I may as well use s-exps.
- deleted 4y ago
  [deleted]
  - djedr 4y ago
    Indeed, in most of the formats I built on Jevko this is how it works. To use the nomenclature from the spec, if there are no subjevkos (subtrees) in a jevko (tree), then it is interpreted as a string (which is made from its suffix).
- zokier 4y ago
  Simple answer is that apparently the examples are false, feeding the above string to the JS parser spits out the following object: { "subjevkos": [ { "prefix": "first name ", "jevko": { "subjevkos": [], "suffix": "John" } }, { "prefix": "\nlast name ", "jevko": { "subjevkos": [], "suffix": "Smith" } }, { "prefix": "\nis alive ", "jevko": { "subjevkos": [], "suffix": "true" } }, { "prefix": "\nage ", "jevko": { "subjevkos": [], "suffix": "27" } }, { "prefix": "\naddress ", "jevko": { "subjevkos": [ { "prefix": "\n street address ", "jevko": { "subjevkos": [], "suffix": "21 2nd Street" } } ], "suffix": "\n" } } ], "suffix": "", "opener": "[", "closer": "]", "escaper": "`" } tbh seems like a pita to clean up afterwards
tomjakubowski 4y ago
I'd be interested in a more detailed comparison to s-exprs. Jevko reads less noisily because it uses fewer brackets, which is nice, but the ambiguity around whitespace gives me pause. How is it simpler or lower-level than s-exprs?
- djedr 4y ago
  One comparison is here: https://jevko.github.io/compactness.html https://jevko.github.io/compactness.html To see how it's syntactically simpler than S-exps note that the grammar of Jevko can be condensed into one short line of ABNF: Jevko = *("[" Jevko "]" / "`" ("`" / "[" / "]") / %x0-5a / %x5c / %x5e-5f / %x61-10ffff) The grammar of S-exps on the other hand, I won't quote here, but I assure you it's much more complicated. How much depends on your flavor (Jevko is also simpler in this regard: there is only one flavor, clearly specified). There is no (intended) ambiguity around whitespace in Jevko: whitespace does not occur explicitly in the grammar. Whitespace characters are just characters. This is the defining feature of the syntax. For this reason Jevko is more low-level: if you want to treat whitespace in some special way, you have to do that yourself. Although for most use-cases this is very similar and simple, e.g. https://news.ycombinator.com/item?id=33334314 https://news.ycombinator.com/item?id=33334314 But the point is that you can also leave it as-is, e.g.: https://github.com/jevko/queryjevko.js https://github.com/jevko/queryjevko.js or do something else -- it's up to your format.
  - simplotek 4y ago
    > To see how it's syntactically simpler than S-exps (...) Has anyone ever complained that S-expr were too complex? Adding white noise as a tradeoff doesn't seem like a win.
    - avmich 4y ago
      > Has anyone ever complained that S-expr were too complex? Ask parser writers, I guess? I had some similar devices, explicitly made so that the overall set of parsing rules would be clear, so the idea is likely not too new.
ianbicking 4y ago
Seems like there's a bunch of problems: 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. 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. 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. 4. If an intermediary can't understand it then why define a syntax at all? 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. 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. I think XML shows that "just strings" isn't fatal, and lots of things get jammed into strings in JSON too, you'll never be able to reproduce every type in a general purpose serialization format (I guess XML with namespaces attempted, but also clearly failed). So I can see a place for something that defines a tree where all leaves are strings. But this doesn't seem like a very clean way to do that. [1] https://docs.python.org/3/library/xml.etree.elementtree.html#element-objects https://docs.python.org/3/library/xml.etree.elementtree.html...
- djedr 4y ago
  > 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 it. This is where you should specify a format (which should be standardized) that you use, e.g.: * https://github.com/jevko/easyjevko.lua 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 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 https://github.com/jevko/binary-experiments At some point I might go forward with one, but that's not the focus right now.
djedr 4y ago
Author here, thanks for posting this. If anybody has any technical questions or comments, ask away!
- chii 4y ago
  it's quite interesting. It would be fun to try write that parser/ast library in a language such as haxe (haxe.org) and have it compile to the many target languages that it has - it makes it easier to try it out. When i get some free time this weekend, it'd be a nice fun afternoon hacking project.
  - djedr 4y ago
    If you ever publish the project, send me a gmail at darius.j.chuck I'd love to feature it here: https://github.com/jevko/community https://github.com/jevko/community
  - djedr 4y ago
    By all means! If you run into any trouble let me know. Some tips and useful links are here: https://lobste.rs/s/xm6mm4/jevko_minimal_general_purpose_syntax#c_z3zzbz https://lobste.rs/s/xm6mm4/jevko_minimal_general_purpose_syn... Thanks for the interest! :)
chriswarbo 4y ago
How does this relate to the (earlier?) tree-annotation/TAO system (seemingly from the same author): https://djedr.github.io/mirror/tao/tao.html https://djedr.github.io/mirror/tao/tao.html
- djedr 4y ago
  Nice find! Jevko is the evolved version of that (I'm the author).
zeckalpha 4y ago
Reminds me of Rebol, a precursor to JSON.
- djedr 4y ago
  Yes, it has the same spirit of S-expressions and shares the lovely square brackets with Rebol. The major difference is that Jevko is whitespace-agnostic: it has no notion of elements separated with whitespace. Generally it's a simpler, more low-level thing. It could be used to build a Rebol-like language. You could add whitespace rules on that level. A toy example: https://github.com/jevko/jevkalk https://github.com/jevko/jevkalk This one does not use whitespace as a separator, allowing spaces in identifiers at the expense of more brackets.
  - zeckalpha 4y ago
    And that one reminds me of https://github.com/kmarekspartz/yapl/ https://github.com/kmarekspartz/yapl/ :)
lgas 4y ago
Nice! I wrote a little parser for it (https://github.com/lgastako/jevko https://github.com/lgastako/jevko). It was fun. I'll have to play with building higher level formats on top of it.
- djedr 4y ago
  Awesome, very happy to hear this! For a simple higher-level format, have look at Easy Jevko: * https://github.com/jevko/easyjevko.lua https://github.com/jevko/easyjevko.lua – implementation in Lua * https://github.com/jevko/easyjevko.js https://github.com/jevko/easyjevko.js – implementation in JS A way to complicate it is to add a schema like: https://github.com/jevko/interjevko.js https://github.com/jevko/interjevko.js A lousy demo of that (with syntax coloring!) is here: https://jevko.github.io/interjevko.bundle.html https://jevko.github.io/interjevko.bundle.html I hope to work out simple specs for these formats eventually.
- djedr 4y ago
  Would you mind if I feature this somewhere on a Jevko-related page with attribution to your GitHub user account (or whatever you want)?
  - lgas 4y ago
    Sure, you can use it wherever, however you like.
    - djedr 4y ago
      Thanks! I put it here: https://github.com/jevko/community https://github.com/jevko/community Cheerio

68 points by memorable 4y ago

A minimal general purpose syntax for what? I followed the link and read the page, but I’m still not sure what the point is!

gnulinux 4y ago
For anything? Say you build your own language, but don't want to write a parser for it (people who write tons of prog langs know that syntax is the most boring part (for some, I'm sure some people love it)) so you can borrow this, it gives you a syntax tree, and you just continue from there.
eterps 4y ago
> A minimal general purpose syntax for what? Apparently for the same things as with XML/JSON/TOML. > I followed the link and read the page, but I’m still not sure what the point is! According to the website: > It has no data types, no semantics, no underlying model of cons cells or anything similar. It’s as close to pure generic syntax as it gets. > So at the lowest level Jevko is a minimal formal specification for flexible trees of text. For its simplicity it seems quite powerful to me. I don't see it replacing JSON/markdown or even TOML. But is seems trivial to implement on very low-level, older, less bloated, or less powerful systems.
- djedr 4y ago
  This is correct. Every time I've written or otherwise dealt with JSON/XML/etc. I wished I was dealing with something simpler, so I created it. If I had Jevko as a full-fledged alternative to JSON or XML, supported by tools, etc., I'd pick Jevko in a heartbeat. I like minimalism. Some people like it too, so perhaps Jevko can serve them well. There are many good reasons. > But is seems trivial to implement on very low-level, older, less bloated, or less powerful systems. Indeed, this is THE feature and a realistic application. I hope! For a naive unrealistic vision that I sketched out some time ago see: https://github.com/jevko/writing/blob/main/2022-01-13-vision.md https://github.com/jevko/writing/blob/main/2022-01-13-vision...
saurik 4y ago
If it was "for" something wouldn't it no longer be general purpose?...

tpoacher 4y ago

I appreciate your effort, but your explanation on the first page is too abstract to the point that I read to the end and still didn't know exactly what Jevko is and how to use it. E.g. you introduce "Subjevko" as if it's known knowledge. Also, the singular link to "examples" on that page, which is what I really want to see first, was broken. My advice: for every point you make have a single, simple, illustrative example right below the explanatory text (or better yet, right above it!).

djedr 4y ago
Thank you for your feedback. Can you clarify? What is the "first page" that you are referring to? Can you paste a link to it along with the broken examples link? This Hacker News submission features the blog post under this URL: https://djedr.github.io/posts/jevko-2022-02-22.html https://djedr.github.io/posts/jevko-2022-02-22.html Clearly, you are not talking about this page, as that contains multiple links rather than a singular link. Perhaps you are talking about the specification which is here: https://github.com/jevko/specifications/blob/master/spec-standard-grammar.md https://github.com/jevko/specifications/blob/master/spec-sta... (linked from the blog post) and here: https://jevko.org/spec.html https://jevko.org/spec.html (linked from jevko.org) All three link to Jevko examples here: https://github.com/jevko/examples https://github.com/jevko/examples but all these examples links seem to be correct on my end. I agree about the importance of examples, and I try to lead with them on jevko.org and jevko.github.io (which are the front pages of Jevko -- possibly I should merge them into one). However a formal specification is not necessarily the place to put the leading examples. This is also where the Subjevko rule is defined. It isn't quite introduced as "known knowledge" -- the purpose of a specification is to define the unknown, more or less from the ground up. This is also why specifications tend to get a little abstract. Jevko's spec is no exception. This should be in line with expectations of authors of tools such as parsers, validators, generators, or other kinds of processors, for which the spec is the authoritative reference. It is not necessarily the best first place to look for explanation, if you are approaching from a more casual side. I agree that from that side a clear picture of what Jevko is and how it can be used is still lacking. I certainly should add more examples and explain the concepts with analogies. So I appreciate the essence of your advice and hope I'll manage to improve on that.

Trufa 4y ago

Interesting, I'm wondering where something like this could be useful.

eterps 4y ago
There are a couple of examples here: https://github.com/jevko/examples https://github.com/jevko/examples
deleted 4y ago
[deleted]

Nullabillity 4y ago

I wish we could stop making up new languages in 2022 that use unenclosed strings...

User23 4y ago
There are no strings in this language.
- Nullabillity 4y ago
  The first example on https://jevko.org/ https://jevko.org/ contains plenty of strings.
  - User23 4y ago
    No, it contains a tree of text objects, which aren’t strings. Now the language that the Jevko parser is written in will probably store that text tree using strings, but that’s a statement about the parser implementation and not the formally specified Jevko language, which, as I said, has no strings. For example, a Common Lisp hosted Jevko parser implementation might choose to represent Jevko text objects as symbols.
    - Nullabillity 4y ago
      A "text object" is just an overly verbose name for... a string. Which doesn't necessarily have to be called a capital-s String in your chosen language, atoms/symbols are also forms of strings.
      - User23 4y ago
        If you like confused and muddled understanding of types, why not just insist it’s all bit vectors? Every data type you can name is just a form of bit vector after all.
      - gnulinux 4y ago
        You're not understanding. These are not strings. These are symbols. Say in python you write `a = b`. Are "a" and "b" strings? No. In these examples what you're referring to as strings are just meant to be symbols like "a" and "b". It just so happens that the implementation uses "String" data type to represent them. Other examples: in XML when you write `<abc></abc>` is "abc" a string? In s-expressions (or lisp) when you write `(if a b)` are "if", "a" and "b" strings?

eterps 4y ago

Found an example where it is used as markup: https://github.com/jevko/jevkodom.js/blob/master/test.js#L6 https://github.com/jevko/jevkodom.js/blob/master/test.js#L6

eterps 4y ago
If I understand correctly adding 'sub tags' requires an additional level of square brackets on siblings. I.e. when adding a bold tag on 'world!': p [Hello world!] Changes it to: p [[Hello ] b[world!]]
- eckza 4y ago
  If you see this, and you like it: Elm's HTML DSL is similar, and really nice. Every HTML tag (except for `text`) is an implementation of the base function `node`, which is: node : String -> List Attr msg -> List Html msg -> Html msg So in the base library, the `p` tag is implemented as p : List Attr msg -> List Html msg -> Html msg p = node "p" Which means that in Elm, the above content would look like this: p [] [ text "Hello ", b [] [ text "World" ] ] i.e., every HTML tag can accept as parameters: - A list of attributes - A list of child tags I've found it to be very elegant to work with; and with a good auto-formatter, it's really easy to build complicated HTML without losing your place and dropping a closing tag.
  - djedr 4y ago
    Certainly! The advantage of a Jevko-based format over the above is that it has the simplicity and elegance parameters (IMO) cranked up to maximum! ;) Now, for the tool support...
- djedr 4y ago
  Nice find and you understand correctly! ;) This is one way. I've experimented with many others. Some semi-documented here: https://github.com/jevko/markup-experiments https://github.com/jevko/markup-experiments Some ways don't need additional level of nesting, but it's a trade-off. In the end something like the way you linked is my favorite, because it's very simple. It also gives you explicit control over your text nodes. Attributes can also be added in many ways, but I think I prefer them simply looking like child nodes, except with `=` appended to attribute name: p [class=[sth] [content]] Technically you can mix attributes and elements this way, but it does no harm.

zokier 4y ago

I don't understand the whitespace handling here, it seems very underdefined? Taking the example from github page (abbreviated): first name [John] last name [Smith] address [ street address [21 2nd Street] ] why isn't it equivalent to this json? { "first name ": "John", "\nlast name ": "Smith", "\naddress ": { "\n street address ": "21 2nd Street" } } somehow the whitespace is instead implicitly magiced away, but that isn't defined in the grammar anywhere as far as I can see?

User23 4y ago
I wondered this too. Magic behavior is the opposite of what I’d want from Jevko. At that point I may as well use s-exps.
deleted 4y ago
[deleted]
- djedr 4y ago
  Indeed, in most of the formats I built on Jevko this is how it works. To use the nomenclature from the spec, if there are no subjevkos (subtrees) in a jevko (tree), then it is interpreted as a string (which is made from its suffix).
zokier 4y ago
Simple answer is that apparently the examples are false, feeding the above string to the JS parser spits out the following object: { "subjevkos": [ { "prefix": "first name ", "jevko": { "subjevkos": [], "suffix": "John" } }, { "prefix": "\nlast name ", "jevko": { "subjevkos": [], "suffix": "Smith" } }, { "prefix": "\nis alive ", "jevko": { "subjevkos": [], "suffix": "true" } }, { "prefix": "\nage ", "jevko": { "subjevkos": [], "suffix": "27" } }, { "prefix": "\naddress ", "jevko": { "subjevkos": [ { "prefix": "\n street address ", "jevko": { "subjevkos": [], "suffix": "21 2nd Street" } } ], "suffix": "\n" } } ], "suffix": "", "opener": "[", "closer": "]", "escaper": "`" } tbh seems like a pita to clean up afterwards

tomjakubowski 4y ago

I'd be interested in a more detailed comparison to s-exprs. Jevko reads less noisily because it uses fewer brackets, which is nice, but the ambiguity around whitespace gives me pause. How is it simpler or lower-level than s-exprs?

djedr 4y ago
One comparison is here: https://jevko.github.io/compactness.html https://jevko.github.io/compactness.html To see how it's syntactically simpler than S-exps note that the grammar of Jevko can be condensed into one short line of ABNF: Jevko = *("[" Jevko "]" / "`" ("`" / "[" / "]") / %x0-5a / %x5c / %x5e-5f / %x61-10ffff) The grammar of S-exps on the other hand, I won't quote here, but I assure you it's much more complicated. How much depends on your flavor (Jevko is also simpler in this regard: there is only one flavor, clearly specified). There is no (intended) ambiguity around whitespace in Jevko: whitespace does not occur explicitly in the grammar. Whitespace characters are just characters. This is the defining feature of the syntax. For this reason Jevko is more low-level: if you want to treat whitespace in some special way, you have to do that yourself. Although for most use-cases this is very similar and simple, e.g. https://news.ycombinator.com/item?id=33334314 https://news.ycombinator.com/item?id=33334314 But the point is that you can also leave it as-is, e.g.: https://github.com/jevko/queryjevko.js https://github.com/jevko/queryjevko.js or do something else -- it's up to your format.
- simplotek 4y ago
  > To see how it's syntactically simpler than S-exps (...) Has anyone ever complained that S-expr were too complex? Adding white noise as a tradeoff doesn't seem like a win.
  - avmich 4y ago
    > Has anyone ever complained that S-expr were too complex? Ask parser writers, I guess? I had some similar devices, explicitly made so that the overall set of parsing rules would be clear, so the idea is likely not too new.

ianbicking 4y ago

Seems like there's a bunch of problems: 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. 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. 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. 4. If an intermediary can't understand it then why define a syntax at all? 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. 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. I think XML shows that "just strings" isn't fatal, and lots of things get jammed into strings in JSON too, you'll never be able to reproduce every type in a general purpose serialization format (I guess XML with namespaces attempted, but also clearly failed). So I can see a place for something that defines a tree where all leaves are strings. But this doesn't seem like a very clean way to do that. [1] https://docs.python.org/3/library/xml.etree.elementtree.html#element-objects https://docs.python.org/3/library/xml.etree.elementtree.html...

djedr 4y ago
> 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 it. This is where you should specify a format (which should be standardized) that you use, e.g.: * https://github.com/jevko/easyjevko.lua 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 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 https://github.com/jevko/binary-experiments At some point I might go forward with one, but that's not the focus right now.

djedr 4y ago

Author here, thanks for posting this. If anybody has any technical questions or comments, ask away!

chii 4y ago
it's quite interesting. It would be fun to try write that parser/ast library in a language such as haxe (haxe.org) and have it compile to the many target languages that it has - it makes it easier to try it out. When i get some free time this weekend, it'd be a nice fun afternoon hacking project.
- djedr 4y ago
  If you ever publish the project, send me a gmail at darius.j.chuck I'd love to feature it here: https://github.com/jevko/community https://github.com/jevko/community
- djedr 4y ago
  By all means! If you run into any trouble let me know. Some tips and useful links are here: https://lobste.rs/s/xm6mm4/jevko_minimal_general_purpose_syntax#c_z3zzbz https://lobste.rs/s/xm6mm4/jevko_minimal_general_purpose_syn... Thanks for the interest! :)

chriswarbo 4y ago

How does this relate to the (earlier?) tree-annotation/TAO system (seemingly from the same author): https://djedr.github.io/mirror/tao/tao.html https://djedr.github.io/mirror/tao/tao.html

djedr 4y ago
Nice find! Jevko is the evolved version of that (I'm the author).

zeckalpha 4y ago

Reminds me of Rebol, a precursor to JSON.

djedr 4y ago
Yes, it has the same spirit of S-expressions and shares the lovely square brackets with Rebol. The major difference is that Jevko is whitespace-agnostic: it has no notion of elements separated with whitespace. Generally it's a simpler, more low-level thing. It could be used to build a Rebol-like language. You could add whitespace rules on that level. A toy example: https://github.com/jevko/jevkalk https://github.com/jevko/jevkalk This one does not use whitespace as a separator, allowing spaces in identifiers at the expense of more brackets.
- zeckalpha 4y ago
  And that one reminds me of https://github.com/kmarekspartz/yapl/ https://github.com/kmarekspartz/yapl/ :)

lgas 4y ago

Nice! I wrote a little parser for it (https://github.com/lgastako/jevko https://github.com/lgastako/jevko). It was fun. I'll have to play with building higher level formats on top of it.

djedr 4y ago
Awesome, very happy to hear this! For a simple higher-level format, have look at Easy Jevko: * https://github.com/jevko/easyjevko.lua https://github.com/jevko/easyjevko.lua – implementation in Lua * https://github.com/jevko/easyjevko.js https://github.com/jevko/easyjevko.js – implementation in JS A way to complicate it is to add a schema like: https://github.com/jevko/interjevko.js https://github.com/jevko/interjevko.js A lousy demo of that (with syntax coloring!) is here: https://jevko.github.io/interjevko.bundle.html https://jevko.github.io/interjevko.bundle.html I hope to work out simple specs for these formats eventually.
djedr 4y ago
Would you mind if I feature this somewhere on a Jevko-related page with attribution to your GitHub user account (or whatever you want)?
- lgas 4y ago
  Sure, you can use it wherever, however you like.
  - djedr 4y ago
    Thanks! I put it here: https://github.com/jevko/community https://github.com/jevko/community Cheerio