Re: Q: type ... is new String

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On Mon, 04 Jun 2012 18:06:36 +0200, Georg Bauhaus wrote:

> On 04.06.12 17:14, Dmitry A. Kazakov wrote:
> 
>> malformed /= untyped.
>> 
>> Typing is about a way to describe behavior.
> 
> Well, yes, though in the web word, "type" may de facto mean "element type"
> at best. The problem with strings is not that one could speak
> about operations PUT, GET, DELETE, HEAD, and so on, and consider
> these the behavior of something. The problem is data that cannot
> reliably parsed and mapped to a set of properly typed objects. But
> we still must have that information!

You are mangling OSI layers. String in this case is merely a transport, or
a container. Operations defined on the container type are not the
operations of the things it may contain, nor the operations of the things
the contained things may describe. The string may contain an Ada program
and operations on the Ada source object could be something like ASIS, but
that should have no effect on the implementation of String.

> Everything in practice is implicit, ambiguous, indeterminable,
> inconsistent.

Wrong. In practice there are abstraction layers each of which is
well-defined, except for the last one presented to the reader. There is
nothing ambiguous in character encoding, network frames, states of gates.
For a CPU, network adapter, graphic card etc to work, there is no need to
know anything about the incomputable semantics of the web page rendered
before the user. Similarly the parser of the page content containing "to be
or not to be?" need not to answer such questions. For each possible input
there is a defined output the parser should spill. Where is a problem?

> This may be a consequence of the attitude in the web,
> which does not normally use "type" at all. Not at the level of
> system integration, where it matters. The AI job, then, is to look
> at the forms and try to make sense, even when things are malformed.
> REJECT is not an option.

Yes, this is a consequence of a misconception. Note that *exactly* same
misconception is behind dynamic preconditions of Eiffel now unfortunately
introduced in Ada 2012. There is NO reject. There cannot be any reject. You
have to handle every possible input state. You have no option to put a
precondition on anybody except for very rare cases of which you can safely
forget. That does not work in REAL world. Have courage to face it!

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de