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.

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

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

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.
>

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

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

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.

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.

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

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