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 2012-09-24 15:05, deadalnix wrote:

> I understand your example, but in it, no (int) are involved. So no
> conversion have to be done (and you get an error).

What has that to do with anything. Example:

auto a = 3;

There's no mention of "int" in that example, yet "a" is still an int.

> You see in example above that conversion is done when int is given where
> (int) is expected or vice versa, not whenever the compiler feels to.

int b = 4;
b[0]

Why isn't that an example of where a (int) is expected? I'm no expert on 
how the compiler does semantic analyze but if it sees something like 
"b[0]" then it thinks: it's either an array, a pointer, an associate 
array, opAssign or now a tuple. Then it thinks: hey an int is implicitly 
convertible to a one element tuple, I do that.

-- 
/Jacob Carlborg
September 24, 2012
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
On 2012-09-24 17:24, Andrei Alexandrescu 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'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.

Declaring a tuple is still quire verbose can could really benefit from a 
shorter syntax.

(int, int) foo ();

Vs

import std.typecons;

Tuple!(int, int) foo (); // or what the correct syntax is

-- 
/Jacob Carlborg
September 24, 2012
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
foo(<11,2,8>, a, b)
vs
foo((11,2,8), a, b)

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

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
September 24, 2012
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
On Sunday, 23 September 2012 at 21:51:35 UTC, Nick Sabalausky
wrote:
>
> *Logically* speaking, is there really any difference between a
> one-element tuple and an ordinary single value? I don't think 
> so, and
> here's why: What is a tuple, logically speaking? Multiple 
> values being
> handled as if they were a single value. So what's a one-element 
> tuple?
> *One* value being handled as if it were one value - which is 
> *is*.
>
> Similarly, a zero-element tuple is logically equivalent to void 
> (or the
> one value a void can have: the value void, a concept which has 
> been
> argued in the past that might be useful for D, particularly in
> metaprogramming). (I admit this is a little weaker than my 
> argument
> for one-element tuples.)
>
> So perhaps zero- and one-element tuples should be implicitly
> convertible back and forth with void and ordinary non-tuple 
> values,
> respectively (polysemous values?), because that's what they 
> essentially
> are.

It's informative to look a bit at the Ocaml language:

  - no distinction between 1-tuple and single value:

     # 1;;
     - : int = 1
     # (1);;
     - : int = 1

  - "void" type is called unit and its notation is the empty 
tuple:

     # ();;
     - : unit = ()

  - for some reason tuples can't be indexed in Ocaml
September 24, 2012
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
On Mon, 24 Sep 2012 21:16:06 +0200
Jacob Carlborg <doob@me.com> wrote:

> On 2012-09-24 15:05, deadalnix wrote:
> 
> > I understand your example, but in it, no (int) are involved. So no
> > conversion have to be done (and you get an error).
> 
> What has that to do with anything. Example:
> 
> auto a = 3;
> 
> There's no mention of "int" in that example, yet "a" is still an int.
> 

Of course there is, it's the default type for the literal you have
there.

> > You see in example above that conversion is done when int is given
> > where (int) is expected or vice versa, not whenever the compiler
> > feels to.
> 
> int b = 4;
> b[0]
> 
> Why isn't that an example of where a (int) is expected?


Because 'b' is neither being assigned to an (int) nor passed into a
template/func parameter that's expecting an (int).
September 24, 2012
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
On Mon, 24 Sep 2012 16:50:47 +0200
"foobar" <foo@bar.com> wrote:

> On Monday, 24 September 2012 at 10:05:18 UTC, Nick Sabalausky 
> wrote:
> > On Mon, 24 Sep 2012 10:56:40 +0200
> > Jacob Carlborg <doob@me.com> wrote:
> >
> >> On 2012-09-24 07:01, Nick Sabalausky wrote:
> >> 
> >> > I think one of us is missing something, and I'm not entirely 
> >> > sure
> >> > who.
> >> >
> >> > As I explained (perhaps poorly), the zero- and one-element 
> >> > tuples
> >> > *would still be* tuples. They would just be implicitly 
> >> > convertible
> >> > to non-tuple form *if* needed, and vice versa. Do you see a 
> >> > reason
> >> > why that would *necessarily* not be the case?
> >> 
> >> Would that mean you could start doing things like:
> >> 
> >> int a = 3;
> >> int b = a[0];
> >> 
> >> That feels very weird.
> >> 
> >
> > No, because there's nothing typed (int) involved there. But you 
> > could do
> > this:
> >
> >     int a = 3;
> >     (int) b = a;
> >     a = b;
> >
> > Or this:
> >
> >     void foo((int) a)
> >     {
> >         int b1 = a[0];
> >         int b2 = a;
> >     }
> >     int c = 3;
> >     foo(c);
> 
> What's the point than?
> here's equivalent code without this "feature":
> 
> int a = 3;
> (int) b = (a); // explicitly make 1-tuple

My understanding is that *can't* be made to work in the general
case (without those ugly trailing commas) because, in general, how's the
compiler supposed to know if (a) is a parenthesis expression or a tuple
literal?

That's exactly what my suggestion was attempting to solve: The '(a)'
would be a paren expression (with type 'int') just as right now, but
then in order to make it still assignable to '(int)', just as you've
done, we say "Ok, you can assign an 'int' to an '(int)' and it
implicitly converts."

All the stuff I said earlier about one-element tuples being
conceptually the same as non-tuples was just my way of explaining that
it's not too much of an unintuitive inconsistency if we allow implicit
packing/unpacking of one-element tuples, but not two-or-more-element
tuples.
September 24, 2012
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
On Mon, 24 Sep 2012 15:27:19 +0200
Philippe Sigaud <philippe.sigaud@gmail.com> wrote:

> On Mon, Sep 24, 2012 at 12:46 PM, Nick Sabalausky
> <SeeWebsiteToContactMe@semitwist.com> wrote:
> 
> > That said, I'm not necessarily opposed to the strict separation if
> > we had a good candidate for built-in tuple literal syntax. But *if*
> > the best we have is parens (and maybe there *is* something better?)
> > then maybe this would be an acceptable way to achieve it?
> 
> If the problems in DIP 19 are deemed mostly syntactic (1- and 0-
> element tuples), then maybe *for once* a simple syntax change could
> solve them? I know syntax proposals are a dime a dozen in this
> newsgroup, but why not here, to avoid the ((1)) problem?
> 

I'm all for that. In fact, I was was just about to post the same
suggestion.

My bikeshed is colored one of these:

(:1,2)
(|1,2)

Minimal syntax (one extra character), no ambiguities with anything
else AFAIK. Looks kinda funny, but so did !() at first and we all got
used to that.

> For example choosing { 1, 2} to represent a tuple?

I like it, but what about zero-element tuples vs empty code blocks?
(Or is it ok because code blocks can't be used inside, or as,
expressions?)

Also, it may be too easy to accidentally get mixups between one-element
tuples and certain one-statement blocks:

{ foo(); }  // Block
vs
{ foo() } // Either a tuple or a forgotten semicolon 

Not sure if that's a big enough deal, though.

> > Ie:
> >
> > // (3) is polysemous: Either int or (int)
> > int   a = (3);  // Normal value
> > (int) b = (3);  // One-element tuple
> > auto  c = (3);  // Default to normal "int"?
> 
> For the third case, I'd say it defaults to a tuple. But then again,
> using another syntax solves this problem.
> 

My reasoning for defaulting to non-tuple was minimizing code breakage
and simplifying the handling of general expresssions that happen to
involve parens (ie, it's always a mere expression until it gets
assigned/passed-in to a tuple). But I agree, just using a syntax that's
unambiguous from the start is better.
September 24, 2012
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
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.
September 24, 2012
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
On Mon, 24 Sep 2012 12:51:18 -0400
Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:
> On 9/24/12 11:47 AM, Steven Schveighoffer wrote:
> > 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.
> 

Since the issues with current tuples tend to discourage their use (at
least for me anyway), it's hard to say without having them. Maybe it
would help to look at languages that do have good tuples and see what
kind of mileage they get out of them?
September 24, 2012
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
On 09/24/2012 11:22 PM, Nick Sabalausky wrote:
> On Mon, 24 Sep 2012 15:27:19 +0200
> Philippe Sigaud <philippe.sigaud@gmail.com> wrote:
>
>> On Mon, Sep 24, 2012 at 12:46 PM, Nick Sabalausky
>> <SeeWebsiteToContactMe@semitwist.com> wrote:
>>
>>> That said, I'm not necessarily opposed to the strict separation if
>>> we had a good candidate for built-in tuple literal syntax. But *if*
>>> the best we have is parens (and maybe there *is* something better?)
>>> then maybe this would be an acceptable way to achieve it?
>>
>> If the problems in DIP 19 are deemed mostly syntactic (1- and 0-
>> element tuples), then maybe *for once* a simple syntax change could
>> solve them? I know syntax proposals are a dime a dozen in this
>> newsgroup, but why not here, to avoid the ((1)) problem?
>>
>
> I'm all for that. In fact, I was was just about to post the same
> suggestion.
>
> 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, while still addressing
unpacking in the locations bearophile has designated.


> Minimal syntax (one extra character), no ambiguities with anything
> else AFAIK. Looks kinda funny, but so did !() at first and we all got
> used to that.
>
>> For example choosing { 1, 2} to represent a tuple?
>
> I like it, but what about zero-element tuples vs empty code blocks?
> (Or is it ok because code blocks can't be used inside, or as,
> expressions?)
>
> Also, it may be too easy to accidentally get mixups between one-element
> tuples and certain one-statement blocks:
>
> { foo(); }  // Block
> vs
> { foo() } // Either a tuple or a forgotten semicolon
>
> Not sure if that's a big enough deal, though.
> ...

q(foo())
5 6 7 8 9 10 11 12 13
Top | Discussion index | About this forum | D home