<p9e883002@sneakemail.com> wrote in message news:d6cj21$15d9$1@digitaldaemon.com...
> Ah but :)
>
> In the docs for the debug predicate is says:
>
> debug(Identifier) statements are compiled in when the debug identifier
> matches Identifier.
>
> If Statement is a block statement, it does not introduce a new scope.
>
> That's a very similar compile-time directive. Couldn't a simiilar
non-scoping
> block predicate be used for meta-programming?

They are similar, but to avoid confusion, they are not the same. If statements introduce a new scope, static if's do not.

> How about calling it 'meta'? I dont see that conflicting with any existing
term
> in any other language.

You're right, it doesn't. But I don't see the advantage over 'static if', and I think it will sow confusion to have the regular if not introduce a new scope.

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

> The use of static for both assert and if in this case is really non-intuitive
> and inconsistent with how it is used in other contexts (runtime evaluation).
> 'const' would seem to be better in both cases because they are evaluated
> strictly at compile time.

Personally, I like the idea of "static" to mean "compile-time" while "const" would mean that "you can't change this".  The compiler may evaluate all const stuff at compile time, but it doesn't have to.

Granted, using "static" in this manner differs from using "static" within a class, but that's not all that bad.

                                          Brian
                                 ( bcwhite@precidia.com )

-------------------------------------------------------------------------------
       Leave it to the computer industry to shorten "Year 2000" to "Y2K".
     It's that sort of thinking that led to the problem in the first place.

"Brian White" <bcwhite@precidia.com> wrote in message news:d6fvjd$2u79$1@digitaldaemon.com...
> > The use of static for both assert and if in this case is really non-intuitive and inconsistent with how it is used in other contexts (runtime evaluation). 'const' would seem to be better in both cases because they are evaluated strictly at compile time.
>
> Personally, I like the idea of "static" to mean "compile-time" while "const" would mean that "you can't change this".  The compiler may evaluate all const stuff at compile time, but it doesn't have to.
>
> Granted, using "static" in this manner differs from using "static" within a class, but that's not all that bad.
>
>                                            Brian
>                                   ( bcwhite@precidia.com )
>
> -------------------------------------------------------------------------------
>         Leave it to the computer industry to shorten "Year 2000" to "Y2K".
>       It's that sort of thinking that led to the problem in the first place.

Exactly what I was thinking.

By the way, I like your signature line.  Is that a quote, and of so.. of whom?  (if you happen to know)

TZ

On Mon, 16 May 2005 22:56:29 +0300, Walter <newshound@digitalmars.com> wrote:

>
> "Burton Radons" <burton-radons@smocky.com> wrote in message
> news:d679mt$2ofi$1@digitaldaemon.com..
>> Walter wrote:
>> > "Burton Radons" <burton-radons@smocky.com> wrote in message
>> > news:d65uvo$1sv1$1@digitaldaemon.com...
>> >
>> >>No, no, I mean that "static assert" was the wrong design because it
>> >>shows an inconsistency when extended to apply to more statements.  So  
>> it
>> >>should be "const assert" as well as "const if" instead, while "static
>> >>assert" should be an error.
>> >
>> >
>> > "static assert" comes from C++ terminology for the same thing.
>>
>> C++ sucks.
>>
>> What about if you decide to add an attribute to functions which declare
>> that they must be constant-folded if their parameters are constant,
>> which allows the standard to declare exactly how much constant-folding
>> is necessary for implementations.  What attribute do you use?  You can't
>> use static, because it's already used with an entirely different
>> meaning; however, static would be the consistent attribute.  This
>> inconsistency is just setting up a problem which will take decades to
>> sort out.
>
> That is a good idea, but there's another angle to it. There is a
> characteristic of functions which could be called "atomic" meaning it
> depends only on its parameters and not on any globals. Atomic would also
> mean that the function has no side effects beyond its return value. Hence,
> an optimizing compiler could take an atomic function, see that its arguments
> have known values, and so compute the functions return value at compile
> time. The const attribute for a function would be a subset of this behavior,
> and not necessary.
>
> (An example of an atomic function would be std.math.sin(x).)

I have one more related idea about this. I think it would be nice to have some
virtual methods that are not dependent on instance of object. For example:

: class A {
:   this() {
:     int v = getSomeValue(); // virtual method call
:     ...
:   }
:   // some kind of attrubute required here to tell compiler that
:   // overridables of this method can't use fields and/or other methods without
:   // thesame attribute
:   int getSomeValue() {
:     return 0;
:   }
: }
:
: class B : A {
:   this () { f_C = new C();}
:   int getSomeValue() {
:     return f_C.getValue(); // runtime access violation here
:   }
:   C f_C;
: }
: class C {
:   int getValue() {return f_Value;}
:   int f_Value = 5;
: }

I wrote simple test to verify virtual method call from c-tors and d-tors
and found that current behaviour is different from C++. Now D is allowing
this virtual call where as C++ calls not overriden version of method. For
me it's nice (personally i don't like this in C++), but i understand reason
why it's was done and example mentioned before is shows the case. I think
such cases can be detected at compile time. Moreover sometimes extension
to abstract methods is needed like to tell that some method is requred to
be overridden in final class.

>
> PS: The "static if" is not parsed as a static attribute followed by an if
> statement, it is parsed as the two keywords juxtaposed have a special
> meaning, like "static this" and "static assert". In other words, it's
> treated as if it were a keyword "staticif". The following would not work:
>     static
>     {
>         if (...) ...    // this is not a static if
>     }
>
>


-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/m2/

"Walter" <newshound@digitalmars.com> wrote in message news:d6aud5$2g96$1@digitaldaemon.com...
>
> "Burton Radons" <burton-radons@smocky.com> wrote in message news:d679mt$2ofi$1@digitaldaemon.com...
> > Walter wrote:
> > > "Burton Radons" <burton-radons@smocky.com> wrote in message news:d65uvo$1sv1$1@digitaldaemon.com...
> > >
> > >>No, no, I mean that "static assert" was the wrong design because it shows an inconsistency when extended to apply to more statements.  So it should be "const assert" as well as "const if" instead, while "static assert" should be an error.
> > >
> > >
> > > "static assert" comes from C++ terminology for the same thing.
> >
> > C++ sucks.
> >
> > What about if you decide to add an attribute to functions which declare that they must be constant-folded if their parameters are constant, which allows the standard to declare exactly how much constant-folding is necessary for implementations.  What attribute do you use?  You can't use static, because it's already used with an entirely different meaning; however, static would be the consistent attribute.  This inconsistency is just setting up a problem which will take decades to sort out.
>
> That is a good idea, but there's another angle to it. There is a characteristic of functions which could be called "atomic" meaning it depends only on its parameters and not on any globals. Atomic would also mean that the function has no side effects beyond its return value. Hence, an optimizing compiler could take an atomic function, see that its arguments have known values, and so compute the functions return value at compile time. The const attribute for a function would be a subset of this behavior, and not necessary.
>
> (An example of an atomic function would be std.math.sin(x).)
>
> PS: The "static if" is not parsed as a static attribute followed by an if
> statement, it is parsed as the two keywords juxtaposed have a special
> meaning, like "static this" and "static assert". In other words, it's
> treated as if it were a keyword "staticif". The following would not work:
>     static
>     {
>         if (...) ...    // this is not a static if
>     }
>
>

So here's a thought... why not make a way to specify that a particular function
(or for that matter anything else that could possibly be atomic) is "meant to be atomic" such as...

atomic int f( /*...*/ ) { /*...*/ }

...and as such, the compiler could know that it would be
alright to replace it with anything that would return the same results,
at any time... including at compile time.

If a function or expression labeled as atomic has side effects, those side effects should be supressed.
If any side effects of a function or expression can not be supressed
(or the compiler doesn't know how) the result would be a complie-time error.

What do you think, Walter?  Sound good to you?

TZ

"atomic" -- sounds like a transaction; "pure" is another way of describing it AFAIK.

Reminds me of a project were we used javadoc tags to document an API. Certain methods were marked up as @pure, others as @primitive -- meaning they didn't depend on methods of the same class that could be overridden. Such details can be very useful for clients, but a pain to maintain when its only in the docs.

Walter wrote:
> "Burton Radons" <burton-radons@smocky.com> wrote in message
> news:d679mt$2ofi$1@digitaldaemon.com...
> 
>>Walter wrote:
>>
>>>"Burton Radons" <burton-radons@smocky.com> wrote in message
>>>news:d65uvo$1sv1$1@digitaldaemon.com...
>>>
>>>
>>>>No, no, I mean that "static assert" was the wrong design because it
>>>>shows an inconsistency when extended to apply to more statements.  So it
>>>>should be "const assert" as well as "const if" instead, while "static
>>>>assert" should be an error.
>>>
>>>
>>>"static assert" comes from C++ terminology for the same thing.
>>
>>C++ sucks.
>>
>>What about if you decide to add an attribute to functions which declare
>>that they must be constant-folded if their parameters are constant,
>>which allows the standard to declare exactly how much constant-folding
>>is necessary for implementations.  What attribute do you use?  You can't
>>use static, because it's already used with an entirely different
>>meaning; however, static would be the consistent attribute.  This
>>inconsistency is just setting up a problem which will take decades to
>>sort out.
> 
> 
> That is a good idea, but there's another angle to it. There is a
> characteristic of functions which could be called "atomic" meaning it
> depends only on its parameters and not on any globals. Atomic would also
> mean that the function has no side effects beyond its return value. Hence,
> an optimizing compiler could take an atomic function, see that its arguments
> have known values, and so compute the functions return value at compile
> time. The const attribute for a function would be a subset of this behavior,
> and not necessary.
> 
> (An example of an atomic function would be std.math.sin(x).)
> 
> PS: The "static if" is not parsed as a static attribute followed by an if
> statement, it is parsed as the two keywords juxtaposed have a special
> meaning, like "static this" and "static assert". In other words, it's
> treated as if it were a keyword "staticif". The following would not work:
>     static
>     {
>         if (...) ...    // this is not a static if
>     }
> 
> 

"TechnoZeus" <TechnoZeus@PeoplePC.com> wrote in message news:d6iuba$2ik2$1@digitaldaemon.com...
> So here's a thought... why not make a way to specify that a particular
function
> (or for that matter anything else that could possibly be atomic) is "meant
to be atomic" such as...
>
> atomic int f( /*...*/ ) { /*...*/ }

As a possible future feature.

"Walter" <newshound@digitalmars.com> wrote in message news:d6rg0t$2vce$1@digitaldaemon.com...
>
> "TechnoZeus" <TechnoZeus@PeoplePC.com> wrote in message news:d6iuba$2ik2$1@digitaldaemon.com...
> > So here's a thought... why not make a way to specify that a particular
> function
> > (or for that matter anything else that could possibly be atomic) is "meant
> to be atomic" such as...
> >
> > atomic int f( /*...*/ ) { /*...*/ }
>
> As a possible future feature.
>
>

Cool.  I'll look forward to the possibility of seeing it some day. Thank you very much for that.  :)

TZ

Bill Baxter wrote:
> This comment is about template metaprogramming and metaprogramming in
> general. It's a little more pie-in-the-sky than my last comment.

I've just finished reading this entire thread.

Wow, I'm impressed at how many good points and examples came up! Seems the interest in D meta programming is much wider than I thought only this winter. We are in a good position to actually get somewhere with it! We have enough people wanting it, I see some convergence on how to do it, and folks have largely similar thoughts on it.

I bet this will become one of the hottest topics in this NG after the summer, when D1.0 has been out long enough for the immediate brouhaha to wane off, and everybody gets back to Important Long Term Issues.

And I'm now more convinced than ever that D meta programming will first of all become a reality, and secondly that it will _kick_ass_big_time_!

georg

PS, right now I don't even lurk regularly here, let alone do regular posts. But I ain't gone, take my word for it.