HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
jevko
specifications
HTML2022–2022
jevko / specifications

specifications

Specifications related to Jevko.

2Distinct people
6Mentions
0Explicit recommenders
10GitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

Specifications related to Jevko.

GitHub

Where it is used

No documented product use has been verified yet.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

No other repository is repeatedly linked in the same discussions.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 1:49:46 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by day6 dated mentions

Observed mentions: 2022-10-18 21:54:16 UTC to 2022-11-04 01:44:50 UTC.

012022-10-18 00:00:00 UTC to 2022-10-19 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 commentsOct 182022-10-19 00:00:00 UTC to 2022-10-20 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2022-10-20 00:00:00 UTC to 2022-10-21 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2022-10-21 00:00:00 UTC to 2022-10-22 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2022-10-22 00:00:00 UTC to 2022-10-23 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2022-10-23 00:00:00 UTC to 2022-10-24 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2022-10-24 00:00:00 UTC to 2022-10-25 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2022-10-25 00:00:00 UTC to 2022-10-26 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2022-10-26 00:00:00 UTC to 2022-10-27 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 commentsOct 262022-10-27 00:00:00 UTC to 2022-10-28 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2022-10-28 00:00:00 UTC to 2022-10-29 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2022-10-29 00:00:00 UTC to 2022-10-30 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2022-10-30 00:00:00 UTC to 2022-10-31 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2022-10-31 00:00:00 UTC to 2022-11-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2022-11-01 00:00:00 UTC to 2022-11-02 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2022-11-02 00:00:00 UTC to 2022-11-03 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2022-11-03 00:00:00 UTC to 2022-11-04 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2022-11-04 00:00:00 UTC to 2022-11-05 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 commentsNov 4

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
Oct 182022-10-18 00:00:00 UTC2022-10-19 00:00:00 UTC101
Oct 192022-10-19 00:00:00 UTC2022-10-20 00:00:00 UTC000
Oct 202022-10-20 00:00:00 UTC2022-10-21 00:00:00 UTC000
Oct 212022-10-21 00:00:00 UTC2022-10-22 00:00:00 UTC000
Oct 222022-10-22 00:00:00 UTC2022-10-23 00:00:00 UTC000
Oct 232022-10-23 00:00:00 UTC2022-10-24 00:00:00 UTC000
Oct 242022-10-24 00:00:00 UTC2022-10-25 00:00:00 UTC000
Oct 252022-10-25 00:00:00 UTC2022-10-26 00:00:00 UTC101
Oct 262022-10-26 00:00:00 UTC2022-10-27 00:00:00 UTC101
Oct 272022-10-27 00:00:00 UTC2022-10-28 00:00:00 UTC000
Oct 282022-10-28 00:00:00 UTC2022-10-29 00:00:00 UTC000
Oct 292022-10-29 00:00:00 UTC2022-10-30 00:00:00 UTC000
Oct 302022-10-30 00:00:00 UTC2022-10-31 00:00:00 UTC101
Oct 312022-10-31 00:00:00 UTC2022-11-01 00:00:00 UTC000
Nov 12022-11-01 00:00:00 UTC2022-11-02 00:00:00 UTC000
Nov 22022-11-02 00:00:00 UTC2022-11-03 00:00:00 UTC000
Nov 32022-11-03 00:00:00 UTC2022-11-04 00:00:00 UTC101
Nov 42022-11-04 00:00:00 UTC2022-11-05 00:00:00 UTC101

What Hacker News says

6 sources
Yes, in Elm or Lisp this would be problematic. In this syntax though it isn't. Anything between brackets like this: [foo bar baz] that does not contain any nested brackets is a simple tree which contains "foo bar baz" as its sole value (called a suffix). In this syntax whitespace is not a separator. So you can store a single piece of text in such a simple tree. Now if you want to have 3 pieces of text you do this: [foo][bar][baz] 3 simple trees together -- they are subtrees of a top-level tree. If you want to have 3 of these you do this: [[foo][bar][baz]] [[foo][bar][baz]] [[foo][bar][baz]] The linebreaks don't change the tree structure, they are inserted purely for readability. There are no implicit commas or anything. Each subtree is also potentially a name-value pair. If you insert names before the opening brackets: [x [
Read the rest
foo] y [bar] z [baz]] You have 3 pairs. The names themselves are also pieces of text (whitespace is not a separator), so you can have names like: [my x [foo] your y [bar] their z [baz]] Still 3 pairs. Now to turn trees like this into something useful, for example XML/SVG, you'd do a little bit of processing on them, e.g. you could transform the names like so: my x [foo] your y [bar] their z [baz] into: <myX>foo</myX><yourY>bar</yourY><theirZ>bar</theirZ> in this manner you could transform: svg [x=[0px] y=[0px] view box=[0 0 21 21] path [ fill=[#FFF] stroke=[#146AFF] stroke width=[2] d=[M11.1,1.4l2.4,...] ]] into: <svg x="0px" y="0px" viewBox="0 0 21 21"><path fill="#FFF" stroke="#146AFF" strokeWidth="2" d="M11.1,1.4l2.4,..." ></path></svg> Notice that here I used a convention where names which end with "=" become XML attributes, whereas names which don't become children. I have used the same convention here (except I don't bother with transforming names with spaces into camelCase): https://github.com/jevko/specifications/blob/master/easyjevk... to generate this HTML file: https://htmlpreview.github.io/?https://github.com/jevko/spec... Now I intend to write specifications that codify conventions like this into different formats based on this fundamental syntax of square brackets. It can be useful for all kinds of things. Its advantage is extreme simplicity and flexibility. BTW, for clarity I have to say that the format that I used here: https://news.ycombinator.com/item?id=32995047 does a bit more transformations -- it actually sometimes treats whitespace as a separator (e.g. in `svg width[391]` space is a separator). That allows for extreme conciseness, but is not necessary and introduces complexity.
In SVGs as Elm Code
A plain Jevko parser simply turns your unicode sequence into a tree which has its fragments as leaves/labels. No data types on that level, much like in XML. Now above that level there is several ways to differentiate between them. The simplest pragmatic way is a kind of type inference: if a text parses as a number, it's a number, if it's "true" or "false", it's a boolean. Otherwise it's a string. If you know the implicit schema of your data then this will be sufficient to get the job done. Otherwise you employ a separate schema -- JC in particular has per-parser schemas anyway, so that's covered in this case. If it wouldn't, you'd need to write a schema yourself. Or you do "syntax-driven" data types, similar to JSON, e.g. strings start w/ "'". Here is a shitty demo: https://jevko.github.io/interjevko.bundle.html It shows schema inference
Read the rest
from JSON and the schemaless (syntax-driven) flavor. Jevko itself is stable and formally specified: https://github.com/jevko/specifications/blob/master/spec-sta... It's very easy to write a parser in any language (I've written one in several) and from there start using it. However, I am still very much working on specifications for formats above Jevko. I have some recent implementations of the simplest possible format which converts Jevko to arrays/objects/strings: * https://github.com/jevko/easyjevko.lua * https://github.com/jevko/easyjevko.js The schema-driven format that was used in the demo is implemented here: * https://github.com/jevko/interjevko.js * https://github.com/jevko/jevkoschema.js
In JC – JSONifies the output of many CLI tools
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 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-sta... (linked from the blog post) and here: https://jevko.org/spec.html (linked from jevko.org) All three link to Jevko examples here: 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
Read the rest
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.
In Jevko: a minimal general-purpose syntax
> Semantics is a separate matter. I agree; and symbol is a semantic entity, not a syntactic one. S-expressions do not have symbols, they have tokens which become symbols when read into the machine. Tokens are clumps of characters. i.e. strings. > There are no symbols or references in Jevko. > @gnulinux and @User23 have it right. Those two are insisting that texts are symbols in Jevko, so the above two statements contradict each other. E.g. gnulinux> You're not understanding. These are not strings. These are symbols. User23> Jevko language [...] has no strings. For example, a Common Lisp hosted Jevko parser implementation might choose to represent Jevko text objects as symbols. > 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. Th
Read the rest
at is obviously false. It's operating on a nested list of strings, whereby it's making a semantic decision whether a string in a certain position of a nested item in the structure ends in the = character. In other words the syntax is character-level. The strings themselves have syntax, which is made of characters. That's in the Jevko specification. Characters are the atoms in Jevko. The = character that the code is looking for is a %x3D element. It's right here: https://github.com/jevko/specifications/blob/master/draft-st... The = character is %x3D. An %x3D is Character. A Character is one of the kinds of Symbol (the other being Digraph). A Symbol is a constituent of Text. Text generates a Prefix or Suffix. A Suffix alone can be a Jevko due to this rule: Jevko ::= *Subjevko Suffix Thus, formally Jevko does have Symbols: a Symbol is a Character or Digraph. A Text is a sequence of Symbols, which are Characters or Digraphs. It is in no way an atom. A sequence of characters or diagraphs is a string.
In Jevko: a minimal general-purpose syntax
This is a valid concern, but on a higher-level. Jevko leaves whitespace handling not to clients, but to formats built on Jevko which would be the thing the clients typically use (rather than plain Jevko). Such formats of course should be clearly specified, which is something I hope to get around to soon. I already have a good candidate format for specifying first, which has 2 implementations: * https://github.com/jevko/easyjevko.js * https://github.com/jevko/easyjevko.lua For more details see also: * https://news.ycombinator.com/item?id=33335181 * https://github.com/jevko/specifications/issues/1
In Jevko: a minimal general-purpose syntax
Thank you. :) > I wonder if I should use it for something... I'd be honored! A couple of ideas: How about a simple configuration format? https://gist.github.com/djedr/681e0199859874b3324eaa84192c42... (I should make a library out of this) Or you can put it in your query strings to make them more humane: https://github.com/jevko/queryjevko.js Or make up a markup DSL: https://github.com/jevko/markup-experiments#asttohtmltable Or serialize game objects in your indie game. Or make it the interface of your experimental app. Or use it to shave off a few unnecessary characters off your data: https://jevko.github.io/compactness.html No parser in your favorite language? A basic one should be only a couple dozen lines! https://github.com/jevko/parsejevko.js / https://github.com/jevko/specifications/blob/master/spec-sta...
In Syntax Design (2014)

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.