Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
On 09/23/2012 04:40 PM, Andrei Alexandrescu wrote: I discussed this with Walter, and we concluded that we could deprecate the comma operator if it helps tuples. So I started with this: http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP19 Unfortunately, I started much cockier than I ended. The analysis in there fails to construct a case even half strong that deprecating the comma operator could significantly help tuples. Well it essentially concludes that tuples are mostly fine as they are, and attempts to embellish them syntactically are marred with unexpected problems. Nevertheless, I sure have missed aspects all over, so contributions are appreciated. Thanks, Andrei Might some of the ambiguity be reduced by defining special tokens for dereferencing tuple elements? (int[]) a = ([1,2,3]); assert(a[0] == 1); assert(a[[0]] == [1,2,3]); I suspect that this would allow us to indulge in the attractive notion of single-element tuples. Would the addition of such a token be considered heresy?
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
On 09/24/2012 11:55 AM, Caligo wrote: If tuples are ever introduced, I hope parentheses will not be used. I would prefer something like this: tuple<2,1,8> Not using parentheses: a possibly valid idea! Using angle brackets: never going to happen. People HATE angle brackets. There is extremely good justification for this hatred, because C++ already stepped on that landmine and suffered dearly for it. If you were to use angle brackets, then I would try to do this: tupleb,c> d Which way should this be parsed? It might be a value tuple of type or it might be a declaration: d is of type It is very easy to create cases with angle brackets that are syntactically ambiguous and make it impossible to parse code as a context-free-grammar. It is harder, but probably possible, to create cases where such a syntax is also completely ambiguous semantically too.
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
On Sunday, 23 September 2012 at 20:39:38 UTC, Andrei Alexandrescu
wrote:
I discussed this with Walter, and we concluded that we could
deprecate the comma operator if it helps tuples. So I started
with this:
http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP19
Unfortunately, I started much cockier than I ended. The
analysis in there fails to construct a case even half strong
that deprecating the comma operator could significantly help
tuples. Well it essentially concludes that tuples are mostly
fine as they are, and attempts to embellish them syntactically
are marred with unexpected problems. Nevertheless, I sure have
missed aspects all over, so contributions are appreciated.
Thanks,
Andrei
With removed comma operator from D next code will work?
module maybe;
import std.stdio;
import std.algorithm;
R With(I, R)(I o, R function (I) fun)
{
return o is null ? null : fun(o);
}
R Return(I, R)(I o, R function (I) fun, R failureResult)
{
return o is null ? failureResult : fun(o);
}
I If(I)(I o, bool function (I) fun)
{
return o is null ? null : fun(o) ? o : null;
}
I Unless(I)(I o, bool function (I) fun)
{
return o is null ? null : fun(o) ? null : o;
}
I Do(I)(I o, void function (I) fun)
{
return o is null ? null : fun(o), o;
}
void doit(string value)
{
writeln("Loading... \n");
}
void main()
{
string name = "D";
name = name.With((string x) => "Hello, " ~ x ~ "!").
If((string x) => canFind(x, "D")).
Do((string x) => x.doit).
Return((string x) => x ~ " I love You!", "Oh,
my!");
writeln(name);
}
especially template function
I Do(I)(I o, void function (I) fun)
{
return o is null ? null : fun(o), o;
}
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
On 2012-09-28 19:09, deadalnix wrote: It is ambiguous with the comma declaration syntax. I could live without it. -- /Jacob Carlborg
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
Le 27/09/2012 08:17, Jacob Carlborg a écrit : On 2012-09-27 00:38, bearophile wrote: I have appreciated named fields of D tuples since the beginning, I have found them quite handy. With them sometimes you don't need to unpack a tuple, you can just access its fields with a nice name, avoiding to move around more than one variable. If you could do something like this: auto x, y = tuple(1, 2); Wouldn't that be an acceptable solution instead? It is ambiguous with the comma declaration syntax.
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
Le 27/09/2012 00:38, bearophile a écrit : Jonathan M Davis: It sounds to me like the reason that structural typing is needed is because Tuple allows you to name its fields, which I've always thought was a bad idea, I have appreciated named fields of D tuples since the beginning, I have found them quite handy. With them sometimes you don't need to unpack a tuple, you can just access its fields with a nice name, avoiding to move around more than one variable. What is the benefit over a struct ?
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
int a, int b = 3, 3;
Considering how the syntax is defined, this will not do what
you expect, and it is not fixable easily without breaking other
constructs.
I thought we'd already covered that part, that was what I agreed
would break far too much code. That is not the heart of the
suggestion though and is why I moved on to the same assignment
syntax others were talking about using parens.
(int a, int b) = 3, 3;
or
(int a, int b) = (3, 3);
The parts, which perhaps your answer covers the issues with and I
did not understand, that seem elegant that I was asking about
were these:
int, string a = 1, "hello";
int, string foo(double, double a) {
return cast(int) (d[0] * d[1]), "hello";
}
Tuple assignment to a tuple allowing the omission of the first
level of brackets and multiple return type functions doing the
same, at present these would be unambiguous errors as far as I'm
aware. Especially with functions it seems a lot clearer to me and
as we don't allow functions to do:
void fun(int a, b, c) {
//Stuff
}
To make a, b and c ints then we have the freedom to do multiple
types separated by commas:
void fun(int, string a) {
}
A syntax like this:
(int, string) fun((double, double) a) {
return (cast(int) (d[0] * d[1]), "hello");
}
Is a lot messier and gets overloaded with parens.
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
Le 28/09/2012 00:39, ixid a écrit :
int, string a = 1, "hello";
int, string foo(double, double a) {
return cast(int) (d[0] * d[1]), "hello";
}
This is incompatible with current language specs (or will ends up with
highly bizantine rules do define what to do, in a topic where it is
already complex).
Which parts exactly are Byzantine and why? I'm not arguing, just
interested to know as this is the part that seems most desirable to me.
int a, int b = 3, 3;
Considering how the syntax is defined, this will not do what you expect,
and it is not fixable easily without breaking other constructs.
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
int, string a = 1, "hello";
int, string foo(double, double a) {
return cast(int) (d[0] * d[1]), "hello";
}
This is incompatible with current language specs (or will ends
up with highly bizantine rules do define what to do, in a topic
where it is already complex).
Which parts exactly are Byzantine and why? I'm not arguing, just
interested to know as this is the part that seems most desirable
to me.
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
On Wednesday, 26 September 2012 at 12:20:56 UTC, Dmitry Olshansky
wrote:
On 25-Sep-12 23:29, kenji hara wrote:
My suggestion is very simple.
1. Change all words "built-in tuple" in the documentation to
"built-in
sequence". Then, in the D language world, we can have clarify
name for
the built-in one.
2. Introduce new templates, Seq, TypeSeq, and ExpSeq.
template Seq(T...) { alias T Seq; }// identical with
std.typetuple.TypeTuple
template TypeSeq(T...) if (allSatisfy!(isType, T)) { alias
T TypeSeq; }
template ExpSeq(T...) if (allSatisfy!(isExpression, T)) {
alias T ExpSeq; }
If you really want to a sequence with heterogeneous
elements, use
Seq template. Otherwise use TypeSeq or ExpSeq based on your
purpose.
vote++;
vote++.
(This is also what would be in my never finished std.meta
proposal – interesting how we seem to converge towards the same
solutions in the metaprogramming space…)
David
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
On Thursday, 27 September 2012 at 10:58:12 UTC, Jonathan M Davis wrote: On Thursday, September 27, 2012 11:37:10 foobar wrote: I do _not_ want to consider two different _structs_ (nominal types) as the same type. I would like to get correct tuple semantics which means _structural_ typing (I thought I emphasized that enough in the OP). A tuple is defined by its contained types, *not* its name. What on earth does structural typing get you here? A tuple is a collection of values of varying types. If you have Tuple!(X, Y, Z), it defines a tuple containing the types X, Y, and Z. _All_ tuples with those types will be Tuple! (X, Y, Z). The _only_ reason that this isn't quite the case is the nonsense with being able to give names to the fields in a tuple (and adding an alias this to Tuple should be able to fix that). Being able to create your own tuple type which you can compare with Tuple simply because it happens to hold the same types is completely pointless as far as I can tell (but you can still do it if you really want to). If you want a tuple, then just use std.typecons.Tuple. Creating another tuple type buys you nothing. - Jonathan M Davis std.typecons.Tuple *is* a struct. I agree with the above definition of tuples, but I want the language to ensure that which at the moment it can't.
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
On Wed, 26 Sep 2012 15:54:44 -0400, foobar wrote:
On Tuesday, 25 September 2012 at 21:02:49 UTC, Andrei Alexandrescu wrote:
I agree. That's why I want to take the minimum amount of steps to make
library tuples work. That minimum amount may be 1, i.e. just implement
deconstruction.
Andrei
Library tuples have broken semantics.
Tuples supposed to have _structural_ typing which AFAIK can only be
correctly implemented in language.
import std.typecons.TypeTuple;
struct MyTuple(T...)() {}
auto libTup = tuple(123, "hello");
MyTuple myTup = libTup; // broken
This is broken cause structs in D are nominally typed and even though
both pack the same inner-types, they are not equal.
The problem with the lib solution is the confusion and broken semantics,
_not_ the "tuple()" syntax. Sure, it's long and annoying to type for a
[should be] common construct, but tuple *is* clear and readable, as you
pointed out yourself. So syntax wise, I'm fine with both tuple(...) and
a shorter syntax with some sort of parens-like character. But please,
let's get at least the semantics absolutely right.
I don't have a good suggestion how to fix this with no or minimal code
breakage, but I don't thing that adding broken features the the mix
helps any.
I'm not exactly sure what this is supposed to be (your struct I don't
think is implemented correctly), but are you asking to be able to assign a
struct from a tuple?
Shouldn't tupleof help here?
-Steve
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
On Thursday, September 27, 2012 11:37:10 foobar wrote: > I do _not_ want to consider two different _structs_ (nominal > types) as the same type. I would like to get correct tuple > semantics which means _structural_ typing (I thought I emphasized > that enough in the OP). > A tuple is defined by its contained types, *not* its name. What on earth does structural typing get you here? A tuple is a collection of values of varying types. If you have Tuple!(X, Y, Z), it defines a tuple containing the types X, Y, and Z. _All_ tuples with those types will be Tuple! (X, Y, Z). The _only_ reason that this isn't quite the case is the nonsense with being able to give names to the fields in a tuple (and adding an alias this to Tuple should be able to fix that). Being able to create your own tuple type which you can compare with Tuple simply because it happens to hold the same types is completely pointless as far as I can tell (but you can still do it if you really want to). If you want a tuple, then just use std.typecons.Tuple. Creating another tuple type buys you nothing. - Jonathan M Davis
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
On Wednesday, 26 September 2012 at 23:02:45 UTC, Piotr Szturmaj wrote: Jonathan M Davis wrote: It sounds to me like the reason that structural typing is needed is because Tuple allows you to name its fields, which I've always thought was a bad idea, and which a built-in tuple definitely wouldn't do. If you couldn't name its fields, then any Tuple containing the same sequence of types would be the same type. So, the problem is caused by a feature that built-in tuples wouldn't even have. Exactly my PoV. I think that "tuples with named fields" should be anonymous structs and pure tuples shouldn't have named fields. I agree. Tuples do *not* have field names. (I'm also not sure they should support slicing either). structural compound types with field names are called "records" in FP and they are a completely separate concept from tuples. We really should not conflate the two and I agree that nameless structs are the perfect vehicle to support record types. One of D's strongest design decisions was to separate structs from classes which is a huge win. Why do we want to go back on that with regards to this very similar use case?
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
On Wednesday, 26 September 2012 at 21:31:13 UTC, Jonathan M Davis
wrote:
On Wednesday, September 26, 2012 21:54:44 foobar wrote:
Library tuples have broken semantics.
Tuples supposed to have _structural_ typing which AFAIK can
only
be correctly implemented in language.
import std.typecons.TypeTuple;
struct MyTuple(T...)() {}
auto libTup = tuple(123, "hello");
MyTuple myTup = libTup; // broken
This is broken cause structs in D are nominally typed and even
though both pack the same inner-types, they are not equal.
Of course, they're not equal. One is a Tuple and one is a
MyTuple. Why on
earth would you expect them to be considered equal? Just use
Tuple. And it's
not like you'd be using MyTuple if tuples were built-in. You'd
just use the
built-in tuples. So, this really makes no sense to me at all.
- Jonathan M Davis
I do _not_ want to consider two different _structs_ (nominal
types) as the same type. I would like to get correct tuple
semantics which means _structural_ typing (I thought I emphasized
that enough in the OP).
A tuple is defined by its contained types, *not* its name.
D is a systems language - there are at least half a dozen posts
on this NG where people implemented their own runtime/standard
libraries for their own purposes. There is at least one OS kernel
project that I know of written in D, also with its own
specialized libs. And of course we should not forget the embedded
hardware space. All provide ample opportunity for exactly the
same scenario as in my example - provide a competing, non
compatible, tuple implementations and voilà, you just got an
incompatibility in the language.
Two ways to prevent this,
1. add support in D in order to allow defining a library tuple
type _with_ _correct_ _structural_ typing.
2. make tuples a language construct.
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
On 2012-09-27 00:38, bearophile wrote: I have appreciated named fields of D tuples since the beginning, I have found them quite handy. With them sometimes you don't need to unpack a tuple, you can just access its fields with a nice name, avoiding to move around more than one variable. If you could do something like this: auto x, y = tuple(1, 2); Wouldn't that be an acceptable solution instead? -- /Jacob Carlborg
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
Jonathan M Davis wrote: It sounds to me like the reason that structural typing is needed is because Tuple allows you to name its fields, which I've always thought was a bad idea, and which a built-in tuple definitely wouldn't do. If you couldn't name its fields, then any Tuple containing the same sequence of types would be the same type. So, the problem is caused by a feature that built-in tuples wouldn't even have. Exactly my PoV. I think that "tuples with named fields" should be anonymous structs and pure tuples shouldn't have named fields.
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
I have appreciated named fields of D tuples since the beginning, I have found them quite handy. With them sometimes you don't need to unpack a tuple, you can just access its fields with a nice name, avoiding to move around more than one variable. In Haskell to solve this problem there is the @ syntax for tuples. As an example usage, this Haskell function vNorm normalizes a Vec (a 2D vector). Its input is a Vec, that is unpacked in its x and y fields, but vNorm al gives a name to the whole input Vec, naming it 'v'. So you are able to call the other function vLen with no need to pack again x and y in a Vec: vLen :: Vec -> Double vLen x = sqrt $ vDot x x vNorm :: Vec -> Vec vNorm v@(Vec x y) = Vec (x / l) (y / l) where l = vLen v (In my first post in this thread I have not listed such extra features for tuples because I think they are less important than a good unpacking syntax in those four cases.) Bye, bearophile
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
Jonathan M Davis:
It sounds to me like the reason that structural typing is
needed is because
Tuple allows you to name its fields, which I've always thought
was a bad idea,
I have appreciated named fields of D tuples since the beginning,
I have found them quite handy. With them sometimes you don't need
to unpack a tuple, you can just access its fields with a nice
name, avoiding to move around more than one variable.
In Python there are build-in tuples, and there is a
library-defined tuple type that supports names for its fields, it
even contains its name, so when you print one of them, it's able
to offer a nice textual representation:
from collections import namedtuple
Point = namedtuple('Point', 'x y')
Point(5, 10)
Point(x=5, y=10)
Bye,
bearophile
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
On Thursday, September 27, 2012 00:05:41 bearophile wrote:
> Jonathan M Davis:
> > So, this really makes no sense to me at all.
>
> I agree that foobar examples aren't so good. But it's true that
> Tuple() gives some troubles regarding missed structural typing:
>
>
> import std.stdio, std.typecons;
> alias Tuple!(float, float) T1;
> alias Tuple!(float,"x", float,"y") T2;
> void foo1(T1 t) {}
> void foo2(T2 t) {}
> void main() {
> auto p1 = T1(1, 2);
> auto p2 = T2(1, 2);
> p1 = p2; // no error
> p2 = p1; // no error
> T1[] a1;
> T2[] a2;
> a1 = a2; // error
> a2 = a1; // error
> foo1(p2); // error
> foo2(p1); // error
> }
>
>
> Generally I think "p1 = p2;" is OK, while "p2 = p1;" is not so
> good, because T2 is more specialized.
>
> There are several other more or less similar things related to
> structural typing of tuples that a well implemented built-in
> tuple type will need to address. In Bugzilla there are some open
> bug reports on similar matters. Fixing them with the library
> defined tuples is hard. Of course a possible solution is to
> improve the D language to allow the programmer to specify very
> good struct-based tuples in library code, I think but doing this
> is more complex than implementing good built-in tuples.
It sounds to me like the reason that structural typing is needed is because
Tuple allows you to name its fields, which I've always thought was a bad idea,
and which a built-in tuple definitely wouldn't do. If you couldn't name its
fields, then any Tuple containing the same sequence of types would be the same
type. So, the problem is caused by a feature that built-in tuples wouldn't
even have.
- Jonathan M Davis
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
Jonathan M Davis:
So, this really makes no sense to me at all.
I agree that foobar examples aren't so good. But it's true that
Tuple() gives some troubles regarding missed structural typing:
import std.stdio, std.typecons;
alias Tuple!(float, float) T1;
alias Tuple!(float,"x", float,"y") T2;
void foo1(T1 t) {}
void foo2(T2 t) {}
void main() {
auto p1 = T1(1, 2);
auto p2 = T2(1, 2);
p1 = p2; // no error
p2 = p1; // no error
T1[] a1;
T2[] a2;
a1 = a2; // error
a2 = a1; // error
foo1(p2); // error
foo2(p1); // error
}
Generally I think "p1 = p2;" is OK, while "p2 = p1;" is not so
good, because T2 is more specialized.
There are several other more or less similar things related to
structural typing of tuples that a well implemented built-in
tuple type will need to address. In Bugzilla there are some open
bug reports on similar matters. Fixing them with the library
defined tuples is hard. Of course a possible solution is to
improve the D language to allow the programmer to specify very
good struct-based tuples in library code, I think but doing this
is more complex than implementing good built-in tuples.
Bye,
bearophile
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
On Wednesday, September 26, 2012 21:54:44 foobar wrote:
> Library tuples have broken semantics.
> Tuples supposed to have _structural_ typing which AFAIK can only
> be correctly implemented in language.
>
> import std.typecons.TypeTuple;
>
> struct MyTuple(T...)() {}
>
> auto libTup = tuple(123, "hello");
> MyTuple myTup = libTup; // broken
>
> This is broken cause structs in D are nominally typed and even
> though both pack the same inner-types, they are not equal.
Of course, they're not equal. One is a Tuple and one is a MyTuple. Why on
earth would you expect them to be considered equal? Just use Tuple. And it's
not like you'd be using MyTuple if tuples were built-in. You'd just use the
built-in tuples. So, this really makes no sense to me at all.
- Jonathan M Davis
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
On Tuesday, 25 September 2012 at 21:02:49 UTC, Andrei
Alexandrescu wrote:
I agree. That's why I want to take the minimum amount of steps
to make library tuples work. That minimum amount may be 1, i.e.
just implement deconstruction.
Andrei
Library tuples have broken semantics.
Tuples supposed to have _structural_ typing which AFAIK can only
be correctly implemented in language.
import std.typecons.TypeTuple;
struct MyTuple(T...)() {}
auto libTup = tuple(123, "hello");
MyTuple myTup = libTup; // broken
This is broken cause structs in D are nominally typed and even
though both pack the same inner-types, they are not equal.
The problem with the lib solution is the confusion and broken
semantics, _not_ the "tuple()" syntax. Sure, it's long and
annoying to type for a [should be] common construct, but tuple
*is* clear and readable, as you pointed out yourself. So syntax
wise, I'm fine with both tuple(...) and a shorter syntax with
some sort of parens-like character. But please, let's get at
least the semantics absolutely right.
I don't have a good suggestion how to fix this with no or minimal
code breakage, but I don't thing that adding broken features the
the mix helps any.
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
Also, I want to add that type declarations should be changed from statements to expressions so that we could do: auto tup = (3, "hello"); (int num, string s) = tup; // num == 3, s == "hello" +1. or int num; string s; auto tup = (3, "hello"); (num, s) = tup; or like x++ containers http://msdn.microsoft.com/en-us/library/aa874816.aspx auto tup = [3, "hello"]; [num, s] = tup; In general it's very useful.
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
On 25-Sep-12 23:29, kenji hara wrote:
My suggestion is very simple.
1. Change all words "built-in tuple" in the documentation to "built-in
sequence". Then, in the D language world, we can have clarify name for
the built-in one.
2. Introduce new templates, Seq, TypeSeq, and ExpSeq.
template Seq(T...) { alias T Seq; }// identical with
std.typetuple.TypeTuple
template TypeSeq(T...) if (allSatisfy!(isType, T)) { alias T TypeSeq; }
template ExpSeq(T...) if (allSatisfy!(isExpression, T)) { alias T ExpSeq; }
If you really want to a sequence with heterogeneous elements, use
Seq template. Otherwise use TypeSeq or ExpSeq based on your purpose.
vote++;
--
Dmitry Olshansky
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
Le 25/09/2012 23:34, ixid a écrit :
You've shown it's clearly incompatible with the current language
and would break lots of code. What would it break if assignment
required explicit tuple brackets?
(int a, b) = foo(); // A tuple assignment, 'a' and 'b' will be
filled in order by the multiple return values of foo()
int foo() {
return 1;
}
(int a, b) = foo(); // Also valid and only sets 'a'
int, int foo() {
return 1, 2;
}
int a = foo(); // Also valid and 'a' takes the first tuple value
(int a, auto b) = foo(); // Evaluated left to right so 'a' will
take the first argument of foo and b will auto to a type or tuple
of what remains. It will error if there is nothing remaining for
b. This would still allow the clean expression of stand-alone
tuples and function arguments and return values.
This does not exist according to current language specs, so it is up to
us to decide if it works and how.
int, string a = 1, "hello";
int, string foo(double, double a) {
return cast(int) (d[0] * d[1]), "hello";
}
This is incompatible with current language specs (or will ends up with
highly bizantine rules do define what to do, in a topic where it is
already complex).
Doesn't the needs of bracketing to determine order operation,
(stuff) more or less imply that implicit conversion between one
member tuples and the type of that tuple member is a requirement?
Or would the (stuff, ) syntax be better?
I don't know.
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
Le 25/09/2012 22:55, Nick Sabalausky a écrit : On Tue, 25 Sep 2012 12:07:33 +0200 deadalnix wrote: Le 25/09/2012 09:11, Jacob Carlborg a écrit : On 2012-09-25 00:28, bearophile wrote: (||) (|1|) (|1, 2|) (|1, 2, 3|) What about: || |1| |1, 2| Yeah and why not þ1, 2þ or ŀ1, 2ŀ ? maybe ↓1, 2↓ is better ? or « 1, 2 » (this one at least is readable). | is easily typed. þ, ŀ, ↓ and « I had to copy-paste. My post was ironic. It isn't hard to come up with new characters but is it really useful ?
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
On 09/25/2012 09:29 PM, kenji hara wrote:
2012/9/26 Jonathan M Davis :
On Tuesday, September 25, 2012 13:45:50 Michel Fortin wrote:
On 2012-09-25 16:38:31 +, "Jonathan M Davis" said:
On Tuesday, September 25, 2012 12:28:15 Michel Fortin wrote:
Although to make things less confusing, I think the built-in language
tuple should give up its name. It could become a "sequence". Renaming
the built-in one would certainly be less trouble, as code doesn't refer
to it by its name, and you can pick a name that fits better with its
auto-expanding behaviour.
Not referred to by its name? It's refereed to as TypeTuple all over the
place. It's arguably a bad name, but it would break a _lot_ of code to
change it now.
TypeTuple is only a construct allowing you to create a built-in
language tuple, one that does not necessarily match the definition of a
TypeTuple. The language spec defines a Tuples, TypeTuples, and
ExpressionTuples with these words (ironically, using the word
"sequence" twice):
"""
If the last template parameter in the TemplateParameterList is declared
as a TemplateTupleParameter, it is a match with any trailing template
arguments. The sequence of arguments form a Tuple. A Tuple is not a
type, an expression, or a symbol. It is a sequence of any mix of types,
expressions or symbols.
A Tuple whose elements consist entirely of types is called a TypeTuple.
A Tuple whose elements consist entirely of expressions is called an
ExpressionTuple.
"""
Source: http://dlang.org/template.html
I wasn't aware of that being in the language definition, but it doesn't change
the fact that they're used and referred to in code as TypeTuple, and renaming
that would break a lot of code. And it _is_ used for the built-in tuple type,
regardless of whether the spec considers the terms type tuple and expression
tuple to refer to distinct entities. Rename the stuff in the spec to whatever
you like, but the library uses the term TypeTuple, so it _is_ used in code.
- Jonathan M Davis
I like current design - open (built-in, automatically flattened, and
*unpacked*) tuple, and closed (library, be structured, and *packed*)
tuple.
But, the two are often confused, by the word "tuple". It has
introduced badly confusion in many discussions.
To make matters worse, it had often invoked incorrect suggestion that
merging the two into one.
My suggestion is very simple.
1. Change all words "built-in tuple" in the documentation to "built-in
sequence". Then, in the D language world, we can have clarify name for
the built-in one.
2. Introduce new templates, Seq, TypeSeq, and ExpSeq.
template Seq(T...) { alias T Seq; }// identical with
std.typetuple.TypeTuple
+1.
template TypeSeq(T...) if (allSatisfy!(isType, T)) { alias T TypeSeq; }
template ExpSeq(T...) if (allSatisfy!(isExpression, T)) { alias T ExpSeq; }
If you really want to a sequence with heterogeneous elements, use
Seq template. Otherwise use TypeSeq or ExpSeq based on your purpose.
Kenji Hara
I don't consider TypeSeq and ExpSeq crucial. They do not do more
checking than using the sequence in type or expression context triggers
automatically, but YMMV.
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
On 09/25/2012 11:01 PM, Andrei Alexandrescu wrote:
On 9/25/12 4:14 PM, Jonathan M Davis wrote:
On Wednesday, September 26, 2012 04:29:13 kenji hara wrote:
But, the two are often confused, by the word "tuple". It has
introduced badly confusion in many discussions.
To make matters worse, it had often invoked incorrect suggestion that
merging the two into one.
My suggestion is very simple.
1. Change all words "built-in tuple" in the documentation to "built-in
sequence". Then, in the D language world, we can have clarify name for
the built-in one.
2. Introduce new templates, Seq, TypeSeq, and ExpSeq.
template Seq(T...) { alias T Seq; } // identical with
std.typetuple.TypeTuple
template TypeSeq(T...) if (allSatisfy!(isType, T)) { alias T TypeSeq; }
template ExpSeq(T...) if (allSatisfy!(isExpression, T)) { alias T
ExpSeq; }
If you really want to a sequence with heterogeneous elements, use
Seq template. Otherwise use TypeSeq or ExpSeq based on your purpose.
In principle, renaming TypeTuple makes sense given it's bad name
(though I
really don't seem much point in separating expression tuples and type
tuples),
but it would break a _lot_ of code. And both Walter and Andrei are
increasingly against making any breaking changes.
- Jonathan M Davis
TypeTuple does a lot of harm. I'd be glad to rename it GenericTuple and
leave TypeTuple as a slowly rotting alias.
Andrei
I'd never use GenericTuple, because already after four usages it would
have been cheaper to just define Seq inline.
GenericTupleGenericTupleGenericTupleGenericTuple
template Seq(T...){ alias T Seq; }SeqSeqSeqSeq
What is the rationale for calling this construct a tuple anyway?
Programming language tuples usually impose more structure on the
data than just ordering.
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
On 9/25/12 4:44 PM, Jonathan M Davis wrote: On Tuesday, September 25, 2012 22:39:37 ixid wrote: I meant to reply to your post rather than Jacob's. It would help if you actually quoted at least _some_ of the post that you're replying to. I have _no_ idea what post you're replying to here. Many people view this newsgroup without any threading (meaning that your post is _really_ confusing), and even when you _have_ threading, it doesn't always work right (my mail client frequently puts posts in the wrong place in the hierarchy). So, please include at least some of the posts that you're replying to in your replies. - Jonathan M Davis Also, ixid, while you're at it, don't _forget_ to _underline_ all _words_ that are _important_. _Andrei_
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
On Tuesday, 25 September 2012 at 10:04:46 UTC, deadalnix wrote:
Le 25/09/2012 03:19, ixid a écrit :
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.
It can get pretty confusing with , separated declarations :
int a, b = 3;
or worse :
int a, int b = foo();
-->
(int a, int b) = foo();
or
int a, (int b = foo());
and it gets worse with int a, auto b = foo();
But I do agree that this is really nice in many places.
Replying to the correct post this time, sorry for the repeated
posting.
You've shown it's clearly incompatible with the current language
and would break lots of code. What would it break if assignment
required explicit tuple brackets?
(int a, b) = foo(); // A tuple assignment, 'a' and 'b' will be
filled in order by the multiple return values of foo()
int foo() {
return 1;
}
(int a, b) = foo(); // Also valid and only sets 'a'
int, int foo() {
return 1, 2;
}
int a = foo(); // Also valid and 'a' takes the first tuple value
(int a, auto b) = foo(); // Evaluated left to right so 'a' will
take the first argument of foo and b will auto to a type or tuple
of what remains. It will error if there is nothing remaining for
b. This would still allow the clean expression of stand-alone
tuples and function arguments and return values.
int, string a = 1, "hello";
int, string foo(double, double a) {
return cast(int) (d[0] * d[1]), "hello";
}
Doesn't the needs of bracketing to determine order operation,
(stuff) more or less imply that implicit conversion between one
member tuples and the type of that tuple member is a requirement?
Or would the (stuff, ) syntax be better?
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
On Tuesday, September 25, 2012 22:39:37 ixid wrote: > I meant to reply to your post rather than Jacob's. It would help if you actually quoted at least _some_ of the post that you're replying to. I have _no_ idea what post you're replying to here. Many people view this newsgroup without any threading (meaning that your post is _really_ confusing), and even when you _have_ threading, it doesn't always work right (my mail client frequently puts posts in the wrong place in the hierarchy). So, please include at least some of the posts that you're replying to in your replies. - Jonathan M Davis
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
On 9/25/12 4:37 PM, deadalnix wrote: Le 25/09/2012 17:08, Andrei Alexandrescu a écrit : On 9/25/12 10:05 AM, deadalnix wrote: OK, my bad. It means that tuple(...) behave differently than T... defined tuples. And both behave differently than Caml or Haskell's tuples. isn't the time for some unification ? Preferably on how tuples work in other languages, except if limitations can be shown and better proposal are made (and not include that in D2.xxx). I'm not sure actually. The way I look at it, built-in tuples are quite low-level (types can't be spelled, automatic expansion and flattening, undecided first-class semantics) and should seldom be dealt with directly. The best use of built-in tuples is in the implementation of truly well-behaved, composable tuples. Andrei We currently have 2 type of tuples, both unsatisfying it its own way (and I assume I can say it is confusing as I was confused before). If the new tuple stuff is implemented, D will ends up with 3 tuples systems, 2 of them unsatisfying and 1 of them satisfying (at least that is the goal). Still, language complexity would have increased in the process and have 3 time the same feature with different flavor isn't a good thing. Even if the tuple solution is a good one, the resulting situation isn't. I agree. That's why I want to take the minimum amount of steps to make library tuples work. That minimum amount may be 1, i.e. just implement deconstruction. Andrei
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
On 9/25/12 4:14 PM, Jonathan M Davis wrote:
On Wednesday, September 26, 2012 04:29:13 kenji hara wrote:
But, the two are often confused, by the word "tuple". It has
introduced badly confusion in many discussions.
To make matters worse, it had often invoked incorrect suggestion that
merging the two into one.
My suggestion is very simple.
1. Change all words "built-in tuple" in the documentation to "built-in
sequence". Then, in the D language world, we can have clarify name for
the built-in one.
2. Introduce new templates, Seq, TypeSeq, and ExpSeq.
template Seq(T...) { alias T Seq; } // identical with
std.typetuple.TypeTuple
template TypeSeq(T...) if (allSatisfy!(isType, T)) { alias T TypeSeq; }
template ExpSeq(T...) if (allSatisfy!(isExpression, T)) { alias T
ExpSeq; }
If you really want to a sequence with heterogeneous elements, use
Seq template. Otherwise use TypeSeq or ExpSeq based on your purpose.
In principle, renaming TypeTuple makes sense given it's bad name (though I
really don't seem much point in separating expression tuples and type tuples),
but it would break a _lot_ of code. And both Walter and Andrei are
increasingly against making any breaking changes.
- Jonathan M Davis
TypeTuple does a lot of harm. I'd be glad to rename it GenericTuple and
leave TypeTuple as a slowly rotting alias.
Andrei
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
On Tue, 25 Sep 2012 12:07:33 +0200 deadalnix wrote: > Le 25/09/2012 09:11, Jacob Carlborg a écrit : > > On 2012-09-25 00:28, bearophile wrote: > > > >> (||) > >> (|1|) > >> (|1, 2|) > >> (|1, 2, 3|) > > > > What about: > > > > || > > |1| > > |1, 2| > > > > Yeah and why not þ1, 2þ or ŀ1, 2ŀ ? > > maybe ↓1, 2↓ is better ? > > or « 1, 2 » (this one at least is readable). | is easily typed. þ, ŀ, ↓ and « I had to copy-paste.
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
I meant to reply to your post rather than Jacob's.
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
Le 25/09/2012 17:08, Andrei Alexandrescu a écrit : On 9/25/12 10:05 AM, deadalnix wrote: OK, my bad. It means that tuple(...) behave differently than T... defined tuples. And both behave differently than Caml or Haskell's tuples. isn't the time for some unification ? Preferably on how tuples work in other languages, except if limitations can be shown and better proposal are made (and not include that in D2.xxx). I'm not sure actually. The way I look at it, built-in tuples are quite low-level (types can't be spelled, automatic expansion and flattening, undecided first-class semantics) and should seldom be dealt with directly. The best use of built-in tuples is in the implementation of truly well-behaved, composable tuples. Andrei We currently have 2 type of tuples, both unsatisfying it its own way (and I assume I can say it is confusing as I was confused before). If the new tuple stuff is implemented, D will ends up with 3 tuples systems, 2 of them unsatisfying and 1 of them satisfying (at least that is the goal). Still, language complexity would have increased in the process and have 3 time the same feature with different flavor isn't a good thing. Even if the tuple solution is a good one, the resulting situation isn't.
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
Le 25/09/2012 17:51, ixid a écrit :
You've shown it's clearly incompatible with the current language and
would break lots of code. What would it break if assignment required
explicit tuple brackets?
(int a, b) = foo(); // A tuple assignment, 'a' and 'b' will be filled in
order by the multiple return values of foo()
int foo() {
return 1;
}
(int a, b) = foo(); // Also valid and only sets 'a'
int, int foo() {
return 1, 2;
}
int a = foo(); // Also valid and 'a' takes the first tuple value
(int a, auto b) = foo(); // Evaluated left to right so 'a' will take the
first argument of foo and b will auto to a type or tuple of what
remains. It will error if there is nothing remaining for b. This would
still allow the clean expression of stand-alone tuples and function
arguments and return values.
int, string a = 1, "hello";
int, string foo(double, double a) {
return cast(int) (d[0] * d[1]), "hello";
}
WTF are thoses affirmations ?
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
On 9/25/12 3:39 PM, ixid wrote: "T.expand" naturally has the connotation "unpacked" to me, Isn't T.unpack clearer? Does that clash with a different usage for the term? Let's stay with .expand. Andrei
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
On Wednesday, September 26, 2012 04:29:13 kenji hara wrote:
> But, the two are often confused, by the word "tuple". It has
> introduced badly confusion in many discussions.
> To make matters worse, it had often invoked incorrect suggestion that
> merging the two into one.
>
> My suggestion is very simple.
> 1. Change all words "built-in tuple" in the documentation to "built-in
> sequence". Then, in the D language world, we can have clarify name for
> the built-in one.
> 2. Introduce new templates, Seq, TypeSeq, and ExpSeq.
>
> template Seq(T...) { alias T Seq; } // identical with
> std.typetuple.TypeTuple
> template TypeSeq(T...) if (allSatisfy!(isType, T)) { alias T TypeSeq; }
> template ExpSeq(T...) if (allSatisfy!(isExpression, T)) { alias T
> ExpSeq; }
>
> If you really want to a sequence with heterogeneous elements, use
> Seq template. Otherwise use TypeSeq or ExpSeq based on your purpose.
In principle, renaming TypeTuple makes sense given it's bad name (though I
really don't seem much point in separating expression tuples and type tuples),
but it would break a _lot_ of code. And both Walter and Andrei are
increasingly against making any breaking changes.
- Jonathan M Davis
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
"T.expand" naturally has the connotation "unpacked" to me, Isn't T.unpack clearer? Does that clash with a different usage for the term?
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
The built-in tuple is also quite useful when defining templates.
In essence, we have two kinds of tuples: the built-in language
tuple is the "unpacked" tuple while Phobos hosts the "packed"
one. They each have their own use case and they can coexist
peacefully. But the language itself needs to standardize on one
or the other.
+1, and it should standardize on "packed" (non-expanded) tuples
because "unpacked" ones have very unusual behavior, and because
it's impractical to eliminate "packed" tuples but practical to
eliminate "unpacked" ones. "unpacked" tuples should only exist as
an intermediate result (the result of .expand).
If the language made T… a packed tuple instead, then we could
use the packed tuple everywhere and unpack it where necessary,
and something like this could be used to make a packed tuple:
T getThings(T...)(T.expand t)
{
return T(t);
}
T t1;
T t2 = getThings!(T)(t1.expand);
"T.expand" naturally has the connotation "unpacked" to me,
whereas what you really want to do is indicate that "t" is
packed, right? Clearly, the syntax for a varargs template like
this would have to change to indicate that T is non-expanded;
unfortunately, I don't have a really compelling syntax to suggest.
P.S. If non-expanded tuples were the default, they should
probably have a quicker syntax than "t.expand" to expand them. I
suggest overloading unary * as in "*t"; this is known as the
"explode" operator in boo.
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
2012/9/26 Jonathan M Davis :
> On Tuesday, September 25, 2012 13:45:50 Michel Fortin wrote:
>> On 2012-09-25 16:38:31 +, "Jonathan M Davis" said:
>> > On Tuesday, September 25, 2012 12:28:15 Michel Fortin wrote:
>> >> Although to make things less confusing, I think the built-in language
>> >> tuple should give up its name. It could become a "sequence". Renaming
>> >> the built-in one would certainly be less trouble, as code doesn't refer
>> >> to it by its name, and you can pick a name that fits better with its
>> >> auto-expanding behaviour.
>> >
>> > Not referred to by its name? It's refereed to as TypeTuple all over the
>> > place. It's arguably a bad name, but it would break a _lot_ of code to
>> > change it now.
>> TypeTuple is only a construct allowing you to create a built-in
>> language tuple, one that does not necessarily match the definition of a
>> TypeTuple. The language spec defines a Tuples, TypeTuples, and
>> ExpressionTuples with these words (ironically, using the word
>> "sequence" twice):
>>
>> """
>> If the last template parameter in the TemplateParameterList is declared
>> as a TemplateTupleParameter, it is a match with any trailing template
>> arguments. The sequence of arguments form a Tuple. A Tuple is not a
>> type, an expression, or a symbol. It is a sequence of any mix of types,
>> expressions or symbols.
>>
>> A Tuple whose elements consist entirely of types is called a TypeTuple.
>> A Tuple whose elements consist entirely of expressions is called an
>> ExpressionTuple.
>> """
>> Source: http://dlang.org/template.html
>
> I wasn't aware of that being in the language definition, but it doesn't change
> the fact that they're used and referred to in code as TypeTuple, and renaming
> that would break a lot of code. And it _is_ used for the built-in tuple type,
> regardless of whether the spec considers the terms type tuple and expression
> tuple to refer to distinct entities. Rename the stuff in the spec to whatever
> you like, but the library uses the term TypeTuple, so it _is_ used in code.
>
> - Jonathan M Davis
I like current design - open (built-in, automatically flattened, and
*unpacked*) tuple, and closed (library, be structured, and *packed*)
tuple.
But, the two are often confused, by the word "tuple". It has
introduced badly confusion in many discussions.
To make matters worse, it had often invoked incorrect suggestion that
merging the two into one.
My suggestion is very simple.
1. Change all words "built-in tuple" in the documentation to "built-in
sequence". Then, in the D language world, we can have clarify name for
the built-in one.
2. Introduce new templates, Seq, TypeSeq, and ExpSeq.
template Seq(T...) { alias T Seq; }// identical with
std.typetuple.TypeTuple
template TypeSeq(T...) if (allSatisfy!(isType, T)) { alias T TypeSeq; }
template ExpSeq(T...) if (allSatisfy!(isExpression, T)) { alias T ExpSeq; }
If you really want to a sequence with heterogeneous elements, use
Seq template. Otherwise use TypeSeq or ExpSeq based on your purpose.
Kenji Hara
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
On Tuesday, September 25, 2012 13:45:50 Michel Fortin wrote: > On 2012-09-25 16:38:31 +, "Jonathan M Davis" said: > > On Tuesday, September 25, 2012 12:28:15 Michel Fortin wrote: > >> Although to make things less confusing, I think the built-in language > >> tuple should give up its name. It could become a "sequence". Renaming > >> the built-in one would certainly be less trouble, as code doesn't refer > >> to it by its name, and you can pick a name that fits better with its > >> auto-expanding behaviour. > > > > Not referred to by its name? It's refereed to as TypeTuple all over the > > place. It's arguably a bad name, but it would break a _lot_ of code to > > change it now. > TypeTuple is only a construct allowing you to create a built-in > language tuple, one that does not necessarily match the definition of a > TypeTuple. The language spec defines a Tuples, TypeTuples, and > ExpressionTuples with these words (ironically, using the word > "sequence" twice): > > """ > If the last template parameter in the TemplateParameterList is declared > as a TemplateTupleParameter, it is a match with any trailing template > arguments. The sequence of arguments form a Tuple. A Tuple is not a > type, an expression, or a symbol. It is a sequence of any mix of types, > expressions or symbols. > > A Tuple whose elements consist entirely of types is called a TypeTuple. > A Tuple whose elements consist entirely of expressions is called an > ExpressionTuple. > """ > Source: http://dlang.org/template.html I wasn't aware of that being in the language definition, but it doesn't change the fact that they're used and referred to in code as TypeTuple, and renaming that would break a lot of code. And it _is_ used for the built-in tuple type, regardless of whether the spec considers the terms type tuple and expression tuple to refer to distinct entities. Rename the stuff in the spec to whatever you like, but the library uses the term TypeTuple, so it _is_ used in code. - Jonathan M Davis
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
On 2012-09-25 16:38:31 +, "Jonathan M Davis" said: On Tuesday, September 25, 2012 12:28:15 Michel Fortin wrote: Although to make things less confusing, I think the built-in language tuple should give up its name. It could become a "sequence". Renaming the built-in one would certainly be less trouble, as code doesn't refer to it by its name, and you can pick a name that fits better with its auto-expanding behaviour. Not referred to by its name? It's refereed to as TypeTuple all over the place. It's arguably a bad name, but it would break a _lot_ of code to change it now. TypeTuple is only a construct allowing you to create a built-in language tuple, one that does not necessarily match the definition of a TypeTuple. The language spec defines a Tuples, TypeTuples, and ExpressionTuples with these words (ironically, using the word "sequence" twice): """ If the last template parameter in the TemplateParameterList is declared as a TemplateTupleParameter, it is a match with any trailing template arguments. The sequence of arguments form a Tuple. A Tuple is not a type, an expression, or a symbol. It is a sequence of any mix of types, expressions or symbols. A Tuple whose elements consist entirely of types is called a TypeTuple. A Tuple whose elements consist entirely of expressions is called an ExpressionTuple. """ Source: http://dlang.org/template.html -- Michel Fortin michel.for...@michelf.ca http://michelf.ca/
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
On Tuesday, September 25, 2012 12:28:15 Michel Fortin wrote: > Although to make things less confusing, I think the built-in language > tuple should give up its name. It could become a "sequence". Renaming > the built-in one would certainly be less trouble, as code doesn't refer > to it by its name, and you can pick a name that fits better with its > auto-expanding behaviour. Not referred to by its name? It's refereed to as TypeTuple all over the place. It's arguably a bad name, but it would break a _lot_ of code to change it now. - Jonathan M Davis
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
On 2012-09-25 15:08:25 +, Andrei Alexandrescu
said:
On 9/25/12 10:05 AM, deadalnix wrote:
OK, my bad. It means that tuple(...) behave differently than T...
defined tuples.
And both behave differently than Caml or Haskell's tuples.
isn't the time for some unification ? Preferably on how tuples work in
other languages, except if limitations can be shown and better proposal
are made (and not include that in D2.xxx).
I'm not sure actually. The way I look at it, built-in tuples are quite
low-level (types can't be spelled, automatic expansion and flattening,
undecided first-class semantics) and should seldom be dealt with
directly. The best use of built-in tuples is in the implementation of
truly well-behaved, composable tuples.
The built-in tuple is also quite useful when defining templates.
In essence, we have two kinds of tuples: the built-in language tuple is
the "unpacked" tuple while Phobos hosts the "packed" one. They each
have their own use case and they can coexist peacefully. But the
language itself needs to standardize on one or the other. Take this
example (which is currently illegal because you can't return a built-in
language tuple):
T getThings(T...)(T t)
{
return t;
}
In this situation, there is no question that the language tuple needs
to work as an expanded tuple inside the parameter list of getTuple.
But now, what is the return type of makeTuple(1,2)? Obviously it's
(int, int), but is (int, int) the same thing as T? Or is it a packed
version of T? Well, it can't be a packed version of T because T is
already the unpacked type. I mean that for a function that simply
return its argument this should work:
T t1;
T t2 = getThings!(T)(t1);
If the language made T… a packed tuple instead, then we could use the
packed tuple everywhere and unpack it where necessary, and something
like this could be used to make a packed tuple:
T getThings(T...)(T.expand t)
{
return T(t);
}
T t1;
T t2 = getThings!(T)(t1.expand);
But we can't have it both ways, and the above would be a very drastic
change to the language.
I'm of the opinion that if we want to add tuple returns to the language
(which I'd certainly like), it'll have to be the same kind of tuple we
currently have built-in in the language: the auto-expanding kind.
As we all know, this doesn't preclude anyone from building packed
library tuples:
Tuple!(T) getThings(T...)(T t)
{
return tuple(t);
}
Although to make things less confusing, I think the built-in language
tuple should give up its name. It could become a "sequence". Renaming
the built-in one would certainly be less trouble, as code doesn't refer
to it by its name, and you can pick a name that fits better with its
auto-expanding behaviour.
--
Michel Fortin
michel.for...@michelf.ca
http://michelf.ca/
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
You've shown it's clearly incompatible with the current language
and would break lots of code. What would it break if assignment
required explicit tuple brackets?
(int a, b) = foo(); // A tuple assignment, 'a' and 'b' will be
filled in order by the multiple return values of foo()
int foo() {
return 1;
}
(int a, b) = foo(); // Also valid and only sets 'a'
int, int foo() {
return 1, 2;
}
int a = foo(); // Also valid and 'a' takes the first tuple value
(int a, auto b) = foo(); // Evaluated left to right so 'a' will
take the first argument of foo and b will auto to a type or tuple
of what remains. It will error if there is nothing remaining for
b. This would still allow the clean expression of stand-alone
tuples and function arguments and return values.
int, string a = 1, "hello";
int, string foo(double, double a) {
return cast(int) (d[0] * d[1]), "hello";
}
Doesn't the needs of bracketing to determine order operation,
(stuff) more or less imply that implicit conversion between one
member tuples and the type of that tuple member is a requirement?
Or would the (stuff, ) syntax be better?
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
On 9/23/12, Andrei Alexandrescu wrote:
> http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP19
Oh, I completely forgot to mention this little bug I've had due to the
comma operator a few weeks ago:
import std.stdio;
int getInt(string op)
{
if (op, "a")
return 1;
else
if (op == "b")
return 2;
else
return 3;
}
void main()
{
string op1 = "a";
string op2 = "b";
string op3 = "c";
writeln(getInt(op1));
writeln(getInt(op2));
writeln(getInt(op3));
}
It was a result of a refactoring and the bug went unnoticed until I
started getting weird results back. The if/else was much bigger and
the comma was somewhere in the middle. So yeah, nuke it from orbit!
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
On 9/25/12 10:05 AM, deadalnix wrote: OK, my bad. It means that tuple(...) behave differently than T... defined tuples. And both behave differently than Caml or Haskell's tuples. isn't the time for some unification ? Preferably on how tuples work in other languages, except if limitations can be shown and better proposal are made (and not include that in D2.xxx). I'm not sure actually. The way I look at it, built-in tuples are quite low-level (types can't be spelled, automatic expansion and flattening, undecided first-class semantics) and should seldom be dealt with directly. The best use of built-in tuples is in the implementation of truly well-behaved, composable tuples. Andrei
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
Le 25/09/2012 15:38, Andrei Alexandrescu a écrit :
On 9/25/12 6:10 AM, deadalnix wrote:
Le 24/09/2012 16:59, foobar a écrit :
I'm a bit confused about what is specifically proposed here:
- Is the suggestion to limit tuples to >1 elements? *This* I'm against
for practical as well as completeness reasons. Andrei already provided
one example, and another would be a proper unit type. e.g.
void foo(int a) {}
void bar (int b) { return foo(b); }
- Is the suggestion to allow implicit conversion between (T) and T?
This brings almost no benefit - (you save two keystrokes?) and adds a
special case to the language. The added complexity really does not
justify this.
In fact, they don't need to unpack only for 1 element tuples, but this
is the tricky case. Today, tuples auto unpack on function call for
instance :
auto t = tuple (1, 2);
foo(t); // call foo(int, int)
Actually that's not the case. You need to write
foo(t.expand);
(and I think that's a good thing).
Andrei
OK, my bad. It means that tuple(...) behave differently than T...
defined tuples.
And both behave differently than Caml or Haskell's tuples.
isn't the time for some unification ? Preferably on how tuples work in
other languages, except if limitations can be shown and better proposal
are made (and not include that in D2.xxx).
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
Le 25/09/2012 13:42, Jacob Carlborg a écrit : On 2012-09-25 12:05, deadalnix wrote: It can get pretty confusing with , separated declarations : int a, b = 3; I wouldn't complain if that became illegal. Nor me (it was already confusing and confusable with comma expressions), but a hell lot of code rely on comma declarations.
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
On 9/25/12 6:10 AM, deadalnix wrote:
Le 24/09/2012 16:59, foobar a écrit :
I'm a bit confused about what is specifically proposed here:
- Is the suggestion to limit tuples to >1 elements? *This* I'm against
for practical as well as completeness reasons. Andrei already provided
one example, and another would be a proper unit type. e.g.
void foo(int a) {}
void bar (int b) { return foo(b); }
- Is the suggestion to allow implicit conversion between (T) and T?
This brings almost no benefit - (you save two keystrokes?) and adds a
special case to the language. The added complexity really does not
justify this.
In fact, they don't need to unpack only for 1 element tuples, but this
is the tricky case. Today, tuples auto unpack on function call for
instance :
auto t = tuple (1, 2);
foo(t); // call foo(int, int)
Actually that's not the case. You need to write
foo(t.expand);
(and I think that's a good thing).
Andrei
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
On 2012-09-25 12:05, deadalnix wrote: It can get pretty confusing with , separated declarations : int a, b = 3; I wouldn't complain if that became illegal. -- /Jacob Carlborg
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
deadalnix: The problem with tuple() isn't its syntax, but what you can or can't do with the resulting tuple. See my first posts in this thread :-) On the other hand it's handy to have a compact syntax for something you use often (http://en.wikipedia.org/wiki/Zipf%27s_law ). Bye, bearophile
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
Le 24/09/2012 16:59, foobar a écrit :
I'm a bit confused about what is specifically proposed here:
- Is the suggestion to limit tuples to >1 elements? *This* I'm against
for practical as well as completeness reasons. Andrei already provided
one example, and another would be a proper unit type. e.g.
void foo(int a) {}
void bar (int b) { return foo(b); }
- Is the suggestion to allow implicit conversion between (T) and T?
This brings almost no benefit - (you save two keystrokes?) and adds a
special case to the language. The added complexity really does not
justify this.
In fact, they don't need to unpack only for 1 element tuples, but this
is the tricky case. Today, tuples auto unpack on function call for
instance :
auto t = tuple (1, 2);
foo(t); // call foo(int, int)
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
Le 25/09/2012 03:19, ixid a écrit :
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.
It can get pretty confusing with , separated declarations :
int a, b = 3;
or worse :
int a, int b = foo();
-->
(int a, int b) = foo();
or
int a, (int b = foo());
and it gets worse with int a, auto b = foo();
But I do agree that this is really nice in many places.
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
Le 25/09/2012 09:11, Jacob Carlborg a écrit : On 2012-09-25 00:28, bearophile wrote: (||) (|1|) (|1, 2|) (|1, 2, 3|) What about: || |1| |1, 2| Yeah and why not þ1, 2þ or ŀ1, 2ŀ ? maybe ↓1, 2↓ is better ? or « 1, 2 » (this one at least is readable).
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
Le 25/09/2012 01:39, Andrei Alexandrescu a écrit :
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 "(||)".
The problem with tuple() isn't its syntax, but what you can or can't do
with the resulting tuple.
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
Le 24/09/2012 17:55, Philippe Sigaud a écrit :
On Mon, Sep 24, 2012 at 5:24 PM, 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 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.
And the auto flatten stuff is really weird, and sometime get into the way.
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
Le 24/09/2012 17:24, Andrei Alexandrescu a écrit :
On 9/24/12 9:27 AM, Philippe Sigaud wrote:
On Mon, Sep 24, 2012 at 12:46 PM, Nick Sabalausky
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?
For example choosing { 1, 2} to represent a tuple? { } blocks in D
enclose semi-colon terminated declarations or expressions, but here
it's enclosing comma-separated expressions. And, since { } is probably
dangerous without a completly integrated type systems giving a type to
all expressions ( (){} anyone?) , why not use (| 1, 2 |), or whatever
syntax strikes our collective fancy? (I propose *not* to use< ,>)
Then, the compiler has to change the way it prints its internal tuple,
to follow the new syntax.
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.
auto c = (| 3 |); // or c = { 3 };
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.
Andrei
Clearly, crating a tuple that way isn't the issue. tuple() is ok.
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
Le 25/09/2012 01:59, Andrej Mitrovic a écrit : On 9/25/12, Steven Schveighoffer 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. It will, because it is trying to parse an expression here, not a declaration.
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
Le 24/09/2012 17:29, Andrei Alexandrescu a écrit :
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
{} is often harder to disambiguate then () with current D syntax.
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
On 24/09/12 17:19, Andrei Alexandrescu wrote:
On 9/24/12 4:17 AM, Don Clugston wrote:
Regarding the comma operator: I'd love to deprecate it, but even if we
don't, could we at least ensure that this kind of rubbish doesn't
compile:
void main()
{
int x;
x > 0, x += 5;
}
At present, because comma expressions are expressions, not statements,
the "x > 0" doesn't generate a "statement has no effect" error, despite
the fact that it is meaningless and gets completely discarded.
Interesting. The comma operator is probably the only one in which an
expression is evaluated only for the sake of its side effects. So
eliminating the comma operator would just get rid of that case by design.
Yes. Comma is a special case in a number of ways.
Of course, there's always the option of adding more checks or rewriting
the comma operator from "expr1, expr2, expr3" to "{ expr1; expr2; return
expr3; }()".
We hit this one often in real-world code. On German keyboards , and ;
are on the same key, so it's a fairly easy typo. I don't think it
happens as often when using a US keyboard.
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
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
On 2012-09-25 00:28, bearophile wrote: (||) (|1|) (|1, 2|) (|1, 2, 3|) What about: || |1| |1, 2| -- /Jacob Carlborg
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
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.
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
On 9/25/12, Steven Schveighoffer 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.
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 wrote: On Mon, 24 Sep 2012 10:53:14 -0400 "Steven Schveighoffer" 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
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
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.
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
On Mon, 24 Sep 2012 21:50:34 +0200, Caligo 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
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
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 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.
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 wrote:
On Mon, Sep 24, 2012 at 12:46 PM, Nick Sabalausky
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())
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 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?
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" 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.
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 wrote:
> On Mon, Sep 24, 2012 at 12:46 PM, Nick Sabalausky
> 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.
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
On Mon, 24 Sep 2012 16:50:47 +0200
"foobar" 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 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.
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 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).
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
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 wrote: > > That both breaks code, doesn't improve the syntax, but makes it worse. > > Bye, > bearophile
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
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
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
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
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
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
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>
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
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.
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
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
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
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
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
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
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
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
On 9/24/12 9:27 AM, Philippe Sigaud wrote:
On Mon, Sep 24, 2012 at 12:46 PM, Nick Sabalausky
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?
For example choosing { 1, 2} to represent a tuple? { } blocks in D
enclose semi-colon terminated declarations or expressions, but here
it's enclosing comma-separated expressions. And, since { } is probably
dangerous without a completly integrated type systems giving a type to
all expressions ( (){} anyone?) , why not use (| 1, 2 |), or whatever
syntax strikes our collective fancy? (I propose *not* to use< ,>)
Then, the compiler has to change the way it prints its internal tuple,
to follow the new syntax.
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.
auto c = (| 3 |); // or c = { 3 };
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.
Andrei
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
On Monday, 24 September 2012 at 14:52:21 UTC, Steven
Schveighoffer wrote:
(int[]) x;
int a = x.length;
is a == 0 or 1?
I agree with Andrei, we need something different.
This is exactly the question I was going to ask ...
I don't profess to be even close to an expert on tuples, but I
feel they should be built-in to the language, since they are
actually language constructs that we are declaring types for.
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! {} is already
used in C languages for heterogeneous data
structures(structs/classes, JSON etc). Using () creates too many
special cases, especially in generic programming and seeing how
other languages are dealing with them we'd rather avoid them from
the very beginning.
Right now, I think that is reserved for static struct
initializers. But can't those be considered a tuple also?
Someone will probably destroy this 10 milliseconds after I send
it :)
-Steve
It would be awesome if we could make tuples generic initializers
for various data types in D. Not just structs but for instance
arrays:
int[] a = {1, 2, 3, 4};
Compiler possesses enough type information to know that this
tuple could be converted to the int[].
P.S. The only collision I see with {} is a delegate literal, but
to be honest it's not worth the merit and quite confusing in
fact. There are 3 other ways to define a delegate in D which will
cover all of the user's needs.
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
On 9/24/12 1:01 AM, Nick Sabalausky wrote: On Sun, 23 Sep 2012 18:48:22 -0400 Andrei Alexandrescu wrote: Once a one-element tuple becomes equivalent to the actual item, there's an explosion of trouble and special cases in the language and in code that uses it. For example, divide and conquer code that manipulates tuples and takes t[0 .. $/2] and t[$/2+1 .. $] would suddenly get to cases in which the slices are no longer tuples, and so on. And that's only the beginning. 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? It just creates endless little problems and confusion coming outta the woodwork, as others have pointed out in response to this. There are languages that have also explored a similar approach - a value can be automatically converted to a one-element array and vice versa. It's problematic, especially in a language with generics and function overloading. I think it's safe to just not even discuss it. A nice way to put it :/ Part politician perhaps? ;) I meant it in a simple and forward way - all I want is to save time and trouble in exploring a no-win design. From sheer experience gathered from years at hacking at this stuff I know this can be done but is not worth the trouble. Since it can be done, there's no argument that would definitively close the discussion, and that demotivates me from coming up with explanations. Andrei
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
On 9/24/12 4:17 AM, Don Clugston wrote:
Regarding the comma operator: I'd love to deprecate it, but even if we
don't, could we at least ensure that this kind of rubbish doesn't compile:
void main()
{
int x;
x > 0, x += 5;
}
At present, because comma expressions are expressions, not statements,
the "x > 0" doesn't generate a "statement has no effect" error, despite
the fact that it is meaningless and gets completely discarded.
Interesting. The comma operator is probably the only one in which an
expression is evaluated only for the sake of its side effects. So
eliminating the comma operator would just get rid of that case by design.
Of course, there's always the option of adding more checks or rewriting
the comma operator from "expr1, expr2, expr3" to "{ expr1; expr2; return
expr3; }()".
Andrei
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
On Monday, 24 September 2012 at 10:20:01 UTC, Nick Sabalausky
wrote:
On Mon, 24 Sep 2012 10:47:38 +0200
"foobar" wrote:
Nope.
One of the ways in math to "build" the positive numbers based
on set theory is via singletons:
n := |tuple of empty tuples|
so "1" is defined as { {} } whereas "0" is simply {}. That
does not work with the above suggestion. Now, I realize this
is an arguably convoluted math example but it does show that
the treating { {} } as {} is limiting the expressive power of
tuples.
And int's are limiting compared to mathematical integers. So
what?
So ok, maybe this is limiting from a theoretical standpoint. But
practically speaking? I dunno. We're not making tuples to
emulate
set theory here, we're just looking for ad-hoc anonymous
structs.
Besides, I only said they were logically the same thing, not
mechanically. I'm only suggesting that a one-element tuple be
implicitly
convertible to/from the type of its element. So there would
likely
still be the different types, it just makes sense that you
should be
able to use one as the other.
I'm a bit confused about what is specifically proposed here:
- Is the suggestion to limit tuples to >1 elements? *This* I'm
against for practical as well as completeness reasons. Andrei
already provided one example, and another would be a proper unit
type. e.g.
void foo(int a) {}
void bar (int b) { return foo(b); }
- Is the suggestion to allow implicit conversion between (T) and
T?
This brings almost no benefit - (you save two keystrokes?) and
adds a special case to the language. The added complexity really
does not justify this.
