Bent Rasmussen wrote:

>> Actually, thinking about it all a little more, I realized, that we should not really look at Python or some other scripting language, but at *functional* languages!
> 
> Its nice have have a multiparadigm language like D that makes several programming styles possible and doesn't force you into using classes for everything. It has a very clean feel.

I think "multiparadigm language" is a bit misleading in this context. What I am talking about is, that D contains two independant languages: one that is interpreted at compile time and one, that is compiled to be executed lateron. The first one is pure functional and not object oriented, the latter one is mostly imperative (and of course object oriented) with a few features to support other paradigms to some extent.

The execution of the first language at compile time could probably be compared to a preprocessor run. Of course, it is too closely knit into the language to really split this preprocessor out from the real compilation, but as a concept this really helps. Consider templates, instantiations and mixins as parts of a powerful functional macro language that outputs some code that is similar to D with all templates resolved, which is then compiled.

In article <c8dukv$2als$1@digitaldaemon.com>, Norbert Nemec says... .
>Now, if mytype does not offer a .something() member function, the compiler will, of course, complain. But is it an error in the template code or is it an error of the instantiation with an illegal type parameter? The problem is, that there is no way to specify in the definition of a template what capabilities a parameter should have.
>
>If you have code that nests over several layers of templates, this really gives messy compiler errors.
>
>On the other hand, I realize now: looking at the compile-time-language as
>full functional programming language, template instantiations would
>actually correspond to function calls. If an error occurs several levels
>deep, the compiler error would of course have to include a "stack
>trace" (which is exactly, what the "instantiated at ..., instantiated
>at ..." lists in C++ are!)

I was thinking about this today (i.e. about templates as functions).

Imagine variables that can hold:
1. types.
2. fragments of code.
3. lists of names, values or statements.

And the ability to:

Loop over these (arbitrary statement bodies or variable names),

Pass them into and return them from "functions", i.e. templates or other code generation mechanisms.


The functions of this language would produce lists or arrrays of language elements.

Such a list could be:
a. Passed into a (code gen) function
b. Filtered or processed in some way (not sure...)
c. "Promoted" into actual code (i.e. inserted into the compile stream).

Given a list of names, I would like to (for example) generate 10 classes using those names or some combination thereof as:

1. variable names.
2. string literals.
3. concatenated with a prefix or postfix string and then 1 or 2.
4. Used to construct member variables or methods, using the name
as a typename for a template parameter.
5. or even as a string substitution.

The last sounds a little like "macro", so maybe a more type safe way (3) should
be available first.

With C, its not so much that the language is bad as it now stands (though it has some shortcomings that are a doozy), as that the bad techniques were available first; maybe it always happens in that order though.

Kevin

"Norbert Nemec" <Norbert.Nemec@gmx.de> wrote in message news:c8dukv$2als$1@digitaldaemon.com...
> Achilleas Margaritis wrote:
> > Doesn't template specialization cover this topic ? I thought that D was already capable of defining constraints for template types.
>
> That is just some very basic pattern matching that does not have the necessary power. What I was talking about are common cases like:
>
> ------------------
> template X(T) {
>         void x(T a) {
>                 a.something();
>         }
> }
>
> void myfunc(mytype b) {
>         X!(mytype).x(b);
> }
> ------------------
>
> Now, if mytype does not offer a .something() member function, the compiler will, of course, complain. But is it an error in the template code or is
it
> an error of the instantiation with an illegal type parameter? The problem is, that there is no way to specify in the definition of a template what capabilities a parameter should have.
>
> If you have code that nests over several layers of templates, this really gives messy compiler errors.
>
> On the other hand, I realize now: looking at the compile-time-language as
> full functional programming language, template instantiations would
> actually correspond to function calls. If an error occurs several levels
> deep, the compiler error would of course have to include a "stack
> trace" (which is exactly, what the "instantiated at ..., instantiated
> at ..." lists in C++ are!)

The problem is the messy compiler reporting, not the language. The compiler could easily report the error without the template parameters, which is where the problem actually is (the template parameters make reading the error report difficult).

Achilleas Margaritis wrote:

>> On the other hand, I realize now: looking at the compile-time-language as
>> full functional programming language, template instantiations would
>> actually correspond to function calls. If an error occurs several levels
>> deep, the compiler error would of course have to include a "stack
>> trace" (which is exactly, what the "instantiated at ..., instantiated
>> at ..." lists in C++ are!)
> 
> The problem is the messy compiler reporting, not the language. The compiler could easily report the error without the template parameters, which is where the problem actually is (the template parameters make reading the error report difficult).

There should probably be options to tell the compiler how to give error reports. Nested templates are really similar to nested function calls in a program. If an error happens, you might need a detailed stack-trace to find the problem, but such a stack trace really has to be formatted in a readable way to be helpful. Today's C++ compilers are just not very helpful there...