TRUTH!
Or, expressed in YAML 1.1 [1]
y
Y
yes
Yes
YES
true
True
TRUE
on
On
ON
trueI 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.
For example `x: 3` would be equivalent to `"x": 3` in JSON, but `x:: 3` is equivalent to `"x": [3]`
(One could question how human friendly it is to call lists and dicts "vectors" though...)
props:: mime_type: "text/html", encoding: "gzip" # Inline dict.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.
I think it’s a neat improvement.
Or restrictions like "only one space allowed after : before a value"
25 minute talk at https://www.youtube.com/live/AUrPdOZNsX8?feature=shared&t=13... (starts 3h:52)
The talk proposal is at https://fossunited.org/c/indiafoss/2025/cfp/arsnhack6n
And it primarily tries to avoid YAML horrors : https://noyaml.com/ and https://ruudvanasseldonk.com/2023/01/11/the-yaml-document-fr....
bmn__•1h ago
Term not found.
xpe•45m ago