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

Reply via email to