"Dave" <Dave_member@pathlink.com> wrote in message news:d683ti$8ee$1@digitaldaemon.com...
> In article <d679mt$2ofi$1@digitaldaemon.com>, Burton Radons says...
> >
> >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.
>
> I agree and very good point.
>
> 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.
>
> - Dave
>
> >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.
>
>

When you extend the idea to more complex compile-time structures, const runs into a similar problem.
Consider, for example, the case of a compile-time recursive loop.
It may evaluate to structure that is constant, but what it "does" is a different story.
I think it's mainly a matter of perspective, and in which directions it may go from here.
Since Walter controls that aspect of the D language's forseeable future,
I would think his vision of it is what matters most...
although it's fair for us to share our vision with him, which may in the long run alter his...
as Bill Baxter has obviously done in this case.  (Nice work Bill.)

Hopefully Walter will give (or has given) your comments about when "const" would be better than "static" careful consideration,
and as such, think ahead to avoid the potential porblems... but I also hope he will consider (or has considered) the other side of that coin.
Personally, I think "static" was a good choice, for the implementations being discussed in the present context,
and that future extensions of that concept should prove to be quite useful.
Nothing ruling out the possibility of implementing both ideas though in the long run, I would think... as they have divergent potentials, conceptually.

TZ

"Vladimir" <kv11111@mail.ru> wrote in message news:d64map$11r0$1@digitaldaemon.com...
> Walter wrote:
> >
> > "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;
> > }
>
> It looks really good. In C++ there is two *differect* styles for normal
> programing (imperative style) and metaprograming (functional style by means
> of haskell). Just compare function that evaluates factorial and template
> template that evaluates factorial. It's cool to have ONE approach for
> programing and metaprograming in D.
> The only thing is that 'static' keyword seems to be overused. It has at
> least three different meanings in D, and even more in other languages. What
> about using something like 'meta' or 'compile_time', or UPPERCASE letters ?
>
> -- 
>           Vladimir

I agree that it would be nice to have some clear way of distinguishing this functionality from other functionality,
such as to have a "compiletime" keyword, but then there are limitations to that also.
For example, if anyone ever wants to make a D interpreter for testing programs as you write them,
the concept of compile time wouldn't apply to the interpreter but would still have to be dealt with to properly emulate running compiled code.

The "static" concept in D does in fact encompass the concept of resolving something once at compile-time and having it be constant at run-time.  While this concept is also used in the formation of constants, it is what is passed to the constant that supports the concept of resolving at compile-time,
rather than the constant declaration itself.

The concept being applied is roughly equal to the pseudocode concept of "evaluate once"
except that it is allowed access only to information that is available before the point in program actuation
where the system sets the processor to jump to the entry point of the program as designated in the source code.
This could be done at compile time, or in run-time code at the actual entry point that runs once and then passes control to the virtual entry point.
This versatility of implementation is actually quite consistant with the overall concept of "static" implemented in D so far, as I understand it...
so as such, I would think it should make sense to stick with the "static" keyword which covers the concept well,
rather than arbitrarily adding yet another keyword with no benefits to it's existance other than this minor distinction. (my opinion)

TZ

In article <d62m56$2h67$1@digitaldaemon.com>, Walter says...
>
>
>"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);
>}

Given the potential ambiguity of the meaning of the word 'static' in this context, and the rather inelegant need for it's repetition, how about extending what I think is one of D'd most powerful new features; attributes:

template Integer(int nbits){
compile_time {
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);
}
}

That seems cleaner, simpler and more intuative to me?

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

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

"Bill Baxter" <Bill_member@pathlink.com> wrote in message news:d697ih$11i9$1@digitaldaemon.com...
> I see some folks are unhappy with the use of 'static'.  Is it too hard for
the
> compiler to just figure out what is statically executable and avoid the
use of
> the extra keyword altogether?

It won't work, as the static if is fundamentally different from an if.

> Or is the thought that it's better for the
> programmer to have to declare their intent, so that e.g. the compiler can
tell
> them it's impossible to do what they want at compile time.  At least it
would be
> nice to be able to put it all in a block so you only have to type 'static'
once.
>
> >    static {
> >      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
> >       assert(0);
> >     }
>
> Hmm and why isn't it 'static else'?

Typo. It should be 'else static if'.

> Also, speaking of keywords sounding strange, it also seems kind of strange
to
> call something like that a 'template', since it has little to do with the original meaning of the word.  Not that I really care, but it's sort of reminiscent of how C++ started off using the 'class' keyword for template
type
> arguments, and eventually came around to using 'typename' instead.  I
presume
> that was because it sounds nonsensical to pass in an 'int' as the 'class' parameter.

<p9e883002@sneakemail.com> wrote in message news:d69h2h$184e$1@digitaldaemon.com...
> In article <d62m56$2h67$1@digitaldaemon.com>, Walter says...
> >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);
> >}
>
> Given the potential ambiguity of the meaning of the word 'static' in this context, and the rather inelegant need for it's repetition, how about
extending
> what I think is one of D'd most powerful new features; attributes:
>
> template Integer(int nbits){
> compile_time {
> 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);
> }
> }
>
> That seems cleaner, simpler and more intuative to me?

It does, but there's a problem: you'll get an error "Integer is undefined" because Integer will be local to the if block. Fundamentally, static if has to parse like debug and version declarations, which do not introduce a new scope with the dependent declarations.

"Sean Kelly" <sean@f4.ca> wrote in message news:d682f2$794$1@digitaldaemon.com...
> In article <d66uaa$2i1c$1@digitaldaemon.com>, Kevin Bealer says...
> >>
> >>Does this paragraph mean you can do metaprogamming with static if, or am
I
> >>reading too much into this?
> >
> >Sorry - I was vague; I meant can looping like the "factorial" case be
done; but
> >I think this was asked and answered in another post.
>
> No, it just replaces the standard method for "if" logic:
>
> template If( bit eval, Then, Else ) {
> alias Then If;
> }
>
> template If( bit eval : false, Then, Else ) {
> aliass Else If;
> }
>
> If!( a < b, int, float ) x;

True enough, and as is common with such template solutions, it works on the easy cases but gets pretty unwieldy on more complex ones, like needing to do more than just a simple typedef for the Then or Else.

"TechnoZeus" <TechnoZeus@PeoplePC.com> wrote in message news:d69b6o$13s1$1@digitaldaemon.com...
> Would static if support blocks such as...
> static if (condition){...}
> and if so, will everything in that block be considered static as well?

No. Static if is not an attribute. Consider:

    static if (condition)
    {
        ...
    }

as equivalent to the C++:

    #if (condition)
        ...
    #endif


> Also, are you considering a static switch?

Not at this time. Let's accumulate some experience with static if first, and see where that leads us.

> I would think that should be almost as straight forward to implement as
static if.
>
> Any other static logic support planned, or contemplated?

Something analogous for type querying.

"Walter" <newshound@digitalmars.com> wrote in message news:d6bqo2$g0m$2@digitaldaemon.com...
>
> "TechnoZeus" <TechnoZeus@PeoplePC.com> wrote in message news:d69b6o$13s1$1@digitaldaemon.com...
> > Would static if support blocks such as...
> > static if (condition){...}
> > and if so, will everything in that block be considered static as well?
>
> No. Static if is not an attribute. Consider:
>
>     static if (condition)
>     {
>         ...
>     }
>
> as equivalent to the C++:
>
>     #if (condition)
>         ...
>     #endif
>
>
> > Also, are you considering a static switch?
>
> Not at this time. Let's accumulate some experience with static if first, and see where that leads us.
>
> > I would think that should be almost as straight forward to implement as
> static if.
> >
> > Any other static logic support planned, or contemplated?
>
> Something analogous for type querying.
>
>

Ok.  Thanks.

TZ

In article <d6aud6$2g96$3@digitaldaemon.com>, Walter says...
>
>
><p9e883002@sneakemail.com> wrote in message news:d69h2h$184e$1@digitaldaemon.com...
>> In article <d62m56$2h67$1@digitaldaemon.com>, Walter says...
>> >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);
>> >}
>>
>> Given the potential ambiguity of the meaning of the word 'static' in this context, and the rather inelegant need for it's repetition, how about
>extending
>> what I think is one of D'd most powerful new features; attributes:
>>
>> template Integer(int nbits){
>> compile_time {
>> 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);
>> }
>> }
>>
>> That seems cleaner, simpler and more intuative to me?
>
>It does, but there's a problem: you'll get an error "Integer is undefined" because Integer will be local to the if block. Fundamentally, static if has to parse like debug and version declarations, which do not introduce a new scope with the dependent declarations.
>
>

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?

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

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