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?"

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?"
>
>

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

"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

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

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

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

"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

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