View mode: basic / threaded / horizontal-split · Log in · Help
December 30, 2009
Re: Comma expression as tuple operator [was Tuples, C#, Java, language design]
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
December 30, 2009
Re: Comma expression as tuple operator [was Tuples, C#, Java, language
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.
December 30, 2009
Re: Comma expression as tuple operator [was Tuples, C#, Java, language design]
BCS wrote:

> Hello justme,
> 
>> bearophile Wrote:
>> 
>>> C# will probably not follow the route of stagnation of Java for 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
>> which C# doesn't so such syntax is not possible in D, me thinks.
>> 
> 
> 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)
December 30, 2009
Re: Comma expression as tuple operator [was Tuples, C#, Java, language
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 :)
December 30, 2009
Re: Comma expression as tuple operator [was Tuples, C#, Java, language
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.
December 30, 2009
Re: Comma expression as tuple operator [was Tuples, C#, Java, language
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
December 31, 2009
Re: Comma expression as tuple operator [was Tuples, C#, Java, languagedesign]
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
December 31, 2009
Re: Comma expression as tuple operator [was Tuples, C#, Java, languagedesign]
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?
December 31, 2009
Re: Comma expression as tuple operator [was Tuples, C#, Java, language
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
Next ›   Last »
1 2
Top | Discussion index | About this forum | D home