I actually have some more requests, so please allow me to post again.
1) garbage collection.
what: we all know what it is about, don't we?.
why: it will simplifies programming by relieving the programmer from memory tracking issues, allowing him/her to concetrate on the problem at hand.
2) pass-by-name semantics.
what: to be able to invoke functions by passing parameters by name.
why: it simplifies writing constructors for classes with lots of options; it simplifies calling functions with lots of parameters.
3) tuples as first class values.
what: to be able to handle composite literals, i.e. expression lists surrounded by curly brackets, as first class entities.
why: it will solve the problem of sequence constructors, as well as provide a way to declare composite values in a structured manner, similar to S-expressions.
Let me expand on my third request a little.
It is impossible, for now, to do the following in C++:
vector < Object* > objects = {new Object1, new Object2, new Object3};
If the expression within the curly brackets was a first-class entity, then we could write the vector constructor like this:
template < class T > class vector {
public:
template < tuple T1 > vector( const T1 &values ) {
for(int i = 0; i < lengthof(T1); i++) {
push_back(values[i]);
}
}
}
The
operator [] could be used for indexing of a tuple's members. Arrays are homogeneous tuples after all.
Tuples as first class entities will also allow us to do declarative programming. For example, a GUI dialog could be declared as a series of nested tuples. If coupled with pass-by-name, it could make our life much easier for many things. Example:
Dialog dialog1 = Dialog(text = "my dialog", {
Row({Label(text="name:"), TextBox()}),
Row({Label(text="password:"), TextBox(password = true)}),
Row({Button(text = "ok", click = signal(dialog1, Dialog::ok)), Button(text = "cancel", click = signal(dialog1, Dialog::cancel))})
});
Or an HTML page:
HTML page1 = {
BeginH1(),
Text("Hello world"),
EndH1(),
Row({List({"A", "B", "C"}), Table({1, 2, 3})}),
};
The above code, when executed, would actually process the tuple 'page1' and produce a string buffer with the appropriate HTML.
Tuples themselves could be templates, parameterized over the type of their content. A 'tuple' declaration without template parameters is a generic tuple; a 'tuple' declaration with parameters could only accept a literal that reflects the structure of the tuple. Examples:
//any tuple
tuple
//variable length tuple of integers
tuple < int, ... < int > >
//tuple of an integer and a string
tuple < int, const char * >
Tuple types will be like template constraints: a type system for tuples. It will allow compiler validation of declarative forms.