From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 109fba,cd8ed9115942852f X-Google-NewGroupId: yes X-Google-Thread: 103376,b92b95c9b5585075 X-Google-NewGroupId: yes X-Google-Attributes: gid4f1905883f,gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news3.google.com!feeder.news-service.com!aioe.org!eternal-september.org!feeder.eternal-september.org!.POSTED!not-for-mail From: "Jed" Newsgroups: comp.lang.c++,comp.lang.ada Subject: Re: Why use C++? Date: Fri, 12 Aug 2011 00:03:24 -0500 Organization: A noiseless patient Spider Message-ID: References: <1e292299-2cbe-4443-86f3-b19b8af50fff@c29g2000yqd.googlegroups.com> <1fd0cc9b-859d-428e-b68a-11e34de84225@gz10g2000vbb.googlegroups.com> <9ag33sFmuaU1@mid.individual.net> <1d8wyhvpcmpkd.ggiui9vebmtl.dlg@40tude.net> <150vz10ihvb5a.1lysmewa1muz4$.dlg@40tude.net> <1q4c610mmuxn7$.1k6s78wa0r8fj.dlg@40tude.net> Injection-Date: Fri, 12 Aug 2011 05:03:05 +0000 (UTC) Injection-Info: mx04.eternal-september.org; posting-host="bUZkUS1QLqpHyXuWevVWHQ"; logging-data="2759"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+jlku32k0gPqDVh4Le6ijv" X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6109 X-RFC2646: Format=Flowed; Original X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 Cancel-Lock: sha1:MAjCS6kwZMCR6FQhUSlbdTa53RA= X-Priority: 3 X-MSMail-Priority: Normal Xref: g2news1.google.com comp.lang.c++:82832 comp.lang.ada:20548 Date: 2011-08-12T00:03:24-05:00 List-Id: "Dmitry A. Kazakov" wrote in message news:1q4c610mmuxn7$.1k6s78wa0r8fj.dlg@40tude.net... > On Thu, 11 Aug 2011 05:57:32 -0500, Jed wrote: > >> "Dmitry A. Kazakov" 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.