www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - DMD v1.0 (again)

reply Kyle Furlong <kylefurlong gmail.com> writes:
Why don't we try and be definitive about what needs to get done before a 1.0
release? Walter may contribute his list as well. 
(this is really what I'm looking for) <g>
Mar 22 2006
next sibling parent reply John Demme <me teqdruid.com> writes:
Kyle Furlong wrote:


 Why don't we try and be definitive about what needs to get done before a
 1.0 release? Walter may contribute his list as well. (this is really what
 I'm looking for) <g>


With the recent DMD 0.150 Release I think there are four things that need to
be done before 1.0:

-Linux debugging symbols-- well... maybe not, but it needs to be there
before I can really start hawking D  ;)

-Plaster all the documentation with recommendations to try Ares + Mango as
an alternative to Phobos and instructions on how to do this. (I don't want
to spark a debate on Mango vs Phobos, but I want Mango + Ares advertised as
an option.)  In the final packaging, it might be a good idea to include
some popular D packages such as Mango + Ares, and Derek's build. (Also DDL,
once it's done)

-Linux shared object support

This one's the most important one:
-Anything with which Walter is not ABSOLUTELY satisfied with or believes to
be a hack MUST be dealt with before 1.0.  Now's your last chance to make
changes which could break code, Walter... the bit vs bool change is a good
example.

I think we're getting close, but maybe I'm just really happy about the new
interface stuff.

~John Demme
Mar 22 2006
parent reply BCS <BCS_member pathlink.com> writes:
John Demme wrote:

 Kyle Furlong wrote:
 
 

Why don't we try and be definitive about what needs to get done before a
1.0 release? Walter may contribute his list as well. (this is really what
I'm looking for) <g>


 
 
 
 -Plaster all the documentation with recommendations to try Ares + Mango as
 an alternative to Phobos and instructions on how to do this. (I don't want
 to spark a debate on Mango vs Phobos, but I want Mango + Ares advertised as
 an option.)  In the final packaging, it might be a good idea to include
 some popular D packages such as Mango + Ares, and Derek's build. (Also DDL,
 once it's done)
 


Full (or as much as doable) removal of runtime environment dependencys on
Phobos.


 
 This one's the most important one:
 -Anything with which Walter is not ABSOLUTELY satisfied with or believes to
 be a hack MUST be dealt with before 1.0.  Now's your last chance to make
 changes which could break code, Walter... the bit vs bool change is a good
 example.
 


Ditto


 ~John Demme
Mar 22 2006
parent reply Kyle Furlong <kylefurlong gmail.com> writes:
BCS wrote:

 John Demme wrote:

 Kyle Furlong wrote:



 Why don't we try and be definitive about what needs to get done before a
 1.0 release? Walter may contribute his list as well. (this is really 
 what
 I'm looking for) <g>




 -Plaster all the documentation with recommendations to try Ares + 
 Mango as
 an alternative to Phobos and instructions on how to do this. (I don't 
 want
 to spark a debate on Mango vs Phobos, but I want Mango + Ares 
 advertised as
 an option.)  In the final packaging, it might be a good idea to include
 some popular D packages such as Mango + Ares, and Derek's build. (Also 
 DDL,
 once it's done)


 
 Full (or as much as doable) removal of runtime environment dependencys 
 on Phobos.
 


Do you realize what this entails? Many, I repeat *MANY* language *features* are
implemented in phobos.

 This one's the most important one:
 -Anything with which Walter is not ABSOLUTELY satisfied with or 
 believes to
 be a hack MUST be dealt with before 1.0.  Now's your last chance to make
 changes which could break code, Walter... the bit vs bool change is a 
 good
 example.


 Ditto
 

 ~John Demme
Mar 22 2006
parent reply BCS <BCS_member pathlink.com> writes:
Kyle Furlong wrote:

 BCS wrote:
 

 Full (or as much as doable) removal of runtime environment dependencys 
 on Phobos.


 
 Do you realize what this entails? Many, I repeat *MANY* language 
 *features* are implemented in phobos.
 


a pipe dream?

How about full documentation on what is used, enough so that they can be
replaced.
Mar 22 2006
parent Kyle Furlong <kylefurlong gmail.com> writes:
BCS wrote:

 Kyle Furlong wrote:

 BCS wrote:


 Full (or as much as doable) removal of runtime environment 
 dependencys on Phobos.


 Do you realize what this entails? Many, I repeat *MANY* language 
 *features* are implemented in phobos.


 a pipe dream?
 
 How about full documentation on what is used, enough so that they can be 
 replaced.
Mar 22 2006
prev sibling next sibling parent reply Don Clugston <dac nospam.com.au> writes:
Kyle Furlong wrote:

 Why don't we try and be definitive about what needs to get done before a 
 1.0 release? Walter may contribute his list as well. (this is really 
 what I'm looking for) <g>


Not much more for the language, I reckon. Anything that will break code.
* AFAIK, the only new feature that needs to be done is the change to 
RAII syntax.
* Rounding out a few of the recent features, especially IFTI.
* Deprecate all undesirable features. I hope that this includes implicit 
declaration of printf, and reckless use of the comma operator.
* No bugs in bugzilla of 'normal' or higher severity.

(In practice, I'm now finding the biggest annoyance with the compiler is 
the way it dumps reams of incorrect error messages when it encounters a 
template any time after the first error).

Of course, the library's a different story...
Mar 23 2006
next sibling parent kris <foo bar.com> writes:
Don Clugston wrote:

 (In practice, I'm now finding the biggest annoyance with the compiler is 
 the way it dumps reams of incorrect error messages when it encounters a 
 template any time after the first error).


Yes, that /does/ become tiresome rather quickly.

Another primary one to keep in mind is better debugger support (arrays, 
classes, etc)
Mar 23 2006
prev sibling parent Kyle Furlong <kylefurlong gmail.com> writes:
Don Clugston wrote:

 Kyle Furlong wrote:

 Why don't we try and be definitive about what needs to get done before 
 a 1.0 release? Walter may contribute his list as well. (this is really 
 what I'm looking for) <g>


 
 Not much more for the language, I reckon. Anything that will break code.
 * AFAIK, the only new feature that needs to be done is the change to 
 RAII syntax.
 * Rounding out a few of the recent features, especially IFTI.
 * Deprecate all undesirable features. I hope that this includes implicit 
 declaration of printf, and reckless use of the comma operator.
 * No bugs in bugzilla of 'normal' or higher severity.
 
 (In practice, I'm now finding the biggest annoyance with the compiler is 
 the way it dumps reams of incorrect error messages when it encounters a 
 template any time after the first error).
 
 Of course, the library's a different story...


I think the template error thing will be a deal breaker for C++ template types.
Heres a senario:

C++ guy reads about D v1.0 with cool new template system on /.

C++ guy gets D v1.0 compiler (without template error messages fixed)

C++ guy ports his sweet (so he thinks) template code to D

C++ guy compiles... and WTF?!?! REAMS OF OUTPUT, from a simple noobie error

C++ guy leaves D forever
Mar 23 2006
prev sibling parent reply Wolfgang Draxinger <wdraxinger darkstargames.de> writes:
Kyle Furlong wrote:


 Why don't we try and be definitive about what needs to get done
 before a 1.0 release? Walter may contribute his list as well.
 (this is really what I'm looking for) <g>


* 64 Bit support. That's a must. Or better: Arbitrary register
length support. This of course means, that the ABI is built
around the native length of pointers, pointer differences, etc.

Wishes for D v1.1:

* Eventually it may be good to have types like int8 int64 etc
built into the language. In other languages (C/C++) this is done
using a lot of ugly typedefs, or the compiler introduces types
like __int8 which are then typedefed. Why not build this into
the language? It won't break existing code, too (at least it
doesn't "alias int int32; alias uint uint32;)"

* It would be great to have RTTI without the same dirty tricks as
performed in C++ (deriving everything from a common CObject
class, etc). Make RTTI Information avaliable by introducing
static and dynamic properties.

* I'd like to have classes, interfaces and modules have
a .inferface property (eventually name it a bit different to
avoid clash with "normal" interfaces), that gives a data
structure describing all methods and properties of a class and
it's inheritance hierachy. The inheritance hierachy could be
exposed by a property .super which has itself an .interface
property and .super property. Just have a look at the dir(...)
command of the python language and you get the idea. This
capability of self description would make it much easier to
expose classes to foreign modules loaded by dynamic loaders or
being integrated into component systems or make it avaliable to
script interpreters. I think of the following:

import rtti; // get the types for RTTI

foreach(rtti.method method, this.methods)
{
        script_language_module.add_function(method.name, method.params);
}

method.params would be an array describing each parameter,
eventually having a reference to other RTTI information again.

Up to today no language, that creates compiled binary code has
this feature. Only .net managed code is the closest thing to
have this, but it's not native but gets converted to native code
by a JIT compiler at runtime.

* The other way would be cool, too, i.e. create a typed delegate
from supplied method information. This delegate may then be used
as callback or similair stuff. Through RTTI there is type safety
and giving a mismatching delegate raises an exception. At the
current state such delegates must be defined at compile time.
Runtime function creation can be done with some dirty hacks, but
still requires predefining the types. Normally this involves an
associative array of an intermediary class that does the stack
building and variadic functions. However this is not runtime
safe. So such a class should be able to provide RTTI
information.

* By the way .net: D is IMHO an ideal language to support .net.
Eventually we should try to add CLI output to the compilers for
it.

-- 
Wolfgang Draxinger
Mar 23 2006
parent Wolfgang Draxinger <wdraxinger darkstargames.de> writes:
Wolfgang Draxinger wrote:


 * It would be great to have RTTI without the same dirty tricks as
 performed in C++ (deriving everything from a common CObject
 class, etc). Make RTTI Information avaliable by introducing
 static and dynamic properties.
 ...


D'oh: I've now seen, that this is already provided or intended to be done by
Phobos. Ahm, I should really read more on the standard libraries and not
just focus on the language spec.

Wolfgang Draxinger
Mar 28 2006