Pragma wrote:
> Fraser wrote:
>> In particular, I want a mixin template that mixes in a  unique numeric ID as part of a function every time it's used in a mixin. 
> 
> This is possible, but it will take some mildly ugly code to accomplish*.  The major hurdle to overcome is that templates are effectively stateless.  This is because every template invocation is dependent upon its arguments and global constants for evaluation, and is unable to change anything but its own definition.  The result is that there's no compile-time analog for simple stuff like this:
> 
[...]
> 
> (* welcome to meta-programming)
> 

It's more specific than that. Like "welcome to D meta-programming". Meta-programming in other languages, like macros in Lisp, are done as normal Lisp code and thus also have state (as I believe you know already).
In D that's not the case, and I find it interesting, and even kinda of funny and ironic, that D meta-programming is a *completly* pure functional programming world :P . Funny and ironic because the first thing that poped to mind when I first "entered" D meta-programming, was the Scheme pure functional programs we (me and my fellow colleagues) did some years ago in my college's first-year, SICP-based college course. :)

-- 
Bruno Medeiros - MSc in CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D

Bruno Medeiros wrote:
> [...]
> It's more specific than that. Like "welcome to D meta-programming". Meta-programming in other languages, like macros in Lisp, are done as normal Lisp code and thus also have state (as I believe you know already).
> In D that's not the case, and I find it interesting, and even kinda of funny and ironic, that D meta-programming is a *completly* pure functional programming world :P . Funny and ironic because the first thing that poped to mind when I first "entered" D meta-programming, was the Scheme pure functional programs we (me and my fellow colleagues) did some years ago in my college's first-year, SICP-based college course. :)

It's true that D shares C++'s pure metaprogramming facilities, but I think it is fairly easy to see why.  Both of these languages already know how to do constant folding and template instantiation, which don't require any heap management.  Since dynamic languages like Lisp generally have a runtime evaluation engine, running that in the compile phase is no big deal, whereas it's a lot less trivial to do that in D (though Walter allows dynamic strings as the exception to the compile-time heap rule).

Perhaps D should support phased compilation, but I think a better approach would be to have better support for functional programming (if functions were really first class values in D, you could create them as easily as the builtins and do so at compile time, which would make it possible to do things like monads).

Dave

Reply to David,

> Bruno Medeiros wrote:
> 
>> [...]
>> I find it interesting, and even kinda of
>> funny and ironic, that D meta-programming is a *completly* pure
>> functional programming world :P . Funny and ironic because the first
>> thing that poped to mind when I first "entered" D meta-programming,
>> was the Scheme pure functional programs we (me and my fellow colleagues) did some years ago in my college's first-year, SICP-based
>> college course.
>> :)

same here, meta stuff really clicked after doing some scheme

> It's true that D shares C++'s pure metaprogramming facilities, but I
> think it is fairly easy to see why.  Both of these languages already
> know how to do constant folding and template instantiation, which
> don't require any heap management.  Since dynamic languages like Lisp
> generally have a runtime evaluation engine, running that in the
> compile phase is no big deal, whereas it's a lot less trivial to do
> that in D (though Walter allows dynamic strings as the exception to
> the compile-time heap rule).
> 

why is it just char[], why not T[] for any T that can be used by it's self? I have some cases where I want to do that.

BCS wrote:
> [...]
> why is it just char[], why not T[] for any T that can be used by it's self? I have some cases where I want to do that.

I don't know the full story, but after looking through the front-end code, my guess is that it's just easier that way.  That is, when checking to see whether a particular type can be a compile-time array, it's easier to check against one type than against a set of types, or detect a set of type properties.  Also, since dynamic char[] already violates the purity of metaprogramming, I think that Walter didn't want to expand and encourage that without thinking very hard about it (it's easier to give people new features than to take them away).

Dave

Reply to David,

> BCS wrote:
> 
>> [...]
>> why is it just char[], why not T[] for any T that can be used by it's
>> self? I have some cases where I want to do that.
>
> I don't know the full story, but after looking through the front-end
> code, my guess is that it's just easier that way.  That is, when
> checking to see whether a particular type can be a compile-time array,
> it's easier to check against one type than against a set of types, or
> detect a set of type properties.

Hmmm.

> Also, since dynamic char[] already
> violates the purity of metaprogramming, I think that Walter didn't
> want to expand and encourage that without thinking very hard about it
> (it's easier to give people new features than to take them away).
> 

How is that? If everthing in meta land is pass by value (including strings) how are arrays any different than normal types?

> Dave
> 

BCS wrote:
> Reply to David,
> [...]
>> Also, since dynamic char[] already
>> violates the purity of metaprogramming, I think that Walter didn't
>> want to expand and encourage that without thinking very hard about it
>> (it's easier to give people new features than to take them away).
> 
> How is that? If everthing in meta land is pass by value (including strings) how are arrays any different than normal types?

How about the fact that resizing implies a dynamic allocation?

Dave

David B. Held wrote:
> BCS wrote:
>> [...]
>> why is it just char[], why not T[] for any T that can be used by it's self? I have some cases where I want to do that.
> 
> I don't know the full story, but after looking through the front-end code, my guess is that it's just easier that way.  
> That is, when
> checking to see whether a particular type can be a compile-time array, it's easier to check against one type than against a set of types, or detect a set of type properties.  Also, since dynamic char[] already violates the purity of metaprogramming, I think that Walter didn't want to expand and encourage that without thinking very hard about it (it's easier to give people new features than to take them away).
> 
> Dave


Nope. It's because D had built-in support for string literals from way back (whereas array literals are very recent). Concatenation of string literals was accidentally possible, and I showed that it could be used to do some interesting metaprogramming. I explicitly asked for the other char [] operations to be constant folded at compile time. See the change log for around DMD 0.135-0.145 to see the history.

Reply to David,

> BCS wrote:
> 
>> Reply to David,
>> [...]
>>> Also, since dynamic char[] already
>>> violates the purity of metaprogramming, I think that Walter didn't
>>> want to expand and encourage that without thinking very hard about
>>> it
>>> (it's easier to give people new features than to take them away).
>> How is that? If everthing in meta land is pass by value (including
>> strings) how are arrays any different than normal types?
>> 
> How about the fact that resizing implies a dynamic allocation?
> 
> Dave
> 

the closest you can get to resize in meta land is "~" and that /is/ allowed for strings.

| template Foo(char[] str)
| {
|   const char[] Foo = \" ~ str ~ \"
| }

what specific problems exist for non char arrays that don't exist for char arrays?

BCS wrote:
> [...]
> the closest you can get to resize in meta land is "~" and that /is/ allowed for strings.
> 
> | template Foo(char[] str)
> | {
> |   const char[] Foo = \" ~ str ~ \"
> | }
> 
> what specific problems exist for non char arrays that don't exist for char arrays?

According to Don, it's an accident that it works for strings. ;)  A happy accident, no doubt; but that explains why it doesn't work for anything else.

Dave