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