Lurker:
> Interesting generics
> http://www.reddit.com/r/programming/comments/ctmxx/the_clay_programming_language/
>From what I have seen its generics are almost normal, the main difference is
>the whole-program type inference (that supports a good overloading too).
In the thread kssreeram says that it doeesn't have the higher kinds of Scala,
but he/she says "Template-template parameters are much cleaner in Clay":
> record Point[T] {
> x : T;
> y : T;
> }
>
> [Kind, CoordType]
> initialize(static Kind, x:CoordType, y:CoordType) {
> var p = Kind[CoordType](x, y);
> return p;
> }
>
> var intP = initialize(Point, 10, 10);
> var doubleP = intialize(Point, 1.2, 3.4);
You can write something similar in D too:
struct Point(T) {
T x, y;
}
auto initialize(alias Kind, CoordType)(CoordType x, CoordType y) {
return Kind!CoordType(x, y);
}
void main() {
auto intP = initialize!Point(10, 10);
auto doubleP = initialize!Point(1.2, 3.4);
}
But in D initialize() you must use 'alias' for the template struct argument
(otherwise the error message is so bad that I am considering asking for a
better error message in Bugzilla). If you forget the 'alias' (as I have
originally done) dmd 2.047 prints:
test.d(10): Error: template test.initialize(Kind,CoordType) does not match any
function template declaration
test.d(10): Error: template test.initialize(Kind,CoordType) cannot deduce
template function from argument types !(Point)(int,int)
test.d(10): Error: template instance errors instantiating template
test.d(11): Error: template test.initialize(Kind,CoordType) does not match any
function template declaration
test.d(11): Error: template test.initialize(Kind,CoordType) cannot deduce
template function from argument types !(Point)(double,double)
test.d(11): Error: template instance errors instantiating template
That's noisy and doesn't help much to find what is missing. A better error
message can be something like:
test.d(10): Error: in template test.initialize(Kind,CoordType) template
template argument 'Kind' needs 'alias'.
The main problem I've seen with the Clay language is its main feature: with
ShedSkin I have seen that global type inference doesn't scale. When the program
is past a certain size the compilation becomes too much slow. I don't know how
the author wants to solve this big problem. Many of the limits of D language
come from its 'separate compilations' requirement, but with such limits comes
also out practical compile times for larger projects. One way to solve the
problem for Clay can be to define compilation 'packages', where you define
types in an explicit way on their borders. So type inference can stop at such
borders and such packages become your compilation units (there are other ways
to 'manually' fully specify the types along such borders, for example in
ShedSkin for such purpose I have used unittests! They can be used to give a
full specification).
Bye,
bearophile
