People have suggested using the control characters for CSV structured files. The problem is that they are impossible to edit.

Control characters are invisible, using them means changing text editors to display them. They are also, outside the usual ones, hard to type. ASCII ones have Ctrl combos, but editors used those for other things.

Also, what is the difference between using some new character to start block and "{" or "\n"? Why have new thing to indicate new level when have space and tab?

Well in that case, it's all the ways that IDEs like to jank up whitespace, as well as the additional difficulty knowing 'context'.

With JSON it's fairly easy for me to know if I want to end my structure as well as the structure containing it, I can just type }}, and add the next element.

With whitespace you have to keep track of HOW MUCH whitespace, and trust me once you've got people who are entirely inconsistent with how much whitespace they use it becomes a huge PITA.

Probably the verbosity, necessity of a schema for typing, and mixing of text with tags as siblings.

But it can't be minified without keeping the line endings and whitespace, unlike JSON.

The original designers of YAML explicitly declared in its name "Yet Another Markup Language" that it was designed to be a markup language, which it most certainly was not. Eventually somebody finally pointed out the mistake, and they sheepishly retronymed it "YAML Ain't Markup Language".

https://stackoverflow.com/questions/6968366/if-yaml-aint-mar...

On the other hand, and to your points, Relax/NG (both its XML and simplified syntaxes) is a beautiful successful example of wisely and collaboratively designing a new clean powerful system with the deep understanding of what a markup language really is (James Clark was deeply involved with many SGML and XML standards and implementations), and full cognizance of the strengths and weaknesses of other systems you're trying to replace (SGML DTDs, XML Schemas, TREX, RELAX, XDuce, and other experimental XML schema languages).

https://en.wikipedia.org/wiki/RELAX_NG

>In computing, RELAX NG (REgular LAnguage for XML Next Generation) is a schema language for XML—a RELAX NG schema specifies a pattern for the structure and content of an XML document. A RELAX NG schema is itself an XML document but RELAX NG also offers a popular compact, non-XML syntax.[1] Compared to other XML schema languages RELAX NG is considered relatively simple.

RELAX NG Compact Syntax

https://www.oasis-open.org/committees/relax-ng/compact-20021...

https://relaxng.org/jclark/design.html

The Design of RELAX NG

James Clark (jjc@thaiopensource.com)

Abstract: RELAX NG is a new schema language for XML. This paper discusses various aspects of the design of RELAX NG including the treatment of attributes, datatyping, mixed content, unordered content namespaces, cross-references and modularity. [...]

>Composability

>RELAX NG is designed to be highly composable. A schema language (or indeed a programming language) provides a number of atomic objects and a number of methods of composition. The methods of composition can be used to combine atomic objects into compound objects which can in turn be composed into further compound objects. The composability of the language is the degree to which the various methods of composition can be applied uniformly to all the various objects of the language, both atomic and compound. For example, RELAX NG provides a choice element that can be applied uniformly to elements, attributes, datatypes and enumerated values. This is not mere syntactic overloading. The choice element has a single uniform semantic in all these cases and can have a single implementation. Another example is the grammar element, which is the container for definitions. The grammar element is just another pattern and can be composed in just the same way as other patterns. Composability improves ease of learning and ease of use. Composability also tends to improve the ratio between complexity and power: for a given amount of complexity, a more composable language will be more powerful than a less composable one. [...]

>XML syntax

RELAX NG uses XML instance syntax to express schemas. Although this makes for a rather verbose schema language, it has some major advantages. Since a user of an XML schema language must necessarily already learn XML instance syntax, using XML instance syntax for the schema language reduces the learning burden on a schema user. It also allows XML tools and technologies to be applied to the schema. For example, a schema can be used to specify the syntax of the schema language. Another important benefit of XML syntax is extensibility. RELAX NG has an open syntax that allows the RELAX NG defined elements and attributes to be annotated with elements and attributes from other namespaces. RELAX NG DTD Compatibility [12] uses this annotation mechanism to extend RELAX NG with a mechanism for declaring default values for attributes. RelaxNGCC [23] uses this annotation mechanism to allow users to embed Java code in RELAX NG schemas, which gets executed as an XML document is parsed against the schema. An unofficial non-XML syntax for RELAX NG has also been developed [8]. The non-XML syntax can be used for authoring RELAX NG schemas by hand and can then be transformed into the standard RELAX NG XML syntax for interchange. [...]

It's especially clear in the "inline dict" example. I really like it!

  props:: mime_type: "text/html", encoding: "gzip" # Inline dict.

And the obsession with inserting colons into things (and vice-verse) should be called "colonialism".

Maybe author of huml will read: I would prefer mandatory braces for inline stuff. “X:: 3” feels like a trick question.

A trailing comma would also solve this, but is equally awkward. A clear list delimiter would work for both machines and humans.

> Especially since representing a dict already has 2 ways,

And lists.

> Pythonic

Pythonic in the way that Python's 'There should be one...' is expressed through the existence of tuples, named tuples, dataclasses, regular classes and attrs (not part of the standard library but it seems to be as much of a goto as requests is)? ;)

You could have it like in Python tuples where 1 is a scalar and 1, is a tuple.

Slightly off-topic, but I find the text of that anchor fragment amusing ("why? just why?") and a little disappointing. Automatic CMSs have robbed us of attention to detail - that anchor (for "Why `::`?") should probably be changed to `why-double-colon`.

Yeah, I don't disagree. I'd go further and say the examples are on-point for a "human oriented" language. But the formal spec reveals how simple or complicated this language is. (And I'm also writing this from the perspective of someone who uses a programming language that does not have a HOML implementation).

That's for computers, though, not humans.

It's not more verbose than this markup; strictness is only necessary for disambiguation; and comments are part of JSON5.

There are plenty of times in Python and YAML I cannot visually figure out where some block ends.

JSON prevents this by explicitly closing lists and dicts. Though you do end up with Ladders to Heaven of `}`'s and `]`'s where you have no goddamn clue what is actually being closed out.

XML prevents this by explictly stating what element was just closed. Deeply nested XML, provided the elements don't have some 300 character set of attributes all jammed into the opening element, is vastly easier to read than YAML.

Story time!

Way back in like 2012-2013 I was putting together workflows in ESRI ArcGIS.

The options for scripting were either VBScript or Python. Python was the better choice (AFAIR the UI would show what you were doing in it as python, which made it easy to take a manual flow you developed and automate.)

However, the editor window for scripts in the UI, used the default windows dialog font configured for the user. [0] I wound up having to put together a workflow where I'd have to copy-paste back and forth from a text editor, which was fairly unproductive.

[0] - No, changing the dialog font to fixed width was not a great solution, because then other apps suddenly had terrible UX due to their design....