View mode: basic / threaded / horizontal-split · Log in · Help
December 18, 2009
Re: What's wrong with D's templates?
On 18/12/2009 17:34, dsimcha wrote:
> == Quote from Yigal Chripun (yigal100@gmail.com)'s article
>> I don't know Ada but I do agree with that reddit reply about c++ and D
>> templates. D provides a better implementation of the exact same design,
>> so it does fix many minor issues (implementation bugs).
>
> I think variadics, static if and alias parameters qualify more as a "better
> design" than fixing "minor issues".

actually they qualify as - "even worse design". duplicating the syntax 
like that is butt ugly.

>
>> An example of
>> this is the foo<bar<Class>>  construct that doesn't work because of the
>> ">>" operator.
>> However, using the same design obviously doesn't solve any of the deeper
>> design problems and this design has many of those. An example of that is
>> that templates are compiled as part of the client code. This forces a
>> library writer to provide the source code (which might not be acceptable
>> in commercial circumstances)
>
> There's always obfuscation.  I think people underestimate this.  If you strip out
> all comments and meaningful names (I won't mention mangling whitespace because
> that's programmatically reversible), trade secrets are reasonably well protected.
>   Remember, people can always disassemble your library.  I don't see obfuscated D
> code with names and comments stripped as being **that** much easier to understand
> than a disassembly.

this is the least of the problems of that design. The biggest problem 
IMO is the conflation of user-code and library code.

>
>> but even more frustrating is the fact that
>> template compilation bugs will also happen at the client.
>> There's a whole range of designs for this and related issues and IMO the
>> C++ design is by far the worst of them all. not to mention the fact that
>> it isn't an orthogonal design (like many other "features" in c++). I'd
>> much prefer a true generics design to be separated from compile-time
>> execution of code with e.g. CTFE or AST macros, or other designs.
>
> Since generics work by basically casting stuff to Object (possibly boxing it) and
> casting back, I wonder if it would be easy to implement generics on top of
> templates through a minimal wrapper.  The main uses for this would be executable
> bloat (for those that insist that this matters in practice) and allowing virtual
> functions where templates can't be virtual.

generics have nothing to do with casting and/or boxing (except Java's 
poor excuse of a design/implementation).
.Net generics for example work by creating an instantiation for each 
value type (same as c++ templates) and one instantiation for all 
reference types since at the binary level all reference types are simply 
addresses. C++ can't do this since it has no separation between 
"structs" and "classes".
there is no casting involved since the full type info is stored.
so a Foo<Bar> will be typed as Foo<Bar> at the binary level as well and 
you can use APIs to query this at runtime.

in .Net it's part of the IL, in D this can be done by mangling the type 
info into the symbol's name.
December 18, 2009
Re: What's wrong with D's templates?
On 18/12/2009 22:09, BCS wrote:
> Hello Yigal,
>
>> On 18/12/2009 02:49, Tim Matthews wrote:
>>
>>> In a reddit reply: "The concept of templates in D is exactly the same
>>> as in C++. There are minor technical differences, syntactic
>>> differences, but it is essentially the same thing. I think that's
>>> understandable since Digital Mars had a C++ compiler."
>>>
>>> http://www.reddit.com/r/programming/comments/af511/ada_programming_ge
>>> nerics/c0hcb04?context=3
>>>
>>> I have never touched ada but I doubt it is really has that much that
>>> can't be done in D. I thought most (if not all) the problems with C++
>>> were absent in D as this summary of the most common ones points out
>>> http://www.digitalmars.com/d/2.0/templates-revisited.html.
>>>
>>> Your thoughts?
>>>
>> I don't know Ada but I do agree with that reddit reply about c++ and D
>> templates. D provides a better implementation of the exact same
>> design,
>> so it does fix many minor issues (implementation bugs). An example of
>> this is the foo<bar<Class>> construct that doesn't work because of the
>> ">>" operator.
>> However, using the same design obviously doesn't solve any of the
>> deeper
>> design problems and this design has many of those. An example of that
>> is
>> that templates are compiled as part of the client code. This forces a
>> library writer to provide the source code (which might not be
>> acceptable
>> in commercial circumstances) but even more frustrating is the fact
>> that
>> template compilation bugs will also happen at the client.
>> There's a whole range of designs for this and related issues and IMO
>> the C++ design is by far the worst of them all. not to mention the
>> fact that it isn't an orthogonal design (like many other "features" in
>> c++). I'd much prefer a true generics design to be separated from
>> compile-time execution of code with e.g. CTFE or AST macros, or other
>> designs.
>>
>
> If D were to switch to true generics, I for one would immediately start
> looking for ways to force it all back into compile time. I think that
> this would amount to massive use of CTFE and string mixins.
>
> One of the things I *like* about template is that it does everything at
> compile time.
>
> That said, I wouldn't be bothered by optional generics or some kind of
> compiled template where a lib writer can ship a binary object (JVM
> code?) that does the template instantiation at compile time without the
> text source. (The first I'd rarely use and the second would just be an
> obfuscation tool, but then from that standpoint all compilers are)
>
>
you are confused - the term "generics" refers to writing code that is 
parametrized by type(s). it has nothing to do with JVM or the specific 
Java implementation of this idea. Java's implementation is irrelevant to 
our discussion since it's broken by design in order to accommodate 
backward compatibility.

generics != Java generics !!!

Generics are also orthogonal to meta-programming.

please also see my reply to dsimcha.
December 18, 2009
Re: What's wrong with D's templates?
Sat, 19 Dec 2009 00:24:50 +0200, Yigal Chripun wrote:

> to retard:
> different problems should be solved with different tools. Macros should
> be used for meta-programming and generics for type-parameters. they
> don't exclude each other. E.g. Nemerle has an awesome macro system yet
> it also has .net generics too.
> As the saying goes -"when all you got is a hammer everything looks like
> a nail" which is a very bad situation to be in. templates are that
> hammer while a much better approach is to go and by a toolbox with
> appropriate tools for your problem set.

I didn't say anything that contradicts this.
December 18, 2009
Re: What's wrong with D's templates?
Yigal Chripun wrote:

> On 18/12/2009 02:49, Tim Matthews wrote:
>> In a reddit reply: "The concept of templates in D is exactly the same as
>> in C++. There are minor technical differences, syntactic differences,
>> but it is essentially the same thing. I think that's understandable
>> since Digital Mars had a C++ compiler."
>>
>> 
http://www.reddit.com/r/programming/comments/af511/ada_programming_generics/c0hcb04?context=3
>>
>>
>> I have never touched ada but I doubt it is really has that much that
>> can't be done in D. I thought most (if not all) the problems with C++
>> were absent in D as this summary of the most common ones points out
>> http://www.digitalmars.com/d/2.0/templates-revisited.html.
>>
>> Your thoughts?
> 
> I don't know Ada but I do agree with that reddit reply about c++ and D
> templates. D provides a better implementation of the exact same design,
> so it does fix many minor issues (implementation bugs). An example of
> this is the foo<bar<Class>> construct that doesn't work because of the
> ">>" operator.
> However, using the same design obviously doesn't solve any of the deeper
> design problems and this design has many of those. An example of that is
> that templates are compiled as part of the client code. This forces a
> library writer to provide the source code (which might not be acceptable
> in commercial circumstances) but even more frustrating is the fact that
> template compilation bugs will also happen at the client.

Well yes, but the .NET design restrict the generic type to a specific named 
interface in order to do type checking. You may find this a good design 
choice, but others find it far more frustrating because this is exactly what 
allows for a bit more flexibility in a statically typed world. So it is not 
exactly a problem but rather a trade-off imho.
December 19, 2009
Re: What's wrong with D's templates?
Yigal Chripun:

>To bearophile: you're mistaken on all counts -<

Yes, this happens every day here :-)
I am too much ignorant still about computer science to be able to discuss in this newsgroup in a good enough way.


>generics (when properly implemented) will provide the same performance as templates.<

I was talking about a list of current language implementations.


>Also, a VM is completely orthogonal to this. Ada ain't VM based, is it?<

Ada doesn't use the generics how currently C# implement them. Currently C# generics need a VM.


>Macros should be used for meta-programming and generics for type-parameters.<

This can be true, but there's a lot of design to do to implement that well.
In Go there are no generics/templates nor macros. So generics and macros can be added, as you say.
In D2 there are templates and no macros, so in D3 macros may be added but how can you design a D3 language where templates are restricted enough to become generics? Unless D3 breaks a lot of backwards compatibility with D2 you will end in D3 with templates + macros + language conventions that tell to not use templates when macros can be used. Is this good enough?

Bye,
bearophile
December 19, 2009
Re: What's wrong with D's templates?
Yigal Chripun:

> .Net generics for example work by creating an instantiation for each 
> value type (same as c++ templates) and one instantiation for all 
> reference types since at the binary level all reference types are simply 
> addresses. C++ can't do this since it has no separation between 
> "structs" and "classes".
> there is no casting involved since the full type info is stored.
> so a Foo<Bar> will be typed as Foo<Bar> at the binary level as well and 
> you can use APIs to query this at runtime.

In D structs and classes are distinct enough, but they currently produce duplicated templated code, this may be fixed:

void foo(T)(T o) {
   printf("foo: %d\n", o.y);
}

class A { int x = 1; }
class B : A { int y = 2; }
class C : A { int y = 3; }

void main() {
   B b = new B();
   C c = new C();
   foo(b);
   foo(c);
}

/*
DMD1:

_D4temp17__T3fooTC4temp1BZ3fooFC4temp1BZv   comdat
       push    EAX
       mov ECX,offset FLAT:_D4temp1C6__vtblZ[018h]
       push    dword ptr 0Ch[EAX]
       push    ECX
       call    near ptr _printf
       add ESP,8
       pop EAX
       ret

_D4temp17__T3fooTC4temp1CZ3fooFC4temp1CZv   comdat
       push    EAX
       mov ECX,offset FLAT:_D4temp1C6__vtblZ[018h]
       push    dword ptr 0Ch[EAX]
       push    ECX
       call    near ptr _printf
       add ESP,8
       pop EAX
       ret


LDC:

_D13testtemplates27__T3fooTC13testtemplates1BZ3fooFC13testtemplates1BZv:
   subl    $12, %esp
   movl    12(%eax), %eax
   movl    %eax, 4(%esp)
   movl    $.str3, (%esp)
   call    printf
   addl    $12, %esp
   ret

_D13testtemplates27__T3fooTC13testtemplates1CZ3fooFC13testtemplates1CZv:
   subl    $12, %esp
   movl    12(%eax), %eax
   movl    %eax, 4(%esp)
   movl    $.str3, (%esp)
   call    printf
   addl    $12, %esp
   ret
*/

Bye,
bearophile
December 19, 2009
Re: What's wrong with D's templates?
On 19/12/2009 01:31, Lutger wrote:
> Yigal Chripun wrote:
>
>> On 18/12/2009 02:49, Tim Matthews wrote:
>>> In a reddit reply: "The concept of templates in D is exactly the same as
>>> in C++. There are minor technical differences, syntactic differences,
>>> but it is essentially the same thing. I think that's understandable
>>> since Digital Mars had a C++ compiler."
>>>
>>>
> http://www.reddit.com/r/programming/comments/af511/ada_programming_generics/c0hcb04?context=3
>>>
>>>
>>> I have never touched ada but I doubt it is really has that much that
>>> can't be done in D. I thought most (if not all) the problems with C++
>>> were absent in D as this summary of the most common ones points out
>>> http://www.digitalmars.com/d/2.0/templates-revisited.html.
>>>
>>> Your thoughts?
>>
>> I don't know Ada but I do agree with that reddit reply about c++ and D
>> templates. D provides a better implementation of the exact same design,
>> so it does fix many minor issues (implementation bugs). An example of
>> this is the foo<bar<Class>>  construct that doesn't work because of the
>> ">>" operator.
>> However, using the same design obviously doesn't solve any of the deeper
>> design problems and this design has many of those. An example of that is
>> that templates are compiled as part of the client code. This forces a
>> library writer to provide the source code (which might not be acceptable
>> in commercial circumstances) but even more frustrating is the fact that
>> template compilation bugs will also happen at the client.
>
> Well yes, but the .NET design restrict the generic type to a specific named
> interface in order to do type checking. You may find this a good design
> choice, but others find it far more frustrating because this is exactly what
> allows for a bit more flexibility in a statically typed world. So it is not
> exactly a problem but rather a trade-off imho.

The .Net implementation isn't perfect of course and has a few issues 
that should be resolved, one of these is the problem with using 
operators. requiring interfaces by itself isn't the problem though. The 
only drawback in this case is verbosity which isn't really a big deal 
for this.
December 19, 2009
Re: What's wrong with D's templates?
On 19/12/2009 01:08, retard wrote:
> Sat, 19 Dec 2009 00:24:50 +0200, Yigal Chripun wrote:
>
>> to retard:
>> different problems should be solved with different tools. Macros should
>> be used for meta-programming and generics for type-parameters. they
>> don't exclude each other. E.g. Nemerle has an awesome macro system yet
>> it also has .net generics too.
>> As the saying goes -"when all you got is a hammer everything looks like
>> a nail" which is a very bad situation to be in. templates are that
>> hammer while a much better approach is to go and by a toolbox with
>> appropriate tools for your problem set.
>
> I didn't say anything that contradicts this.

Did you read any arguing in the above? I thought I was agreeing with 
you.. :)
December 19, 2009
Re: What's wrong with D's templates?
On 19/12/2009 02:43, bearophile wrote:
> Yigal Chripun:
>
>> To bearophile: you're mistaken on all counts -<
>
> Yes, this happens every day here :-) I am too much ignorant still
> about computer science to be able to discuss in this newsgroup in a
> good enough way.
>

didn't mean to sound that harsh. sorry about that.
>
>> generics (when properly implemented) will provide the same
>> performance as templates.<
>
> I was talking about a list of current language implementations.
>
>
>> Also, a VM is completely orthogonal to this. Ada ain't VM based, is
>> it?<
>
> Ada doesn't use the generics how currently C# implement them.
> Currently C# generics need a VM.

they were implemented for a VM based system but nothing in the *design* 
itself inherently requires a VM. You keep talking about implementation 
details while I try to discuss the design aspects and trad-offs. It's 
obvious that we can't just copy-paste the .NET implementation to D.


>> Macros should be used for meta-programming and generics for
>> type-parameters.<
>
> This can be true, but there's a lot of design to do to implement that
> well. In Go there are no generics/templates nor macros. So generics
> and macros can be added, as you say. In D2 there are templates and no
> macros, so in D3 macros may be added but how can you design a D3
> language where templates are restricted enough to become generics?
> Unless D3 breaks a lot of backwards compatibility with D2 you will
> end in D3 with templates + macros + language conventions that tell to
> not use templates when macros can be used. Is this good enough?
>
> Bye, bearophile

I don't know about D3, But even now in D2 there is confusion as to what 
should be implemented with templates and what with CTFE.
December 19, 2009
Re: What's wrong with D's templates?
Sat, 19 Dec 2009 15:19:16 +0200, Yigal Chripun wrote:

> On 19/12/2009 01:08, retard wrote:
>> Sat, 19 Dec 2009 00:24:50 +0200, Yigal Chripun wrote:
>>
>>> to retard:
>>> different problems should be solved with different tools. Macros
>>> should be used for meta-programming and generics for type-parameters.
>>> they don't exclude each other. E.g. Nemerle has an awesome macro
>>> system yet it also has .net generics too.
>>> As the saying goes -"when all you got is a hammer everything looks
>>> like a nail" which is a very bad situation to be in. templates are
>>> that hammer while a much better approach is to go and by a toolbox
>>> with appropriate tools for your problem set.
>>
>> I didn't say anything that contradicts this.
> 
> Did you read any arguing in the above? I thought I was agreeing with
> you.. :)

Ok, sorry :) It just sounded like a lecture. I was well aware of all 
this. I sometimes forget that not everyone knows what we are discussing 
here.
1 2 3 4 5 6
Top | Discussion index | About this forum | D home