Walter Bright wrote:
> Charles D Hixson wrote:
>> But D is here now, and if the libraries aren't all that one could wish, they show promise of growing over time, and not being arbitrarily broken.
> 
> Also D has very easy compatibility with C, and it goes both ways.

Even building a D library isn't "easy".  Were I to attempt it, I'd use GDC (which currently means limiting myself to a subset of D's features).

It's also not clear (to me) how to call a D routine from a program whose main routine is written in another language. This is a significant limitation...especially when more than one language makes it difficult.

Now I will readily grant that I'm not the best programmer using Linux...especially when one gets down to linking routines.  I haven't debugged from an octal dump since the CDC 7600, and I've never used a hex dump since the Apple ][. Before I started using D my favorite languages were Ruby and Python (Ruby for elegance, Python for speed).  As such, if the documentation doesn't specify how to include and link in the correct libraries, and how to initialize anything that needs initialization, I'm pretty much lost.  And I don't alway know where to look in the documentation, or what terms to use.  (I learned in Python to rely heavily on code examples...as well as documentation indexes.  This doesn't work as well in D, as there usually aren't any simple examples to do what I want...or if there are, I don't know where to find them.)

FWIW, D's compatibility with C is better than that of most languages.  This doesn't make it good.  I understand the problem caused by macros in header files...but they are a severe impediment to "very easy compatibility".  "Very easy compatibility" (my definition) means that I take of chunk of C code in multiple separate files linked by header files, and replace on of the files with a chunk of D code that performs an equivalent function.  This isn't possible, and probably isn't going to be possible.  At any rate, not until interpretation of C header files is handled.

I'm more or less in awe of the manipulations that can be done with templates...but I'm never going to be interested in using them at more than a very basic level.  I am more interested in run-time flexibility rather than in compile time flexibility.  Importing C header files, though, would immediately move D up to "The Single Most Superior Language" in my books.  (OK. I read the comments a few years ago, and you were advised that this was a can of worms and should be avoided.  It's probably right.  But it would be *SO* convenient.)

Another thing that would be useful is a specific and well documented entry point in the libraries (probably std.compiler or std.object) that could be called to do all necessary initializations if the main routine were, e.g., C.


OTOH, you notice that I'm posting here.  D appears a better language for me to use than any other.  Just not perfect.  So for the moment I'm doing etudes in C that I'll eventually link to D routines.  This will let me call C object files and libraries from D with only a lot of extra work and indirection.  Ugly and inconvenient, but better than the obvious alternatives.

Charles D Hixson wrote:
> Even building a D library isn't "easy".  Were I to attempt it, I'd use GDC (which currently means limiting myself to a subset of D's features).

Building a library is as easy as building the obj's, then putting them into a library with lib or ar. Granted, dmd could build the library itself like it does the link itself.

> It's also not clear (to me) how to call a D routine from a program whose main routine is written in another language. This is a significant limitation...especially when more than one language makes it difficult.

If you give the D routine C linkage, with extern (C), you can call it directly from any language that supports C (including, of course, C!).

> FWIW, D's compatibility with C is better than that of most languages.  This doesn't make it good.  I understand the problem caused by macros in header files...but they are a severe impediment to "very easy compatibility".  "Very easy compatibility" (my definition) means that I take of chunk of C code in multiple separate files linked by header files, and replace on of the files with a chunk of D code that performs an equivalent function.  This isn't possible, and probably isn't going to be possible.  At any rate, not until interpretation of C header files is handled.

The h2d.exe program will convert C headers to D import files. It isn't perfect, but it does a pretty good job of it.

> I'm more or less in awe of the manipulations that can be done with templates...but I'm never going to be interested in using them at more than a very basic level.

That's ok. The advanced stuff is there for the folks who need it, for bread & butter programmers it can be ignored. But, I also intend to make it so easy to do templates, you won't even notice you're using them!

> I am more interested in run-time flexibility rather than in compile time flexibility.  Importing C header files, though, would immediately move D up to "The Single Most Superior Language" in my books.  (OK. I read the comments a few years ago, and you were advised that this was a can of worms and should be avoided.  It's probably right.  But it would be *SO* convenient.)
> 
> Another thing that would be useful is a specific and well documented entry point in the libraries (probably std.compiler or std.object) that could be called to do all necessary initializations if the main routine were, e.g., C.

That's a good suggestion.


> OTOH, you notice that I'm posting here.  D appears a better language for me to use than any other.  Just not perfect.  So for the moment I'm doing etudes in C that I'll eventually link to D routines.  This will let me call C object files and libraries from D with only a lot of extra work and indirection.  Ugly and inconvenient, but better than the obvious alternatives.

Walter Bright wrote:

>> FWIW, D's compatibility with C is better than that of most languages.  This doesn't make it good.  I understand the problem caused by macros in header files...but they are a severe impediment to "very easy compatibility".  "Very easy compatibility" (my definition) means that I take of chunk of C code in multiple separate files linked by header files, and replace on of the files with a chunk of D code that performs an equivalent function.  This isn't possible, and probably isn't going to be possible.  At any rate, not until interpretation of C header files is handled.
> 
> The h2d.exe program will convert C headers to D import files. It isn't perfect, but it does a pretty good job of it.

While it is possible to run h2d.exe using Wine, there are also some open
source and free software like the h2d.pl hack or the bcd.gen program...

http://www.algonet.se/~afb/d/h2d.pl (GD, GL, AL, SDL, Tk, etc. etc.)
http://www.dsource.org/projects/bcd (fltk2, gtk+, libxml2, etc. etc.)

It's nowhere as convenient as with C-compatible languages like C++ or
Objective-C where you can do a #include, but it usually does the trick.
(and once the initial D import module has been created, it normally only
needs minor patches to keep up with version updates from the C header)

The real issue is C++ headers, where it is needed to generate one C++
file with extern "C" and one D wrapper that calls these function stubs.
Or with system headers that aren't distributable, or other secret stuff
where everyone has to re-generate their own bindings instead of sharing.

For instance with libraries like wxWidgets, you run into both of these.

--anders

Charles D Hixson wrote:

> Vala is interesting, especially because it looks to have easy support for GTK, and easy linkage to C.  (Both ways?  It's not clear.  Could you call a Vala routine from a program started in C?)

Seeing as how "valac" generates C source code, I don't see why not...
e.g. http://www.algonet.se/~afb/d/sample1.vala =>
	http://www.algonet.se/~afb/d/sample1.h
	http://www.algonet.se/~afb/d/sample1.c

"Vala is a modification of C# to better match the GObject type system."
I'm sure it could generate D source code instead, if it made any sense.

> And as usual the problem is with C++ libraries.  Nobody but C++ appears able to talk to them directly.  At some point I really MUST learn to use swig.

Nobody, *including* C++ itself, is able to talk with C++ libraries :-)

--anders

Reiner Pope Wrote:
> kris wrote:
> > http://arstechnica.com/journals/linux.ars/2007/09/02/vala-high-level-programming-with-less-fat
> > 
> > 
> > "Vala is still a work in progress, but support for the language is growing rapidly. Close GObject integration makes Vala an ideal choice for GNOME development, and the requisite library support is steadily falling into place. Vala's biggest deficiency right now is the lack of documentation. In time, Vala could replace C as the principle language of the GNOME platform."
> 
> Most of the listed features, D has too:
> - Interfaces
> - Properties
> - Signals  (why is this a language feature?)

Maybe to have a better syntax?

> - Foreach
> - Lambda expressions
> - Type inference for local variables
> - Generics
> - Non-null types

Are you sure that D has the 'non-null types' feature?
What I understand by 'non-null types' is like in Nice:
having a syntax to declare nullable types, and by default types are not nullable i.e
Type foo = null; is an error (if possible a compile-time error).
Type? foo = null; is ok.
This means that when you have a function f(Type t) you don't need to check in f whether t is null or not, it's already done for you.

AFAIK D doesn't have this.

renoX

> - Assisted memory management
> - Exception handling
> - Type modules (Plugins)
> 
> I'm not sure how type modules work, but I do know about non-null types, and they would sure be nice in D.
> 
> 
>    -- Reiner

renoX wrote:
> Reiner Pope Wrote:
>> kris wrote:
>>> http://arstechnica.com/journals/linux.ars/2007/09/02/vala-high-level-programming-with-less-fat 
>>>
>>>
>>> "Vala is still a work in progress, but support for the language is growing rapidly. Close GObject integration makes Vala an ideal choice for GNOME development, and the requisite library support is steadily falling into place. Vala's biggest deficiency right now is the lack of documentation. In time, Vala could replace C as the principle language of the GNOME platform."
>> Most of the listed features, D has too:
>> - Interfaces
>> - Properties
>> - Signals  (why is this a language feature?)
> 
> Maybe to have a better syntax? 
> 
>> - Foreach
>> - Lambda expressions
>> - Type inference for local variables
>> - Generics
>> - Non-null types
> 
> Are you sure that D has the 'non-null types' feature?
> What I understand by 'non-null types' is like in Nice:
> having a syntax to declare nullable types, and by default types are not nullable i.e
> Type foo = null; is an error (if possible a compile-time error).
> Type? foo = null; is ok.
> This means that when you have a function f(Type t) you don't need to check in f whether t is null or not, it's already done for you.
> 
> AFAIK D doesn't have this.

You should have read what you quoted afterwards  :-)

>> I'm not sure how type modules work, but I do know about non-null types, and they would sure be nice in D.
>>
>>
>>    -- Reiner
> 

D doesn't have it, but I think they would be nice.

   -- Reiner

Anders F Björklund wrote:
> Nobody, *including* C++ itself, is able to talk with C++ libraries :-)

It's true. And getting two C++ libraries from different vendors to coexist peacefully is yet another major problem. After all, what if each invents their own custom string class? Override operator new? etc.

Walter Bright wrote:
> Anders F Björklund wrote:
>> Nobody, *including* C++ itself, is able to talk with C++ libraries :-)
> 
> It's true. And getting two C++ libraries from different vendors to coexist peacefully is yet another major problem. After all, what if each invents their own custom string class? Override operator new? etc.

Getting two C++ libraries from the SAME vendor to work together is a problem!
<bangs head on keyboard after struggling all day with MSVC7 vs MSVC8 library incompatibilities>

--bb

Reiner Pope Wrote:

> renoX wrote:
> > Reiner Pope Wrote:
> >> kris wrote:
> >>> http://arstechnica.com/journals/linux.ars/2007/09/02/vala-high-level-programming-with-less-fat
> >>>
> >>>
> >>> "Vala is still a work in progress, but support for the language is growing rapidly. Close GObject integration makes Vala an ideal choice for GNOME development, and the requisite library support is steadily falling into place. Vala's biggest deficiency right now is the lack of documentation. In time, Vala could replace C as the principle language of the GNOME platform."
> >> Most of the listed features, D has too:
> >> - Interfaces
> >> - Properties
> >> - Signals  (why is this a language feature?)
> > 
> > Maybe to have a better syntax?
> > 
> >> - Foreach
> >> - Lambda expressions
> >> - Type inference for local variables
> >> - Generics
> >> - Non-null types
> > 
> > Are you sure that D has the 'non-null types' feature?
> > What I understand by 'non-null types' is like in Nice:
> > having a syntax to declare nullable types, and by default types are not nullable i.e
> > Type foo = null; is an error (if possible a compile-time error).
> > Type? foo = null; is ok.
> > This means that when you have a function f(Type t) you don't need to check in f whether t is null or not, it's already done for you.
> > 
> > AFAIK D doesn't have this.
> 
> You should have read what you quoted afterwards  :-)
> 
> >> I'm not sure how type modules work, but I do know about non-null types, and they would sure be nice in D.
> >>
> >>
> >>    -- Reiner
> > 
> 
> D doesn't have it, but I think they would be nice.

Ooops, sorry for having misread your post.

And yes it would be nice but on one hand it's a "specialised" feature, it only works for non-null checks, I've read some article about Haskell which talks about 'type modifiers' where for example you could declare a function to return a type 'Maybe Foo'
and the typesystem makes you checks whether there is an error or not before being able to use 'Maybe Foo' as 'Foo'..
So it's more generic, but of course having Type? is a more readable syntax than 'MaybeNull Type'.

renoX

> 
>     -- Reiner

renoX wrote:
> Reiner Pope Wrote:
> 
>> renoX wrote:
>>> Reiner Pope Wrote:
>>>> kris wrote:
>>>>> http://arstechnica.com/journals/linux.ars/2007/09/02/vala-high-level-programming-with-less-fat 
>>>>>
>>>>>
>>>>> "Vala is still a work in progress, but support for the language is growing rapidly. Close GObject integration makes Vala an ideal choice for GNOME development, and the requisite library support is steadily falling into place. Vala's biggest deficiency right now is the lack of documentation. In time, Vala could replace C as the principle language of the GNOME platform."
>>>> Most of the listed features, D has too:
>>>> - Interfaces
>>>> - Properties
>>>> - Signals  (why is this a language feature?)
>>> Maybe to have a better syntax? 
>>>
>>>> - Foreach
>>>> - Lambda expressions
>>>> - Type inference for local variables
>>>> - Generics
>>>> - Non-null types
>>> Are you sure that D has the 'non-null types' feature?
>>> What I understand by 'non-null types' is like in Nice:
>>> having a syntax to declare nullable types, and by default types are not nullable i.e
>>> Type foo = null; is an error (if possible a compile-time error).
>>> Type? foo = null; is ok.
>>> This means that when you have a function f(Type t) you don't need to check in f whether t is null or not, it's already done for you.
>>>
>>> AFAIK D doesn't have this.
>> You should have read what you quoted afterwards  :-)
>>
>>>> I'm not sure how type modules work, but I do know about non-null types, and they would sure be nice in D.
>>>>
>>>>
>>>>    -- Reiner
>> D doesn't have it, but I think they would be nice.
> 
> Ooops, sorry for having misread your post.
> 
> And yes it would be nice but on one hand it's a "specialised" feature, it only works for non-null checks, I've read some article about Haskell which talks about 'type modifiers' where for example you could declare a function to return a type 'Maybe Foo'
> and the typesystem makes you checks whether there is an error or not before being able to use 'Maybe Foo' as 'Foo'..
> So it's more generic, but of course having Type? is a more readable syntax than 'MaybeNull Type'.
> 

I think that's just a feature of pattern matching with algebraic data types. (Well, when I say just, I don't mean to demean it, though.) They are very interesting, but they can mostly be already emulated in D through meta-programming (I've been playing with doing this and it is over-all quite promising. For many of the problems I encounter, I think "this will be fixed with hygienic macros").

The problem is that it is easy, given a never-null type to make a maybe-null type -- you just make an algebraic datatype

     data MaybeNull a = Null | Some a

whereas the situation is much harder the other way around: how do you create a never-null type based on a maybe-null type?

We can try to emulate this in future D using static parameters:

struct NeverNull(T)
{
    T impl;
    void opAssign(static T t)
    {
        static assert(t !is null, "Can't assign null to a never-null");
        impl = t;
    }

    T implicitCastTo()
    {
        return impl;
    }
}

This would catch any attempt to write

NeverNull!(int*) = null;

at compile-time (since null is a compile-time constant). However, the fundamental problem is that the type system loses information in constructors: the result of a constructor is guaranteed to be non-null (am I right? or are there GC issues?), yet it is typed as a nullable type. So the following *should* be guaranteed to work

NeverNull!(int*) = new int;

yet assigning a nullable to a never-null doesn't typecheck in the general case, as it could allow

int* i = null;
NeverNull!(int*) = i;

Without never-null types, I don't think the type system can distinguish those two cases.


    -- Reiner