www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Four things

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


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.



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


So it seems they have partially refused how classes are managed in D. 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.


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
Mar 31 2009
next sibling parent 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.
Mar 31 2009
prev sibling parent reply Rainer Deyke <rainerd eldwood.com> writes:
bearophile wrote:


 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.




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


 So it seems they have partially refused how classes are managed in D.
 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
Mar 31 2009
parent 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
Mar 31 2009