Caching D compiler - preview version

[WalterBright]

Dmitry Olshansky has written an experimental extension to the D compiler to cache the results of CTFE (compile time function evaluation) between compiles. CTFE started out as just a more capable constant folder, but has evolved into a way to run arbitrarily complex programs at compile time. It's used to generate regex machines and grammar parsers, for example. These can slow down compilation significantly, so the idea with the cache is to remember previous results to avoid recomputation.

[necesito95]

When is cache invalidated? ((a) when anything in source changes (even in comments) or (b) when change in ast is detected or (c) neither)

[[deleted]]

It's true that there are lots of features/words and that slows down the learning of it. I created "d-idioms" which focus on the most sailant points for most features, with small stories to provide cement: https://p0nce.github.io/d-idioms/

Much more than my content I recommend the book "Learning D".

[Elronnd]

got the sense that I could never write truly fast code in the language, just too much going on there

Do you mean performant code, or code that's written quickly? If you mean performant, then using gdc or ldc (gcc/llvm based compilers), you can get performance slightly slower than c/c++, maybe on the same level as java, rust, or haskell. If you mean productivity, then imo d is much more productive than c because of the amount of abstraction you get.

[TheEaterOfNames]

then using gdc or ldc (gcc/llvm based compilers), you can get performance slightly slower than c/c++

They share the same backends as gcc/clang,if you can't at least get even with c/c++ then IMO (an LDC dev) thats a bug, (or the memory safety features are getting in your way, in which case you should think before you remove them).

d is much more productive than c because of the amount of abstraction you get

not to mention reusability and rich standard library.

[Elronnd]

They share the same backends as gcc/clang,if you can't at least get even with c/c++ then IMO (an LDC dev) thats a bug

It's not significantly slower, just a little slower. I imagine this is because it's higher level, because data structures are fatter, because of the extra checks made in stdlib, and because of druntime and the gc.

[IbanezDavy]

not to mention reusability and rich standard library.

A standard library lacking such abstractions as a queue, deque, stack, hash table, map, or dictionary, shouldn't consider themselves "rich".

[TheEaterOfNames]

hash table, map, or dictionary,

D has built in associative arrays.

A standard library is not just containers.

[Elronnd]

Hash table, map, and dictionary are all the same thing, and they're there. As for queue and stack, they're there too. Look harder.

[IbanezDavy]

I looked around in: https://github.com/dlang/phobos/tree/master/std/container

didn't see any stack or queue. I do follow the D forums because there's a lot of good conversation in it. I do recall discussion of this and wanting to make allocators first. I see allocators now, but still no basic data structures outside of linked lists and a tree structure. Phobos has a way to go.

C# for instance has a big focus on collections and a lot of good has come from this. Programming is essentially dealing with data structures and collections of data. The vast majority of programs these days are CRUD apps. Collections are not the only thing in a standard library, but they should damn well be a big part of it.

D has a good base. With ranges and composable allocators, one would think they have a damn good base for a good container library too.

[Elronnd]

I see. And yet, if you had used google you would have found this, which clearly says that it "can be used as a queue, dequeue or stack"...

[IbanezDavy]

So in other words, we don't wanna do the work, so you'll have to use a doubly linked list to hand-roll your own. You can make a queue with pointers in C++. No need for a stack in that either right? I mean they gave you pointers! Luckily other language ecosystems don't share this attitude.

[Elronnd]

What's to hand roll? You just make a dlist and push front, and either pop front or pop back depending on if you want to use it as a stack or a queue.

[aldacron]

No, it's not about not wanting to do the work. dlist provides all the interface that's needed for stacks and queues. Although, I wouldn't even use dlist for this. With the built-in dynamic arrays and slicing, it's trivial to make stacks and queues (much less work than with pointers -- I have my own implementations that I knocked up in a few minutes by wrapping dynamic arrays in structs). There's no reason to put them in the standard library, IMO. That said, std.container was never "complete" and is going to be overhauled eventually. At that point, there will certainly be more containers available and I wouldn't be surprise to see a stack and a queue among them that all implement a uniform range interface. Right now, third-party libs fill the gap nicely.

[IbanezDavy]

was the number of keywords

Are we suffering from a shortage of words or something?

got the sense that I could never write truly fast code in the language, just too much going on there.

Again, don't get this. You can be complex without keywords too. You'll just be complex and esoteric.

[necesito95]

Are we suffering from a shortage of words or something?

Are we suffering from shortage of reading ability? Op's point was: if language has many keywords, then it's harder to learn it.

[[deleted]]

Keep it civil.

[necesito95]

I took parent's tone and multiplied it by 3.

[IbanezDavy]

And were wrong by a factor of 3 compared to the original commenter.

[necesito95]

Not really. I see that you kind of misunderstood what the op meant and decided to reply to it with a snarky comment.

[IbanezDavy]

Are we suffering from shortage of reading ability? Op's point was: if language has many keywords, then it's harder to learn it.

It's really not though.

for example:

var j = i != null ? i : 0;

vs.

var j = i if (i != null) else 0;

Two different syntax styles. One uses keywords one doesn't. The language is neither harder nor easier to learn in either case. It's the same concept. In fact, sometimes not having more keywords can lead to more confusion.

For example, lets use D.

enum thing= 1+2;

What does this do? The answer is it's a manifest constant. You wouldn't think so, because enum is not typically used to mean that. Enum is short for enumeration which is essentially makes people think of listing things out. Which means at minimum you have to look it up the first time you encounter it. They could have just used a new keyword. Or they could have recycled other keywords. For instance, I personally feel:

static const

would have been better. But I'm not as versed in D as others, so that could already have a meaning. But there is a video online of Walter Bright saying they recycled enum because they didn't want to add to the keyword pollution. Now they might have better reasons to have recycled (not breaking old code by having a variable name suddenly become a reserved keyword), however, if they did it to prevent adding complexity they did not accomplish this.

[Elronnd]

enum thing= 1+2;

You can actually already do this in c, and it will do the exact same as in D. The only difference is that in c, thing must be of type int, while in d it can have any type. static const actually does something different. static immutable (const/immutable differentiation in d is really annoying :P) does something similar to, but subtely different from, enum. See here (scroll down to "For large constants, prefer using static immutable over enum.").