Re: Why use C++?

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

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.

(Types algebra refers to the set of [meta]operations used to create new
types)

>> 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
 
>>  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. (The way compiler would implement that type is uninteresting, so long
we are considering only the type interface).

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

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

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

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

> Can it/should it be hardware-supported?

No. Hardware becomes less and less relevant as the software complexity
increases.

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

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