Scala future, Sing#

[bearophile]

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? Scala compiler contains some parts to do that at compile-time (so it's not done at runtime by the JavaVM).
- I have put inside my dlibs a select() (adapting code written by another person) that uses lazy arguments to implement an eager (it can't be lazy, unfortunately) array comphrension. 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.


>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.


>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.


>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

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.


>Can you give an example?<

I don't know Scala enough to give you examples, so I leave this to Jari-Matti. But I think Scala uses an Hindley-Milner type inference algorithm, it's another class of type inferencing. I am not asking you to put Hindley-Milner inside D.


>[array literal type inference] How should it be done?<

Silently dropping information is bad. So cutting strings according to the length of the first one as in D1 is bad.
The type of an array literal has to be determined by the type specified by the programmer on the right. If such annotation is absent (because there's an auto, or because the array is inside an expression) the type has to be the most tight able to represent all the types contained in the array literal (or raise an error if no one can be found).
By default array literals have to produce dynamic arrays, unless the programmers specifies that he/she/shi wants a fixed-size one.
(People are asking for similar things for years, it's not a new topic invented by Jari-Matti M. or by me).

Bye,
bearophile