A well-known problem in YAML is a type-inference issue in parsing where a string is misinterpreted as a boolean. This is known as the "Norway problem", because it occurs when a field or array entry intended to hold an ISO-3166-2 country code as a string is given the code for Norway — NO.

- SE
- NO
- FI

YAML accepts yes and no as true and false values, and so when processed the expected string value in the field is instead a boolean. The syntax highlighting above should indicate that.

Norway is the most noted source of these issues, but it would also happen for Ontario, and for values expected to include the strings "yes", "true", "false" (Unix commands), "off" (not leg), "null" (a surname), "nan" (a relative), and some others. A similar, but separate, issue can arise with version numbers, where 1.2.1 and 1.2 are different types, or ratios, where 1:12 is the float 1.2 but 5:60 is a string.

While YAML is a human-editable serialisation format, reminiscent issues could arise in Perl, PHP, shell scripts, and a number of other unequivocal programming languages with unmarked string literals, as well as some other configuration and transfer formats. Later versions of YAML attempted to remove much of this overloading, and it and similar constructions are generally frowned upon — but still present in real-world systems.

There are variations, but versions of this sort of issue have arisen enough that the choices leading to them must have value. What conditions lead to these decisions, in YAML or elsewhere, and when (if ever) is this sort of "smart" value parsing a worthwhile trade-off?


1 Answer 1


It is a somewhat reasonable idea to provide convenient facilities for presumed common cases, but when done carelessly, it tends to backfire in unexpected situations. Javascript is notoriously plagued by this problem. Introducing features like this makes the language generally simpler to use. That's why you can see this in scripting and configuration languages, where it had been intended to facilitate simple tasks. However, the benefits tend to eventually get outweighted by the confusing and inconvenient experiences with unaccounted use-cases. I don't believe there's any further motive behind such features other than the near-sightedness of the language authors.

  • 2
    $\begingroup$ "It makes easy things easier, and hard things impossible." $\endgroup$ Jul 27, 2023 at 2:54
  • $\begingroup$ @JohnGordon is that a quote you've found elsewhere? I like it! I'd love the source, and if it's you, to quote you :-) $\endgroup$
    – 0atman
    Dec 4, 2023 at 9:15
  • 1
    $\begingroup$ @0atman It's a half-remembered quote about something on Windows -- possibly Visual Basic? It's a deliberate snarky take on an earlier quote something like "the easy things should be easy, and the hard things should be possible". $\endgroup$ Dec 4, 2023 at 13:31
  • $\begingroup$ @JohnGordon brilliant, that's VB in a nut shell! thank you! $\endgroup$
    – 0atman
    Dec 13, 2023 at 16:43

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .