Sean Kelly wrote:
> I don't know.  To do so would be like allowing:
> 
> struct S
> {
>     S val;
> }

Umm... not quite. In your case it's just a plain nested, recursive struct which is obviously impossible. In my case:

struct Foo(T) {
    Foo!(Foo!(T)) rec()() {
        Foo!(Foo!(T)) res;
        return res;
    }
}

When the function template is instantiated, one more nesting level is 'added' and a non-recurring struct is returned. The compiler reports an error because somehow it doesn't instantiate the 'rec' template lazily. In the example you've given there's an infinite theoretical nesting, yet in the version with the function, infinite nesting isn't possible, because the nesting increases one level with each 'rec' instantiation. IIRC, that's perfectly legit in C++ as it uses a different method for template instantiation.


> I'm not sure I'd want the compiler to try and "fix" a mistake I'd made involving this.  Adding an integer is pretty easy anyway.

Easy ? It's undocumented, tedious and generally weird. It might stop working in the next compiler version because I'm not even sure why DMD allows it.


-- 
Tomasz Stachowiak  /+ a.k.a. h3r3tic +/

Tom S wrote:
> Sean Kelly wrote:
>> I don't know.  To do so would be like allowing:
>>
>> struct S
>> {
>>     S val;
>> }
> 
> Umm... not quite. In your case it's just a plain nested, recursive struct which is obviously impossible. In my case:
> 
> struct Foo(T) {
>     Foo!(Foo!(T)) rec()() {
>         Foo!(Foo!(T)) res;
>         return res;
>     }
> }
> 
> When the function template is instantiated, one more nesting level is 'added' and a non-recurring struct is returned.

Oops, you're right.  I should have looked at the example more closely.

> The compiler reports an
> error because somehow it doesn't instantiate the 'rec' template lazily. In the example you've given there's an infinite theoretical nesting, yet in the version with the function, infinite nesting isn't possible, because the nesting increases one level with each 'rec' instantiation. IIRC, that's perfectly legit in C++ as it uses a different method for template instantiation.

Yeah.  I think the problem in D is that all template members are explicitly instantiated together instead of on an as-needed basis.  But as rec() is itself a template function I wouldn't have expected this behavior.  I agree that this should be changed, assuming it's possible to do so without entirely changing the way templates are instantiated in D.

>> I'm not sure I'd want the compiler to try and "fix" a mistake I'd made involving this.  Adding an integer is pretty easy anyway.
> 
> Easy ? It's undocumented, tedious and generally weird. It might stop working in the next compiler version because I'm not even sure why DMD allows it.

You're right.  Sorry for the confusion.


Sean

Sean Kelly wrote:
> Tom S wrote:
>> Sean Kelly wrote:
>>> I don't know.  To do so would be like allowing:
>>>
>>> struct S
>>> {
>>>     S val;
>>> }
>>
>> Umm... not quite. In your case it's just a plain nested, recursive struct which is obviously impossible. In my case:
>>
>> struct Foo(T) {
>>     Foo!(Foo!(T)) rec()() {
>>         Foo!(Foo!(T)) res;
>>         return res;
>>     }
>> }
>>
>> When the function template is instantiated, one more nesting level is 'added' and a non-recurring struct is returned.
> 
> Oops, you're right.  I should have looked at the example more closely.

Ah, you haven't noticed the second pair of parentheses after 'rec' ?


> Yeah.  I think the problem in D is that all template members are explicitly instantiated together instead of on an as-needed basis.  But as rec() is itself a template function I wouldn't have expected this behavior.  I agree that this should be changed, assuming it's possible to do so without entirely changing the way templates are instantiated in D.

Thanks for support :)


-- 
Tomasz Stachowiak  /+ a.k.a. h3r3tic +/

Sean Kelly wrote:
> Don Clugston wrote:
>> Sean Kelly wrote:
>>> Chris Nicholson-Sauls wrote:
>>>> Tom S wrote:
>>>>> ...DMD eats many many rams...
>>>>
>>>> *Gasp!*  Those poor sheep/goats!
>>>>
>>>> I would be interested in seeing exactly what your 'Input' mixin does.  The use of self-referancing returns to initialize it is pretty nifty though.  Might be a way to get rid of the '.end' at the end, though?
>>>>
>>>> The error baffles me, though.
>>>
>>> Symbols are limited to ~255 chars on Win32.  I think it's a limitation of the object file format.  "symbol too long" errors are painfully common in C++, though they're typically truncated to the max length to allow for debugging.
>>
>> I thought the OMF lib-imposed limit was about 4K. I've just made a template with a symbol name of 480 characters, and that was OK.
> 
> Perhaps it is--it's been a while since I developed on Windows.  I only remember seeing the errors quite often.
> 
>> Maybe in the future, we'll be able to add some kind of 'final' declaration to templates, which would indicate that they don't need to be stored in the object file or library, and can be discarded from the symbol table as soon as they are instantiated. This would be particularly useful for recursive templates, which can easily spew reams of garbage into the object file.
> 
> This would be nice.  I generally expect this to occur anyway, but it would be nice to have some sort of insurance.

It definitely happens, but I don't understand why they're in the obj at all (if I understand correctly, it has to happen that way in C++ because it's possible for a seperate obj file to provide a specialisation; but that's not an issue for D).

It's a real problem for the use of metaprogramming with DDL. The .objs can a be a megabyte in size, but contribute only a hundred bytes to the final exe. It would make linking much faster if it didn't happen, and it would probably improve compilation time.

Tom S wrote:
> Sean Kelly wrote:
>> I don't know.  To do so would be like allowing:
>>
>> struct S
>> {
>>     S val;
>> }
> 
> Umm... not quite. In your case it's just a plain nested, recursive struct which is obviously impossible. In my case:
> 
> struct Foo(T) {
>     Foo!(Foo!(T)) rec()() {
>         Foo!(Foo!(T)) res;
>         return res;
>     }
> }
> 
> When the function template is instantiated, one more nesting level is 'added' and a non-recurring struct is returned. The compiler reports an error because somehow it doesn't instantiate the 'rec' template lazily. In the example you've given there's an infinite theoretical nesting, yet in the version with the function, infinite nesting isn't possible, because the nesting increases one level with each 'rec' instantiation. IIRC, that's perfectly legit in C++ as it uses a different method for template instantiation.
> 
> 
>> I'm not sure I'd want the compiler to try and "fix" a mistake I'd made involving this.  Adding an integer is pretty easy anyway.
> 
> Easy ? It's undocumented, tedious and generally weird. It might stop working in the next compiler version because I'm not even sure why DMD allows it.
> 
> 

The compiler does always evaluate "lazily", and that is documented, although it may not be immediately obvious:
The template spec states that "Semantic analysis is not done until instantiated." which in other words means a template is not evaluated until instantiated. This remains true for nested templates, and thus for your example as well.
Then why the error message? My guess is that the error message is simply a mistake on part of the compiler, where the recursive template detection system gives a false positive (it thinks it will expand indefinitely but it won't). Thus it is a bug.


-- 
Bruno Medeiros - CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D

Don Clugston wrote:
> Sean Kelly wrote:
>> Chris Nicholson-Sauls wrote:
>>> Tom S wrote:
>>>> ...DMD eats many many rams...
>>>
>>> *Gasp!*  Those poor sheep/goats!
>>>
>>> I would be interested in seeing exactly what your 'Input' mixin does.  The use of self-referancing returns to initialize it is pretty nifty though.  Might be a way to get rid of the '.end' at the end, though?
>>>
>>> The error baffles me, though.
>>
>> Symbols are limited to ~255 chars on Win32.  I think it's a limitation of the object file format.  "symbol too long" errors are painfully common in C++, though they're typically truncated to the max length to allow for debugging.
> 
> I thought the OMF lib-imposed limit was about 4K. I've just made a template with a symbol name of 480 characters, and that was OK.
> If Tuple!() works with a nesting level of 50, the limit would have to be pretty big.
> Maybe in the future, we'll be able to add some kind of 'final' declaration to templates, which would indicate that they don't need to be stored in the object file or library, and can be discarded from the symbol table as soon as they are instantiated. This would be particularly useful for recursive templates, which can easily spew reams of garbage into the object file.

What are these templates that can be discarded from the object file? Is it templates that only contain compile-time members? Do these even take space in an object file (since they have no run-time members) ?


-- 
Bruno Medeiros - CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D

Bruno Medeiros wrote:
> Don Clugston wrote:
>> Sean Kelly wrote:
>>> Chris Nicholson-Sauls wrote:
>>>> Tom S wrote:
>>>>> ...DMD eats many many rams...
>>>>
>>>> *Gasp!*  Those poor sheep/goats!
>>>>
>>>> I would be interested in seeing exactly what your 'Input' mixin does.  The use of self-referancing returns to initialize it is pretty nifty though.  Might be a way to get rid of the '.end' at the end, though?
>>>>
>>>> The error baffles me, though.
>>>
>>> Symbols are limited to ~255 chars on Win32.  I think it's a limitation of the object file format.  "symbol too long" errors are painfully common in C++, though they're typically truncated to the max length to allow for debugging.
>>
>> I thought the OMF lib-imposed limit was about 4K. I've just made a template with a symbol name of 480 characters, and that was OK.
>> If Tuple!() works with a nesting level of 50, the limit would have to be pretty big.
>> Maybe in the future, we'll be able to add some kind of 'final' declaration to templates, which would indicate that they don't need to be stored in the object file or library, and can be discarded from the symbol table as soon as they are instantiated. This would be particularly useful for recursive templates, which can easily spew reams of garbage into the object file.
> 
> What are these templates that can be discarded from the object file? Is it templates that only contain compile-time members? Do these even take space in an object file (since they have no run-time members) ?

Yes, they take up a lot of space in the object file (can be megabytes).

eg, if the source file contains
int f = factorial!(7),

then the object file will also contain the useless intermediates factorial!(6), factorial!(5),...factorial!(1). The unused ones don't get discarded until link time. I'm not sure why they're in the obj file at all, but they certainly get in there.

Don Clugston wrote:
> Bruno Medeiros wrote:
>> Don Clugston wrote:
>>> Sean Kelly wrote:
>>>> Chris Nicholson-Sauls wrote:
>>>>> Tom S wrote:
>>>>>> ...DMD eats many many rams...
>>>>>
>>>>> *Gasp!*  Those poor sheep/goats!
>>>>>
>>>>> I would be interested in seeing exactly what your 'Input' mixin does.  The use of self-referancing returns to initialize it is pretty nifty though.  Might be a way to get rid of the '.end' at the end, though?
>>>>>
>>>>> The error baffles me, though.
>>>>
>>>> Symbols are limited to ~255 chars on Win32.  I think it's a limitation of the object file format.  "symbol too long" errors are painfully common in C++, though they're typically truncated to the max length to allow for debugging.
>>>
>>> I thought the OMF lib-imposed limit was about 4K. I've just made a template with a symbol name of 480 characters, and that was OK.
>>> If Tuple!() works with a nesting level of 50, the limit would have to be pretty big.
>>> Maybe in the future, we'll be able to add some kind of 'final' declaration to templates, which would indicate that they don't need to be stored in the object file or library, and can be discarded from the symbol table as soon as they are instantiated. This would be particularly useful for recursive templates, which can easily spew reams of garbage into the object file.
>>
>> What are these templates that can be discarded from the object file? Is it templates that only contain compile-time members? Do these even take space in an object file (since they have no run-time members) ?
> 
> Yes, they take up a lot of space in the object file (can be megabytes).
> 
> eg, if the source file contains
> int f = factorial!(7),
> 
> then the object file will also contain the useless intermediates factorial!(6), factorial!(5),...factorial!(1). The unused ones don't get discarded until link time. I'm not sure why they're in the obj file at all, but they certainly get in there.

Then that means a language construct would not be necessary, as the compiler or linker should be able themselves to know not to generate empty template sections. And that seems easy to implement, at least at first sight (if it requires changing optlink we might not be so lucky).

-- 
Bruno Medeiros - CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D