Re: Why use C++?

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

On Fri, 12 Aug 2011 08:26:26 -0500, Jed wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
> news:1vn800hbyx8k4$.1lsveclj56197$.dlg@40tude.net...

>> I think you get me wrong. It is rather about an ability to state the
>> contracts than about flexibility. If any type is needed in your design, you
>> should be able to describe the behavior of that type [by the language
>> means!] in a way the program reader would understand without looking into
>> the implementation or compiler/machine documentation.
> 
> In another post in this thread, I wondered if you just want a higher 
> level of abstraction, and then noted that I consider that at a higher 
> level than "close to the machine" like C and C++ are. So, is that what 
> you want?

I want the type semantics specified. C/C++ int is neither lower level nor
closer to the machine it is just ill-defined. The concern is this, not its
relation to the machine, of which I (as a programmer) just do not care.

>>>> That depends. In Ada integer types are constructed from ranges.
>>>
>>> Oh, I thought ranges in Ada were "subtype ranges", hence being based 
>>> upon
>>> the built-ins.
>>
>> Both:
>>
>>   type Tiny is range -100..100;  -- A new type
>>   subtype Nano is Tiny range 0..2; -- A subtype
> 
> What underlies those "new" types though?

That is up to the compiler. 

> Aren't they just "syntactic" sugar over some well-defined primitives?

What are "well-defined primitives"?

> Wouldn't they have to be? I.e., 
> at some point, the hardware has to be interfaced.

Yes. Consider a that the target is a pile of empty bier cans maintained by
a robot. I presume that somehow the position of the cans or maybe their
colors in that pile must reflect values of the type. Why should I (as a
programmer) worry about that?
 
>>>>  In order to
>>>> specify the range you need literals. The type of a literal
>>>> (Universal_Integer) is not the type of the result. So technically the
>>>> type is not built on Universal_Integer.
>>>
>>> But the "subrange" is meant as "subrange of some existing type", yes? 
>>> If so, what existing type?
>>
>> Mathematically there is no need to have a supertype containing the 
>> ranged one.
> 
> I'm only concerned about pragmatics (implementation).

It is simple to implement such a type based on an integer machine type when
values of the language type correspond to the values of the machine type
(injection). It is less simple but quite doable to implement this type on a
array of machine values. The algorithms are well known and well studied. I
see no problem with that.

>> (The way compiler would implement that type is uninteresting,
> 
> Ha! To me that is KEY.

This is not a language design question. It is a matter of compiler design
targeting given machine.

>>>> The language shall distinguish the interface, the contract the
>>>> type fulfills, and the implementation of that type. "raw" turns this
>>>> picture upside down. First comes an implementation and then, frequently
>>>> never, consideration whether this implementation is right for the needs.
>>>
>>> You meant "application" instead of "language", right? So you would prefer
>>> to have a special "loop counter integer" instead of using a general
>>> unsigned integer?
>>
>> Sure. In fact in Ada it is much in this way:
>>
>>   for Index in A'Range loop
>>
>> I don't care about the type of Index, it is just the type suitable to index
>> the array A.
> 
> In loop control, I wouldn't care either, but given that it's a compiler 
> thing then, it wouldn't have to be a special type at all, for the 
> compiler can guarantee that the use of the standard primitive type would 
> be used appropriately for it is the one to generate the code from the 
> loop.

This is an implementation detail which shall not be exposed. Because Index
is a subtype of the array index the compiler can omit any range checks.
Contracts are useful for both the programmer and the compiler.

> I care in data structs though what the "physical" type is.

Why should you? Again, considering design by contract, and attempt to
reveal the implementation behind the contract is a design error. You shall
not rely on anything except the contract, that is a fundamental principle.

>>>>> Are you suggesting that a language have NO types?
>>>>
>>>> I suggest a minimal possible set of given types and as wide as 
>>>> possible set of types constructed.
>>>
>>> And do you reject wrapping an existing integer types to get desired
>>> semantics?
>>
>> Not at all.
> 
> But you do think it is inadequate, clearly.

No. Inadequate would be to expose such integer types in the contracts.
Implementations based on existing types are possible, but you would need
much language support (e.g. reflection) in order to ensure that the
implementation fulfills the contract. As an example, consider an
implementation of

   type I is range -200_000_000..100_000; -- This is the contract, which
      -- includes the range and the behavior of +,-,*/,**,mod,rem, overflow
      -- checks etc

on top of C's int.

>>>> The point is that it is the application domain
>>>> requirements to drive the design, and the choice of types in
>>>> particular.
>>>
>>> Can that be achieved? At what degree of complexity?
>>
>> We probably are close to the edge.
> 
> Meaning "highly complex"?

Enough complex to make unsustainable the ways programs are designed now.

>>> Can it/should it be hardware-supported?
>>
>> No. Hardware becomes less and less relevant as the software complexity
>> increases.
> 
> OK, so another layer of abstraction is what you want. The syntax of, say, 
> Ada's ranged types, for example. So your call is just for more syntactic 
> sugar then, yes?

Rather more support to contract driven design and static analysis.

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