Re: Why use C++?

["Jed" <jehdiah@orbitway.net>]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:fwnlcp4mgj03$.1tjeqjtos00o8$.dlg@40tude.net...
> 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.

What more definition do you want? Size guarantee? Other than that, what 
is ambiguous (platform-specific) about C++ int?

>
>>>>> 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.

Do you care about the size of the type ever?

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

The built-in things that are closest to the machine, with consistent 
representation across machines that can be relied on, that other things 
are built on top of. (That's a stab at it, anywho).

>
>> 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?

Because you know it isn't beer cans (call it, say, "a simplifying 
assumption") and you may want to (probably will want to) send some of 
those integers to another machine across the internet or to disk.

>
>>>>>  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.

Just another layer of abstraction. So it's as simple as that (another 
layer of abstraction), yes?

>
>>> (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.

Oh? I've been having a language design discussion (primarily). You've 
been having a compiler implementation discussion?

>
>>>>> 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.

Sure, it doesn't matter in the case of the loop variable.

>  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.

While that paradigm does have a place, that place is not "everywhere". 
That would be throwing the baby out with the bath water.

The comments being made in this thread are really suggesting 4GL. While 
that is fine, there is a place for 3GLs and hybrids. One size fits all, 
really doesn't.

>
>>>>>> 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.

Well then, if wrapping is OK, what else is needed and why?

> Inadequate would be to expose such integer types in the contracts.

What 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.
>

Oh, THAT "contract". (I reserve that term for function calls, just to 
avoid overloading it, but I actually prefer "specification" as I 
associate "contract" with Eiffel).

I'm don't know what you are suggesting the ideal implementation would be 
of the ranged type above.

>>>>> 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.

Explain please.

>
>>>> 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.

That doesn't appear to be a lot of complexity to introduce into a 
compiler. It seems like common sense. So, what am I missing here?

The new enums in C++11 are a step in the right direction, yes? Maybe in 
the next iteration we'll get ranges.