Origins of the D Programming Language

Timon Gehr timon.gehr at gmx.ch
Sat Dec 1 15:00:35 UTC 2018


On 30.11.18 20:34, 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)

Great write-up!

Comments:

110-111: UB on assertion failure is still terrible even if it is 
considered to be a bug and a non-recoverable error. Those things have 
nothing to do with each other. The airplane analogy would be roughly: 
"Components that are about to fail may start to arbitrarily violate the 
laws of physics."

169: Potentially confusing language. An associative operator op usually 
is taken to be an operator that satisfies (a op b) op c = a op (b op c).

175: ergnomic -> ergonomic

482: I don't think it is true that array slices are an enabler for CTFE. 
It is easy to write a safe and complete enough interpreter for code that 
uses pointer indexing.

499: "Built-in tuple". This terminology is not very forward-compatible. 
Typically, tuples in programming languages do not auto-expand. Also, 
before this point, it is not discussed what a "built-in tuple" is.

544: Boolean expresions -> Boolean expressions

753: Something is missing here. Maybe add a sentence that explains that 
pure has been changed from its initial definition or rewrite in another way.



More information about the Digitalmars-d mailing list