www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - Vala could replace C ...

reply kris <foo bar.com> writes:
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."
Sep 02 2007
next sibling parent reply Reiner Pope <some address.com> writes:
kris wrote:

 http://arstechnica.com/journals/linux.ars/2007/09/02/vala-high-level-progr
mming-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?)
- Foreach
- Lambda expressions
- Type inference for local variables
- Generics
- Non-null types
- 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
Sep 02 2007
next sibling parent reply Sean Kelly <sean f4.ca> writes:
Reiner Pope wrote:

 kris wrote:

 http://arstechnica.com/journals/linux.ars/2007/09/02/vala-high-level-progr
mming-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?)


For object destruction notification with weak pointers, some runtime 
support is required, which one could argue imposes language requirements.


 - Foreach
 - Lambda expressions
 - Type inference for local variables
 - Generics


Generics or templates?  Big difference.


 - Non-null types
 - 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.


Plugin support in D would be great.  There is DDL...


Sean
Sep 03 2007
parent BLS <nanali nospam-wanadoo.fr> writes:
Sean Kelly schrieb:

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


 
 Plugin support in D would be great.  There is DDL...
 


Meanwhile I am quit pessimistic regarding DDL
Bjoern

 
 Sean
Sep 03 2007
prev sibling parent reply renoX <renosky free.fr> writes:
Reiner Pope Wrote:

 kris wrote:

 http://arstechnica.com/journals/linux.ars/2007/09/02/vala-high-level-progr
mming-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
Sep 04 2007
parent reply Reiner Pope <some address.com> writes:
renoX wrote:

 Reiner Pope Wrote:

 kris wrote:

 http://arstechnica.com/journals/linux.ars/2007/09/02/vala-high-level-progr
mming-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
Sep 04 2007
parent reply renoX <renosky free.fr> writes:
Reiner Pope Wrote:


 renoX wrote:

 Reiner Pope Wrote:

 kris wrote:

 http://arstechnica.com/journals/linux.ars/2007/09/02/vala-high-level-progr
mming-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
Sep 04 2007
parent Reiner Pope <some address.com> writes:
renoX wrote:

 Reiner Pope Wrote:
 

 renoX wrote:

 Reiner Pope Wrote:

 kris wrote:

 http://arstechnica.com/journals/linux.ars/2007/09/02/vala-high-level-progr
mming-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
Sep 04 2007
prev sibling next sibling parent reply Clay Smith <clayasaurus gmail.com> writes:
kris wrote:

 http://arstechnica.com/journals/linux.ars/2007/09/02/vala-high-level-progr
mming-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."


Looks like the GNOME folks wanted to write their own language 
specifically for GNOME stuff. That said, 'Vala /might/ replace C for the 
GNOME team.' I don't think many outside the GNOME team would be very 
interested.

~ Clay
Sep 03 2007
parent Bill Baxter <dnewsgroup billbaxter.com> writes:
Clay Smith wrote:

 kris wrote:

 http://arstechnica.com/journals/linux.ars/2007/09/02/vala-high-level-progr
mming-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."


 
 Looks like the GNOME folks wanted to write their own language 
 specifically for GNOME stuff. That said, 'Vala /might/ replace C for the 
 GNOME team.' I don't think many outside the GNOME team would be very 
 interested.


It sounds to me like they're trying to make something like ObjC but 
based on glib.

--bb
Sep 03 2007
prev sibling parent reply Charles D Hixson <charleshixsn earthlink.net> writes:
kris wrote:

 http://arstechnica.com/journals/linux.ars/2007/09/02/vala-high-level-progr
mming-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."


I think you've been oversold.  Note that it's at version 0.13. 
  Read how it does memory management. Search the site for 
documentation.  (Documentation is one of the main reasons that 
I've avoided gcj.  I NEED to be able to call C libraries...and 
gcj will let me, but won't describe how.  [Well, *I* haven't 
found where it's described.]  I could use Fortran or Ada, but 
they don't have garbage collection.  Eiffel, another 
possibility, is still recovering from it's most recent 
schism...and it provokes them so often that it's never been 
able to standardize it's libraries.  [E.g., gobo works with 
SmartEiffel 1.0, but not with 1.2, and the compiler writers 
are disdainful of any suggestion that they should consider 
that a problem.  "To us SmartEiffel is a research project.")

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?)

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.

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.
Sep 03 2007
next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
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.
Sep 03 2007
parent reply Charles D Hixson <charleshixsn earthlink.net> writes:
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.
Sep 03 2007
next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
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.
Sep 03 2007
parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
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
Sep 03 2007
prev sibling parent Sean Kelly <sean f4.ca> writes:
Charles D Hixson wrote:

 
 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.


In Tango, these are:

extern (C) void rt_init( void delegate(Exception) dg = null );
extern (C) void rt_term( void delegate(Exception) dg = null );


Sean
Sep 04 2007
prev sibling next sibling parent reply kris <foo bar.com> writes:
Charles D Hixson wrote:

 kris wrote:

 http://arstechnica.com/journals/linux.ars/2007/09/02/vala-high-level-progr
mming-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."


 
 I think you've been oversold.  


Who? Me? I'm just the messenger boy. Thought ppl might be interested?
Sep 03 2007
parent Charles D Hixson <charleshixsn earthlink.net> writes:
kris wrote:

 Charles D Hixson wrote:

 kris wrote:

 http://arstechnica.com/journals/linux.ars/2007/09/02/vala-high-level-progr
mming-with-less-fat 
...


 I think you've been oversold.  


 
 Who? Me? I'm just the messenger boy. Thought ppl might be interested?


And I quote " Vala could replace C ...".  (It *is* interesting.)
Sep 03 2007
prev sibling parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
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


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
Sep 04 2007
next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
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.
Sep 04 2007
parent Bill Baxter <dnewsgroup billbaxter.com> writes:
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
Sep 04 2007
prev sibling parent reply =?ISO-8859-1?Q?Julio_C=E9sar_Carrascal_Urquijo?= writes:
Anders F Björklund wrote:


 I'm sure it could generate D source code instead, if it made any sense.


It does to me. I think the difference in compilation speed of GCC vs DMD 
justifies just that.
Sep 04 2007
parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Julio César Carrascal Urquijo wrote:



 I'm sure it could generate D source code instead, if it made any sense.


 
 It does to me. I think the difference in compilation speed of GCC vs DMD 
 justifies just that.


It doesn't to me, since I normally use GCC to compile my D code too.
(gdc is a lot faster than g++, but that's because of the languages)

--anders
Sep 04 2007