Re: Why use C++?

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

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:1vn800hbyx8k4$.1lsveclj56197$.dlg@40tude.net...
> On Fri, 12 Aug 2011 00:03:24 -0500, Jed wrote:
>
>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
>> news:1q4c610mmuxn7$.1k6s78wa0r8fj.dlg@40tude.net...
>>> On Thu, 11 Aug 2011 05:57:32 -0500, Jed wrote:
>>>
>>>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
>>>> news:150vz10ihvb5a.1lysmewa1muz4$.dlg@40tude.net...
>>>
>>>>> Types that cannot be constructed by the operations of the types 
>>>>> algebra
>>>>> provided by the language. Richer the algebra is, less built-in 
>>>>> types needed.
>>>>
>>>> Will you give an example to clarify please?
>>>
>>> Ada does not have predefined modular types in the package Standard, 
>>> because
>>> any modular type can be constructed using "type T is mod N" 
>>> construct.
>>
>> OK, I plainly see what you meant now even without your example. It's
>> amazing what a good night's sleep will do. Last night, I was keying-in 
>> on
>> the word "algebra" too much and it blinded me to the overall meaning.
>>
>> I'm not sure I'd want that level of flexibility in a language.
>
> 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? And do you want that in exclusion of well-defined primitive 
integers?

>>> 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? Aren't they just "syntactic" 
sugar over some well-defined primitives? Wouldn't they have to be? I.e., 
at some point, the hardware has to be interfaced.

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

> (The way compiler would implement that type is uninteresting,

Ha! To me that is KEY.

> so long we are considering only the type interface).

Abstraction. High level.

>
>>>> If so, aren't modular, wrapping and overflow-checked equally good 
>>>> for
>>>> something and all worthy of being in a language? Of course there is
>>>> signed, unsigned and the different bit widths as candidates also.
>>>
>>> Packed decimal, non-symmetric around zero, saturating, 
>>> non-continuous, big
>>> number, non-complement encoded, integers with ideal values (like NaN 
>>> etc)
>>> and so on, and so forth. You cannot have them built-in.
>>
>> Why not? What do you understand as "built-in"? Intel x86 has BCDs, so
>> would be easy to have that as a type in a language. Do you require
>> "built-in" to mean "supported directly by the hardware"?
>
> Built-in = predefined type, e.g. int, char, double.

OK, good. That's what I though you meant but just making sure we are on 
the same page.

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

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

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

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

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

>
>> From a HLL-designer POV, saying assembly language is "typeless", is 
>> fair,
>> and usually stated that way. One can pick nits at that if they want 
>> to.
>
> Yes, but "typeless" actually means broken, implicit types, rather than 
> no
> types at all.
>