Remix.run Logo
jameskilton 9 hours ago

I couldn't help but notice almost immediately one feature that is not human oriented, but most likely exists because it's easier for a machine to parse: single (":") vs double colon ("::"). This is not human-friendly. A human wants to write "key" "is" "value", and YAML has for a very long time supported a single ":" for "is" regardless of the actual type of the value.

I shouldn't have to care about what the type of the value is when writing out effectively YAML. This double-colon feature will do nothing but lead to bug reports from people confused as to why their document is invalid.

xpe 9 hours ago | parent | next [-]

The comment above gives explanations defending subjective preferences about what "human oriented" means. That's fine as long as you remember that is what is happening: justification of subjective preferences. Other people can reasonably (or unreasonably) have different subjective preferences.

Also notice what the commenter above haven't done (yet, maybe they will?): done a full "forest level" comparison of all the trade-offs between the current HUML specification and ... what is your alternative proposal, exactly?

Based on my experience, I would guess that most people who design a language (and written a parser for it) for the first time will: (1) be surprised at how quickly design decisions snowball and lead to unexpected places; (ii) discover just how entangled design choices really are; (iii) will give up on trying to please everyone.

In my view, a language designer does really well to describe one's motivations, goals, tradeoffs, decisions, and then live with what you make, because... (a) making something real and useful is rad and (b) any language you make will probably have some weird stank you can't seem to get rid of.

DonHopkins 6 hours ago | parent [-]

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. [...]

jampekka 9 hours ago | parent | prev | next [-]

I find this very human-friendly: "[double colon] permits vectors to be defined inline without additional syntax such as [ ... ] or { ... }."

(One could question how human friendly it is to call lists and dicts "vectors" though...)

https://huml.io/specifications/v0-1-0/#why

sippeangelo 8 hours ago | parent [-]

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

  props:: mime_type: "text/html", encoding: "gzip" # Inline dict.
OJFord 7 hours ago | parent [-]

But that's not done for human readability, that's done for machine parsing? A human would understand just as well:

  props: mime_type: "text/html", encoding: "gzip" # Inline dict.
lucketone 5 hours ago | parent | next [-]

My mind has a feeling that this might be possible interpretation:

    props: [mime: [html, encoding:[gzip]]]
(Even if not legal, to be sure, I must backtrack and concentrate on this particular piece)

There are many different humans. I definitely like the idea to separate “:: vs :”.

F3nd0 5 hours ago | parent | prev [-]

For me, it’s clearer with a double colon. Not intuitive, but extremely easy to get used to. When I see the first colon introduce a list, I have to go out of my way to not see the other colons as introducing lists.

debo_ 7 hours ago | parent | prev | next [-]

I think we should have a name for the often undue examination and analysis of colon/semicolon usage in machine languages. I volunteer the name "colonoscopy."

DonHopkins 6 hours ago | parent [-]

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

Sohcahtoa82 9 hours ago | parent | prev | next [-]

The double-colon is probably a necessity to disambiguate a scalar from an inline list that only has one scalar.

For example `x: 3` would be equivalent to `"x": 3` in JSON, but `x:: 3` is equivalent to `"x": [3]`

lucketone 5 hours ago | parent | next [-]

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

SpaceNoodled 6 hours ago | parent | prev [-]

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

JoBrad 7 hours ago | parent | prev | next [-]

I found that example to be humerous, but specifically compared to the goals:

> Provide as few ways as possible—preferably one—of representing something.

Very Pythonic. Especially since representing a dict already has 2 ways, on the first page!

sunrunner 6 hours ago | parent [-]

> 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)? ;)

inerte 7 hours ago | parent | prev | next [-]

Maybe the plural of "is" is "are" :)

But why double the character instead of picking another one... plenty of other non-alphanumeric characters to chose from.

xg15 5 hours ago | parent | prev | next [-]

There would at least be some ambiguity with single-value lists otherwise:

If

  numbers: 1, 2, 3
was a list, what would

  numbers: 1
be?
jampekka 5 hours ago | parent [-]

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

xg15 4 hours ago | parent [-]

True, but I think that wouldn't be any more intuitive or error safe than the :: syntax.

xpe 9 hours ago | parent | prev | next [-]

Language design often involves subjective tradeoffs. The author gives their rationale here: https://huml.io/specifications/v0-1-0/#why

LordDragonfang 8 hours ago | parent [-]

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`.

8 hours ago | parent | prev | next [-]
[deleted]
vczf 8 hours ago | parent | prev [-]

The clear distinction between scalars and vectors appears to be the main advancement HUML offers.

I think it’s a neat improvement.