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 09/24/2012 09:50 PM, Caligo wrote:
> On Mon, Sep 24, 2012 at 11:37 AM, bearophile <bearophileHUGS@lycos.com> wrote:
>>
>> That both breaks code, doesn't improve the syntax, but makes it worse.
>>
>> Bye,
>> bearophile
>
> foo(<11,2,8>, a, b)
> vs
> foo((11,2,8), a, b)
>

I don't spot a significant difference.

> Parentheses are everywhere in D.  Sometimes it looks like Lisp.
>

Lisp is beautiful.
September 24, 2012
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
Timon Gehr:

>> My bikeshed is colored one of these:
>>
>> (:1,2)
>> (|1,2)
>>
>
> At that point you might as well just use
>
> import std.typecons : q = tuple, Q = Tuple;
>
> Q!(int, int) foo(){
>     return q(1, 2);
> }
>
> If built-in tuples are not going to look like
>
> (1, 2)
>
> then imho we might as well leave them out,

But the banana syntax doesn't look bad:

(||)
(|1|)
(|1, 2|)
(|1, 2, 3|)

It's short enough, it's not visually noisy, it's simple enough to
type, it consistently avoids the problems with literals for
0-tuples and 1-tuples, and it's sufficiently intuitive once you
have seen it one time. It's just a bit longer to type than the
syntax with simple (), that has problems with the shorter tuples.

The now dead Fortress language used several similar syntaxes,
like (|...|), {|...|}, [|...|], etc.

Bye,
bearophile
September 24, 2012
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
On Mon, 24 Sep 2012 21:50:34 +0200, Caligo <iteronvexor@gmail.com> wrote:

> foo(<11,2,8>, a, b)
> vs
> foo((11,2,8), a, b)
>
> Parentheses are everywhere in D.  Sometimes it looks like Lisp.

And <> is ambiguous, ugly, an affront before Walter, and an abomination  
born
in the fiery depths of hell. Can we please just leave it behind?

-- 
Simen
September 24, 2012
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
On 09/25/2012 12:28 AM, bearophile wrote:
> Timon Gehr:
>
>>> My bikeshed is colored one of these:
>>>
>>> (:1,2)
>>> (|1,2)
>>>
>>
>> At that point you might as well just use
>>
>> import std.typecons : q = tuple, Q = Tuple;
>>
>> Q!(int, int) foo(){
>>     return q(1, 2);
>> }
>>
>> If built-in tuples are not going to look like
>>
>> (1, 2)
>>
>> then imho we might as well leave them out,
>
> But the banana syntax doesn't look bad:
>
> (||)
> (|1|)
> (|1, 2|)
> (|1, 2, 3|)
>
> It's short enough,

It's not shorter than q()

> it's not visually noisy,

It adds more noise than q()

> it's simple enough to type,

It is harder to type than q().

> it consistently avoids the problems with literals for
> 0-tuples and 1-tuples, and it's sufficiently intuitive once you
> have seen it one time.  It's just a bit longer to type than the
> syntax with simple (), that has problems with the shorter tuples.
>

I still think any built-in special syntax that differs from (1,2,3) is
not worth it.

> The now dead Fortress language used several similar syntaxes,
> like (|...|), {|...|}, [|...|], etc.
>
September 24, 2012
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
On 9/24/12 6:28 PM, bearophile wrote:
> Timon Gehr:
>
>>> My bikeshed is colored one of these:
>>>
>>> (:1,2)
>>> (|1,2)
>>>
>>
>> At that point you might as well just use
>>
>> import std.typecons : q = tuple, Q = Tuple;
>>
>> Q!(int, int) foo(){
>> return q(1, 2);
>> }
>>
>> If built-in tuples are not going to look like
>>
>> (1, 2)
>>
>> then imho we might as well leave them out,
>
> But the banana syntax doesn't look bad:
>
> (||)
> (|1|)
> (|1, 2|)
> (|1, 2, 3|)

tuple()
tuple(1)
tuple(1, 2)
tuple(1, 2, 3)

also arguably enjoys the same advantages and in fact is much more 
intuitive. Like, totally intuitive. Like, it says "tuple" to create a 
tuple. And one advantage is, there's never ever going to be butt jokes 
about tuple() as there'd be with "(||)".

> It's short enough, it's not visually noisy, it's simple enough to
> type, it consistently avoids the problems with literals for
> 0-tuples and 1-tuples, and it's sufficiently intuitive once you
> have seen it one time. It's just a bit longer to type than the
> syntax with simple (), that has problems with the shorter tuples.
>
> The now dead Fortress language used several similar syntaxes,
> like (|...|), {|...|}, [|...|], etc.

Well let's not take inspiration from dead languages :o).


Andrei
September 24, 2012
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
On Mon, 24 Sep 2012 17:31:27 -0400, Nick Sabalausky  
<SeeWebsiteToContactMe@semitwist.com> wrote:

> On Mon, 24 Sep 2012 10:53:14 -0400
> "Steven Schveighoffer" <schveiguy@yahoo.com> wrote:
>>
>> (int[]) x;
>>
>> int a = x.length;
>>
>> is a == 0 or 1?
>>
>
> It'd be 1, but I agree that's a pretty solid counter-argument.
>

It would be if it were valid code :)  d complains (and rightly so) that  
you can't use C-style casts anymore!

This is what I really meant:

int[] x;
int a = (x).length;

But I think you got the point.

However, this brings up another issue, what about porting C code?  All of  
a sudden c style casts are no loner errors, but are type tuples!

-Steve
September 24, 2012
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
On 9/25/12, Steven Schveighoffer <schveiguy@yahoo.com> wrote:
> However, this brings up another issue, what about porting C code?  All of
> a sudden c style casts are no loner errors, but are type tuples!

I think they're still errors:

int x = (int)foo;

Maybe the compiler could figure out if a cast was attempted rather
than a tuple, and could print out the ol' "Can't use C shenanigans in
D" error.
September 25, 2012
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
What would a special case where the first level of tuple (with 
higher levels being tuples in tuples) didn't require parens 
break? This would be a beautiful syntax:

auto a = 1, 2; // A tuple of two ints

int, string fun(double, double d) {
    return cast(int) (d[0] * d[1]), "hello";
}

auto a, b = 1, 2; // Two ints
auto a = fun(1.0, 1.0); // Tuple of 1 and "hello".
auto a, b = fun(1.0, 1.0); // An int and a string.
September 25, 2012
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
On 2012-09-24 22:45, Nick Sabalausky wrote:

> Because 'b' is neither being assigned to an (int) nor passed into a
> template/func parameter that's expecting an (int).

Either I'm just stupid or I've failed completely to understand "implicit 
convertible to".

Another example:

struct Foo
{
    int[] arr;
    alias arr this;
}

void main ()
{
    auto foo = Foo([3, 4]);
    auto i = foo[0];
}

Have a look at the last line. In that line "foo" is implicitly converted 
to "int[]" with the help of the "alias this" in Foo, because the context 
requires something "indexable". Since you cannot index a struct the 
implicit conversion kicks in. What's the difference?

-- 
/Jacob Carlborg
September 25, 2012
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
On 2012-09-25 03:19, ixid wrote:
> What would a special case where the first level of tuple (with higher
> levels being tuples in tuples) didn't require parens break? This would
> be a beautiful syntax:
>
> auto a = 1, 2; // A tuple of two ints
>
> int, string fun(double, double d) {
>      return cast(int) (d[0] * d[1]), "hello";
> }
>
> auto a, b = 1, 2; // Two ints
> auto a = fun(1.0, 1.0); // Tuple of 1 and "hello".
> auto a, b = fun(1.0, 1.0); // An int and a string.
>

I like this one.

-- 
/Jacob Carlborg
6 7 8 9 10 11 12 13 14
Top | Discussion index | About this forum | D home