www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Tuples, C#, Java, language design

reply bearophile <bearophileHUGS lycos.com> writes:

thanks to Mono too. I don't like that string interpolation syntax because it
looks unsafe, and that design of tuples can be improved, but they are listening
to programmes (even if they risk creating a mudball language):
http://www.infoq.com/news/2009/12/Mono-CSharp-Ex

More on those tuples:
http://tirania.org/blog/archive/2009/Dec-23.html

Eventually it will be quite useful to have some very well designed multi-return
support in D (like those tuples, but better).

Bye,
bearophile
Dec 28 2009
parent reply justme <justme somewhere.net> writes:
bearophile Wrote:



time, thanks to Mono too. I don't like that string interpolation syntax because
it looks unsafe, and that design of tuples can be improved, but they are
listening to programmes (even if they risk creating a mudball language):
 http://www.infoq.com/news/2009/12/Mono-CSharp-Ex
 
 More on those tuples:
 http://tirania.org/blog/archive/2009/Dec-23.html
 
 Eventually it will be quite useful to have some very well designed
multi-return support in D (like those tuples, but better).



doesn't so such syntax is not possible in D, me thinks.
Dec 29 2009
next sibling parent reply grauzone <none example.net> writes:
justme wrote:

 bearophile Wrote:
 


time, thanks to Mono too. I don't like that string interpolation syntax because
it looks unsafe, and that design of tuples can be improved, but they are
listening to programmes (even if they risk creating a mudball language):
 http://www.infoq.com/news/2009/12/Mono-CSharp-Ex

 More on those tuples:
 http://tirania.org/blog/archive/2009/Dec-23.html

 Eventually it will be quite useful to have some very well designed
multi-return support in D (like those tuples, but better).


 

doesn't so such syntax is not possible in D, me thinks.


But tuples in D really suck. Compared to other languages, D tuples feel 
inflexible, stiff, and complicated.
Dec 29 2009
parent reply justme <justme somewhere.net> writes:
grauzone Wrote:


 justme wrote:

 bearophile Wrote:
 


time, thanks to Mono too. I don't like that string interpolation syntax because
it looks unsafe, and that design of tuples can be improved, but they are
listening to programmes (even if they risk creating a mudball language):
 http://www.infoq.com/news/2009/12/Mono-CSharp-Ex

 More on those tuples:
 http://tirania.org/blog/archive/2009/Dec-23.html

 Eventually it will be quite useful to have some very well designed
multi-return support in D (like those tuples, but better).


 

doesn't so such syntax is not possible in D, me thinks.


 
 But tuples in D really suck. Compared to other languages, D tuples feel 
 inflexible, stiff, and complicated.


The burden of proving your claims is still there. Isn't D meritocracy - nobody
listens your opinions unless you post compiler / stdlib patches. I believe the
Phobos tuple classes are sufficient until a better system arrives in D3 or D4.
D2 book is almost finished so you need to write your patches against D3 now.
Dec 29 2009
parent reply grauzone <none example.net> writes:
justme wrote:

 grauzone Wrote:
 

 justme wrote:

 bearophile Wrote:



time, thanks to Mono too. I don't like that string interpolation syntax because
it looks unsafe, and that design of tuples can be improved, but they are
listening to programmes (even if they risk creating a mudball language):
 http://www.infoq.com/news/2009/12/Mono-CSharp-Ex

 More on those tuples:
 http://tirania.org/blog/archive/2009/Dec-23.html

 Eventually it will be quite useful to have some very well designed
multi-return support in D (like those tuples, but better).



doesn't so such syntax is not possible in D, me thinks.


 But tuples in D really suck. Compared to other languages, D tuples feel 
 inflexible, stiff, and complicated.


 
 The burden of proving your claims is still there. Isn't D meritocracy - nobody
listens your opinions unless you post compiler / stdlib patches. I believe the
Phobos tuple classes are sufficient until a better system arrives in D3 or D4.
D2 book is almost finished so you need to write your patches against D3 now.


My experience with patches is, that they're mostly either ignored or 
rejected. I guess the chance of an unrequested patch changing a core 
language feature in crucial ways is 200%. Walter doesn't listen to 
anyone anyway *g*.

The downsides of D tuples has been often mentioned, e.g. here: 
http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=98953
(Sorry, I'm not as eloquent as language_fan to write it up myself, plus 
nobody would read it.)
Dec 29 2009
parent grauzone <none example.net> writes:
grauzone wrote:

 justme wrote:

 grauzone Wrote:


 justme wrote:

 bearophile Wrote:



 some more time, thanks to Mono too. I don't like that string 
 interpolation syntax because it looks unsafe, and that design of 
 tuples can be improved, but they are listening to programmes (even 
 if they risk creating a mudball language):
 http://www.infoq.com/news/2009/12/Mono-CSharp-Ex

 More on those tuples:
 http://tirania.org/blog/archive/2009/Dec-23.html

 Eventually it will be quite useful to have some very well designed 
 multi-return support in D (like those tuples, but better).


 Doesn't D2 already have tuples in Phobos. D has the comma operator 



 But tuples in D really suck. Compared to other languages, D tuples 
 feel inflexible, stiff, and complicated.


 The burden of proving your claims is still there. Isn't D meritocracy 
 - nobody listens your opinions unless you post compiler / stdlib 
 patches. I believe the Phobos tuple classes are sufficient until a 
 better system arrives in D3 or D4. D2 book is almost finished so you 
 need to write your patches against D3 now.


 
 My experience with patches is, that they're mostly either ignored or 
 rejected. I guess the chance of an unrequested patch changing a core 
 language feature in crucial ways is 200%. Walter doesn't listen to 
 anyone anyway *g*.
 
 The downsides of D tuples has been often mentioned, e.g. here: 
 http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmar
.D&article_id=98953 


That was incomplete. You have to compare the code examples with the D 
version: 
http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=98947


 (Sorry, I'm not as eloquent as language_fan to write it up myself, plus 
 nobody would read it.)
Dec 29 2009
prev sibling parent reply BCS <none anon.com> writes:
Hello justme,


 bearophile Wrote:
 


 more time, thanks to Mono too. I don't like that string interpolation
 syntax because it looks unsafe, and that design of tuples can be
 improved, but they are listening to programmes (even if they risk
 creating a mudball language):
 
 http://www.infoq.com/news/2009/12/Mono-CSharp-Ex
 
 More on those tuples:
 http://tirania.org/blog/archive/2009/Dec-23.html
 Eventually it will be quite useful to have some very well designed
 multi-return support in D (like those tuples, but better).
 


 Doesn't D2 already have tuples in Phobos. D has the comma operator

 


A though on the comma operator: if the comma operator were defined to give 
a tuple type and be implicitly castable to any suffix of it's self, then 
you could get both the comma expression usage that Walter wants as well as 
all the fun things that tuple expressions give.

int i = 1, j = 2;

(i, j) = (j, i); // swap

i = (j+= i, i*2 + j); // first expression gets evaluated and dropped.

Thoughts?
Dec 29 2009
next sibling parent reply grauzone <none example.net> writes:
BCS wrote:

 Hello justme,
 

 bearophile Wrote:



 more time, thanks to Mono too. I don't like that string interpolation
 syntax because it looks unsafe, and that design of tuples can be
 improved, but they are listening to programmes (even if they risk
 creating a mudball language):

 http://www.infoq.com/news/2009/12/Mono-CSharp-Ex

 More on those tuples:
 http://tirania.org/blog/archive/2009/Dec-23.html
 Eventually it will be quite useful to have some very well designed
 multi-return support in D (like those tuples, but better).


 Doesn't D2 already have tuples in Phobos. D has the comma operator



 
 A though on the comma operator: if the comma operator were defined to 
 give a tuple type and be implicitly castable to any suffix of it's self, 
 then you could get both the comma expression usage that Walter wants as 
 well as all the fun things that tuple expressions give.
 
 int i = 1, j = 2;
 
 (i, j) = (j, i); // swap
 
 i = (j+= i, i*2 + j); // first expression gets evaluated and dropped.
 
 Thoughts?


Why not make the programmer write tuple[$-1] instead?

i = (j += i, i*2 + j)[$-1];

There's no reason to keep the current comma operator.
Dec 29 2009
parent reply BCS <none anon.com> writes:
Hello grauzone,


 BCS wrote:
 

 Hello justme,
 

 bearophile Wrote:
 


 some more time, thanks to Mono too. I don't like that string
 interpolation syntax because it looks unsafe, and that design of
 tuples can be improved, but they are listening to programmes (even
 if they risk creating a mudball language):
 
 http://www.infoq.com/news/2009/12/Mono-CSharp-Ex
 
 More on those tuples:
 http://tirania.org/blog/archive/2009/Dec-23.html
 Eventually it will be quite useful to have some very well designed
 multi-return support in D (like those tuples, but better).


 Doesn't D2 already have tuples in Phobos. D has the comma operator

 


 A though on the comma operator: if the comma operator were defined to
 give a tuple type and be implicitly castable to any suffix of it's
 self, then you could get both the comma expression usage that Walter
 wants as well as all the fun things that tuple expressions give.
 
 int i = 1, j = 2;
 
 (i, j) = (j, i); // swap
 
 i = (j+= i, i*2 + j); // first expression gets evaluated and dropped.
 
 Thoughts?
 


 Why not make the programmer write tuple[$-1] instead?
 
 i = (j += i, i*2 + j)[$-1];
 
 There's no reason to keep the current comma operator.
 


Frankly, while I have no problem with it, I'd also be fine with dumping the 
comma operator all together, even making the [$-1] thing illegal ("code has 
no effect" and all that) but Walter has time and again shot down anything 
that does away with the comma operator so I was looking at it as a way to 
have my cake and eat it to.
Dec 29 2009
parent reply "Joel C. Salomon" <joelcsalomon gmail.com> writes:
On 12/30/2009 12:38 AM, BCS wrote:

 Hello grauzone,

 Why not make the programmer write tuple[$-1] instead?

 i = (j += i, i*2 + j)[$-1];

 There's no reason to keep the current comma operator.


 
 Frankly, while I have no problem with it, I'd also be fine with dumping
 the comma operator all together, even making the [$-1] thing illegal
 ("code has no effect" and all that) but Walter has time and again shot
 down anything that does away with the comma operator so I was looking at
 it as a way to have my cake and eat it to.


Can the comma operator be given a different symbol to use?  How about,
e.g., a double comma:

auto i = 1, 2;	// tuple
auto j = 1,,2;	// sequence operator

—Joel
Dec 30 2009
parent retard <re tard.com.invalid> writes:
Wed, 30 Dec 2009 21:30:14 -0500, Joel C. Salomon wrote:


 On 12/30/2009 12:38 AM, BCS wrote:

 Hello grauzone,

 Why not make the programmer write tuple[$-1] instead?

 i = (j += i, i*2 + j)[$-1];

 There's no reason to keep the current comma operator.


 
 Frankly, while I have no problem with it, I'd also be fine with dumping
 the comma operator all together, even making the [$-1] thing illegal
 ("code has no effect" and all that) but Walter has time and again shot
 down anything that does away with the comma operator so I was looking
 at it as a way to have my cake and eat it to.


 
 Can the comma operator be given a different symbol to use?  How about,
 e.g., a double comma:
 
 auto i = 1, 2;	// tuple
 auto j = 1,,2;	// sequence operator


Wouldn't that break the C compatibility?
Dec 31 2009
prev sibling next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
BCS:

 A though on the comma operator: if the comma operator were defined to give 
 a tuple type and be implicitly castable to any suffix of it's self, then 
 you could get both the comma expression usage that Walter wants as well as 
 all the fun things that tuple expressions give.


D2 has enough warts now, so it's much better to not add some more. Languages
must be tidy, when possible. It's often better to not have a feature that
having a dirty one.

Bye,
bearophile
Dec 29 2009
parent reply grauzone <none example.net> writes:
bearophile wrote:

 BCS:

 A though on the comma operator: if the comma operator were defined to give 
 a tuple type and be implicitly castable to any suffix of it's self, then 
 you could get both the comma expression usage that Walter wants as well as 
 all the fun things that tuple expressions give.


 
 D2 has enough warts now, so it's much better to not add some more. Languages
must be tidy, when possible. It's often better to not have a feature that
having a dirty one.


I think in this case, it's more about cleaning up and polishing, than 
adding "warts".

The big danger is, that this may require incompatible language changes, 
which won't be possible anymore after D2. D3? Anyone who talks about D3 
must be kidding.


 Bye,
 bearophile
Dec 30 2009
parent reply justme <justme somewhere.net> writes:
grauzone Wrote:


 bearophile wrote:

 BCS:

 A though on the comma operator: if the comma operator were defined to give 
 a tuple type and be implicitly castable to any suffix of it's self, then 
 you could get both the comma expression usage that Walter wants as well as 
 all the fun things that tuple expressions give.


 
 D2 has enough warts now, so it's much better to not add some more. Languages
must be tidy, when possible. It's often better to not have a feature that
having a dirty one.


 
 I think in this case, it's more about cleaning up and polishing, than 
 adding "warts".
 
 The big danger is, that this may require incompatible language changes, 
 which won't be possible anymore after D2. D3? Anyone who talks about D3 
 must be kidding.


So D3 won't ever appear? At least in many open source projects the final
released is tagged one to two weeks before the final release. Distributions
have then time to repackage the release. Meanwhile, the core developers are
already enthusiastically implementing wild new features after a long feature
freeze.

It's similar kind of tick-tock as Intel has with their CPU line (1 smaller
process -> 2 improved core -> goto 1). In successful software projects they
have alpha/beta period, feature freeze, stabilization period, release, new
alpha/beta period etc. Concurrently new bugfix releases come out just like with
D. I haven't heard of new features lately so D2 must be stabilizing now.
Dec 30 2009
next sibling parent reply "Denis Koroskin" <2korden gmail.com> writes:
On Wed, 30 Dec 2009 15:41:58 +0300, justme <justme somewhere.net> wrote:


 grauzone Wrote:


 bearophile wrote:

 BCS:

 A though on the comma operator: if the comma operator were defined  




 to give

 a tuple type and be implicitly castable to any suffix of it's self,  




 then

 you could get both the comma expression usage that Walter wants as  




 well as

 all the fun things that tuple expressions give.


 D2 has enough warts now, so it's much better to not add some more.  


 Languages must be tidy, when possible. It's often better to not have a  
 feature that having a dirty one.

 I think in this case, it's more about cleaning up and polishing, than
 adding "warts".

 The big danger is, that this may require incompatible language changes,
 which won't be possible anymore after D2. D3? Anyone who talks about D3
 must be kidding.


 So D3 won't ever appear? At least in many open source projects the final  
 released is tagged one to two weeks before the final release.  
 Distributions have then time to repackage the release. Meanwhile, the  
 core developers are already enthusiastically implementing wild new  
 features after a long feature freeze.

 It's similar kind of tick-tock as Intel has with their CPU line (1  
 smaller process -> 2 improved core -> goto 1). In successful software  
 projects they have alpha/beta period, feature freeze, stabilization  
 period, release, new alpha/beta period etc. Concurrently new bugfix  
 releases come out just like with D. I haven't heard of new features  
 lately so D2 must be stabilizing now.



According to development stages you provided, D2 is currently in  
alpha/beta period. Feature freeze will follow once TDPL is released  
(around March, 2010). Stabilization and release is even further, and D3 is  
sooo far away it's hardly imagineable we will see any signs of it in a  
foreseeable future :)
Dec 30 2009
parent reply Don <nospam nospam.com> writes:
Denis Koroskin wrote:

 On Wed, 30 Dec 2009 15:41:58 +0300, justme <justme somewhere.net> wrote:
 

 grauzone Wrote:


 bearophile wrote:

 BCS:

 A though on the comma operator: if the comma operator were defined 




 to give

 a tuple type and be implicitly castable to any suffix of it's 




 self, then

 you could get both the comma expression usage that Walter wants as 




 well as

 all the fun things that tuple expressions give.


 D2 has enough warts now, so it's much better to not add some more. 


 Languages must be tidy, when possible. It's often better to not have 
 a feature that having a dirty one.

 I think in this case, it's more about cleaning up and polishing, than
 adding "warts".

 The big danger is, that this may require incompatible language changes,
 which won't be possible anymore after D2. D3? Anyone who talks about D3
 must be kidding.


 So D3 won't ever appear? At least in many open source projects the 
 final released is tagged one to two weeks before the final release. 
 Distributions have then time to repackage the release. Meanwhile, the 
 core developers are already enthusiastically implementing wild new 
 features after a long feature freeze.

 It's similar kind of tick-tock as Intel has with their CPU line (1 
 smaller process -> 2 improved core -> goto 1). In successful software 
 projects they have alpha/beta period, feature freeze, stabilization 
 period, release, new alpha/beta period etc. Concurrently new bugfix 
 releases come out just like with D. I haven't heard of new features 
 lately so D2 must be stabilizing now.


 
 
 According to development stages you provided, D2 is currently in 
 alpha/beta period. Feature freeze will follow once TDPL is released 
 (around March, 2010). Stabilization and release is even further, and D3 
 is sooo far away it's hardly imagineable we will see any signs of it in 
 a foreseeable future :)


Yes, that's about right.  Let's get an estimate about stablisation:

There are 1400 open bugs (DMD+Phobos), which are currently being fixed 
at the rate of 50/month.
Historically, new bugs have been found at the rate of 66/month.
Since D2 began, 50% of the open bugs have been D2-only. So, 50% of the 
bugs have been related to new features.
Which would suggest that even if the bug rate halves when after the 
feature freeze, it'll be about 5 years until the bug count drops to 
zero... :-(
Actually, I don't think it's that bad, since some of the most important 
structural compiler bugs have been fixed, which should greatly reduce 
the rate that new bugs are found.
Even so, I'd recommend at least two years of bug-fixes and library 
development (and toolchain issues), before we even think about more 
features.
Dec 30 2009
parent bearophile <bearophileHUGS lycos.com> writes:
Don:

 I'd recommend at least two years of bug-fixes and library 
 development (and toolchain issues), before we even think about more 
 features.


There are two other important thing that can be done in that stabilizing period:
1) find where are the D2 design mistakes and invent better ways to design the
same features.
2) Invent new ways to use D2 language (this has happened too all major
languages, for example the introduction of the many lazy features of Python3
doesn't come after design of Python2, it comes from the slow invention of new
ways to use Python, partially invented by R. Hettinger. Later some of such
ideas are being moved from the std library (itertools) to the language itself
(the built-in map and filter become lazy, etc)).

Bye,
bearophile
Dec 30 2009
prev sibling parent grauzone <none example.net> writes:
justme wrote:

 grauzone Wrote:
 

 bearophile wrote:

 BCS:

 A though on the comma operator: if the comma operator were
 defined to give a tuple type and be implicitly castable to any
 suffix of it's self, then you could get both the comma
 expression usage that Walter wants as well as all the fun
 things that tuple expressions give.


 D2 has enough warts now, so it's much better to not add some
 more. Languages must be tidy, when possible. It's often better to
 not have a feature that having a dirty one.


 I think in this case, it's more about cleaning up and polishing,
 than adding "warts".
 
 The big danger is, that this may require incompatible language
 changes, which won't be possible anymore after D2. D3? Anyone who
 talks about D3 must be kidding.




On the other hand, one could introduce "fixed tuples" as a new feature, 
that doesn't touch the old tuples. It would be annoying, but allows for 
perfect backwards compatibility.


 So D3 won't ever appear? At least in many open source projects the
 final released is tagged one to two weeks before the final release.
 Distributions have then time to repackage the release. Meanwhile, the
 core developers are already enthusiastically implementing wild new
 features after a long feature freeze.


D3 would just mean "incompatible to D2". The "final" version of D1 (dmd 
1.000) was released on Jan 2, 2007, and the first version of D2 (dmd 
2.000) on Jun 17, 2007. Can't let that happen again.

But adding features after finalization in a backward compatible way 
would be nice. Other languages can do it too, why not D?


 It's similar kind of tick-tock as Intel has with their CPU line (1
 smaller process -> 2 improved core -> goto 1). In successful software
 projects they have alpha/beta period, feature freeze, stabilization
 period, release, new alpha/beta period etc. Concurrently new bugfix
 releases come out just like with D. I haven't heard of new features
 lately so D2 must be stabilizing now.


That isn't the case. Have a look at the "New/Changed Features" section 
in the changelog: http://www.digitalmars.com/d/2.0/changelog.html
Dec 31 2009
prev sibling parent Johan Granberg <lijat.meREM OVEgmail.com> writes:
BCS wrote:


 Hello justme,
 

 bearophile Wrote:
 


 more time, thanks to Mono too. I don't like that string interpolation
 syntax because it looks unsafe, and that design of tuples can be
 improved, but they are listening to programmes (even if they risk
 creating a mudball language):
 
 http://www.infoq.com/news/2009/12/Mono-CSharp-Ex
 
 More on those tuples:
 http://tirania.org/blog/archive/2009/Dec-23.html
 Eventually it will be quite useful to have some very well designed
 multi-return support in D (like those tuples, but better).
 


 Doesn't D2 already have tuples in Phobos. D has the comma operator

 


 
 A though on the comma operator: if the comma operator were defined to give
 a tuple type and be implicitly castable to any suffix of it's self, then
 you could get both the comma expression usage that Walter wants as well as
 all the fun things that tuple expressions give.
 
 int i = 1, j = 2;
 
 (i, j) = (j, i); // swap
 
 i = (j+= i, i*2 + j); // first expression gets evaluated and dropped.
 
 Thoughts?


I have had the same idea and thinking about it I have not found any problems
with it. So I would get hapy if it was implementet. When tupples where
first introduced in D the ovious problems with them was the auto flattening
and lack of literal syntax, fixing that would probably make using tuoples
much nicer. (Allowing things like multiple return value as used in matlab)
Dec 30 2009