What's wrong with D's templates?

[BCS]

Hello Yigal,

> 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).

I've never looked into them in detail but I think I'm taking about the same 
idea as you are.

To be clear, the aspect of generics that I dislike is the part that has them 
use the exact same code for all cases. The aspect of true templates that 
I like is that the template gets specialized for the type very early in the 
compile process. That name lookup is done after the type is know. That code 
gen happens after all (or at least most) of the things that make it a template 
are gone. That the resulting code can take full advantage of all the details 
of the actual type the template is instantiated on rather than being limited 
to merely the things they are true of everything it could be used with. And 
that ALL of that is over and done (including all possible template related 
errors) with befor runtime time.

That is the aspect of generics vs template that I care about. The actual 
implementation doesn't bother me a bit. Heck, if you can get all of that 
in something that gives you the bits of generics you want, I'd be happy

> 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.

I actually have no clue how the Java generics work and for what I'm proposing, 
using a JVM would be purely an implementation detail. In fact it is very 
likely that Java generics would NOT be used anywhere in the system


What I was proposing is that when someone wants to ship a template lib without 
the source, they would compile it into a JVM file that the compiler would 
load. This file WOULD NOT be put right into the final binary but rather be 
loaded by the compiler and used by the compiler to instantiate a template. 
Whatever functions from the file that the compiler calls would take the place 
of the code in the compiler that normally instantiates a template; that is, 
function would generate an AST or IL blob that would get passed to the backend.

Note, using the JVM for this is an implementation detail. You could just 
as easily use Linux shared objects, DLLs, DDl, .NET assemblies, JavaScript, 
Python, Lua, perl, LISP, or BF. The point is that rather than ship template 
source, you ship a program that, when run, does the instantiation of the 
template. What form this program is shipped in as a minor detail as far as 
I'm concerned.

> generics != Java generics !!!
> 
> Generics are also orthogonal to meta-programming.
> 

Yes they are orthogonal. However the same is less true with regards to the 
aspects of templates that I want. For example, without some bits of meta-programing, 
you can't do most of what I want and with a really good meta-programing system, 
you wouldn't need any template specific features at all except as sugar. 

> please also see my reply to dsimcha.
>