Is this UTF-8 regular expression semantically correct?
in [MFC]
|
Prev: Love Potion for Miss Blandish
Next: Newcomer's CAsyncSocket example: trouble connecting with other clients
From: Peter Olcott on 19 May 2010 10:26 On 5/19/2010 12:57 AM, Mihai N. wrote: >> (2) Makes my success too dependent upon Microsoft. > > That's a good reason, indeed. > You stuff is so great, that Microsoft might actually drag you down :-) > > How well does ActiveX run on Linux or Apple? There are other reasons why I considered and rejected this otherwise excellent idea. In fact I will still be offering my OCR4Sreen technology as an ActiveX component at some point.
From: Peter Olcott on 19 May 2010 11:01 On 5/19/2010 1:32 AM, Joseph M. Newcomer wrote: > See below... > On Tue, 18 May 2010 20:48:26 -0500, Peter Olcott<NoSpam(a)OCR4Screen.com> wrote: > >> >> A church that I used to go to had an expression, "What would Jesus do?" >> as their measure of correct behavior. In my case I have an analogous >> measure, "What would C++ do?" >> >> Would C++ permit digits other than ASCII [0-9] ??? > *** > How about > > "Would a person who makes a claim that his language allows programmers to program in their > native language create a compiler in which their native digits are considered letters be > lying in his teeth about his claim?" > **** The claim was merely imprecisely (thus incorrectly) stated. What I meant by this was that Identifiers can be written in the native language, and C++ language constraints must be otherwise maintained. Will C++ allow anything other than an ASCII comma between parameters? What are the limits on exactly how much C++ is Unicode aware? I already know that std::wstring it totally clueless. I assumed based on this that all of C++ was generally clueless about Unicode. >> >>>> >>>> From what I understand what I am proposing is much better than C/C++ >>>> provides. From what I understand C/C++ only accepts ASCII. This >>>> restriction mandates substantially poorer code quality (in terms of self >>>> documenting code) for much of the rest of the world. >>> **** >>> C/C++ actually states that the character set for identifiers is implementation-specific >> >> So C++ can handle UTF-8? > **** > No, the language document does NOT specify UTF-8; it says it is implementation-specific. > You seem to confuse a couple implementations that have deliberately limited themselves to > the ASCII-7 subset to be definitive of the language. No. UTF-8 does not care about Endianess, thus it is the most logical choice for this reason. > Then you say you are going to create > a compiler which allows localized identifiers, then you say that by "localized identifier" > you mean "Whatever combination of special characters you feel like". I guess I don't see > how you can claim you have extended the acceptable set of input tokens and then said "any > glyph which is not an ASCII-7 character is necessarily a letter". Either you have a made > a horrible design blunder, or you are falsely representing that you can support localized > languages. UTF-8 is a trivial implementation detail by comparison. You seem to have > confused the concept of representation of symbols (UTF-8) with semantics of symbols > (localized digits and punctuation marks). Please explain the details of exactly what difference this makes to any lexical analyzer when this lexical analyzer is recognizing identifiers. > > This sounds like another "My design decisions must be correct because they are the > decisions I made and therefore they cannot be in error" discussion. If anyone tries to > point out exactly how your design decisions are wrong, you insist that they are, by > definition, correct, because you have made them that way and you are always correct. This > is not productive. You don't even understand the difference between abstractions (lexical > tokens and parser noterminals) and their implementation (UTF-8 input text vs. Unicode > input text vs, ASCII-7 text). > joe > > Joseph M. Newcomer [MVP] > email: newcomer(a)flounder.com > Web: http://www.flounder.com > MVP Tips: http://www.flounder.com/mvp_tips.htm
From: Joseph M. Newcomer on 19 May 2010 11:34 ActiveX was designed to be portable, even at the binary level on the same machine architecture. Since a Mac is just a Unix variant (actually, the Mach operating system, developed at CMU by the person who is now the head of Microsoft Research), anything that runs on Unix will run on a Mac. In principle, if you compile an ActiveX control with a 68000 compiler, the interface should work on a 68000-based Mac. The interface does not care what machine code should be running. But there are no other good component models for the Mac or Unix. joe On Wed, 19 May 2010 09:26:35 -0500, Peter Olcott <NoSpam(a)OCR4Screen.com> wrote: >On 5/19/2010 12:57 AM, Mihai N. wrote: >>> (2) Makes my success too dependent upon Microsoft. >> >> That's a good reason, indeed. >> You stuff is so great, that Microsoft might actually drag you down :-) >> >> >How well does ActiveX run on Linux or Apple? > >There are other reasons why I considered and rejected this otherwise >excellent idea. In fact I will still be offering my OCR4Sreen technology >as an ActiveX component at some point. Joseph M. Newcomer [MVP] email: newcomer(a)flounder.com Web: http://www.flounder.com MVP Tips: http://www.flounder.com/mvp_tips.htm
From: Joseph M. Newcomer on 19 May 2010 15:31 See below... On Wed, 19 May 2010 10:01:36 -0500, Peter Olcott <NoSpam(a)OCR4Screen.com> wrote: >On 5/19/2010 1:32 AM, Joseph M. Newcomer wrote: >> See below... >> On Tue, 18 May 2010 20:48:26 -0500, Peter Olcott<NoSpam(a)OCR4Screen.com> wrote: >> >>> >>> A church that I used to go to had an expression, "What would Jesus do?" >>> as their measure of correct behavior. In my case I have an analogous >>> measure, "What would C++ do?" >>> >>> Would C++ permit digits other than ASCII [0-9] ??? >> *** >> How about >> >> "Would a person who makes a claim that his language allows programmers to program in their >> native language create a compiler in which their native digits are considered letters be >> lying in his teeth about his claim?" >> **** > >The claim was merely imprecisely (thus incorrectly) stated. What I meant >by this was that Identifiers can be written in the native language, and >C++ language constraints must be otherwise maintained. **** This is a typical pattern: Peter: "X is true" World: "X is false" Peter: "I meant to say, X is true under the following conditions" World: "X is false in two of those three conditions" Peter: "No, I REALLY meant that X is true only under conditions when it is true, and I'm going to ignore all the conditions where it is false, and define them out of existence by stating they were not part of my design" > >Will C++ allow anything other than an ASCII comma between parameters? >What are the limits on exactly how much C++ is Unicode aware? I already >know that std::wstring it totally clueless. I assumed based on this that >all of C++ was generally clueless about Unicode. **** But you said you were EXTENDING the language to be a C-like language that supported localization! Did you mean something different? (See Magic Morphing Requirements) So why claim you are making an extension, and every time we point out a failure, say "I didn't MEAN I was extending C, I meant something else" and say "the reason I don't support this in my extension is that the old C language designed in the era of punched cards didn't support it, even though I said I was extending the language, I meant something else" What DO you mean? joe **** > >>> >>>>> >>>>> From what I understand what I am proposing is much better than C/C++ >>>>> provides. From what I understand C/C++ only accepts ASCII. This >>>>> restriction mandates substantially poorer code quality (in terms of self >>>>> documenting code) for much of the rest of the world. >>>> **** >>>> C/C++ actually states that the character set for identifiers is implementation-specific >>> >>> So C++ can handle UTF-8? >> **** >> No, the language document does NOT specify UTF-8; it says it is implementation-specific. >> You seem to confuse a couple implementations that have deliberately limited themselves to >> the ASCII-7 subset to be definitive of the language. > >No. UTF-8 does not care about Endianess, thus it is the most logical >choice for this reason. > >> Then you say you are going to create >> a compiler which allows localized identifiers, then you say that by "localized identifier" >> you mean "Whatever combination of special characters you feel like". I guess I don't see >> how you can claim you have extended the acceptable set of input tokens and then said "any >> glyph which is not an ASCII-7 character is necessarily a letter". Either you have a made >> a horrible design blunder, or you are falsely representing that you can support localized >> languages. UTF-8 is a trivial implementation detail by comparison. You seem to have >> confused the concept of representation of symbols (UTF-8) with semantics of symbols >> (localized digits and punctuation marks). > >Please explain the details of exactly what difference this makes to any >lexical analyzer when this lexical analyzer is recognizing identifiers. > >> >> This sounds like another "My design decisions must be correct because they are the >> decisions I made and therefore they cannot be in error" discussion. If anyone tries to >> point out exactly how your design decisions are wrong, you insist that they are, by >> definition, correct, because you have made them that way and you are always correct. This >> is not productive. You don't even understand the difference between abstractions (lexical >> tokens and parser noterminals) and their implementation (UTF-8 input text vs. Unicode >> input text vs, ASCII-7 text). >> joe >> >> Joseph M. Newcomer [MVP] >> email: newcomer(a)flounder.com >> Web: http://www.flounder.com >> MVP Tips: http://www.flounder.com/mvp_tips.htm Joseph M. Newcomer [MVP] email: newcomer(a)flounder.com Web: http://www.flounder.com MVP Tips: http://www.flounder.com/mvp_tips.htm
From: Peter Olcott on 19 May 2010 15:54
On 5/19/2010 2:31 PM, Joseph M. Newcomer wrote: > See below... > On Wed, 19 May 2010 10:01:36 -0500, Peter Olcott<NoSpam(a)OCR4Screen.com> wrote: > >> On 5/19/2010 1:32 AM, Joseph M. Newcomer wrote: >>> See below... >>> On Tue, 18 May 2010 20:48:26 -0500, Peter Olcott<NoSpam(a)OCR4Screen.com> wrote: >>> >>>> >>>> A church that I used to go to had an expression, "What would Jesus do?" >>>> as their measure of correct behavior. In my case I have an analogous >>>> measure, "What would C++ do?" >>>> >>>> Would C++ permit digits other than ASCII [0-9] ??? >>> *** >>> How about >>> >>> "Would a person who makes a claim that his language allows programmers to program in their >>> native language create a compiler in which their native digits are considered letters be >>> lying in his teeth about his claim?" >>> **** >> >> The claim was merely imprecisely (thus incorrectly) stated. What I meant >> by this was that Identifiers can be written in the native language, and >> C++ language constraints must be otherwise maintained. > **** > This is a typical pattern: > > Peter: "X is true" > World: "X is false" > Peter: "I meant to say, X is true under the following conditions" > World: "X is false in two of those three conditions" > Peter: "No, I REALLY meant that X is true only under conditions when it is true, > and I'm going to ignore all the conditions where it is false, and > define them out of existence by stating they were not part of > my design" >> >> Will C++ allow anything other than an ASCII comma between parameters? >> What are the limits on exactly how much C++ is Unicode aware? I already >> know that std::wstring it totally clueless. I assumed based on this that >> all of C++ was generally clueless about Unicode. > **** > But you said you were EXTENDING the language to be a C-like language that supported > localization! Did you mean something different? (See Magic Morphing Requirements) I was not aware of any other issues pertaining to the localization of a language based on C++ than providing a way to write identifiers in the native language. I had thought that C++ required all users to use ASCII numeric digits. To exactly what extent does the current C++ provide for localization? Does the current C++ allow you to use anything other than an ASCII comma to separate parameters? |