FAQ
This question isn't strictly related to Go, but perhaps you can help me.
I'm writing a compiler for a Forth language of my own design which uses
UTF8. Later on I will write the IDE in Go, but right now I'm writing my
compiler in assembly-language. I really like assembly-language a lot better
than high-level-language (HLL), but Go is the first HLL other than Forth
that I have seen in decades that I think is worth learning, so I'm delving
into it! :-)

I'm trying to write a function that will convert lowercase text into
uppercase. This is for case-insensitive string comparisons (the symbol
table, for one thing). What I'm doing right now is just building a table of
rune values with all of the lowercase letters converted into uppercase. I
will use my rune as an index to pull out the upperized version. This is a
pretty good technique for the first couple of 256-byte pages of runes. It
is rather tedious to build the table though. Also, I don't know anything
about any languages other than English and Spanish, so I'm really just
guessing about how text is upperized in other languages.

Has anybody ever written an upperize function that covers a slew of
languages beyond English and Spanish? Hopefully this would be done by a
team of linguists who actually know those languages. Can I download this
and port it into my program? In the history of Unicode, somebody must have
bumped into this problem already --- I can't be the first.

Does the concept of uppercase and lowercase even exist in all languages?
I've heard of something called "title-case," but I don't know what that is.
I want to provide case-insensitive string comparisons for some of the more
common languages --- but I don't need to go overboard and support every
language in the world plus Klingon --- unless I get some help from somebody
who knows languages, I'll just support English and Spanish which I'm
familiar with and which should cover pretty much all of my users.

Another question: Is Go the only language that uses UTF8 as its fundamental
kind of text? I know that a lot of languages have libraries of code
available that support UTF8, but I find that to be a rather clunky approach
--- I like Go's approach in which everything including source-code is UTF8,
and this was the inspiration for me to do the same thing in my own
language. :-)

Another question: I have a function $CRUNCH that crunches all of the
overlong UTF8 codes in a string and produces a proper UTF8 string. I'm
going to recommend that the user do this with any string data that comes
from questionable sources. Are overlong codes much of a problem in the UTF8
world? Is Modified-UTF8 the only dirty UTF8 data that I have to fix? Is
Modified-UTF8 used very much? If all the editors and other UTF8 software in
the world produce proper UTF8, then I could just ignore the problem of
fixing overlong codes (abort with an error message if I run into them, just
like I already do with undecodable UTF8) --- I would prefer not to slow
down my own program fixing dirty data produced by other people's programs.

Another question: Is the BOM used very much in UTF8 data? That is something
else that I would prefer to just ignore.

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Search Discussions

  • Lucy hi at Dec 22, 2013 at 8:09 pm
    You could use http://golang.org/pkg/strings/#ToUpper and/or
    http://golang.org/pkg/unicode/#ToUpper for converting strings/runes to
    upper case.

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Hugh Aguilar at Dec 22, 2013 at 8:32 pm

    On Sunday, December 22, 2013 1:09:43 PM UTC-7, Lucy wrote:
    You could use http://golang.org/pkg/strings/#ToUpper and/or
    http://golang.org/pkg/unicode/#ToUpper for converting strings/runes to
    upper case.
    Is the source-code available so I could port it over to my
    assembly-language program?

    I don't know what the definition of "uppercase" and "lowercase" is --- in
    ascii it was simple because the uppercase and lowercase alphabets were in
    blocks of A--Z and a--z. In UTF8 they are scattered all over in no apparent
    arrangement.

    I suppose I could write a Go program that uses Go's ToUpper to built the
    kind of table that I described earlier and which I described as being
    tedious when done by hand --- it could generate assembly-language
    source-code for the table.

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Lucy at Dec 22, 2013 at 9:50 pm

    On Sunday, 22 December 2013 21:32:14 UTC+1, Hugh Aguilar wrote:

    On Sunday, December 22, 2013 1:09:43 PM UTC-7, Lucy wrote:

    You could use http://golang.org/pkg/strings/#ToUpper and/or
    http://golang.org/pkg/unicode/#ToUpper for converting strings/runes to
    upper case.
    Is the source-code available so I could port it over to my
    assembly-language program?

    I don't know what the definition of "uppercase" and "lowercase" is --- in
    ascii it was simple because the uppercase and lowercase alphabets were in
    blocks of A--Z and a--z. In UTF8 they are scattered all over in no apparent
    arrangement.

    I suppose I could write a Go program that uses Go's ToUpper to built the
    kind of table that I described earlier and which I described as being
    tedious when done by hand --- it could generate assembly-language
    source-code for the table.

    Yes, the source code is available. See
    http://code.google.com/p/go/source/browse/src/pkg/unicode or
    $GOROOT/src/pkg/unicode. The program that's used to create tables for Go's
    ToUpper and related is in there as well
    (http://code.google.com/p/go/source/browse/src/pkg/unicode/maketables.go).

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Hugh Aguilar at Dec 22, 2013 at 10:39 pm

    On Sunday, December 22, 2013 2:50:18 PM UTC-7, Lucy wrote:
    Yes, the source code is available. See
    http://code.google.com/p/go/source/browse/src/pkg/unicode or
    $GOROOT/src/pkg/unicode. The program that's used to create tables for Go's
    ToUpper and related is in there as well (
    http://code.google.com/p/go/source/browse/src/pkg/unicode/maketables.go).
    I'll look into all of that --- thanks for the links.

    Considering that I don't know any languages other than English and a little
    Spanish, I'm not a good candidate to become a UTF8 expert. I want to
    support it in my compiler though --- if I can get the basics running,
    people can go from there in supporting their favorite languages.

    I'm dubious about allowing source-code to contain foreign-language names
    for variables and functions etc.. I worked at a place where most of the
    programmers were Spanish-speaking and our program was for use in Latin
    America so it worked with Spanish text --- but we still required our
    source-code and comments to be in English (there are programmers such as
    myself who know English but not Spanish, but almost everybody who knows
    Spanish also knows English reasonably well). Do people ever write Go
    source-code using foreign-language? Or do they write the source-code in
    English and just use Go's LTF8 capability to allow their programs to work
    with foreign-language text at run-time?

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Egon at Dec 22, 2013 at 8:33 pm

    On Sunday, December 22, 2013 8:51:41 PM UTC+2, Hugh Aguilar wrote:
    This question isn't strictly related to Go, but perhaps you can help me.
    I'm writing a compiler for a Forth language of my own design which uses
    UTF8. Later on I will write the IDE in Go, but right now I'm writing my
    compiler in assembly-language. I really like assembly-language a lot better
    than high-level-language (HLL), but Go is the first HLL other than Forth
    that I have seen in decades that I think is worth learning, so I'm delving
    into it! :-)

    I'm trying to write a function that will convert lowercase text into
    uppercase. This is for case-insensitive string comparisons (the symbol
    table, for one thing). What I'm doing right now is just building a table of
    rune values with all of the lowercase letters converted into uppercase. I
    will use my rune as an index to pull out the upperized version. This is a
    pretty good technique for the first couple of 256-byte pages of runes. It
    is rather tedious to build the table though. Also, I don't know anything
    about any languages other than English and Spanish, so I'm really just
    guessing about how text is upperized in other languages.
    Most languages have gotten the upperize wrong, so guess how difficult it is
    :D. But yes some writing systems do not have uppercase (such as Arabic,
    Hebrew, Chinese, Hangul).

    Read http://mortoray.com/2013/11/27/the-string-type-is-broken/
    and http://blog.golang.org/normalization will get you started with some of
    the stuff and internals of Unicode.

    (Also don't ask me any extended questions; I only know it's non-trivial
    stuff... :)

    Has anybody ever written an upperize function that covers a slew of
    languages beyond English and Spanish? Hopefully this would be done by a
    team of linguists who actually know those languages. Can I download this
    and port it into my program? In the history of Unicode, somebody must have
    bumped into this problem already --- I can't be the first.
    There's https://code.google.com/p/go/source/browse/?repo=text that does
    some of the text related stuff.

    Does the concept of uppercase and lowercase even exist in all languages?
    I've heard of something called "title-case," but I don't know what that is.
    I want to provide case-insensitive string comparisons for some of the more
    common languages --- but I don't need to go overboard and support every
    language in the world plus Klingon --- unless I get some help from somebody
    who knows languages, I'll just support English and Spanish which I'm
    familiar with and which should cover pretty much all of my users.

    Another question: Is Go the only language that uses UTF8 as its
    fundamental kind of text? I know that a lot of languages have libraries of
    code available that support UTF8, but I find that to be a rather clunky
    approach --- I like Go's approach in which everything including source-code
    is UTF8, and this was the inspiration for me to do the same thing in my own
    language. :-)
    I believe not... I can remember Fortress, Red, and probably some lisps did
    it as well.

    Another question: I have a function $CRUNCH that crunches all of the
    overlong UTF8 codes in a string and produces a proper UTF8 string. I'm
    going to recommend that the user do this with any string data that comes
    from questionable sources. Are overlong codes much of a problem in the UTF8
    world? Is Modified-UTF8 the only dirty UTF8 data that I have to fix? Is
    Modified-UTF8 used very much? If all the editors and other UTF8 software in
    the world produce proper UTF8, then I could just ignore the problem of
    fixing overlong codes (abort with an error message if I run into them, just
    like I already do with undecodable UTF8) --- I would prefer not to slow
    down my own program fixing dirty data produced by other people's programs.
    I think Go already has that protection built-in some places, not sure where
    exactly though. Also it is a best practice to protect against such things.

    Another question: Is the BOM used very much in UTF8 data? That is
    something else that I would prefer to just ignore.
    I don't think it's used that much.

    + egon

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Lucio at Dec 23, 2013 at 4:04 am

    Most languages have gotten the upperize wrong, so guess how difficult it is :D.
    But yes some writing systems do not have uppercase (such as Arabic, Hebrew,
    Chinese, Hangul).
    Putting both upper and lower case in the character set was one of those
    historical mistakes that will be regretted for a very long time. Upper
    case is actually the lower case letter in a different font and should be
    treated as such. It's a bit late, but perhaps the next generation of text
    representations will treat case shifts and accents in the same way, as a
    prefix (or suffix?) to shift to a different font. This will open the door
    to novel representations and may well lead to new typographical facilities.

    Lucio.

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Hugh Aguilar at Dec 24, 2013 at 4:10 am

    On Sunday, December 22, 2013 9:04:42 PM UTC-7, Lucio wrote:
    Most languages have gotten the upperize wrong, so guess how difficult it is :D.
    But yes some writing systems do not have uppercase (such as Arabic, Hebrew,
    Chinese, Hangul).
    Putting both upper and lower case in the character set was one of those
    historical mistakes that will be regretted for a very long time. Upper
    case is actually the lower case letter in a different font and should be
    treated as such. It's a bit late, but perhaps the next generation of text
    representations will treat case shifts and accents in the same way, as a
    prefix (or suffix?) to shift to a different font. This will open the door
    to novel representations and may well lead to new typographical facilities.

    Lucio.
    I had never given the subject any thought prior to this. What you are
    saying makes a lot of sense though --- that uppercase is just lowercase in
    a different font.

    Is it true that Unicode doesn't define the fonts for any of its characters?
    The software that generates the display or the printer file just does
    whatever it wants? It would be better if text contained font information.

    BTW: I have used LaTeX a lot for writing technical documents. I also
    recently learned a little bit of PostScript and wrote a program (in Forth)
    that generated images of slide-rule faces in both PostScript and CNC gcode.
    Have Go programmers been doing anything like this?

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Jeremy Jackins at Dec 24, 2013 at 4:22 pm

    On Tue, Dec 24, 2013 at 3:29 AM, Lucio wrote:
    I'm not sure I can answer you: your Euro-centric assumptions are too
    fundamental to your argument, without being provably unique or
    correct.

    How would you phrase your counter-argument(s) if you were using
    hieroglyphics or Korean?
    I don't know Korean, but here it is in Japanese. Shall カ and か be treated
    as the same character? Both represent the sound "ka". But both can convey
    different meanings, just like lower and upper case. They are also treated
    as two different characters, just as 'a' and 'A' should be.

    PS, whoops, I meant to reply to the golang-nuts thread, not just to you.
    Adding the group back in.
    On 12/23/13, Jeremy wrote:
    On Sunday, December 22, 2013 9:04:42 PM UTC-7, Lucio wrote:

    Upper case is actually the lower case letter in a different font and
    should be treated as such.
    What? How do you propose we represent uppercase in code? Shall compilers
    divine what font you typed a character in? How will you search text for
    the
    word raid vs the acronym RAID? Please back up your assertion.
    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Jsor at Dec 24, 2013 at 10:06 pm
    I did do a test once with Go, and I appreciate its ability to accept
    unicode, but in non-cased languages the export/hidden field thing makes its
    ability to be written in arbitrary unicode academic. I can't remember
    exactly which it is, but I found that Japanese (and thus, I presume,
    Chinese, Korean, and other non-cased languages) is always interpreted as
    either upper or lower case, and thus you can't choose exports. I want to
    say they were interpreted as lower case which means it's basically
    impossible to write a package in it because nothing can be exported. But I
    could be wrong.

    Of course, many languages don't even accept arbitrary unicode in their
    compilers, so it's kind of academic. I was sort of bummed that I couldn't
    write a program almost entirely in Japanese, though (not that I have any
    reason to do so, it would mostly be for fun in my case).
    On Tuesday, December 24, 2013 9:21:58 AM UTC-7, Jeremy Jackins wrote:
    On Tue, Dec 24, 2013 at 3:29 AM, Lucio wrote:
    I'm not sure I can answer you: your Euro-centric assumptions are too
    fundamental to your argument, without being provably unique or
    correct.

    How would you phrase your counter-argument(s) if you were using
    hieroglyphics or Korean?
    I don't know Korean, but here it is in Japanese. Shall カ and か be treated
    as the same character? Both represent the sound "ka". But both can convey
    different meanings, just like lower and upper case. They are also treated
    as two different characters, just as 'a' and 'A' should be.

    PS, whoops, I meant to reply to the golang-nuts thread, not just to you.
    Adding the group back in.
    On 12/23/13, Jeremy wrote:
    On Sunday, December 22, 2013 9:04:42 PM UTC-7, Lucio wrote:

    Upper case is actually the lower case letter in a different font and
    should be treated as such.
    What? How do you propose we represent uppercase in code? Shall compilers
    divine what font you typed a character in? How will you search text for
    the
    word raid vs the acronym RAID? Please back up your assertion.
    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Rob Pike at Dec 25, 2013 at 2:12 am
    Issue 5763.

    -rob

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Lucio at Dec 25, 2013 at 5:01 am

    On Tuesday, 24 December 2013 18:21:58 UTC+2, Jeremy Jackins wrote:

    [...]
    I don't know Korean, but here it is in Japanese. Shall カ and か be treated
    as the same character? Both represent the sound "ka". But both can convey
    different meanings, just like lower and upper case. They are also treated
    as two different characters, just as 'a' and 'A' should be.

    That's a fundamental difference between my view and yours: (a) upper case
    should not be used to convey a different meaning and (b) different ideogram
    are different ideograms, who decides when they are "equal"?

    That said, I dream of a phonetic alphabet being universally accepted, but
    it's not practical because of the localisation of pronunciations. Had it
    been my choice, I would have kept the alphabet for instructing computers
    totally distinct (think APL) from that for communicating between humans.
      But that is an elitist view that may get in the way of instructing
    computers in a natural language.

    Lucio.

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Thomas Bushnell, BSG at Jan 2, 2014 at 3:39 pm

    On Tue, Dec 24, 2013 at 9:01 PM, Lucio wrote:
    On Tuesday, 24 December 2013 18:21:58 UTC+2, Jeremy Jackins wrote:

    [...]
    I don't know Korean, but here it is in Japanese. Shall カ and か be treated
    as the same character? Both represent the sound "ka". But both can convey
    different meanings, just like lower and upper case. They are also treated
    as two different characters, just as 'a' and 'A' should be.

    That's a fundamental difference between my view and yours: (a) upper case
    should not be used to convey a different meaning and (b) different ideogram
    are different ideograms, who decides when they are "equal"?
    Here's the deal: while you may believe (a), the writing systems we're
    talking about are not hypothetical entities that you get to redesign
    because you've got a better way. So, in fact, upper case *is *used to
    convey a different meaning in many contexts, and that's the world as it is.

    Thomas

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Thomas Bushnell, BSG at Jan 2, 2014 at 3:38 pm

    On Sun, Dec 22, 2013 at 8:04 PM, Lucio wrote:

    Most languages have gotten the upperize wrong, so guess how difficult it is :D.
    But yes some writing systems do not have uppercase (such as Arabic, Hebrew,
    Chinese, Hangul).
    Putting both upper and lower case in the character set was one of those
    historical mistakes that will be regretted for a very long time. Upper
    case is actually the lower case letter in a different font and should be
    treated as such. It's a bit late, but perhaps the next generation of text
    representations will treat case shifts and accents in the same way, as a
    prefix (or suffix?) to shift to a different font. This will open the door
    to novel representations and may well lead to new typographical facilities.
    The world of writing systems is always more complex than programmers
    imagine. Unicode comes from actually trying to address the complexities,
    rather than think that programmers have it within their power to change
    them.

    While the *origin *of upper and lower case is certainly from different
    writing styles (not fonts; it predates the invention of metal type by many
    centuries), they are now in the category of spelling rules in languages
    such as English, and even affect correct pronunciation. Here's a sample
    minimal pair:

    "Do you know anything about polish?"
    "Do you know anything about Polish?"

    Thomas

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Dan Kortschak at Jan 2, 2014 at 9:35 pm
    Very nice.
    On 03/01/2014, at 2:08 AM, "Thomas Bushnell, BSG" wrote:

    "Do you know anything about polish?"
    "Do you know anything about Polish?"
    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Lucio De Re at Jan 3, 2014 at 4:21 am
    Clever and useful, thank you Thomas for the pointer.

    Pure opinion and speculation below. Read at your own peril, this
    conversation should probably no longer be public. The subject
    definitely intrigues me.

    I'm not sure what we're discussing an longer, but I've yet to see an
    argument against treating upper case as a font change rather than a
    code point (I hope I'm using the right terminology) change.

    Again, I believe that the latter introduces a semantic value where
    there is no need for one. That the Go developers have picked on an
    existing convention and exploited it, is not relevant here, whereas I
    think it matters that the Unicode inventors could have chosen a
    different path.

    Personally, I think we need to distinguish between regional and global
    needs for accurate and successful communication and allowing the
    complexity of such communication to increase without restriction is
    already reflected to the mythical Babel story, which ought to serve as
    a cautionary tale.

    Unfortunately, a lot of computing effort seems to be expended
    specifically in pampering to regional, even sectarian desires and the
    target market is lapping it all up.

    Lucio.
    On 1/2/14, Dan Kortschak wrote:
    Very nice.
    On 03/01/2014, at 2:08 AM, "Thomas Bushnell, BSG" wrote:

    "Do you know anything about polish?"
    "Do you know anything about Polish?"
    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Thomas Bushnell, BSG at Jan 3, 2014 at 4:30 am

    On Thu, Jan 2, 2014 at 8:21 PM, Lucio De Re wrote:
    I'm not sure what we're discussing an longer, but I've yet to see an
    argument against treating upper case as a font change rather than a
    code point (I hope I'm using the right terminology) change.

    Again, I believe that the latter introduces a semantic value where
    there is no need for one.

    My point is that it _already_ is a semantic issue. The language and the
    writing systems are designed. It's done. Just as Go 1 is done, with no more
    design work to be done, you and I get essentially no votes whatsoever on
    what the writing system of English should look like. It uses capital
    letters, with semantic meaning, and that's really just the way it is,
    whether it seems sensible and elegant or not.

    Font changes do not change the pronunciation of words (except in the sense
    that they can indicate the *marking *of speech, which is quite a different
    thing); capitalization is sufficient to change one word into a completely
    different word, just as much as a different spelling.

    Another excellent reason, by the way, is that "font" is a word which
    already has a meaning, and it refers to a set of type at a particular
    size *including
    *capitals and lower case, and *not *including both Roman and Italics, for
    example. Typographers may know more about this than most computer
    programmers.

    Thomas

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Andy Balholm at Jan 3, 2014 at 4:04 pm

    On Thursday, January 2, 2014 8:21:09 PM UTC-8, Lucio wrote:
    the Unicode inventors could have chosen a
    different path.
    Ideally, a "character" would be represented by some sort of
    multidimensional matrix of features. Case would be one of those features.
    So would the attribute that distinguishes the Roman numeral I from the
    letter I. And the attribute that distinguishes the ohm symbol from the
    Greek omega. etc.

    Unicode chose the simpler course of using an integer for each character.
    This is not as good in theory, but it is much more practical. So it wins
    out under the "worse is better" principle.

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-nuts @
categoriesgo
postedDec 22, '13 at 6:51p
activeJan 3, '14 at 4:04p
posts18
users10
websitegolang.org

People

Translate

site design / logo © 2021 Grokbase