"Bill Baxter" <Bill_member@pathlink.com> wrote in message news:d5c1mu$640$1@digitaldaemon.com...
> Thoughts?  Any chances something like this could ever come to D?

I agree with you on all points - especially on the one that if metaprogramming was easier to do, it would be a lot more practical. I'd like to bring this to D.

In article <d5klem$10bl$1@digitaldaemon.com>, Walter says...
>
>
>"Bill Baxter" <Bill_member@pathlink.com> wrote in message news:d5c1mu$640$1@digitaldaemon.com...
>> Thoughts?  Any chances something like this could ever come to D?
>
>I agree with you on all points - especially on the one that if metaprogramming was easier to do, it would be a lot more practical. I'd like to bring this to D.

Whee!  Really looking forward to see how it turns out.
Are you in contact with folks like Andrescu who know these tricks for C++ inside
out?  Seems like that would be really valuable to pick those folks' brains to
find out what they would add to or change about C++ if they could.

--bb

Bill Baxter wrote:
> ...lots of interesting stuff...

Okay, you convinced me. :)

--BenjiSmith

In article <d5l4b8$1k5i$1@digitaldaemon.com>, Bill Baxter says...
>
>In article <d5klem$10bl$1@digitaldaemon.com>, Walter says...
>>
>>
>>"Bill Baxter" <Bill_member@pathlink.com> wrote in message news:d5c1mu$640$1@digitaldaemon.com...
>>> Thoughts?  Any chances something like this could ever come to D?
>>
>>I agree with you on all points - especially on the one that if metaprogramming was easier to do, it would be a lot more practical. I'd like to bring this to D.
>
>Whee!  Really looking forward to see how it turns out.
>Are you in contact with folks like Andrescu who know these tricks for C++ inside
>out?  Seems like that would be really valuable to pick those folks' brains to
>find out what they would add to or change about C++ if they could.

D already supports some nice improvements over C++ so far as templates are concerned.  Templated typedefs, for example.  Walter has also said he'd like to allow for specialization on classes of types in addition to on explicit types, ie.

template Templ(T: Numeric) {}

Personally, I've been holding off on any hardcore template programming because compiler support is still a tad shaky (though things are much better than they were 25 builds ago).  One feature that could make D really shine for code generation is mixins, but the aliasing problem is still an issue.  For example:

# import std.c.stdio;
#
# template Mix1() {
#     void f1() { printf( "f1\n" ); }
# }
#
# template Mix2() {
# //    mixin Mix1!() Mix1_;
# //    alias Mix1_.f1 f1;
#     void f2() { printf( "f2\n" ); }
# }
#
# interface I {
#     void f1();
#     void f2();
# }
#
# class C : I {
# //    mixin Mix1!();
#     mixin Mix2!();
# }
#
# void main() {
#     C c = new C();
#     I i = c;
#     c.f1();
#     i.f2();
# }

For this code to compile, you will have to uncomment one of the two code blocks above.  The problem is that this requirement prevents certain methods of code generation--aliasing in the mixin isn't always feasible because the mixed-in symbol names may not be known.  It might be sufficient if something like the following were allowed:

# template Mix2() {
#     mixin Mix1!() Mix1_;
#     alias Mix1_.*; // alias all mixin symbols in local scope
#     void f2() { printf( "f2\n" ); }
# }

There also appears to be an issue with template template parameters:

# import std.c.stdio;
#
# template Mix1() {
#     void f1() { printf( "f1\n" ); }
# }
#
# // first example--f1 is not visible
# template Mix2(T) {
#     // how do we know that T has a function f1?
#     alias T.f1 f1;
#     void f2() { printf( "f2\n" ); }
# }
#
# // second example--T is not a template
# template Mix3(alias T) {
#     alias T.f1 f1;
#     void f2() { printf( "f2\n" ); }
# }
#
# interface I {
#     void f1();
#     void f2();
# }
#
# class C : I {
#     // mixin a.C.Mix2!(Mix1_) does not match any template declaration
#     mixin Mix2!(Mix1!());
#     // class a.C interface function I.f1 isn't implemented
#     mixin Mix3!(Mix1!());
# }
#
# void main() {
#     C c = new C();
#     I i = c;
#     c.f1();
#     i.f2();
# }

This prevents any simple means I can think of for template-based code generation.  Beyond that, I guess we'll see.  I've been assuming Walter will address template issues once other core language issues have been dealt with.


Sean

"Bill Baxter" <Bill_member@pathlink.com> wrote in message news:d5c1mu$640$1@digitaldaemon.com...
> Yikes!  All that is, really, is just an if-else, but dressed up in C++
template
> metaprogramming it takes about a page of code!  My thought is that if the language actually had first-class support for metaprogramming, then you
could
> just do something like write a short metafunction that returns a type:
>
> metafun type integer(int numbits)
> {
> if (numbits<=sizeof(char)) return char;
> if (numbits<=sizeof(short)) return short;
> if (numbits<=sizeof(int)) return int;
> if (numbits<=sizeof(long)) return long;
> if (numbits<=sizeof(cent)) return cent;
>
> metathrow "Compiler error";
> }

You've inspired me:

template Integer(int nbits)
{
    static if (nbits <= 8)
       alias byte Integer;
    else static if (nbits <= 16)
       alias short Integer;
    else static if (nbits <= 32)
       alias int Integer;
    else static if (nbits <= 64)
       alias long Integer;
    else
       static assert(0);
}

int main()
{
    Integer!(8) i ;
    Integer!(16) j ;
    Integer!(29) k ;
    Integer!(64) l ;
    printf("%d %d %d %d\n", i.sizeof, j.sizeof, k.sizeof, l.sizeof);
    return 0;
}

In article <d62m56$2h67$1@digitaldaemon.com>, Walter says...
>
>You've inspired me:
>
>template Integer(int nbits)
>{
>    static if (nbits <= 8)
>       alias byte Integer;

Static if?  This isn't possible in DMD .123, is it?  And what about static while loops and other such logic?


Sean

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Sean Kelly schrieb am Fri, 13 May 2005 20:01:53 +0000 (UTC):
> In article <d62m56$2h67$1@digitaldaemon.com>, Walter says...
>>
>>You've inspired me:
>>
>>template Integer(int nbits)
>>{
>>    static if (nbits <= 8)
>>       alias byte Integer;
>
> Static if?  This isn't possible in DMD .123, is it?  And what about static while loops and other such logic?

.123 doesn't support this but I see no reason why "static if" would be hard to implement. Just enhance the version/debug condition implementation a bit and you get the same features as as "static if".

Thomas


-----BEGIN PGP SIGNATURE-----

iD8DBQFChTOA3w+/yD4P9tIRAvkuAJ0e1vo88VYhyevT93WBI7YMM7eQagCgp8by
AZVdILdc8ImJki9bcPX1E9o=
=z18g
-----END PGP SIGNATURE-----

"Sean Kelly" <sean@f4.ca> wrote in message news:d6313h$2qik$1@digitaldaemon.com...
> In article <d62m56$2h67$1@digitaldaemon.com>, Walter says...
> >
> >You've inspired me:
> >
> >template Integer(int nbits)
> >{
> >    static if (nbits <= 8)
> >       alias byte Integer;
>
> Static if?  This isn't possible in DMD .123, is it?

Nope. .124 <g>

> And what about static while
> loops and other such logic?

Never satisfied <g>. (Those are much harder to implement.)

In article <d63598$2tuo$1@digitaldaemon.com>, Walter says...
>
>> And what about static while
>> loops and other such logic?
>
>Never satisfied <g>. (Those are much harder to implement.)

I thought they might be :)  Only reason I ask is because it's currently possible to implement all the standard control structures (if, while, switch) in template code as it exists now, so if the language were to support 'if' I'd expect it to support others as well.  Though I suppose recursion seems more of an obvious method for looping than it does for switching on a boolean expression.


Sean

"Thomas Kuehne" <thomas-dloop@kuehne.thisisspam.cn> wrote in message news:0lofl2-jd3.ln1@lnews.kuehne.cn...
> .123 doesn't support this but I see no reason why "static if" would be hard to implement. Just enhance the version/debug condition implementation a bit and you get the same features as as "static if".

Yup, that's nearly all there is to it. What's interesting, though, it how it transforms template metaprogramming. C++ template metaprogramming was 'discovered' rather than designed, and as Bill Baxter's reference shows, it is very hard to use.