Origins of the D Programming Language

[anon reviewer]

On Friday, 30 November 2018 at 19:34:58 UTC, Andrei Alexandrescu 
wrote:
> Over the past few months, Walter, Mike, and myself have been 
> working on a draft submission for the HOPL 2020 conference 
> (History of Programming Languages).
>
> The submission proceeds in several stages. Currently we've been 
> through one round of preliminary review. Here is the current 
> draft:
>
> http://erdani.com/hopl2020-draft.pdf
>
> We'd appreciate feedback and additional historical details.
>
>
> Thanks,
>
> Andrei (on behalf of Walter and Mike as well)

I have completed a more thorough reading and here are additional 
comments that would strengthen the manuscript:

On the topic of slices as a built-in type in D, these were of 
course well-studied in the literature aka as fat pointers- 
combining a pointer with its bounds- and in particular have been 
well studied and implemented in C, with the most well-known 
example being the influential cyclone language with its @fat 
pointers, which should be referenced (see 
https://cyclone.thelanguage.org/wiki/Pointers/ ).

The manuscript in several places uses well-known terms in 
programming language theory but is written in a way suggesting 
that these terms originated in D. This is misleading for readers 
with insufficient background in comparative programming 
languages. In particular, the term "slice" is of course the 
standard term used for a reference to a part of a contiguous 
block of memory in array languages, including Fortran 95. In C++ 
such slices into contiguous blocks of dynamically-allocated 
memory have been available as library types, as opposed to a 
built-in type, since initial standardization, e.g. see 
valarray::slice and slice_array, or as third party array classes 
such as Blitz++ ca. 2005 (see 
http://physik.uni-graz.at/~crg/Programmierkurs1112/pdfs/blitz.pdf), for which subarrays and slices to a block of memory have their memory-management handled automatically through reference-counting, and which can be attached to raw memory pointers- essentially the same functionality as the the built-in D slice but as a separate library type, which fits more closely with the C++ design principle of preferring library solutions over built-in types.

Also, the use of the keyword "trait" in D clearly comes from the 
use of the well-known term "trait" in C++ for a similar purpose 
of compile-time lookup of type information e.g. the C++ 
std::type_traits header. So the original publication by Meyers 
introducing the term "traits" should be referenced (Traits: a new 
and useful template technique by Nathan C. Myers C++ Report, June 
1995).

Other points:
Matthew Wilson's rangelib is mentioned but without citation. A 
reference to his and his colleagues' original publication on 
their range library is needed ("Ranges, part 1: Concepts and 
Implementation", Matthew Wilson and John Torjo, C/C++ User's 
Journal, Volume 22 Number 10, October 2004).

In the section on mistakes made, it would be interesting to 
expand the discussion:
(i) on the broader topic of built-in types versus library 
classes, it was noted in the manuscript that having a built-in 
complex number was a mistake versus a library type. What of other 
built-in types such as associative arrays and slices which are 
built-in in D? Some insight into when built-in types are 
preferable could be a useful contribution of the manuscript (ii) 
on the topic of garbage collection it is mentioned that reference 
counting is planned.  Is gc now considered a mistake to be fully 
removed in the future or is it considered a success, and how did 
it impact library design?

Also, to clarify further on the Fortran 95 pure keyword discussed 
in the previous comment: in Fortran 95 pure procedures include 
both (i) pure functions and (ii) pure subroutines. For both 
types, iteration and local variable are allowed, as long as the 
mutation is local to the function- what is termed  "relaxed 
functional purity" in the manuscript. The distinction between 
pure functions and pure subroutines is that pure subroutines can 
also mutate arguments passed by reference (a distinction not 
discussed in the manuscript but referred to as "weak" and 
"strong" purity in the D broader D documentation). See 
http://earth.uni-muenster.de/~joergs/doc/f90/lrm/lrm0157.htm .