Re: Why use C++?

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

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.

>>> What kinds of integer types would
>>> you like to see built-in to a hypothetical ideal language?
>>
>> As little as possible. Usage of predefined integer types makes design more
>> fragile. E.g. it is bad when somebody uses Ada's Integer, or C++ int (OK,
>> in C++ there is no other option), instead of introducing a type reflecting
>> the application semantics rather than the decision of some compiler vendor
>> motivated by other concerns.
> 
> You have to build those types though based upon the built-in ones, yes?

That depends. In Ada integer types are constructed from ranges. 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.
 
> 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.

> And are not those built-ins good to use "raw" in many cases?

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

> 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. The point is that it is the application domain
requirements to drive the design, and the choice of types in particular.

> There is assembly language for that (and 
> the instruction set pretty much dictates what types you have to work with 
> at that level).

There is no language without types. That includes assembly languages.
Weak/paraconsistent typing does not mean no typing. In each context you
have a type associated with any object involved in an operation on that
object.

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