Re(3): [colorforth] abort

["Arthur W. Green" <goshawk@xxxxxxxxx>]

Hi, thanks for your response!

>Sorry, I wasn't clear. It doesn't matter what names or what logic structures
>one uses to handle error laden data. The point is that there are two entirely
>different development contexts:
>
Your explanation was fine. The problem was in my response. My
understanding in your original post was that you felt that in an "open"
development context, you feel colorForth needs something leaning towards
Standard-style error handling. Did I miss something?


What I was at least trying to imply in my previous response was that I
felt that the distinction between "native" and "foreign" data (and
"closed" and "open" systems) seems arbitrary and may not be particularly
useful. Whether data is "native" or "foreign" generally shouldn't matter. 

Using your example of an HTML processor, nothing "important" depends on
the correctness of HTML code. ColorForth obviously doesn't have any idea
how badly written it might be. This means that in a happily (and sanely)
executing application, if you don't think there is an error, then
colorForth obviously shouldn't flag you about it. A rare case of "out of
mind, out of sight". =)

Since colorForth doesn't care, you have the full freedom to allow for a
very large threshold for "acceptable" error when we accept and render
HTML code, which is defined pretty much arbitrarily by the application.
We can still pretend nothing ever went wrong, because basically, nothing
did. We just do the best we can. The worst-case scenario is that a
document won't end up rendering particularly well or might be totally
unreadable.

I guess I just fail to grasp the usefulness of Standard-style error
handling for what amounts to (in most applications) maybe a wad of
trivial and non-critical errors with basically not much that anyone can
do about them. Am I wrong in still feeling that just about none of it is
needed?


>Read Jeff Fox's comments on the application development for iTV and then read
>Chuck's comments about develpping colorForth and OKAD. Radically different
>contexts.
>
I agree that they are different contexts, but I don't feel it has much to
do with the distinction between open and closed systems. I think the user
demographics targeted by iTV and colorForth/OKAD, respectively, play a
considerably bigger role in defining the context of development.


>I have been lusting after developing a communication based 'closed box'
system
>for some time now. The perfect example of what I am talking about can be
found
>at:
[..]
>
Neat. I'll be sure to take a quick look at that.

>The differences are worth soaking up a few beers over, discussing the merits
>of the various implementations, but are actually moot until such time as
>someone in the community produces a TCP/IP stack.
>
I'm with you on that!

>Regards,
>Terry Loveall
>
Thanks!

-- Art



---------------------------------------------------------------------
To unsubscribe, e-mail: colorforth-unsubscribe@xxxxxxxxxxxxxxxxxx
For additional commands, e-mail: colorforth-help@xxxxxxxxxxxxxxxxxx
Main web page - http://www.colorforth.com