www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - D2 Closure

reply Steve Teale <steve.teale britseyeview.com> writes:
Just a few days ago, Walter was talking about 'the final feature'. Andrei 
is going through the tedious and unpleasant process of finalizing TDPL 
with his publisher. In a minute it will be March, so to get anything 
finalized by the summer of 2010 is already looking like a stretch.

Now we have a whole new slew of suggestions for change.

I think that at some point the membership of digitalmars.D needs to 
accept that there is a deadline, and that further discussion of the ideal 
language refers to D3.

Another provocative way of thinking about this is that D2 is already 'E', 
unless the faithful users of D1 and Tango are to be unceremoniously 
dumped. In that case, the discussions that have suddenly flared up now 
are about 'F'.

Time to choose. Will D ever be a widely used programming language, or is 
it just a excellent vehicle for discussion of programming language 
features?

Steve
Feb 17 2010
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Steve Teale wrote:

 Just a few days ago, Walter was talking about 'the final feature'. Andrei 
 is going through the tedious and unpleasant process of finalizing TDPL 
 with his publisher. In a minute it will be March, so to get anything 
 finalized by the summer of 2010 is already looking like a stretch.
 
 Now we have a whole new slew of suggestions for change.
 
 I think that at some point the membership of digitalmars.D needs to 
 accept that there is a deadline, and that further discussion of the ideal 
 language refers to D3.
 
 Another provocative way of thinking about this is that D2 is already 'E', 
 unless the faithful users of D1 and Tango are to be unceremoniously 
 dumped. In that case, the discussions that have suddenly flared up now 
 are about 'F'.
 
 Time to choose. Will D ever be a widely used programming language, or is 
 it just a excellent vehicle for discussion of programming language 
 features?
 
 Steve


assert(cat !in bag);

D2 has officially been frozen. There is no major breaking change we can 
make at this moment. Defining features that don't change the semantics 
of existing code is possible, but will be undocumented at least in the 
first print of TDPL.


Andrei
Feb 17 2010
parent reply bearophile <bearophileHUGS lycos.com> writes:
Andrei Alexandrescu:

 D2 has officially been frozen.


Congratulations to Walter and you then :-)



 There is no major breaking change we can 
 make at this moment. Defining features that don't change the semantics 
 of existing code is possible, but will be undocumented at least in the 
 first print of TDPL.


There is a certain amount of features already partially implemented or
partially broken than can be fixed and finished from now on.
A little example: I think this doesn't compile yet (the compiler can't find
std.math.sqrt):

void main() {
    double x = 5 ^^ 0.5;
}

Bye,
bearophile
Feb 17 2010
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
bearophile wrote:

 Andrei Alexandrescu:

 D2 has officially been frozen.


 
 Congratulations to Walter and you then :-)


Thanks much.


 There is no major breaking change we can 
 make at this moment. Defining features that don't change the semantics 
 of existing code is possible, but will be undocumented at least in the 
 first print of TDPL.


 
 There is a certain amount of features already partially implemented or
partially broken than can be fixed and finished from now on.
 A little example: I think this doesn't compile yet (the compiler can't find
std.math.sqrt):
 
 void main() {
     double x = 5 ^^ 0.5;
 }


Please bugzillize.

Generally this is the time to align the implementation with the book and 
also to put it in great shape. Walter and I needed to make a lot of 
microdecisions in the past weeks, which put pressure on the 
implementation. But I am happy to report that it generally feels that 
we're turning the right corners.

Regarding the recent debate regarding signed and unsigned numbers, I 
have great faith in value range propagation.


Andrei
Feb 17 2010
prev sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Recently I think Walter has said something about this, but then he was probably
too much busy: I'd like to read an article written by Walter that contains a
list of the things that D2 does wrong. (Among then I'd like to put that default
storage type is mutable instead of immutable, as I have written in a recent
post).

Such list can be divided in parts:
1) Some quite important missing things, that can be added later, in D2+ or D3.
2) Errors that somehow can be fixed, if necessary deprecating a feature that
we'll just stop using, so we'll use another feature that replaces it.
3) Little or larger errors that are not easy to fix in future, design mistakes
that we'll have to live with.

This list is useful for future D2 users to know how to use the language better,
for future designers of similar languages, and of course people here will try
to invent ways to move some items from the third list to the second list in D3
:-)

Bye,
bearophile
Feb 17 2010
parent reply Martin Franklin <martin246564 btinternet.com> writes:
retard Wrote:


 That sounds like heresy :) Would anyone in D community really switch to 
 some other language? I'm sure there's a strong emotional bond already. 
 Even badly designed features and bugs can be seen as a strength if your 
 opinion is heavily biased. Learning a language is an investment. If 
 you've invested lot of time and effort in a language, all kinds of 
 feelings such as bitterness and frustation come up.
 


Its time to dump C-like languages - I have the evidence.

http://www.modulaware.com/mdlt28.htm
Feb 18 2010
parent reply Michel Fortin <michel.fortin michelf.com> writes:
On 2010-02-18 12:18:47 -0500, Martin Franklin 
<martin246564 btinternet.com> said:


 Its time to dump C-like languages - I have the evidence.
 
 http://www.modulaware.com/mdlt28.htm


Nice read... and it gives me a new feature idea for D! The article 
rants about default parameters not being very useful when you have more 
than one (something I agree with), then propose an improvement:


 Furthermore, they do not provide a great deal of convenience. If a 
 routine has five parameters, the last three of which are optional, and 
 caller wants to assume the defaults for parameters 3 and 4, but must 
 specify parameter 5, then all five parameters must be specified. A 
 better scheme would be to have a default keyword in function calls:
 
 f (a, b, default, default, e);


Would't that be nice to be able to use the 'default' keyword when you 
want to use the default value for a parameter? Should be pretty trivial 
to implement.


-- 
Michel Fortin
michel.fortin michelf.com
http://michelf.com/
Feb 18 2010
next sibling parent reply Jonathan M Davis <jmdavisProg gmail.com> writes:
Michel Fortin wrote:


 Would't that be nice to be able to use the 'default' keyword when you
 want to use the default value for a parameter? Should be pretty trivial
 to implement.


Except that to some extent, that would defeat the purpose of default 
parameters. Part of the idea is that you don't have to worry about their 
existence unless you actually want to change them. If you're going to have 
to put the word default there, then in many cases, you might as well just 
put an actual value yourself.

The one thing that word default would give you would be the ability to 
choose the the default value for parameters in the middle of the parameter 
list and still give values for parameters at the end. But that's just extra 
complication and likely wouldn't be worth the benefit.

- Jonathan M Davis
Feb 18 2010
next sibling parent Michel Fortin <michel.fortin michelf.com> writes:
On 2010-02-18 16:11:39 -0500, Jonathan M Davis <jmdavisProg gmail.com> said:


 Michel Fortin wrote:
 

 Would't that be nice to be able to use the 'default' keyword when you
 want to use the default value for a parameter? Should be pretty trivial
 to implement.


 
 Except that to some extent, that would defeat the purpose of default
 parameters. Part of the idea is that you don't have to worry about their
 existence unless you actually want to change them. If you're going to have
 to put the word default there, then in many cases, you might as well just
 put an actual value yourself.
 
 The one thing that word default would give you would be the ability to
 choose the the default value for parameters in the middle of the parameter
 list and still give values for parameters at the end. But that's just extra
 complication and likely wouldn't be worth the benefit.


I don't see the complication you talk about. It's no complication 
unless you use it, and if you feel the need to use it it's probably 
because there's a benefit. You can still call functions with default 
parameters by omitting the parameters if you want, I'm not trying to 
change that.

	void test(int a = 1, int b = 2);

	test();                 // same as test(1, 2);
	test(8);                // same as test(8, 2);
	test(default, 8);       // same as test(1, 8); <- here it's useful


-- 
Michel Fortin
michel.fortin michelf.com
http://michelf.com/
Feb 18 2010
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2010-02-18 22.11, Jonathan M Davis wrote:

 Michel Fortin wrote:


 Would't that be nice to be able to use the 'default' keyword when you
 want to use the default value for a parameter? Should be pretty trivial
 to implement.


 Except that to some extent, that would defeat the purpose of default
 parameters. Part of the idea is that you don't have to worry about their
 existence unless you actually want to change them. If you're going to have
 to put the word default there, then in many cases, you might as well just
 put an actual value yourself.

 The one thing that word default would give you would be the ability to
 choose the the default value for parameters in the middle of the parameter
 list and still give values for parameters at the end. But that's just extra
 complication and likely wouldn't be worth the benefit.

 - Jonathan M Davis


That sounds like named parameters, which could be nice to have.
Feb 18 2010
prev sibling next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Michel Fortin wrote:

 On 2010-02-18 12:18:47 -0500, Martin Franklin 
 <martin246564 btinternet.com> said:
 

 Its time to dump C-like languages - I have the evidence.

 http://www.modulaware.com/mdlt28.htm


 
 Nice read...


Very interesting indeed. It was written in 1992 and it's really 
fascinating to put this in historical perspective, considering what 
happened to the languages involved.

As they say in chess - never ignore the whole for the beauty of the part.


Andrei
Feb 18 2010
prev sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Michel Fortin" <michel.fortin michelf.com> wrote in message 
news:hlk4le$13ht$1 digitalmars.com...

 On 2010-02-18 12:18:47 -0500, Martin Franklin 
 <martin246564 btinternet.com> said:


 Its time to dump C-like languages - I have the evidence.

 http://www.modulaware.com/mdlt28.htm


 Nice read... and it gives me a new feature idea for D! The article rants 
 about default parameters not being very useful when you have more than one 
 (something I agree with), then propose an improvement:


 Furthermore, they do not provide a great deal of convenience. If a 
 routine has five parameters, the last three of which are optional, and 
 caller wants to assume the defaults for parameters 3 and 4, but must 
 specify parameter 5, then all five parameters must be specified. A better 
 scheme would be to have a default keyword in function calls:

 f (a, b, default, default, e);


 Would't that be nice to be able to use the 'default' keyword when you want 
 to use the default value for a parameter? Should be pretty trivial to 
 implement.


VBScript (Or maybe it's just VB6. Not sure about VB.NET) allows the above by 
doing this:

f (a, b, , , e)

That's the one thing about VB that I actually kinda liked. Of coruse, it may 
not be a perfect approach, but at least you *can* leave middle params as 
default.
Feb 21 2010
next sibling parent Nathan Tuggy <bugzilla nathan.tuggycomputer.com> writes:
On 2010-02-21 21:50, Nick Sabalausky wrote:

 VBScript (Or maybe it's just VB6. Not sure about VB.NET) allows the above by
 doing this:

 f (a, b, , , e)

 That's the one thing about VB that I actually kinda liked. Of coruse, it may
 not be a perfect approach, but at least you *can* leave middle params as
 default.


Yeah, I like that feature too (I have to use VB a lot for work; I freely 
admit to being something of a "quiche-eating" programmer, with 
aspirations to D). Note that VB 4-6 (and probably earlier), VBScript, 


is still in beta.

-- 
‖ Insert clever saying here… ‖ http://tagzilla.mozdev.org v0.066
Feb 21 2010
prev sibling parent bearophile <bearophileHUGS lycos.com> writes:
Nick Sabalausky:


 "Michel Fortin

 f (a, b, default, default, e);




 f (a, b, , , e)


The syntax with just commas is shorter but you can miss commas, so I prefer the
version with the default keyword, because it's more syntactically visible by
the programmer's eye. Here saving the 'default' keystrokes doesn't look like an
improvement.

I'd like to have named function arguments, even if partially implemented (there
are cases with delegates/function pointers where you need to do more changes if
you want to fully support named arguments, I've discussed this in the past.
Such cases can be omitted in the first implementation of this feature), because
in some situations they can increase code readability, and code readability can

implemented this feature).

Named arguments and that syntax to omit default arguments in the middle can be
used for similar purposes:
void foo(int a=1, int b=2, int c=3) {...}
foo(5, , 3);
foo(5, default, 3);
foo(a=5, c=3);
foo(5, c=3);

But this feature can be added later, I think it's an additive change. What's
instead more important to discuss first are features for D2 that can't be just
be added later, because they aren't just additive changes because they need
changes not backwards compatible with D1 (or with the precedent version of D2).
This is how the list of changes in Python3 was chosen: the minimal number of
changes that are not backwards compatible with Python2.x minus the additive
changes. All the other things that can be just added were postponed to
Python3.1 or later. This is a good design strategy that I have not seen
explicitly expressed in this newsgroup :-( I am sorry for not thinking and
writing this comments few months ago, because now it's not that useful.

Bye,
bearophile
Feb 22 2010