Re: Is this expected behavior or not

[Georg Bauhaus <rm.dash-bauhaus@futureapps.de>]

On 18.04.13 13:52, Dmitry A. Kazakov wrote:
> On Wed, 17 Apr 2013 21:38:28 +0200, Georg Bauhaus wrote:
>
>> On 17.04.13 11:57, Dmitry A. Kazakov wrote:
>>
>>>> If the Ada type system cannot express
>>>> time and space, I'll still consider them
>>>> functional requirements.
>>>
>>> And this should justify conflation of a representation with the type
>>> semantics... surely.
>>
>> Representation is functional,
>
> You should feel obliged to write an AI to disband ARM 7.3.

Semantics is not restricted to private types. Neither is any of the
perspectives on semantics demonstrably more important, so much more
important that other perspective do not matter to programmers
(or language designers, I'd think).

>> Nothing is conflated here because semantics is assignment of meaning,
>
> http://en.wikipedia.org/wiki/Semantics

Yes, you might want to read it once more:

  "Semantics (from Ancient Greek: σημαντικός sēmantikós) is the study of
    meaning. It focuses on the relation between signifiers, like words,
    phrases, signs, and symbols, and what they stand for, their denotation."

Thus, a functional requirement can be expressed as

   for A'Component_Size use 24;  -- needed for CRM 114

and that which this declaration stands for is a consequence of Ada.
It is much less a consequence of what a delighted mind might otherwise
read into it, however spirited that other meaning may be.
Semantics is not restricted to private types. Some things are
language defined.

>> String is a good example. String is an array, and nothing else.
>
> Wrong. String has an array interface.

No, right. String has the "interface" of array. Period.
Some intellectual type that some people may want to call
"string" has some other properties. I may want to call
this type Egg. Clearly, it is not a string then, right?
Conversely, not everything that is called "string" is well
defined because it someone calls it "string".

> Operations like Find can be considered a third array interface.

Confusion starts precisely from considering the mix of language
defined semantics and used defined types.

Go ahead. Tell us how a compiler will check the consistency
of used defined array types with built-in arrays in all required
places in Ada programs; then, suggesting a different array
facility for Ada might be more convincing.

> In many
> languages strings can be indexed by strings.

Show me one, I'm curios. Hashing is not indexing by strings, because
hashing means computing a non-string that is to be used as the index
value. The same is true for computing a position number for a find.
  
>> The existence of RM A.4.({4,5}) is of no consequence. To hell with it.
>
> In that case show us a way to create unbounded arrays with representation
> guts inside out.

Ada does not have unbounded arrays and is not going to have them,
I dare say. Instead, I suggest that you focus on creating/stealing types
useful for text processing, and make them very different---unless you
can finally produce a user-definable array facility 100% compatible
with the known Ada array facility. Their only relation to current String
(the current array) should be subprograms for conversion. How about
that?


> Your concept simply does not hold. There are simple indisputable facts:
>
> 1. The representation of string object is irrelevant to what string is.

Again, an occurrence of, and stipulation of truth in, the auxiliary
verb "is", without offering the necessary definitions of (a) its meaning,
(b) a proof of concept.

> 2. It is impossible to have one implementation suitable for all string
> objects and all application domains that use strings, e.g. DNA sequencing,
> pattern matching, text processing, compiler construction etc.

Yes, the impossible string. And equally unlikely, there will be
"whatever-way-generic" types that have substitutable sets of operations
suitable for all "string processing". (Should the Find operation be
required to be stateful so that it can be used in a lazy iteration
scheme? Why? Why not?)

>> The existence of RM 3.6 is essential, because of array semantics.
>
> Array semantics? What's that?

When I declare an array type, RM 3.6 instructs about the meaning.

> You claimed that semantics is representation.

Again, a nice occurrence of a rhetorical classic. I said, instead:

  "Representation ... is meaningful, therefore it is semantically important."
  "semantics is assignment of meaning,"

http://en.wikipedia.org/wiki/Semantics