Re: Teaching C/C++ from Ada perspective?

["Dan'l Miller" <optikos@verizon.net>]

I found another 2 OCR mistakes that occurred within MacOS's PDF-world during the bitmap-to-text copy paste (that I missed during the original edit).  Their correction is interspersed below, to try to preclude anyone from pondering what a “mamfest” is.

On Thursday, July 5, 2018 at 10:32:36 PM UTC-5, Dan'l Miller wrote:
> On Tuesday, July 3, 2018 at 3:00:27 AM UTC-5, Maciej Sobczak wrote:
> > > Overtly declaring the range of integers over which this portion of code operates can be a key portion
> > > of eliminating all variants of the overflow/overrun vuln(erabilitie)s that worms utilize as their attack
> > > vector to insert machine code.
> > ...
> > > But never mind SEI software engineering principles, eh?
> > 
> > So can you kindly point me to where exactly SEI recommends defining integer range types ...
> 
> Maciej, I'll see your integer range types as software-engineering principles emanating from the SEI team
> at CMU, and raise you one Tartan in 1978.  The integer ranges as constant attributes on integer (or,
> indeed, on any scalar type) comes not merely from the various team members, but from the imprimatur
> of William A. Wulf himself, the founder-progenitor-anchor-pillar of the entire software-engineering team
> at CMU.
> 
> The Software Engineering Institute was formed on 14 November 1984.  Prior to the official formation of
> the SEI, William Wulf's team were a DoD-supported research contractor at Carnegie Mellon University.
> The DoD High-Order Language Working Group (HOLWG) authored a series of -man requirements for
> HOLWG's new language:  strawman, woodenman, tinman, ironman, steelman.  Ironman and Steelman
> were issued to the {Yellow, Blue, Red, Green} color teams to design a language that conforms to the
> Ironman-at-first and then-Steelman requirements.  Steelman requirements added a brand-new
> requirement that had no precursor in Ironman:
> “3-1C. Numeric Variables. The range of each numeric variable must be specified in programs and shall
> be determined by the time of its allocation. Such specifications shall be interpreted as the minimum
> range to be implemented and as the maximum range needed by the application. Explicit conversion
> operations shall not be required between numeric ranges.”
> 
> https://en.wikisource.org/wiki/Steelman_language_requirements
> 
> But notably (and the ultimate SEI/CMU answer to your question) there were 2 pre-disqualified
> noncolor/noncompetitor language designs that had a extra-special relationship with HOLWG:  Tartan
> from the pre-SEI team at CMU and -75+15PL/I from IBM.
> 
> http://archive.adaic.com/pol-hist/history/holwg-93/holwg-93.htm
> As mentioned in the 2nd paragraph below Figure 9, Tartan was an apparent wordplay on the color
> naming of the 4 official competitors; tartan is a specific kind of plaid in William Wulf's ancestral
> Scotland.  -75+15PL/I was PL/I with 75% of PL/I removed and a new 15% added.  HOLWG issued Ironman
> requirements to CMU and IBM to design a language from Ironman, and harshly critique whether Ironman
> was on-track or off-track.  HOLWG utilized the language definitions (including the language designers'
> insights and criticisms) that they got back from Tartan and -75+15PL/I to author their Steelman
> requirements as a definitive improvement over their Ironman requirements.
> 
> https://ia800804.us.archive.org/7/items/DTIC_ADA062815/DTIC_ADA062815.pdf
> In §1.7 Unresolved Issues, the §1.7.3 Definition of Integers overtly recommends the content that became
> Steelman's new 3-1C requirement:
> “In the reference manual we chose fIxed as a primitive and defined lnt as a special case by choosing
> attributes appropriately. We believe it is possible to treat int as primitive and define Fixed as
> nonprlmative by associating •range•/precision bookkeeplng with the operations.”  [Operations were
> Tartan's jargon for compile-time definitions of the values of the attributes of types.]
> 
> [Btw, Dmitry, you & your Steelman 3-3F-esque compile-time constant tag attributes for untagged types
> should pay especial attention henceforth, because, had more of Tartan made it into Steelman and thus
> into Green/Ada, then you yourself [not language designers] would have been able to define your own
> compile-time constant tag attributes for •any• type.  In the form of a standard library of Tartan-esque
> type compile-time operations, you would have had your tags for untagged types feature in a
> hypothetical more-Tartan-influenced Ada83+ almost 4 decades ago.]
> 
> In §1.5.6 Definition of Types, we see::
> “A ••user•• may introduce a new type into his program with a type deflation. The type definition itself
> merely introduces the <type name> and defines the representation of the type. Operations are
> introduced by writing routines whose formal parameters are of the newly-dsflned type. …

defined

> ¶A type definition may be paremeterized with •attributes•. The bindings in the formal parameter list
> must be •const• or mamfest. If a <binding> is omitted, it will be assumed to be const[, •Dmitry•]. The

manifest

> names of the formal parameters of the type are available throughout the elaboration of the program as
> •constants• [just as in Steelman requirement 3-3F], called •attributes• [just as they later became known
> in Ada]. They are accessed by treating the <var ident> as a •record•[, Dmitry] and the type attribute as a
> [Steelman 3-3F-compliant] •const• field. Attributes for primitive types are given as part of the type
> definitions [just as they later became in Ada].”
> 
> So there we have it, almost* precisely as Maciej requested:
> constant compile-time attributes for integer (and fixed-point) ranges (and precision) from Carnegie
> Mellon University's DoD computer-science research team that a few years later named themselves
> Software Engineering Institute feeding directly into the requirements document that is to measure the
> amount of software-engineering-ness present in any programming language.
> 
> * just without mentioning C++ by name, mainly because C++ didn't exist yet (nor did C with Classes),
> because C++ hadn't yet mimicked Ada to this degree until a half to full decade later
> 
> Btw, Maciej, Steelman requirements are governing any programming language that purports to be a
> software-in-the-large software-engineering language, C++ included.
> 
> How well does 1990s-era {Ada95, C, C++, Java, Pascal}, and 2010s-era {D, Rust, Parasail} measure up
> against Steelman's software-engineering requirements?
> 
> https://www.dwheeler.com/steelman/steeltab.htm
> 
> http://jedbarber.id.au/steelman.html