• bearophile <bearophileHUGS lycos.com> Mar 31 2009
• Jarrett Billingsley <jarrett.billingsley gmail.com> Mar 31 2009
• Rainer Deyke <rainerd eldwood.com> Mar 31 2009
• bearophile <bearophileHUGS lycos.com> Mar 31 2009

bearophile <bearophileHUGS lycos.com> writes:

In this post I list four random things I have seen/found lately. Some of them
may be interesting for the development of D.

C# has arrays of arrays as D, plus it has built-in multidimensional arrays too:
http://msdn.microsoft.com/en-us/library/aa288453(VS.71).aspx
They have some advantages:
- On them the compiler can use some extra optimizations, common in all Fortran
compilers. D seems a language fit for matrix processing, etc. So this may be
useful.
- Such matrixes can be reshaped on the fly, they just keep their line length as
an extra parameter.
- Being made of a single block of memory, the memory allocator wastes less
memory, sometimes much less. You can try this yourself with a single
stc.gc.malloc compared to the newing of a 2D matrix made of arrays of arrays.
I am ignorant about this topic, but maybe Lucarella may say something.


The GC used by dotnet C# is quite more efficient than the GC used by C# mono.
This page is about the development of a future better mono GC:
http://www.mono-project.com/Compacting_GC
It also reminds me that a (single) good GC may manage two kinds of objects:
"safe objects", that may be moved to allow heap compaction, and pinned objects,
coming from or referenced by unsafe modules.
If most modules in a D project are going to be safe, then most objects may be
unpinned, allowing the GC to move them. This in theory may lead to a D GC that
is often as efficient as ones like HotSpot ones.


The Scala language is quite interesting, it a quite modern language mixes OOP
and functional-style programming as very few other languages can. It also has a
quite good (but not always easy to use) type system, pattern matching, etc. So
I think it can be followed to look for possible ideas for D, because D2 too
wants to be a bit FP.
Despite running on a JavaVM its designers have given it class system different
from the Java/D one, you can find a short note on Wikipedia, plus quite more
explanations on Scala docs:
http://en.wikipedia.org/wiki/Scala_(programming_language)#Object-oriented_features
It says:
Data types and behaviors of objects are described by classes and traits. Class
abstractions are extended by subclassing and by a flexible mixin-based
composition mechanism to avoid the problems of multiple inheritance.<




Java has tons of standard exceptions, you can see some of them humorously
explained here:
http://rymden.nu/exceptions.html
I don't need hundreds of different exceptions organized in a deep tree, but I
have felt the need to define few basic ones:
http://www.fantascienza.net/leonardo/so/dlibs/exceptions.html
Is Phobos of D2 going to define a handful (10 may be enough) of standard
exceptions?

Bye,
bearophile

Jarrett Billingsley <jarrett.billingsley gmail.com> writes:

On Tue, Mar 31, 2009 at 7:31 PM, bearophile <bearophileHUGS lycos.com> wrote:
 Java has tons of standard exceptions, you can see some of them humorously
explained here:
 http://rymden.nu/exceptions.html
 I don't need hundreds of different exceptions organized in a deep tree, but I
have felt the need to define few basic ones:
 http://www.fantascienza.net/leonardo/so/dlibs/exceptions.html
 Is Phobos of D2 going to define a handful (10 may be enough) of standard
exceptions?


It already does, viz. druntime.

Rainer Deyke <rainerd eldwood.com> writes:

bearophile wrote:
 C# has arrays of arrays as D, plus it has built-in multidimensional
 arrays too: 
 http://msdn.microsoft.com/en-us/library/aa288453(VS.71).aspx They
 have some advantages: - On them the compiler can use some extra
 optimizations, common in all Fortran compilers. D seems a language
 fit for matrix processing, etc. So this may be useful. - Such
 matrixes can be reshaped on the fly, they just keep their line length
 as an extra parameter. - Being made of a single block of memory, the
 memory allocator wastes less memory, sometimes much less. You can try
 this yourself with a single stc.gc.malloc compared to the newing of a
 2D matrix made of arrays of arrays. I am ignorant about this topic,
 but maybe Lucarella may say something.


I use multi-dimensional arrays all the time.  Arrays of arrays are
totally inadequate as a substitute.  However, I'm not sure what
advantage a built-in type would provide over a library type.

 The GC used by dotnet C# is quite more efficient than the GC used by
 C# mono. This page is about the development of a future better mono
 GC: http://www.mono-project.com/Compacting_GC It also reminds me that
 a (single) good GC may manage two kinds of objects: "safe objects",
 that may be moved to allow heap compaction, and pinned objects,
 coming from or referenced by unsafe modules. If most modules in a D
 project are going to be safe, then most objects may be unpinned,
 allowing the GC to move them. This in theory may lead to a D GC that
 is often as efficient as ones like HotSpot ones.


Better GC is always nice, but I'd rather see the language stabilize
before worrying about such implementation details.

  It says:
 Data types and behaviors of objects are described by classes and
 traits. Class abstractions are extended by subclassing and by a
 flexible mixin-based composition mechanism to avoid the problems of
 multiple inheritance.<


 I'd like to know if this is actually (a bit) better than the way OOP
 is done in D. If such things are better, D2/D3 may eventually copy
 something.


Disclaimer: I haven't looked at Scala.

If mixins are such a good replacement for multiple inheritance, then
they are also a good replacement for single inheritance.  Having single
inheritance without multiple inheritance is /wrong/.  Based on the above
paragraph, it sounds like this criticism applies as much to Scala as it
does to D and Java.


-- 
Rainer Deyke - rainerd eldwood.com

bearophile <bearophileHUGS lycos.com> writes:

Rainer Deyke:

 However, I'm not sure what advantage a built-in type would provide over a
library type.<


Some C++ libs show that you can implement some of the optimizations I was
talking about (present in Fortran compilers, that juggle, split, merge and
slice nested for loops in various ways, in a cache-aware way too) with a
library type too. But I guess it's not easy to do.


 Better GC is always nice, but I'd rather see the language stabilize
 before worrying about such implementation details.


I have real small Java programs that run 6+ times slower once translated to D.
And I have benchmarks that run 12+ times slower, all thanks to the GC.
There are many Java programmers around, if one of them comes to D, writes some
code and sees the program run 5 times slower than the same program running on
Java I think you may have lost a potential new D programmer.
So I agree the GC it's less important than other things, but it's not a small
detail.


mixins: I skip this because I am too much ignorant on the topic. I'll learn a
bit more Scala.

Bye,
bearophile