Scala future, Sing#

[Walter Bright]

bearophile wrote:
> Walter Bright:
> 
>> Actually, you can do them with "lazy" function arguments. There was
>> an example somewhere of doing control structures with it.<
> 
> There are some problems with this: - Are current (especially LDC)
> compilers able to inline those lazy delegates?

No, but it's not a technical issue, just more of no demand for it. But 
this would not be a reason to use Scala, as one doesn't use Scala for 
performance oriented programs.


> I'ver tried to see how the LDC compiles it and people
> there have shown me distaste for that code of mine, even just for a
> benchmark. So it seems the D community doesn't like to use lazy
> arguments to create control structures. - Andrei has shown so much
> distate for such things that the Phobos2 doesn't ususually even use
> normal delegates, and you have even added a "typeless" way to give a
> delegate to a template in D2. This shows there's little interest
> among D developers to go the way of Scala. Scala uses delegates for
> those purposes, and then inlines them.

D supports many styles of programming. Whether a particular style is 
popular or not is not really the issue - if someone wants to use that 
style, it is available. If someone builds a compelling case for the 
advantages of such a style, it can catch on.

We can see this in C++ over time, where different styles have gained 
ascendancy and then were replaced by new styles.


>> I've been hearing that (about Java, same problem) for as long as
>> Java has been around. It might get there yet, but that won't be in
>> the near future.<
> 
> Today Java is very fast, especially for very OOP-style code.
> Sometimes programs in C++ can be a little faster, but generally no
> more than 2 times. C# on dotnet too is fast, for example its GC and
> associative arrays are much faster.

A factor of 2 is a big deal.


>> Yes, but an interpreter or JIT is required to make that work. That
>> makes the language binary not lightweight.<
> D can be improved/debugged in several ways in this regard, even if
> keeps not using a VM.

Sure, but there's still a huge difference.


>> Do you mean knowing a class or virtual method has no descendants?
>> Sure, you need to know the whole program to do that, or just
>> declare it as final.<
> 
> I can see there's lot of confusion about such matters. Experience has
> shown that class-hierarchy-based optimization isn't much effective,
> because in most practical programs lot of virtual calls are bi- or
> multi- morphic. Other strategies like "Type feedback" work better. I
> have already discussed this topic a little, but it was on the D.learn
> newsgroup, so you have missed it.
> 
> A good old paper about this topic: "Eliminating Virtual Function
> Calls in C++ Programs" (1996), by Gerald Aigner, Urs Hölzle: 
> http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.7.7766

Thanks for the reference. DMC++ does a good job of eliminating many 
virtual calls.

> There are other papers written on this topic, and some of such papers
> are more modern/updated too (this is about 13 years old), but it's a
> good starting point. If yoy want more papers please ask.
> 
> Note that the LDC compiler has Link-Time Optimization too, and LTO
> can also be done when you "know the whole program". If the front-end
> gives some semantic annotations to LDC, it can do powerful things
> during LTO.

I didn't know that.