• Daniel Yokomiso (21/21) Nov 25 2002 Hi,
• Walter (7/28) Nov 25 2002 Cool!
• Walter (6/8) Nov 28 2002 under
• Daniel Yokomiso (175/183) Nov 28 2002 Hi,
• Walter (53/178) Nov 29 2002 Working like magic always made me uncomfortable, I always need to know j...
• Evan McClanahan (18/306) Nov 29 2002 Some things. First, I quite like the idea of templated modules being
• Daniel Yokomiso (14/31) Nov 29 2002 Hi,
• Daniel Yokomiso (49/75) Nov 29 2002 Reply embedded.
• Walter (14/97) Nov 29 2002 I'm slowly warming to the idea of using 'import' for template instances ...

"Daniel Yokomiso" <daniel_yokomiso yahoo.com.br> writes:

Hi,

    I'm releasing version 0.0.1 of the Deimos Template Library for D, under
the LGPL license. This initial release includes some template array
functions, most of them from Burton Radons' "Array handling" post. Other
stuff in the DTL: Range template classes, RangeSet template classes, a
fraction class and some very simple templates for everyday programming.
    The zip including makefile is available at:

        http://www.minddrome.com/d/deimos/deimos-0.0.1.zip

    It's designed with lots of unit tests and contracts in many functions,
but no documentation currently. Requests for documentation, bugfixes,
enhancements and other stuff will be accepted. I'm planning to release it
via opend.org until next friday, so community work will be available. In the
zip exists a vowels.d file with a simple usage of the library. A make (dmd)
run will execute unittests.
    I intend to work on matrix and numeric libraries in the next couple of
weeks, porting BLAS-like libraries.

    Best regards,
    Daniel Yokomiso.

"I'm not saying there should be a capital punishment for stupidity, but why
don't we just take the safety labels off of everything and let the problem
solve itself?"

"Walter" <walter digitalmars.com> writes:

Cool!

"Daniel Yokomiso" <daniel_yokomiso yahoo.com.br> wrote in message
news:artv39$o0a$1 digitaldaemon.com...
 Hi,

     I'm releasing version 0.0.1 of the Deimos Template Library for D,

under
 the LGPL license. This initial release includes some template array
 functions, most of them from Burton Radons' "Array handling" post. Other
 stuff in the DTL: Range template classes, RangeSet template classes, a
 fraction class and some very simple templates for everyday programming.
     The zip including makefile is available at:

         http://www.minddrome.com/d/deimos/deimos-0.0.1.zip

     It's designed with lots of unit tests and contracts in many functions,
 but no documentation currently. Requests for documentation, bugfixes,
 enhancements and other stuff will be accepted. I'm planning to release it
 via opend.org until next friday, so community work will be available. In

the
 zip exists a vowels.d file with a simple usage of the library. A make

(dmd)
 run will execute unittests.
     I intend to work on matrix and numeric libraries in the next couple of
 weeks, porting BLAS-like libraries.

     Best regards,
     Daniel Yokomiso.

 "I'm not saying there should be a capital punishment for stupidity, but

why
 don't we just take the safety labels off of everything and let the problem
 solve itself?"

"Walter" <walter digitalmars.com> writes:

"Daniel Yokomiso" <daniel_yokomiso yahoo.com.br> wrote in message
news:artv39$o0a$1 digitaldaemon.com...
     I'm releasing version 0.0.1 of the Deimos Template Library for D,

under
 the LGPL license.

Since you're an expert with both D templates and templates in other
languages, I'd be very interested in your opinions on D template "look and
feel" compared with C++'s.

"Daniel Yokomiso" <daniel_yokomiso yahoo.com.br> writes:

"Walter" <walter digitalmars.com> escreveu na mensagem
news:as5r9b$f7j$2 digitaldaemon.com...
 "Daniel Yokomiso" <daniel_yokomiso yahoo.com.br> wrote in message
 news:artv39$o0a$1 digitaldaemon.com...
     I'm releasing version 0.0.1 of the Deimos Template Library for D,

 under
 the LGPL license.

 Since you're an expert with both D templates and templates in other
 languages, I'd be very interested in your opinions on D template "look and
 feel" compared with C++'s.

Hi,

    Hey, thanks for the title :-) . My knowledge comes more from studies and
reading than from proper coding (I'm a language designer too, so I study
lots of languages for my pet language Eon).
    Well first a brief disclaimer: IMHO C++ is a wonderful language to
study, one of the most comprehensive multi-paradigm languages, but is a pain
to work with.
    C++ templates have a wizardry feel to the novice. Template usage is
quite simple, implicit instantiation works like magic. But sometimes strange
things happen and the reasons for this behavior is difficult to grasp, error
messages are cryptic and reading the source codes for the templates is an
experts task. To the initiated in template idioms, it still looks like
magic, but they can write very powerful templates to solve lots of problems.
Papers from http://www.oonumerics.org/oon/#reference are very relevant to
understand the capabilities of C++ templates. Most of its power comes from
partial instantiation and template specialization. One example from Todd
Veldhuizen's 'Template Metaprograms' is the factorial template:


template<int N>
class Factorial {
public:
    enum {value = N * Factorial<N-1>::value};
};

class Factorial<1> {
public:
    enum {value = 1};
};


    This template uses a specialized template version for N = 1, and defines
a recursive template that when compiled will compute the factorial. A
brilliant usage of this techniques is used in the Blitz++ library
(http://www.oonumerics.org/blitz/manual/Frames.html). But reading their
sources requires experience with C++.
    D templates on the other hand are quite easy to write and understand (if
you're familiar with generic programming techniques from other languages).
But its usage is verbose and sometimes very cumbersome to use. This is a
code snippet from DTL (Deimos Template Library) of a Matrix method to
calculate the product of two matrices:

public Matrix times (Matrix other)
in {
// rows and columns provide the number of rows and columns of a matrix
    assert(other.rows() == columns());
} out(result) {
    assert(rows() == result.rows());
    assert(other.columns() == result.columns());
} body {
// creates the result matrix
    Matrix res = new Matrix(rows(), other.columns());
// explicit instantiation of two templates from DTL
    instance TFunctionalArrays(T, T, T) func2;
    for (int j = 0; j < other.columns(); j++) {
        for (int i = 0; i < rows(); i++) {

// functional idiom to compute the products of two arrays
// ops is a template instance to provide generic basic arithmetic operations
// row(int) and column(int) return the selected row and column as an array
            T[] products = func2.map(row(i), other.column(j), &ops.mul);

            res.set(i, j, ops.sum(products, zero));
        }
    }
    return res;
}

    From this code snippet you can see the primary problem with D template
syntax: it's difficult to write terse code when you need to refer to
explicitly instantiate templates and refer to this template instances
through the code. Also current limitations on operator overloading doesn't
allow us to use matrices like we use arrays, or to provide numeric operator
to numeric arrays. If that was possible we could write:


public Matrix times (Matrix other)
    Matrix res = new Matrix(rows(), other.columns());
    firstIndex i;
    secondIndex j;
    res[i,j] = sum(row(i) * other.column(j));
    return res;
}


    In this example firstIndex and secondIndex are Blitz++-like tensors
(http://www.oonumerics.org/blitz/manual/blitz03.html#l75). No need to
reference  explicitly to TOperations(T) instance (defines sum function and
numeric array operators), also no need to explicitly define for-loops or
zero value (this is passed as a template value parameter). This version
express better the syntax than the first one;
    The main problem with D template look and feel is that they're too
heavy-weight to use. Writing templates in D is easy, but using them has an
unnatural feeling. A template function use is different from a regular
function use. Statically typed functional programming depends heavily on
type inference mechanisms, so the programmer just need to express the
algorithm and the compiler can safely determine the types of the
expressions. A simple function composition ( . is defines, in most
functional languages the function composition operator) is expressed as
(Haskell prelude definitions):


(.) :: (b -> c) -> (a -> b) -> (a -> c)
(f . g) x = f (g x)


    It's powerful because it's generic, expressive and safe to use. The
programmer just write '((3+).(5*)) 6' and the compiler figures out the rest
(the expression value is 33, if someone is curious). If the programmer was
required to write explicit references to the function composition operator,
instead of a simple dot notation, there is a higher chance of the programmer
rewriting the code to avoid the complications. In DTL we have two simple
functions first and rest that operates on arrays, giving respectively
array[0] and array[1..array.length]. If I need to write:


instance TArrays(char) arrays;
printf("first is '%c' and the rest is '%.*s'\r\n", arrays.first(text),
arrays.rest(text));


I'll probably won't bother using it at all and rewrite the code. If instead
I can write:


printf("first is '%c' and the rest is '%.*s'\r\n", first(text), rest(text));


I'll probably incorporate first and rest in my set of useful tools (because
they express the intent not the implementation used). Small templates are
useful to reduce code duplication, but they add more complexity than needed.
If the template encapsulated complexity is greater than the complexity of
thinking about explicit instantiation and explicit references, then it'll be
used.
    My conclusion is that C++ template writing has a different feel than
regular C++ coding, but they can be used naturally in the language. D goes
the other way around. The good news is that C++ templates cannot be easily
repaired to be simple for both users and library writers. But D templates
can be made simple for both (IME they're already simple for library
writers). The most important problems needing addressing right now are
explicit template instance reference and explicit instantiation. Explicit
instantiation is not a problem if D supports implicit type inference a la
Haskell. There is a very good post about generic programming (with type
classes) in Haskell on
http://groups.google.com/groups?q=g:thl953488923d&dq=&hl=en&lr=&ie=UTF-8&sel
m=93i9qa-1l.ln%40ID-7776.user.dfncis.de . In brief the example is translated
to D as:

module ai;
template AI(A, A (*add)(A,A)) {
// the first template parameter is a type, the second is a function
   A twice(A a) {
       return add(a, a);
   }
}

module client;
import ai;

instance AI(int, +);
// declares that when A is an int, add is the + operation
instance AI(T[], ~);
// declares that when an array of any type T is used as A, add is the ~
operation;

example1 = twice(4);
// example1 == 8

example2 = twice("xyz")
// example2 == "xyzxyz"


    This syntax is less cumbersome and more expressive than the current one.
It addresses both explicit referencing of template instances, partial
instantiation and template constant parameters (in this case functions, but
any other value could be used). The problems of template specialization are
not addressed, but another syntax could be defined for it. Now if we drop
the instance and template keywords, and reuse the module and import keyword
we could have:


module aiAI(A, A (*add)(A,A));
// a parametrized module, just like a template
A twice(A a) {
   return add(a, a);
}

module client;
import ai(int, +);
import ai(T[], ~);

example1 = twice(4);
// example1 == 8

example2 = twice("xyz")
// example2 == "xyzxyz"


which is more concise and as clear as the previous.
    I hope this comparison is useful. But C++ templates aren't the only
genericity mechanism we can compare D to, trying to improve it. When we are
talking about statically type-safe templates we can point to either Haskell
or ML on the functional side, or we can look on Ada 95 or Eiffel (Sather is
also good, but it is inactive right now). I don't think we can have all the
power of C++ templates without its problems, but if we can have some of its
power (say ~70%) and few of its complexity (< 10%) we will be able to
provide value to programmers searching for a efficient high-level language.

    Best regards,
    Daniel Yokomiso.

"Common sense is that layer of prejudices which we acquire before we are
sixteen."
- Albert Einstein

"Walter" <walter digitalmars.com> writes:

"Daniel Yokomiso" <daniel_yokomiso yahoo.com.br> wrote in message
news:as6fmc$14ma$1 digitaldaemon.com...
     C++ templates have a wizardry feel to the novice. Template usage is
 quite simple, implicit instantiation works like magic.

Working like magic always made me uncomfortable, I always need to know just
what is going on under the hood with any construct I use. C++ templates do a
good job of obfuscating what is happening, which makes me very reluctant to
use C++ templates for production code (and I know many shops where template
use is strongly discouraged because of the high degree of difficulty walking
through the code and verifying that it is doing what you want it to do).

 But sometimes strange
 things happen and the reasons for this behavior is difficult to grasp,

error
 messages are cryptic and reading the source codes for the templates is an
 experts task.

Yes. I believe that the power can be made available without needing to be an
expert.

 To the initiated in template idioms, it still looks like
 magic, but they can write very powerful templates to solve lots of

problems.
 Papers from http://www.oonumerics.org/oon/#reference are very relevant to
 understand the capabilities of C++ templates. Most of its power comes from
 partial instantiation and template specialization.

Yes. Partial instantiation and specialization are brilliant, and why D
templates do that too!

  D templates on the other hand are quite easy to write and understand (if
 you're familiar with generic programming techniques from other languages).
 But its usage is verbose and sometimes very cumbersome to use. This is a
 code snippet from DTL (Deimos Template Library) of a Matrix method to
 calculate the product of two matrices:

 public Matrix times (Matrix other)
 in {
 // rows and columns provide the number of rows and columns of a matrix
     assert(other.rows() == columns());
 } out(result) {
     assert(rows() == result.rows());
     assert(other.columns() == result.columns());
 } body {
 // creates the result matrix
     Matrix res = new Matrix(rows(), other.columns());
 // explicit instantiation of two templates from DTL
     instance TFunctionalArrays(T, T, T) func2;
     for (int j = 0; j < other.columns(); j++) {
         for (int i = 0; i < rows(); i++) {

 // functional idiom to compute the products of two arrays
 // ops is a template instance to provide generic basic arithmetic

operations
 // row(int) and column(int) return the selected row and column as an array
             T[] products = func2.map(row(i), other.column(j), &ops.mul);

             res.set(i, j, ops.sum(products, zero));
         }
     }
     return res;
 }

     From this code snippet you can see the primary problem with D template
 syntax: it's difficult to write terse code when you need to refer to
 explicitly instantiate templates and refer to this template instances
 through the code.

You can inline replace the
    func2.map(...)
with
    instance TFunctionalArrays(T, T, T).map(...)
which isn't too much more verbose than C++:
    TFunctionalArrays<T, T, T>(...)



 Also current limitations on operator overloading doesn't
 allow us to use matrices like we use arrays, or to provide numeric

operator
 to numeric arrays.

Yes, that should be improved.

 The main problem with D template look and feel is that they're too
 heavy-weight to use. Writing templates in D is easy, but using them has an
 unnatural feeling. A template function use is different from a regular
 function use.

Yes, though that can be mitigated by using an alias:
    alias instance Foo(T).bar mybar;


 In DTL we have two simple
 functions first and rest that operates on arrays, giving respectively
 array[0] and array[1..array.length]. If I need to write:

 instance TArrays(char) arrays;
 printf("first is '%c' and the rest is '%.*s'\r\n", arrays.first(text),
 arrays.rest(text));

 I'll probably won't bother using it at all and rewrite the code. If

instead
 I can write:

 printf("first is '%c' and the rest is '%.*s'\r\n", first(text),

rest(text));
 I'll probably incorporate first and rest in my set of useful tools

(because
 they express the intent not the implementation used).

Point taken.

 Small templates are
 useful to reduce code duplication, but they add more complexity than

needed.
 If the template encapsulated complexity is greater than the complexity of
 thinking about explicit instantiation and explicit references, then it'll

be
 used.

I agree - but is it really a good idea to use templates for trivial
operations? I had to maintain a project once where the guy used a swath of
templates, with < and > all over the place. After spending considerable time
going through ten thousand lines of this, I finally realized that all he was
doing was a simple linked list. It got replace with ->next, and the code got
a lot easier to read, and the number of lines of code dropped significantly
too <g>.

     My conclusion is that C++ template writing has a different feel than
 regular C++ coding, but they can be used naturally in the language. D goes
 the other way around. The good news is that C++ templates cannot be easily
 repaired to be simple for both users and library writers.

I agree it is beyond repair.

 But D templates
 can be made simple for both (IME they're already simple for library
 writers). The most important problems needing addressing right now are
 explicit template instance reference and explicit instantiation. Explicit
 instantiation is not a problem if D supports implicit type inference a la
 Haskell. There is a very good post about generic programming (with type
 classes) in Haskell on

http://groups.google.com/groups?q=g:thl953488923d&dq=&hl=en&lr=&ie=UTF-8&sel
 m=93i9qa-1l.ln%40ID-7776.user.dfncis.de . In brief the example is

translated
 to D as:

 module ai;
 template AI(A, A (*add)(A,A)) {
 // the first template parameter is a type, the second is a function
    A twice(A a) {
        return add(a, a);
    }
 }

 module client;
 import ai;

 instance AI(int, +);
 // declares that when A is an int, add is the + operation
 instance AI(T[], ~);
 // declares that when an array of any type T is used as A, add is the ~
 operation;

 example1 = twice(4);
 // example1 == 8

 example2 = twice("xyz")
 // example2 == "xyzxyz"


     This syntax is less cumbersome and more expressive than the current

one.
 It addresses both explicit referencing of template instances, partial
 instantiation and template constant parameters (in this case functions,

but
 any other value could be used). The problems of template specialization

are
 not addressed, but another syntax could be defined for it. Now if we drop
 the instance and template keywords, and reuse the module and import

keyword
 we could have:


 module aiAI(A, A (*add)(A,A));
 // a parametrized module, just like a template
 A twice(A a) {
    return add(a, a);
 }

 module client;
 import ai(int, +);
 import ai(T[], ~);

 example1 = twice(4);
 // example1 == 8

 example2 = twice("xyz")
 // example2 == "xyzxyz"


 which is more concise and as clear as the previous.

I'll have to study that some more.

     I hope this comparison is useful. But C++ templates aren't the only
 genericity mechanism we can compare D to, trying to improve it. When we

are
 talking about statically type-safe templates we can point to either

Haskell
 or ML on the functional side, or we can look on Ada 95 or Eiffel (Sather

is
 also good, but it is inactive right now). I don't think we can have all

the
 power of C++ templates without its problems, but if we can have some of

its
 power (say ~70%) and few of its complexity (< 10%) we will be able to
 provide value to programmers searching for a efficient high-level

language.

Yes.

Evan McClanahan <evan dontSPAMaltarinteractive.com> writes:

Some things.  First, I quite like the idea of templated modules being 
the primary method of template instantiation, although it raises some 
interesting issues which I don't really have time to go into today.  I 
think that we should give the idea some more thought and discussion 
though, before we use it.  I agree with Daniel's statement that the 
syntax seems cumbersome, but I don't think that introducing a lot of 
keywords and behaviors from functional programming is quite the answer 
we're looking for(or at least me).  Then again, i don't have any 
suggestions for cleaning them up, as I haven't written anything with 
templates in D yet.  Need to do that, one of these days, then, I hope, 
I'll have something more useful to say.

To be honest, as more of a practioner programmer than a language 
designer, all I really care about is the non-magic feeling aspect of it, 
and the simplicity of integrating the mechanism with a debugger, 
something that C++ templates, with all of their complexity, generally 
don't have.

Evan

Walter wrote:
 "Daniel Yokomiso" <daniel_yokomiso yahoo.com.br> wrote in message
 news:as6fmc$14ma$1 digitaldaemon.com...
 
    C++ templates have a wizardry feel to the novice. Template usage is
quite simple, implicit instantiation works like magic.

 
 
 Working like magic always made me uncomfortable, I always need to know just
 what is going on under the hood with any construct I use. C++ templates do a
 good job of obfuscating what is happening, which makes me very reluctant to
 use C++ templates for production code (and I know many shops where template
 use is strongly discouraged because of the high degree of difficulty walking
 through the code and verifying that it is doing what you want it to do).
 
 
But sometimes strange
things happen and the reasons for this behavior is difficult to grasp,

 
 error
 
messages are cryptic and reading the source codes for the templates is an
experts task.

 
 
 Yes. I believe that the power can be made available without needing to be an
 expert.
 
 
To the initiated in template idioms, it still looks like
magic, but they can write very powerful templates to solve lots of

 
 problems.
 
Papers from http://www.oonumerics.org/oon/#reference are very relevant to
understand the capabilities of C++ templates. Most of its power comes from
partial instantiation and template specialization.

 
 
 Yes. Partial instantiation and specialization are brilliant, and why D
 templates do that too!
 
 
 D templates on the other hand are quite easy to write and understand (if
you're familiar with generic programming techniques from other languages).
But its usage is verbose and sometimes very cumbersome to use. This is a
code snippet from DTL (Deimos Template Library) of a Matrix method to
calculate the product of two matrices:

public Matrix times (Matrix other)
in {
// rows and columns provide the number of rows and columns of a matrix
    assert(other.rows() == columns());
} out(result) {
    assert(rows() == result.rows());
    assert(other.columns() == result.columns());
} body {
// creates the result matrix
    Matrix res = new Matrix(rows(), other.columns());
// explicit instantiation of two templates from DTL
    instance TFunctionalArrays(T, T, T) func2;
    for (int j = 0; j < other.columns(); j++) {
        for (int i = 0; i < rows(); i++) {

// functional idiom to compute the products of two arrays
// ops is a template instance to provide generic basic arithmetic

 
 operations
 
// row(int) and column(int) return the selected row and column as an array
            T[] products = func2.map(row(i), other.column(j), &ops.mul);

            res.set(i, j, ops.sum(products, zero));
        }
    }
    return res;
}

    From this code snippet you can see the primary problem with D template
syntax: it's difficult to write terse code when you need to refer to
explicitly instantiate templates and refer to this template instances
through the code.

 
 
 You can inline replace the
     func2.map(...)
 with
     instance TFunctionalArrays(T, T, T).map(...)
 which isn't too much more verbose than C++:
     TFunctionalArrays<T, T, T>(...)
 
 
 
 
Also current limitations on operator overloading doesn't
allow us to use matrices like we use arrays, or to provide numeric

 
 operator
 
to numeric arrays.

 
 
 Yes, that should be improved.
 
 
The main problem with D template look and feel is that they're too
heavy-weight to use. Writing templates in D is easy, but using them has an
unnatural feeling. A template function use is different from a regular
function use.

 
 
 Yes, though that can be mitigated by using an alias:
     alias instance Foo(T).bar mybar;
 
 
 
In DTL we have two simple
functions first and rest that operates on arrays, giving respectively
array[0] and array[1..array.length]. If I need to write:

instance TArrays(char) arrays;
printf("first is '%c' and the rest is '%.*s'\r\n", arrays.first(text),
arrays.rest(text));

I'll probably won't bother using it at all and rewrite the code. If

 
 instead
 
I can write:

printf("first is '%c' and the rest is '%.*s'\r\n", first(text),

 
 rest(text));
 
I'll probably incorporate first and rest in my set of useful tools

 
 (because
 
they express the intent not the implementation used).

 
 
 Point taken.
 
 
Small templates are
useful to reduce code duplication, but they add more complexity than

 
 needed.
 
If the template encapsulated complexity is greater than the complexity of
thinking about explicit instantiation and explicit references, then it'll

 
 be
 
used.

 
 
 I agree - but is it really a good idea to use templates for trivial
 operations? I had to maintain a project once where the guy used a swath of
 templates, with < and > all over the place. After spending considerable time
 going through ten thousand lines of this, I finally realized that all he was
 doing was a simple linked list. It got replace with ->next, and the code got
 a lot easier to read, and the number of lines of code dropped significantly
 too <g>.
 
 
    My conclusion is that C++ template writing has a different feel than
regular C++ coding, but they can be used naturally in the language. D goes
the other way around. The good news is that C++ templates cannot be easily
repaired to be simple for both users and library writers.

 
 
 I agree it is beyond repair.
 
 
But D templates
can be made simple for both (IME they're already simple for library
writers). The most important problems needing addressing right now are
explicit template instance reference and explicit instantiation. Explicit
instantiation is not a problem if D supports implicit type inference a la
Haskell. There is a very good post about generic programming (with type
classes) in Haskell on

 
 http://groups.google.com/groups?q=g:thl953488923d&dq=&hl=en&lr=&ie=UTF-8&sel
 
m=93i9qa-1l.ln%40ID-7776.user.dfncis.de . In brief the example is

 
 translated
 
to D as:

module ai;
template AI(A, A (*add)(A,A)) {
// the first template parameter is a type, the second is a function
   A twice(A a) {
       return add(a, a);
   }
}

module client;
import ai;

instance AI(int, +);
// declares that when A is an int, add is the + operation
instance AI(T[], ~);
// declares that when an array of any type T is used as A, add is the ~
operation;

example1 = twice(4);
// example1 == 8

example2 = twice("xyz")
// example2 == "xyzxyz"


    This syntax is less cumbersome and more expressive than the current

 
 one.
 
It addresses both explicit referencing of template instances, partial
instantiation and template constant parameters (in this case functions,

 
 but
 
any other value could be used). The problems of template specialization

 
 are
 
not addressed, but another syntax could be defined for it. Now if we drop
the instance and template keywords, and reuse the module and import

 
 keyword
 
we could have:


module aiAI(A, A (*add)(A,A));
// a parametrized module, just like a template
A twice(A a) {
   return add(a, a);
}

module client;
import ai(int, +);
import ai(T[], ~);

example1 = twice(4);
// example1 == 8

example2 = twice("xyz")
// example2 == "xyzxyz"


which is more concise and as clear as the previous.

 
 
 I'll have to study that some more.
 
 
    I hope this comparison is useful. But C++ templates aren't the only
genericity mechanism we can compare D to, trying to improve it. When we

 
 are
 
talking about statically type-safe templates we can point to either

 
 Haskell
 
or ML on the functional side, or we can look on Ada 95 or Eiffel (Sather

 
 is
 
also good, but it is inactive right now). I don't think we can have all

 
 the
 
power of C++ templates without its problems, but if we can have some of

 
 its
 
power (say ~70%) and few of its complexity (< 10%) we will be able to
provide value to programmers searching for a efficient high-level

 
 language.
 
 Yes.
 
 

"Daniel Yokomiso" <daniel_yokomiso yahoo.com.br> writes:

"Evan McClanahan" <evan dontSPAMaltarinteractive.com> escreveu na mensagem
news:as7d45$2c1v$1 digitaldaemon.com...
 Some things.  First, I quite like the idea of templated modules being
 the primary method of template instantiation, although it raises some
 interesting issues which I don't really have time to go into today.  I
 think that we should give the idea some more thought and discussion
 though, before we use it.  I agree with Daniel's statement that the
 syntax seems cumbersome, but I don't think that introducing a lot of
 keywords and behaviors from functional programming is quite the answer
 we're looking for(or at least me).  Then again, i don't have any
 suggestions for cleaning them up, as I haven't written anything with
 templates in D yet.  Need to do that, one of these days, then, I hope,
 I'll have something more useful to say.

 To be honest, as more of a practioner programmer than a language
 designer, all I really care about is the non-magic feeling aspect of it,
 and the simplicity of integrating the mechanism with a debugger,
 something that C++ templates, with all of their complexity, generally
 don't have.

 Evan

Hi,

    The idea is not add keywords and behaviors to D from functional
languages. But to provide the possibility of a library writer to create
functions with functional 'look and feel'. If you check DTL 0.0.1
(http://www.minddrome.com/d/deimos/deimos-0.0.1.zip) you can see working
code that uses today's template syntax to provide functions like map,
filter, foldl, etc. D should remain a multi-paradigmatic language, like C++,
not became a functional language or an OO language.

    Best regards,
    Daniel Yokomiso.

"Quote me as saying I was mis-quoted."
- Groucho Marx

"Daniel Yokomiso" <daniel_yokomiso yahoo.com.br> writes:

Reply embedded.

"Walter" <walter digitalmars.com> escreveu na mensagem
news:as7akt$29fv$1 digitaldaemon.com...

[snip]
 You can inline replace the
     func2.map(...)
 with
     instance TFunctionalArrays(T, T, T).map(...)
 which isn't too much more verbose than C++:
     TFunctionalArrays<T, T, T>(...)

    I know it, but writing 'import TFunctionalArrays(T,T,T);' after the
module declarationg and then just using map(...) is as expressive, has no
magic feeling and looks like a regular module import and imported function
call. That's why I proposed that syntax.

[snip]

 The main problem with D template look and feel is that they're too
 heavy-weight to use. Writing templates in D is easy, but using them has


an
 unnatural feeling. A template function use is different from a regular
 function use.

 Yes, though that can be mitigated by using an alias:
     alias instance Foo(T).bar mybar;

    I use lots of alias, specially to make template classes less verbose.
But it doesn't work when you have dozens of functions (like in deimos.arrays
module). But it's better than nothing.

[snip]

 Small templates are
 useful to reduce code duplication, but they add more complexity than

 needed.
 If the template encapsulated complexity is greater than the complexity


of
 thinking about explicit instantiation and explicit references, then


it'll
 be
 used.

 I agree - but is it really a good idea to use templates for trivial
 operations? I had to maintain a project once where the guy used a swath of
 templates, with < and > all over the place. After spending considerable

time
 going through ten thousand lines of this, I finally realized that all he

was
 doing was a simple linked list. It got replace with ->next, and the code

got
 a lot easier to read, and the number of lines of code dropped

significantly
 too <g>.

    It's like people say: you can write Fortran in any language ;-) .
Genericity is good, just like classes, high-order functions and
dynamic-dispatched methods. But lots of people write unmaintainable code
everywhere, whether having templates or not. Java is my usual example of
language with lots of duplicated code in libraries. People rewrite dynamic
arrays, binary trees, linked lists, primitive holders and even sorting,
because the language lacks a genericity mechanism. It's broken beyond
repair, because when they add generics (next release IIRC) millions of lines
of code will already be written. Anyone thinks JBoss or Jakarta codebase
will be completly reviewed and rewritten to support the genericity
mechanism? D can be more successful here, because it'll have templates
weaved in the basic libraries.
    Some trivial operations are really trivial but other are just instances
of a more abstract generic pattern. Functional programmers are very fond of
generic programming, and they can produce very simple and expressive
algorithms. Look at STL functional-style programming vs. any functional
language. This is a problem of finding the correct abstractions for any
problem. If a language is powerful enough some of its users will shoot
themselves in the foot. A nice view on this subject is on
http://www-users.cs.york.ac.uk/~susan/joke/foot.htm .
    I'll still use templates in D, even if the syntax doesn't change. I can
live with some verbosity, if at least I can write generic code. I prefer the
'module as genericity unit' syntax, mostly because expressive languages has
this point of view. As I said in another post we need a better C and D is
today a better C. Everything else is sugar ;-)

    Best regards,
    Daniel Yokomiso.

"The only difference between me and a madman is that I am not mad."
- Salvador Dali

"Walter" <walter digitalmars.com> writes:

I'm slowly warming to the idea of using 'import' for template instances to
not only instantiate the template, but to put the names into the current
scope.

"Daniel Yokomiso" <daniel_yokomiso yahoo.com.br> wrote in message
news:as8740$1q4m$1 digitaldaemon.com...
 Reply embedded.

 "Walter" <walter digitalmars.com> escreveu na mensagem
 news:as7akt$29fv$1 digitaldaemon.com...

 [snip]
 You can inline replace the
     func2.map(...)
 with
     instance TFunctionalArrays(T, T, T).map(...)
 which isn't too much more verbose than C++:
     TFunctionalArrays<T, T, T>(...)

     I know it, but writing 'import TFunctionalArrays(T,T,T);' after the
 module declarationg and then just using map(...) is as expressive, has no
 magic feeling and looks like a regular module import and imported function
 call. That's why I proposed that syntax.

 [snip]

 The main problem with D template look and feel is that they're too
 heavy-weight to use. Writing templates in D is easy, but using them



has
 an
 unnatural feeling. A template function use is different from a regular
 function use.

 Yes, though that can be mitigated by using an alias:
     alias instance Foo(T).bar mybar;

     I use lots of alias, specially to make template classes less verbose.
 But it doesn't work when you have dozens of functions (like in

deimos.arrays
 module). But it's better than nothing.

 [snip]

 Small templates are
 useful to reduce code duplication, but they add more complexity than

 needed.
 If the template encapsulated complexity is greater than the complexity


 of
 thinking about explicit instantiation and explicit references, then


 it'll
 be
 used.

 I agree - but is it really a good idea to use templates for trivial
 operations? I had to maintain a project once where the guy used a swath


of
 templates, with < and > all over the place. After spending considerable

 time
 going through ten thousand lines of this, I finally realized that all he

 was
 doing was a simple linked list. It got replace with ->next, and the code

 got
 a lot easier to read, and the number of lines of code dropped

 significantly
 too <g>.

     It's like people say: you can write Fortran in any language ;-) .
 Genericity is good, just like classes, high-order functions and
 dynamic-dispatched methods. But lots of people write unmaintainable code
 everywhere, whether having templates or not. Java is my usual example of
 language with lots of duplicated code in libraries. People rewrite dynamic
 arrays, binary trees, linked lists, primitive holders and even sorting,
 because the language lacks a genericity mechanism. It's broken beyond
 repair, because when they add generics (next release IIRC) millions of

lines
 of code will already be written. Anyone thinks JBoss or Jakarta codebase
 will be completly reviewed and rewritten to support the genericity
 mechanism? D can be more successful here, because it'll have templates
 weaved in the basic libraries.
     Some trivial operations are really trivial but other are just

instances
 of a more abstract generic pattern. Functional programmers are very fond

of
 generic programming, and they can produce very simple and expressive
 algorithms. Look at STL functional-style programming vs. any functional
 language. This is a problem of finding the correct abstractions for any
 problem. If a language is powerful enough some of its users will shoot
 themselves in the foot. A nice view on this subject is on
 http://www-users.cs.york.ac.uk/~susan/joke/foot.htm .
     I'll still use templates in D, even if the syntax doesn't change. I

can
 live with some verbosity, if at least I can write generic code. I prefer

the
 'module as genericity unit' syntax, mostly because expressive languages

has
 this point of view. As I said in another post we need a better C and D is
 today a better C. Everything else is sugar ;-)

     Best regards,
     Daniel Yokomiso.

 "The only difference between me and a madman is that I am not mad."
 - Salvador Dali