D User Poll (page 5)

August 25, 2003

Re: D User Poll

Posted by Walter
in reply to Peter Hercek

Permalink

Walter

Posted in reply to Peter Hercek

Permalink

That does help clear it up. Thanks. BTW, D does support nested templates.

"Peter Hercek" <vvp@no.post.spam.sk> wrote in message news:bibpjk$1q6m$1@digitaldaemon.com...
> I do not know D, I know C++ a little. I think, I know what Daniel wants.
> I try to explain in C++ nomenclature (I'll abreviate COLUMNS to COLS):
> * class Matrix is like C++ template class:
>     template<typename T, int ROWS, int COLS> class Matrix;
> * class method mull is like C++ member template method of a (templated)
class;
>   in C++ it would look like this when defined within Matrix body:
>     template<int N> Matrix<T,ROWS,N> mul(Matrix<T,COLS,N> other);
>   or like this when defined outside of class Matrix:
>     template<typename T, int ROWS, int COLS>
>     template<int N>
>     Matrix<T,ROWS,N> Matrix<T,ROWS,COLS>::mul(Matrix<T,COLS,N> other);
> * ie Matrix<T,ROWS,COLS> contains potentionally infinite number of methods
mul
>   as part of its definition
> * what is Daniel saying is that in this case explicit instatination of D
language is a pain,
>   because you do need not only to explicitly intantiate classes
Matrix<T,ROWS,COLS>,
>   Matrix<T,ROWS,N> and Matrix<T,COLS,N> (ie all the matrices used), but
also
>   all the methods mul which are possible or better which are used, to
multiply these
>   matrices; so Daniel is proposing to introduce implicit instatiations for
member templates
>   and template argument deduction for them (he wants [inner] template
argument N to
>   be deducted from "other" argument of mul method ... probably the same
way as C++
>   would do it)
> * as for as infinite recursion problem, I think that here you think too
much in a way how
>   you have template explicit instation implemented and Daniel is at a too
high level; imagine
>   that Daniel used in his examples keyword painstance instead of
instatnce; painstance
>   would not start the whole process of code generation (which would
probably result in
>   infinite recursion in your current implementation), but only prepare typ
e to which an
>   alias can be created; the point is that OtherMatrich and ResultMatrix
are not part of
>   Matrix template; they are only referenced there with "painstance" :) ...
no problem with
>   infinite recursion; there is still a problem with creating instances for
all the possible/used
>   mull method for each Matrix type
> * I'm not sure whether D handles nested templates at all...
> * the secon example is exactly the same idea, with only one exception and
it is that
>   it requires constat expresions to be possible for template arguments, I
think this is
>   not possible in C++ (please correct me if I'm wrong), but in C++ you can
use an
>   workaround with some enums
> * the key to understand it is this C++ nomenclature: member template,
implicit instantiation,
>   template argument deduction (for [member] function templates)
>
> hope this helps
>
> "Walter" <walter@digitalmars.com> wrote in message
news:bib45j$qos$1@digitaldaemon.com...
> >
> [snip]
> > > > > template TMatrix(T, int ROWS, int COLUMNS) {
> > > > >     class Matrix {
> > > > >         private T[] data = new T[ROWS * COLUWNS];
> > > > >         public Matrix add(Matrix other) {
> > > > >             // code goes here
> > > > >         }
> > > > >         template implicit (N) {
> > > > > /* "implicit" is a keyword to make a template with implicit
instantiation.
> > > > >  * we could also use the "this" keyword or whatever, as long as
the programmer
> > > > >  * doesn't need to write something like "A instance
A.TMul(B.columns()).mul(B)" to
> > > > >  * safely multiply the A and B matrices.
> > > > >  */
> > > > >             alias instance TMatrix(T, COLUMNS, N).Matrix
OtherMatrix;
> here should be painstance :)
>
> > > > >             alias instance TMatrix(T, ROWS, N).Matrix
ResultMatrix;
> here should be painstance
>
> > > > >             public ResultMatrix mul(OtherMatrix other) {
> > > > >                 // code goes here
> > > > >             }
> > > > >         }
> > > > >     }
> > > > > }
> [snip]
> > > > > template TUnit(T, int C, int G, int S) {
> > > > >     struct Unit {
> > > > >         private T value;
> > > > >         public Unit add(Unit other) {
> > > > >             // code goes here
> > > > >         }
> > > > >         template implicit (C1, G1, S1) {
> > > > >             alias instance TUnit(T, C1, G1, S1).Unit OtherUnit;
> here should be painstance
>
> > > > >             alias instance TUnit(T, C + C1, G + G1, S + S1).Unit
ResultUnit;
> here should be painstance
>
> > > > >             public ResultUnit mul(OtherUnit other) {
> > > > >                 // code goes here
> > > > >             }
> > > > >         }
> > > > >         // other methods here
> > > > >     }
> > > > > }
> > > > > template TUnits(T) {
> > > > >     alias instance TUnit(T, 1, 0, 0).Unit Length;
> > > > >     alias instance TUnit(T, 0, 1, 0).Unit Mass;
> > > > >     alias instance TUnit(T, 0, 0, 1).Unit Time;
> > > > >     alias instance TUnit(T, 1, 0, -1).Unit Speed;
> > > > >     alias instance TUnit(T, 1, 0, -2).Unit Acceleration;
> > > > >     const Length meter = {100};
> > > > >     const Time second = {1};
> > > > > }
> > > > > // all operations below should be statically verified
> > > > > instance TUnits(double).Acceleration a = 2 * meter / (second *
second);
> > > > > instance TUnits(double).Length l = 10 * meter;
> > > > > instance TUnits(double).Speed s = a * l;
> [snip]
>
>

> >     My other example involving statically-typed units would become:
> >
> > template TUnit(T, int C, int G, int S) {
> >     struct Unit {
> >         private T value;
> >         public Unit add(Unit other) {
> >             // code goes here
> >         }
> >         template implicit (C1, G1, S1) {
> >             alias instance TUnit(T, C1, G1, S1).Unit OtherUnit;
> >             alias instance TUnit(T, C + C1, G + G1, S + S1).Unit
> ResultUnit;
> >             public ResultUnit mul(OtherUnit other) {
> >                 // code goes here
> >             }
> >         }
> >         // other methods here
> >     }
> > }
[...two levels of quoting snipped]

In article <bib45j$qos$1@digitaldaemon.com>, Walter wrote:
> I'm also quite lost here as to why this would not instantiate TUnit with infinite recursion.

It indeed would, and we don't want that. So make it so that it won't. :-)

*ahem* Seriously. Would it possibly be feasible to allow template instantiation to be lazy, so that the template would be instantiated only when it used?

C++ does something like this. I think. But on the other hand, horror stories are told about its instantiation rules, complexity, lack of portability between subtly different incompatible compiler vendors etc. etc.  Well, everything Walter should be well aware of.

Certainly, as we can see from the example, lazy template instantiation would make the type system more powerful as it would allow template instances to depend on other templates in interesting ways.

By the way - is the "instance" keyword necessarily needed? I'd guess its primary meaning is to make parsing easier, but as a human reader I don't think it makes the code any more clearer.  Without the instance keyword, template instantiations would look the same as function calls, agreed, but this could be remedied by using a convention where templates start with a capital letter and functions with lowercase letter.  Besides, whether we're looking at a template instantiation is often clear from the context.

Again, I'm thinking C++ -- blame me for homesickness -- where template declaration/definition syntax can be complex but at least the instantiation syntax is simple and legible: TUnit<1,2,3> unit;

-Antti

Forums