Interesting post and the information is reflected at an abstract high level. If you don't mind me asking, why only use the example of ASCII? You seem to incorporate serial data communications and that works on a different layer than ASCII characters. The truncated bit from your proposed octet (octets work better in bit parsing/manipulation) could enhance error correction I suppose but we're also talking about a standard where all values in the 7-bit field would represent a valid ASCII character. You would have to go "outside the box" a lot more for validation because a processor does not care that a word is miss spelled in a message or on a web page.

TCP is already error correcting for data transmissions on networks and requests re-transmissions as well as complete "hand shakes" between to hosts no matter their locations on a network. I was hoping that this post would give some insight on your solution to the grammatic problem as opposed to ill received bits that are automatically corrected or re-transmitted from the originating transmitting host. Do you propose a standard core-dictionary as part of all operating system releases? Do you include slang and conversely, common miss spelled words in their erroneous constructs? You would also have to incorporate excellent grammatic rules/structures to validate against and even then good grammar can be subjective. A human decision still has to be involved which hinders correction; detection would be the easier component to the puzzle.

The introduction of captcha has helped web spamming quite a bit though, it's an excellent technology. It's too "fuzzy" for most malicious code. It could be the key reason for the spike in image processing research in the CS field, or maybe those research efforts are highlighted because of our awareness of captcha. Who knows. I'll be reading the rest of your blog series because I'm a senior CS student that has high interest in programming langagues and lexical analysis. Thanks for the food for thought.

Jeff

Mr. Adam: that is somewhat my point. I don't believe that error handling should be done at an ASCII level, that is very undesirable. I'm trying to gauge what problem and what solution the author is proposing because it wasn't clear (to me anyways). If this is to be included in a blog series for language then bit correction isn't necessary. There is a lot more beyond that level to consider if grammatical correction is needed. Is it supposed to be an overall solution to a big problem that computers aren't versed in? Does the scope include web, electronic documents, telecommunications, etc.? I only proposed a very basic solution to see how the author responds and either discredit my train of thought and construct a new view or build on top of it as necessary.

Integrity should remain in tact for data transmission and not involve grammar rules or business rules. There are protocols in place that manage intricacies of traveling bits and may not need to be included in this idea. However, transfer mechanisms are used in networking. Otherwise there would be no way to know that a problem occurred in a session. Errors are corrected at the originating host when a retransmit is needed in a TCP connection; hand-shakes, connection states, and associated transfer confirmations keeps it all in check very nicely.

Thatz Y U can reed this evn wiv orl of teh miss takes

Patrick;  it's interesting when you really analyze this sentence and see what's happening regarding the error detection and correction.

Thatz doesn't produce a problem because reading it and pronouncing it uses the overlapping sound of the letter 'z' with the 's', they are redundant in this usage.

Y and U are equally redundant since the name of these letters is a word.
NOTE:  What is interesting is that these two letters next to each other make me constantly want to use the word 'YOU' and I have to strictly correct myself to not modify the sentence to read "That's so you can read ...."

can and this are spelled correctly and reed is phonetically identical, so the meaning is also redundant.

evn is more interesting because it is a problem we encounter whenever we have adjacent consonants.  It appears that our pronunciation of the latters themselves introduces a vowel.  For example, 'n' is really 'en' and letters like 'k' are really 'ka' when we attempt to represent the sound they make.

wiv (to me) translated to wif which sounded like a mispronunciation of "with" so it's almost like you could follow the error correction path with this one.

orl  - this one only makes sense when you vocalize it within the context of the sentence and see that what should be there is 'all'.

teh - visually this jumps out as a transposition error and is corrected visually rather than phonetically.

miss and takes - Visually this is meaningless, but when it is spoken out loud, the relationship to the next sound becomes clear and we understand that it is only half of a total word.

In any case, it's an interesting exercise to see which error handling mechanism seems to dominate in something like this.

Jeff:  Not to sound too cynical, but I'd be happy if they bring most humans closer to human thought. :))

Gerhard: your analysis of my deliberate errors example is spot on!  I should comment that 'wiv' is a common British, mainly London, pronunciation of 'with'.  People who turn word-final th into V commonly turn word-initial th into F, so thick becomes 'fick', for example.

When presented with an example of errors we can focus on the error-correction measures that are available.  What is not commonly realised is that we error-correct every time we use language, but we are not usually conscious of it.  More accurately, if ther are no errors, then the error-handling codes are used as validation codes and then discarded, never triggering any conscious awareness that they were ever a part of the conversation stream.

I believe that one day there will be a computer revolution in the
(hopefully near) future that brings computation closer to human thought.

Jeff:  hold that thought!  Before computers can reliably read documents out loud they must be able to handle human language according to the rules of semantics and pragmatics.  Natural Language Programming, NLP is also a goal that cannot be reached by syntax alone.

Please keep those comments coming - let's learn from each other, that's what language is for.