November 09, 2012
Rob T wrote:

> The above template definitions define exactly the same structure as the original

No, they implement not _exactly_ the same structure, because they supply more freedom than the original templates version. The original version forced a recursion onto every implementation, whereas this new templates version allows non-recursive implementations.

It might be helpfull to reintroduce the forced recursion using the new template definitions.

Hint:
start with
| alias d_list!node00 d_list00;
| d_list00 var;
and publish whether it is possible to compile this line:
| alias R!d_list00 R0;

-manfred
November 09, 2012
Nick Sabalausky wrote:

> So ok:
> 
> s/There *IS NO RECURSION* here./There is no _IMPOSSIBLE_ recursion here./

That's one correection only. Several more are to come.

Sorrily no one seems to have recognized this sentence in digitalmars.D.learn:40918:

> Because `R' can recurse infinitely over `Ancor' a mooring and a way to that mooring is needed.

In regex-parlor this meens, that `( R!Ancor!)*' is the type the compiler should be able to handle according to the template definitions given.

But the compiler currently can only handle types with a finite length of description on instantiation. For me it is in doubt that this restriction can be declared as a bug.

-manfred
November 09, 2012
On Friday, 9 November 2012 at 14:04:26 UTC, Manfred Nowak wrote:
> Nick Sabalausky wrote:
>
>> So ok:
>> 
>> s/There *IS NO RECURSION* here./There is no _IMPOSSIBLE_ recursion
>> here./
>
> That's one correection only. Several more are to come.
>
> Sorrily no one seems to have recognized this sentence in
> digitalmars.D.learn:40918:
>
>> Because `R' can recurse infinitely over `Ancor' a mooring and a way to that mooring is needed.
>
> In regex-parlor this meens, that `( R!Ancor!)*' is the type the
> compiler should be able to handle according to the template definitions
> given.
>
> But the compiler currently can only handle types with a finite length
> of description on instantiation. For me it is in doubt that this
> restriction can be declared as a bug.
>
> -manfred

I'm not sure if you commented on why the non-templated version compiled. Since it does compile as I expected it would, it means that the templates operate in another dimension from what I was expecting, i.e., there's two languages in D, one for templates and another for non-temnplate code. My understanding of D from what I read, was that templates are supposed to work in the same way as regular code. The (T) is only there to introduce a type, so that code can be reused over multiple types. What is happening however, is that the templates are not doing what would be expected if the type was introduced manually, and to me this is plain wrong, or at best very unfortunate for D.

--rt
November 09, 2012
Rob T wrote:

> What is happening however, is that the templates are not doing what would be expected if the type was introduced manually

The expectations might be wrong.

With Templates one is able to introduce recursive definitions of types into the type system. As with recursive functions, the feedom, thereby generated, can introduce relaxation as well as strain.

-manfred

November 09, 2012
On 11/09/2012 02:17 PM, Manfred Nowak wrote:
> Rob T wrote:
>
>> The above template definitions define exactly the same structure
>> as the original
>
> No, they implement not _exactly_ the same structure, because they
> supply more freedom than the original templates version. The original
> version forced a recursion onto every implementation, whereas this new
> templates version allows non-recursive implementations.
>
> It might be helpfull to reintroduce the forced recursion using the new
> template definitions.
>
> Hint:
> start with
> | alias d_list!node00 d_list00;
> | d_list00 var;
> and publish whether it is possible to compile this line:
> | alias R!d_list00 R0;
>
> -manfred
>

The example definitely exposes a bug in DMD.
The D front end I am developing can already handle it.
November 09, 2012
Timon:

> The D front end I am developing can already handle it.
>

Developed in D, I suppose?


November 09, 2012
Timon Gehr wrote:

> The example definitely exposes a bug in DMD.
> The D front end I am developing can already handle it.

May I guess, that your front end is also able to handle this code:

struct Elem( size_t myNumber) {
  Elem!( myNumber +1)* next;
}
void main(){
  Elem!0 list;
  list.next= new Elem!1;
}

-manfred
November 09, 2012
On 11/09/2012 10:32 PM, Manfred Nowak wrote:
> Timon Gehr wrote:
>
>> The example definitely exposes a bug in DMD.
>> The D front end I am developing can already handle it.
>
> May I guess, that your front end is also able to handle this code:
>
> struct Elem( size_t myNumber) {
>    Elem!( myNumber +1)* next;
> }
> void main(){
>    Elem!0 list;
>    list.next= new Elem!1;
> }
>
> -manfred
>

In theory yes, but it takes a long time and uses a lot of memory, especially on a 64 bit build. This is a very different example from the OT's though.
November 09, 2012
On 11/09/2012 10:24 PM, Philippe Sigaud wrote:
>
> Timon:
>
>     The D front end I am developing can already handle it.
>
>
> Developed in D, I suppose?
>

Yes.
November 10, 2012
On Friday, 9 November 2012 at 21:32:01 UTC, Manfred Nowak wrote:
> Timon Gehr wrote:
>
>> The example definitely exposes a bug in DMD.
>> The D front end I am developing can already handle it.
>
> May I guess, that your front end is also able to handle this code:
>
> struct Elem( size_t myNumber) {
>   Elem!( myNumber +1)* next;
> }
> void main(){
>   Elem!0 list;
>   list.next= new Elem!1;
> }
>
> -manfred

With the unmodified template as posted, I get a very specific error about "recusive expansion", but I can see why using that form of template - it will expand into multiple types forever Elem!(0), Elem!(1), Elem!(2) ... Elem!(infinity).

Now take note that with the modified code below, it works fine, and exactly as I would expect:

struct Elem(T) {
 Elem* next;
}

My attempt to mess up the compiler did not succeed, the code below still compiles as expected.

struct Elem(T) {
 Elem!(T)* next;
}


If it works above, then it should also work with the code I introduced in the OP because it's the exact same scenario, only much more simplified. The type expansion should stop at the pointers, and the error message indicates that it does (there's no recursive expansion message), but it fails to evaluate all the types correctly (forwarded reference message).

I think this example clears the matter up nicely, and the problem I'm experiencing is definitely a compiler bug. I'd like to see this problem resolved, so I'll file a bug report.

BTW, thanks for all the attention to this matter, I've learned a lot more about D templates, such as the recusivness of templates demonstrated by manfred, and the dialogue in here helped me to find a reasonable work-a-round for my particular application.

--rt