View mode: basic / threaded / horizontal-split · Log in · Help
September 24, 2012
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
On 9/24/12 11:23 AM, Eldar Insafutdinov wrote:
> On Monday, 24 September 2012 at 14:52:21 UTC, Steven Schveighoffer wrote:
>> Without any research or investigation, what about using a different
>> set of delimiters for tuples? Like {1,2,3}
>
> .... and exactly the syntax I was going to propose!

Assume you had this syntax working today. So instead of writing 
"tuple(a. b. c)" you write "{ a, b, c }". To what extent would your code 
be better? (Honest question. Don't forget that adding the => syntax for 
lambda /did/ make for better code.)


Andrei
September 24, 2012
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
On 9/24/12 11:29 AM, Andrei Alexandrescu wrote:
> On 9/24/12 11:23 AM, Eldar Insafutdinov wrote:
>> On Monday, 24 September 2012 at 14:52:21 UTC, Steven Schveighoffer wrote:
>>> Without any research or investigation, what about using a different
>>> set of delimiters for tuples? Like {1,2,3}
>>
>> .... and exactly the syntax I was going to propose!
>
> Assume you had this syntax working today. So instead of writing
> "tuple(a. b. c)" you write "{ a, b, c }". To what extent would your code
> be better? (Honest question. Don't forget that adding the => syntax for
> lambda /did/ make for better code.)
>
>
> Andrei

Hrm, I meant "tuple(a, b, c)".

Andrei
September 24, 2012
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
On Monday, September 24, 2012 16:00:06 David Piepgrass wrote:
> There is also no consideration in the DIP of what I consider one
> of D's most confusing "features": "pre-expanded tuples" or in
> other words, type tuples.

That's a completely separate issue. The DIP doesn't even introduce normal 
tuples into the language. It merely proposes that the comma operator be 
deprecated and uses the _possibility_ of introducing tuples into the language 
as an argument for that deprecation.

- Jonathan M Davis
September 24, 2012
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
On Mon, 24 Sep 2012 11:29:53 -0400, Andrei Alexandrescu  
<SeeWebsiteForEmail@erdani.org> wrote:

> On 9/24/12 11:23 AM, Eldar Insafutdinov wrote:
>> On Monday, 24 September 2012 at 14:52:21 UTC, Steven Schveighoffer  
>> wrote:
>>> Without any research or investigation, what about using a different
>>> set of delimiters for tuples? Like {1,2,3}
>>
>> .... and exactly the syntax I was going to propose!
>
> Assume you had this syntax working today. So instead of writing  
> "tuple(a. b. c)" you write "{ a, b, c }". To what extent would your code  
> be better? (Honest question. Don't forget that adding the => syntax for  
> lambda /did/ make for better code.)

I can't honestly say I've used either tuple(a, b, c), or tuples in other  
languages very much.

I can say that I have *avoided* tuples as return values because I don't  
want to type Tuple!(x, y) as the return type.  But I haven't come across  
that need very much.  You can say "yeah, but what about auto?"  Cases I'm  
referring to were to make interface declarations -- can't use auto.

I can similarly say I have never had need to type x, b (i.e. use the  
current comma operator), except in for statements.

I'd be fine with getting rid of comma operator and not doing tuples in the  
language, but it certainly feels weird that we have a tuple type in the  
language, without any formal type unless you alias it (as std.tuple does).

It's almost like instead of saying:

int[] x;

you had to do:

typeof([1,2]) x;

Yeah, with alias, we could arrive at:

Array!int x;

But really, it seems odd that the language has a type for something that  
doesn't have a name/syntax.  Odd, but not unworkable.

I just wanted to point out that it seems the largest trouble,  
implementation-wise, for DIP19 is the choice of parentheses to denote a  
tuple.  If we do want to add built-in tuples, maybe we should be looking  
at a different delimiter.

-Steve
September 24, 2012
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
On Mon, 24 Sep 2012 11:47:09 -0400, Steven Schveighoffer  
<schveiguy@yahoo.com> wrote:


> I can say that I have *avoided* tuples as return values because I don't  
> want to type Tuple!(x, y) as the return type.  But I haven't come across  
> that need very much.  You can say "yeah, but what about auto?"  Cases  
> I'm referring to were to make interface declarations -- can't use auto.

To further this, I would love to see something where "quick POD structs"  
can be constructed using some builtin syntax.

For example:

{valid:bool, value:int}

which would be equivalent to Tuple!(bool, "valid", int, "value")

I would *definitely* like to see that.  This might be on par with the =>  
addition.

-Steve
September 24, 2012
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
On Mon, Sep 24, 2012 at 5:24 PM, Andrei Alexandrescu
<SeeWebsiteForEmail@erdani.org> wrote:
>
> I think my main problem with this is that I'm perfectly happy with the
> baseline, which has "tuple(" as the left delimiter and ")" as the right
> delimiter.

I found it a bit long compared to other languages in the beginning,
but I've been using them heavily since you added them to Phobos and
I'm now quite happy with them. I even like the .expand thingy.


(I have a few nitpicks, about std.typecons.tuple, but those would be
the subject of another thread)


> I'd be more excited to invent notation if there was overwhelming
> or at least considerable evidence that the notation considerably helps
> certain use cases, or is very frequent. As things are, I'd be quite "meh"
> about suddenly adding lenses.

OK.

One standard use for tuples is assignment:

a,b = someTuple;  // a and b already exist in this scope
auto (c,d) = someTuple; // creates c and d

and similar variations, which Phobos' tuples do not provide.
September 24, 2012
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
If tuples are ever introduced, I hope parentheses will not be used.

I would prefer something like this:

tuple<2,1,8>
September 24, 2012
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
Caligo:

> If tuples are ever introduced, I hope parentheses will not be 
> used.
>
> I would prefer something like this:
>
> tuple<2,1,8>

That both breaks code, doesn't improve the syntax, but makes it 
worse.

Bye,
bearophile
September 24, 2012
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
On 9/24/12 11:47 AM, Steven Schveighoffer wrote:
> On Mon, 24 Sep 2012 11:29:53 -0400, Andrei Alexandrescu
> <SeeWebsiteForEmail@erdani.org> wrote:
>
>> On 9/24/12 11:23 AM, Eldar Insafutdinov wrote:
>>> On Monday, 24 September 2012 at 14:52:21 UTC, Steven Schveighoffer
>>> wrote:
>>>> Without any research or investigation, what about using a different
>>>> set of delimiters for tuples? Like {1,2,3}
>>>
>>> .... and exactly the syntax I was going to propose!
>>
>> Assume you had this syntax working today. So instead of writing
>> "tuple(a. b. c)" you write "{ a, b, c }". To what extent would your
>> code be better? (Honest question. Don't forget that adding the =>
>> syntax for lambda /did/ make for better code.)
>
> I can't honestly say I've used either tuple(a, b, c), or tuples in other
> languages very much.
>
> I can say that I have *avoided* tuples as return values because I don't
> want to type Tuple!(x, y) as the return type. But I haven't come across
> that need very much. You can say "yeah, but what about auto?" Cases I'm
> referring to were to make interface declarations -- can't use auto.

Yah, after writing DIP19 I was like, "creating tuples is nice and easy, 
but expressing function returns is less so". Besides, the comma operator 
does not hurt the syntax for types all that much.

> I just wanted to point out that it seems the largest trouble,
> implementation-wise, for DIP19 is the choice of parentheses to denote a
> tuple. If we do want to add built-in tuples, maybe we should be looking
> at a different delimiter.

Indeed. The question is what mileage we get out of it.


Andrei
September 24, 2012
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
On Sunday, September 23, 2012 16:40:34 Andrei Alexandrescu wrote:
> http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP19

My #1 concern here is that for loops do _not_ ever change how they function 
with regards to commas (which the DIP seems to do, but it also seems to imply 
that we might want to get rid of that later - which I do _not_ agree with). 
The comma operator is occasionally useful beyond for loops, but it's usually 
considered bad practice to do so, so if we want to get rid of it aside from 
for loops, then I have no problem with that. If anything, I'd argue that 
bringing tuples into the mix is muddying matters, since I think that there's a 
solid argument for deprecating the comma operator based solely on the problems 
that it causes even if we never add any other syntax which uses commas in a 
way that the comma operator prevents.

As to whether we add tuples or not, I don't know. Being able to do something 
like.

int i;
string s;

(i, s) = foo();

or

(auto i, string is) = foo();

would be useful, but I can live without it. std.typecons.tuple takes care of 
most of what you need from tuples IMHO. So, if we can find a way to cleanly add 
tuples to the language, I'm fine with that, but I'm also fine with leaving 
tuples as they are.

- Jonathan M Davis
4 5 6 7 8 9 10 11 12
Top | Discussion index | About this forum | D home