Larry Wall wrote:
On Fri, Jan 30, 2009 at 03:30:02AM -0800, Darren Duncan wrote:
What's with this NFG / Normal Form G that you refer to? I don't see any
mention of that in http://unicode.org/reports/tr15/ ... did you mean NFC?
Nope, this is a Perl/Parrot idea. It started out with a notion of mine a
year ago. Search for 'grapheme' in
We named it NFG about the time Simon Cozens wrote a PDD for it for parrot.
At the moment it's much better specced in Parrotland than in P6land. See
Okay, I understand now. NFG is designed just as a temporary in-process normal
form where the same representation of a character as a number can't reliably be
consistent over the long term, unlike NFC/D/KC/KD/etc.
It does occur to me, though, that as long as we include the generated lookup
table (not required for NFC/etc), NFG can be serialized as is and be
unambiguously understood by NFG-savvy programs over the long term.
Much how LZW (name?) compression works, that includes its own lookup table.
So as long as this nature of NFG is understood, and if necessary any serialized
forms will include a spec version num / etc as protection in the face of
upgrades, this could also stand to be a standard beyond Perl/Parrot/etc.
I wonder if the Unicode consortium would be interested in adopting an NFG-alike,
or whether that would be beyond their scope?
By the way, we could use someone to write the Perl 6 Unicode synopsis,
based on PDD 28.
Well, if someone else doesn't do it first, I don't think it would be too
difficult for me to do this, at least the initial based-on-PDD-28 cut; however
it would likely be a few weeks before I get around to it, partly since I don't
have a Pugs repo checkout in place ... maybe when I port the new Set::Relation
to Perl 6, requiring such a checkout, I may do that too ... but don't wait for me.
By the way, in the mean-time, someone should update that reference to NFG in S02
to include a link to that PDD28, so other people encountering it don't have to
ask the same question I did.
-- Darren Duncan