On 12/1/2018 3:12 AM, Kagamin wrote:
> Also string as just a plain immutable slice of utf8 text is a distinct feature too. Nobody else did it. Swift only recently adopted utf8 encoding, I thought it always worked that way, at least NSString in gnustep did.

In other languages, strings were always "special". I tried hard to make them not special in D, they were just arrays. (Unfortunately, autodecode broke that.)

On Saturday, 1 December 2018 at 18:28:14 UTC, H. S. Teoh wrote:
> On Sat, Dec 01, 2018 at 05:32:44PM +0000, Paolo Invernizzi via Digitalmars-d wrote:
>> On Saturday, 1 December 2018 at 16:07:28 UTC, H. S. Teoh wrote:
>> > On Sat, Dec 01, 2018 at 11:02:51AM +0000, Kagamin via Digitalmars-d wrote: [...]
>> > > [...]
>> > 
>> > I think you misunderstand the intent here.  Purity by default doesn't mean everything must be pure with no way out except awkward periphrases like monads.  It means you opt out of purity by specifying impure, rather than start with impure and opt into purity by specifying pure.  I.e., an undecorated function will be implicitly pure, but if you want impure code, you add an `impure` attribute to the function.
>> > 
>> > [...]
>> 
>> And maybe, class methods final by default?
> [...]
>
> This one is a toss-up.  Based on Walter's airplane design philosophy, the idea is to make the default behaviour the correct / good one, and require effort to write incorrect / bad code.  Purity by default is good because pure code has no side-effects, which makes it easier to reason about (and in some cases, easier for the optimizer to optimize). Immutable by default is good because it provides more optimization opportunities (if something doesn't need to change, it shouldn't be mutable, then the optimizer can eliminate redundant loads where it would otherwise be unsure whether intervening code may have changed the original value, if it was mutable), and also prevents common errors like accidentally changing a value that's not expected to change, or code smells like reusing variables for something completely unrelated to the original use.
>
> But for class methods, it's less clear what's the better default. Especially in D, where structs and compile-time template polymorphism tend to be preferred where possible, and it almost feels like the raison d'etre of classes is OO-style runtime polymorphism, so it would make sense for methods to be virtual by default. OTOH, making them final by default would also mean you don't incur runtime costs except when you explicitly ask for virtual.  But then you'd have to specify virtual everywhere in a construct that seems to be intended precisely for such a use in the first place. So I'm tempted to say virtual by default makes more sense (code correctness / clarity / less boilerplate come first, performance comes later), but I can see how it can be argued both ways.
>
>
> T

"virtual is a one-way trip. It can't be undone without risking breaking
code once released to the wild. How can that state be a sensible default?"
(Cit. Manu)

Some years ago, that was debated for long time, and final by default was almost landed into D, with the approval of both W&A.[1][2], see rationale here [3]

I dare to say that this specific episode was the beginning of all the "break/non break" code debate [4] that still persist, and that I hope we will tame in the next future...

/P

[1] https://forum.dlang.org/post/koo65g$1nqs$2@digitalmars.com
[2] https://forum.dlang.org/post/koqkhc$4nn$1@digitalmars.com
[3] https://www.artima.com/intv/nonvirtualP.html
[4] https://forum.dlang.org/post/lfqoan$5qq$1@digitalmars.com

On Friday, November 30, 2018 6:00:00 PM MST H. S. Teoh via Digitalmars-d wrote:
> On Fri, Nov 30, 2018 at 02:34:58PM -0500, Andrei Alexandrescu via
Digitalmars-d 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.
>
> [...]
>
> Lines 1049-1050: I wasn't there at the time, so this may be inaccurate, but I clearly remember someone mentioning that Tango has been ported to D2 and is quite usable, at least as of a few years ago.  But I haven't tried it myself, so I can't for sure whether this is actually the case. But it's worth checking so that the HOPL document is factually accurate.

Tango was eventually ported to D2, but it hasn't been maintained. I tried to compile it to benchmark its XML parser against dxml when preparing my dconf talk this year, and Tango wouldn't compile anymore.

- Jonathan M Davis

On Friday, November 30, 2018 6:23:33 PM MST H. S. Teoh via Digitalmars-d wrote:
> On Sat, Dec 01, 2018 at 01:14:58AM +0000, Neia Neutuladh via Digitalmars-d
wrote:
> > On Fri, 30 Nov 2018 17:00:00 -0800, H. S. Teoh wrote:
> > > Lines 1049-1050: I wasn't there at the time, so this may be inaccurate, but I clearly remember someone mentioning that Tango has been ported to D2 and is quite usable, at least as of a few years ago.  But I haven't tried it myself, so I can't for sure whether this is actually the case.  But it's worth checking so that the HOPL document is factually accurate.
> >
> > It's updated to roughly 2.068, I think, and doesn't really compile beyond that.
> >
> > I tried to update it to the most recent DMD, but that was painful. If I try in the future, I'll probably go one major release at a time.
>
> So I'm guessing that other than Sociomantic(?), there aren't any other major codebases out there that use Tango?

Likely not, and Sociomantic uses their own fork of it, so I don't know how different it is to what Tango was. As I understand it, the core Tango folks mostly abandoned it as D1 started dying off, and they were uninterested in D2. As a result, it was quite a while before Tango was ported to D2, and so any projects that used it would either have been stuck using D1 or had to be rewritten to not use D2 for Tango anyway. So, I think that the combination of Tango not being ported to D2 very quickly and the fact that many of the folks heavily into D1 did not like D2 resulted in very few D2 projects using Tango. And since at this point, it doesn't even compile anymore, no projects really can be using it even if someone wanted to. Sociomantic's Ocean is the closest that anyone could be using right now without putting in a lot of work to fix up Tango.

- Jonathan M Davis

On Saturday, December 1, 2018 8:00:35 AM MST Timon Gehr via Digitalmars-d wrote:
> 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."

UB on assertion failure fundamentally breaks the guarantees of @safe. @safe is supposed to guarantee that invalid memory accesses cannot occur (assuming that @trusted code was properly vetted anyway), whereas allowing UB on assertion failure violates that, because it makes it so that memory safety is not guaranteed if an assertion every fails. IIRC, the spec even specfically states that @safe code is not allowed to have UB, and as I understand it, if it's allowed to have UB, then the optimizer can make the code @system in spite of it being marked as @safe, because the optimizer can assume pretty much whatever it wants about code which is UB (e.g. as I understand it, that currently happens with ldc if it ever detects that a pointer or reference is null and is then dereferenced, because it treats dereferencing null as UB - I don't know if dmd has a similar problem). If assertion failures are allowed to introduce UB, then assertions should be treated as @system, not @safe.

Really, at minimum, assertions should not be allowed to introduce UB in @safe code, and even allowing it in @system code gets iffy, because UB makes it extremely difficult for the programmer to properly vet the code for memory safety so that that they can properly mark the code as @trusted. I don't think that optimizing based on assertions is necessarily bad, but the optimizations need to be restricted such that they're not allowed to make it so that the code is not memory safe if the assertion fails. Without that, I don't see how we could reasonably argue that @safe code is memory safe if it contains assertions.

- Jonathan M Davis

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 tried to assemble some of these data here:

https://wiki.dlang.org/Language_History_and_Future

There are some important events inside.

dub, the number of packages, GDC and some other points might be worth to get included.

Regards mt.

On Fri, 30 Nov 2018 at 20:35, Andrei Alexandrescu via Digitalmars-d <digitalmars-d@puremagic.com> 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)

Wrong accreditation, lines 1118-1119.

> 2002, May: David Friedman began creation of another D compiler by adapting the D front end sources for use with gcc, calling it the BrightD Compiler project

It was our resident Jan Knepper who did this, not David.  The codename was BrightD, under the OpenD umbrella project.

Citation: https://web.archive.org/web/20180324145631/http://www.opend.org/

It's a shame that this site has now been sniped by what looks to be a domain shark, according to the registrar information, shortly after Burton's apparent passing earlier this year too.

--
Iain

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)

ulong factorial(ulong n) {
  ulong result = 1;
  foreach (i; 0 .. n) result *= i; // off by one.
  return result;
}

Even the best make mistake ;)

On Mon, Dec 03, 2018 at 11:42:40PM +0000, Q. Schroll via Digitalmars-d wrote: [...]
> ulong factorial(ulong n) {
>   ulong result = 1;
>   foreach (i; 0 .. n) result *= i; // off by one.
>   return result;
> }
> 
> Even the best make mistake ;)

Optimizer output:

	ulong factorial(n) { return 0; }

:-D

Where are the unittests that would have caught this?? ;-)

Furthermore, it's not just off by 1, since i=1 is a redundant case. The loop really ought to start with 2.


T

-- 
In theory, software is implemented according to the design that has been carefully worked out beforehand. In practice, design documents are written after the fact to describe the sorry mess that has gone on before.

On Mon, 03 Dec 2018 16:02:30 -0800, H. S. Teoh wrote:
> Furthermore, it's not just off by 1, since i=1 is a redundant case. The loop really ought to start with 2.

factorial(0) is 1 because it's the product of an empty sequence.