aarti_pl wrote:
> My proposal would make meta programing in D much more intuitive (because of using rules - not bunch of corner cases as it is today). Unfortunately almost no one from NG commented on that...

Thank you, but I don't see in your proposal a method that can:

1. instantiate templates only if a value argument is prime or odd.

2. instantiate templates only on a type which supports addition and has the method foo.

Note that C++ Concepts could do (2) but could not do (1).

Walter Bright escribió:
> Jarrett Billingsley wrote:
>> Let's try to *simplify* metaprogramming and make things *orthogonal*
>> instead of tacking on features with no regard to the existing ones.
> 
> Type matching cannot do what expression matching can do. You'd need a totally new syntax anyway to bring expression matching into the template type parameter list.

But don't bring expression matching into the template type parameter list, bring template type parameter list into expression matching!

...

Done!

is(...)

"if" in the template is more powerful than template parameters restrictions. Why use those restrictions? Having two things for almost the same thing is confusing.

Suppose you implement partial ordering with template constraints and drop the others. What things you couldn't do? (I need an example because I can't see it).

Walter Bright pisze:
> aarti_pl wrote:
>> My proposal would make meta programing in D much more intuitive (because of using rules - not bunch of corner cases as it is today). Unfortunately almost no one from NG commented on that...
> 
> Thank you, but I don't see in your proposal a method that can:
> 
> 1. instantiate templates only if a value argument is prime or odd.
> 
> 2. instantiate templates only on a type which supports addition and has the method foo.
> 
> Note that C++ Concepts could do (2) but could not do (1).

ad.1

template normalizedType((T U N : U[N=size_t]) && (N & 1))

As it is stated in proposal commas are only syntax sugar for more general form with '&&'.

ad.2.

This case is in fact the same as 1. Because of the fact that A, B, C <=> A && B && C, you can create expressions as you want just using second form with logical operators. In this case you should just use proper compile time reflection mechanism in D to get information about type properties.

BR
Marcin Kuszczak
(aarti_pl)

aarti_pl wrote:
> Walter Bright pisze:
>> aarti_pl wrote:
>>> My proposal would make meta programing in D much more intuitive (because of using rules - not bunch of corner cases as it is today). Unfortunately almost no one from NG commented on that...
>>
>> Thank you, but I don't see in your proposal a method that can:
>>
>> 1. instantiate templates only if a value argument is prime or odd.
>>
>> 2. instantiate templates only on a type which supports addition and has the method foo.
>>
>> Note that C++ Concepts could do (2) but could not do (1).
> 
> ad.1
> 
> template normalizedType((T U N : U[N=size_t]) && (N & 1))
> 
> As it is stated in proposal commas are only syntax sugar for more general form with '&&'.

How do you distinguish a type from an expression?


> ad.2.
> 
> This case is in fact the same as 1. Because of the fact that A, B, C <=> A && B && C, you can create expressions as you want just using second form with logical operators. In this case you should just use proper compile time reflection mechanism in D to get information about type properties.

class C {
    int opAdd(C);
}

How would I write the parameter to accept any type that supports addition? I want to support int, float, C, etc., without having to exhaustively enumerate them.

Ary Borenszweig wrote:
> Suppose you implement partial ordering with template constraints and drop the others. What things you couldn't do? (I need an example because I can't see it).

How could I do partial ordering if one constraint expression accepts only "odd" integers? Remember that partial ordering is not done with the specific argument values, but with the general parameter ones.

On Thu, Jul 16, 2009 at 5:03 PM, Walter Bright<newshound1@digitalmars.com> wrote:
> Jarrett Billingsley wrote:
>>
>> Let's try to *simplify* metaprogramming and make things *orthogonal* instead of tacking on features with no regard to the existing ones.
>
> Type matching cannot do what expression matching can do. You'd need a totally new syntax anyway to bring expression matching into the template type parameter list.
>

Wow, can you say "taken out of context?"  I proposed the *exact* opposite.  Note:

template X(T: A, U: B)
would basically be syntactic sugar for
template X(T) if(is(T: A) && is(U: B))

Walter Bright pisze:
> aarti_pl wrote:
>> Walter Bright pisze:
>>> aarti_pl wrote:
>>>> My proposal would make meta programing in D much more intuitive (because of using rules - not bunch of corner cases as it is today). Unfortunately almost no one from NG commented on that...
>>>
>>> Thank you, but I don't see in your proposal a method that can:
>>>
>>> 1. instantiate templates only if a value argument is prime or odd.
>>>
>>> 2. instantiate templates only on a type which supports addition and has the method foo.
>>>
>>> Note that C++ Concepts could do (2) but could not do (1).
>>
>> ad.1
>>
>> template normalizedType((T U N : U[N=size_t]) && (N & 1))
>>
>> As it is stated in proposal commas are only syntax sugar for more general form with '&&'.
> 
> How do you distinguish a type from an expression?

Type is in fact the same thing as reduced expression. Please look at grammar. Everything except first type is *OPTIONAL*. So in fact you need always look for ctexpr (compile time expression) until you find some logical or grouping operator.

>> ad.2.
>>
>> This case is in fact the same as 1. Because of the fact that A, B, C <=> A && B && C, you can create expressions as you want just using second form with logical operators. In this case you should just use proper compile time reflection mechanism in D to get information about type properties.
> 
> class C {
>     int opAdd(C);
> }
> 
> How would I write the parameter to accept any type that supports addition? I want to support int, float, C, etc., without having to exhaustively enumerate them.

I will give you another question instead :-)

How would you do currently in D?

(In fact I just forgot how to do it in D now :-) But give me current syntax and I will rewrite it in my syntax)

BR
Marcin Kuszczak

aarti_pl wrote:
> How would you do currently in D?

template (T) if (T.init + T.init)
{
}

Walter Bright wrote:
> BLS wrote:
>> The current Template specialization implementation is doing a best fit search anyway, so why constraints are not able to use the same mechanism. ?
> 
> The template specialization method is based on types - but there's no way to look inside those types and specialize based on properties of those types. That's where constraints come in.
> 
> Constraints use a completely different matching method than the type parameters do. It makes intuitive sense to logically separate them, rather than to mix them up.
> 


Thanks for taking the time to answer ; But the question remains the same : _Why_ ? Constraints /have/ to use a completely different approach ?

("more intuitive than" is not ..ahem.. is not a good enough reason)

> 
>> bearophile brings in several times Scala/OCAML like pattern matching. Why not using that for constraints ?
> 
> I have no idea how that works, though Bartosz has been looking into it.

O well, I am pretty sure that bearophile is willing to give you any information you need  :)

Walter Bright pisze:
> aarti_pl wrote:
>> How would you do currently in D?
> 
> template (T) if (T.init + T.init)
> {
> }

in D1.0

template(T if typeof(T.init + T.init) == T)

or in D2.0

template(T if __traits(compiles, T.init + T.init))

I could mess something in above examples, but as you can see, getting it to work is not a problem of my syntax for templates. It is just a matter of using proper syntax for compile time reflection.

BR
Marcin Kuszczak
(aarti_pl)