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?
> 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.
The call-by-name trailing block syntax is also more uniform with the built-ins
in scala, e.g.:
scala> object Helpers { def run_twice[T](block: => T) = { block; block } }
defined module Helpers
scala> import Helpers._
import Helpers._
scala> var i = 1
i: Int = 1
scala> run_twice { i += 1; i }
res5: Int = 3
scala> run_twice { print("foo\n") }
foo
foo
> >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.
Java is /fast enough/ for many (if not most) purposes. People even use
languages with slower implementations like php or javascript these days (ever
heard of web 2.0?). Often the other aspects of the language have a larger
impact on real world projects than raw execution speed.
> >[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.
Since now I've mostly been experimenting with D1. But this seems to be fixed in
D2.
> 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.
The literals should also handle cases like [[],[],[1,2]], not only the string
case. What makes this frustating is that one can assume that since the generic
type inference engine isn't used consistently in all cases, there isn't one in
dmd. This might result in more corner cases in other parts of the language.
