Re: Why use C++?

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

"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 it 
may be too much effort for too little benefit. It seems it may be doing 
something in software that could be supported in hardware but isn't (?).
Maybe too much of a "purist" approach. I'd need more info about it and be 
convinced it is worth it before I'd put that on my shortlist of 
compelling features for a language to have. Investigation into Ada? Does 
Ada, in your opinion, "do it right/better"?

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

Oh, I thought ranges in Ada were "subtype ranges", hence being based upon 
the built-ins.

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

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

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

Pretty strong opinion there.

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

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

> 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? Can it/should it be 
hardware-supported? Is it compromised if implemented in software?

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

"Typeless" then (quotes usually omitted for the meaning is generally 
understood).

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

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.