No mention of NFG in the docs?

[lizmat]

Looks like NFG is not explained anywhere? While it is one of the Unique Selling Points of Raku.

https://6guts.wordpress.com/2015/04/30/this-week-the-big-nfg-switch-on-and-many-fixes/ perhaps as a source of information?

[JJ]

Not that I remember. We'll have to do something about it. Thanks for the report.

[coke]

We should still have our own writeup, but:

https://docs.raku.org/language/glossary#index-entry-NFG points to articles

and there are multiple pointers to that in Lang/regex, Lang/unicode, and Type/Cool

[mykhal]

I was writing new issue request (but eventually got here):

Raku docs don't seem to sufficiently reflect potentially unexpected Unicode normalization during Str construction. (I don't see it mentioned in docs at raku.org). See e.g. following cases:

"\x340" eq "\x300" ;           # True # False might have been expected
"\x340".ords.map(*.base(16)) ; # (300) # (340) might have been expected

Find some more interesting character on which it happens, put it in nicer code example, and mention it at least in

• type/Str

maybe also in

• language/syntax#String_literals

Also mention how to make/handle intentionally non-normalized Unicode strings, if applicable.

[JJ]

Any idea why it happens in that specific case? Is that legit or is it a bug?

[mykhal]

@JJ it's OK, see red closed rakudo issue #4457 link above. Non-normalizad Unicode strings should be probably done like

Uni(0x340).list eqv Uni(0x300).list  # False

(direct Uni eqv'ing does not (yet(?)) work. UPDATE: now it does)

[JJ]

So it's totally legit, but it might still need some explanation as required by the OP.

[mykhal]

Right. Here it's kind of mentioned: language/traps, section All text is normalized by default. Similar example might fit there.