Digital Mars - digitalmars.D - #if, #else, #assert and #is

↑ ↓ ← → Derek Parnell <derek psych.ward> writes:

On Tue, 21 Jun 2005 12:56:01 +1000, James McComb wrote:

 What about this? Instead of:
 
 static if() {}
 else
 
 What about:
 
 #if() {} // static if
 #else () {} // static else
 
 If would be easy to write code mixing #if, if, #else and else without 
 confusing them.
 
 Other 'static functions' that evaluate compile-time expressions could 
 use this pragma-style syntax, e.g:
 
 #assert() {} // instead of static assert
 #is() {} // instead of iftype, or the 'static' is
           // (there would be both is and #is)
 
 It would be easy to extend this so that other functions have both 
 compile-time and run-time versions.
 
 What do you think?
 
 James McComb
 
 P.S. Maybe these should change (for consistency):
 
 #pragma() {} // instead of pragma
 #debug() {} // instead of debug
 #version() {} // instead of version


Yes, this is the sort of thing I was thinking of. It would enhance the
legibility of code immensely. It quickly signals a compile-time activity
and is hard to confuse with run-rime statements. It greps well too.

-- 
Derek
Melbourne, Australia
21/06/2005 1:07:45 PM

Jun 20 2005

↑ ↓ ← → "Lionello Lunesu" <lio lunesu.removethis.com> writes:

I have to agree..

It's a great a idea to put this functionality in the language, instead of a 
seperate preprocess step, but to make it look like normal code is merely 
confusing.

Furthermore, any fancy IDE will want to use a different color for the 
highlighting of these 'preprocessor' commands, which might be tricky in the 
case of "static if ... else".

L.

"James McComb" <ned jamesmccomb.id.au> wrote in message 
news:d97vjn$20lk$1 digitaldaemon.com...
| What about this? Instead of:
|
| static if() {}
| else
|
| What about:
|
| #if() {} // static if
| #else () {} // static else
|
| If would be easy to write code mixing #if, if, #else and else without
| confusing them.
|
| Other 'static functions' that evaluate compile-time expressions could
| use this pragma-style syntax, e.g:
|
| #assert() {} // instead of static assert
| #is() {} // instead of iftype, or the 'static' is
|          // (there would be both is and #is)
|
| It would be easy to extend this so that other functions have both
| compile-time and run-time versions.
|
| What do you think?
|
| James McComb
|
| P.S. Maybe these should change (for consistency):
|
| #pragma() {} // instead of pragma
| #debug() {} // instead of debug
| #version() {} // instead of version
|
|
|
|
|
|

Jun 21 2005

↑ ↓ ← → Nod <Nod_member pathlink.com> writes:

In article <d97vjn$20lk$1 digitaldaemon.com>, James McComb says...
What about this? Instead of:

static if() {}
else

What about:

#if() {} // static if
#else () {} // static else

If would be easy to write code mixing #if, if, #else and else without 
confusing them.

Other 'static functions' that evaluate compile-time expressions could 
use this pragma-style syntax, e.g:

#assert() {} // instead of static assert
#is() {} // instead of iftype, or the 'static' is
          // (there would be both is and #is)

It would be easy to extend this so that other functions have both 
compile-time and run-time versions.

What do you think?

James McComb

P.S. Maybe these should change (for consistency):

#pragma() {} // instead of pragma
#debug() {} // instead of debug
#version() {} // instead of version


Yes, I like this. Easier to both read and write imo. Very intuitive also, for
anyone coming from C/C++. Although I cringe a bit every time I see that syntax,
due to previous battles with the C preprocessor, I think D can change that
mental image.

-Nod-

Jun 21 2005

↑ ↓ ← → "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:

"James McComb" <ned jamesmccomb.id.au> wrote in message 
news:d97vjn$20lk$1 digitaldaemon.com...
 What about this? Instead of:

 static if() {}
 else

 What about:

 #if() {} // static if
 #else () {} // static else

 If would be easy to write code mixing #if, if, #else and else without 
 confusing them.

 Other 'static functions' that evaluate compile-time expressions could use 
 this pragma-style syntax, e.g:

 #assert() {} // instead of static assert
 #is() {} // instead of iftype, or the 'static' is
          // (there would be both is and #is)

 It would be easy to extend this so that other functions have both 
 compile-time and run-time versions.

 What do you think?

 James McComb

 P.S. Maybe these should change (for consistency):

 #pragma() {} // instead of pragma
 #debug() {} // instead of debug
 #version() {} // instead of version


As much as I hate the # symbol, it's a good idea.  It makes compile-time 
stuff stand out.

Jun 21 2005

↑ ↓ ← → clayasaurus <clayasaurus gmail.com> writes:

Jarrett Billingsley wrote:
 "James McComb" <ned jamesmccomb.id.au> wrote in message 
 news:d97vjn$20lk$1 digitaldaemon.com...
 
What about this? Instead of:

static if() {}
else

What about:

#if() {} // static if
#else () {} // static else

If would be easy to write code mixing #if, if, #else and else without 
confusing them.

Other 'static functions' that evaluate compile-time expressions could use 
this pragma-style syntax, e.g:

#assert() {} // instead of static assert
#is() {} // instead of iftype, or the 'static' is
         // (there would be both is and #is)

It would be easy to extend this so that other functions have both 
compile-time and run-time versions.

What do you think?

James McComb

P.S. Maybe these should change (for consistency):

#pragma() {} // instead of pragma
#debug() {} // instead of debug
#version() {} // instead of version


 
 As much as I hate the # symbol, it's a good idea.  It makes compile-time 
 stuff stand out. 
 
 


I agree.

Jun 21 2005

↑ ↓ ← → Eugene Pelekhay <pelekhay gmail.com> writes:

James McComb wrote:
 What about this? Instead of:
 
 static if() {}
 else
 
 What about:
 
 #if() {} // static if
 #else () {} // static else
 
 If would be easy to write code mixing #if, if, #else and else without 
 confusing them.
 
 Other 'static functions' that evaluate compile-time expressions could 
 use this pragma-style syntax, e.g:
 
 #assert() {} // instead of static assert
 #is() {} // instead of iftype, or the 'static' is
          // (there would be both is and #is)
 
 It would be easy to extend this so that other functions have both 
 compile-time and run-time versions.
 
 What do you think?
 
 James McComb
 
 P.S. Maybe these should change (for consistency):
 
 #pragma() {} // instead of pragma
 #debug() {} // instead of debug
 #version() {} // instead of version
 
 



Interesting how many positive posts must be in this thread to have this 
change implemented by Walter?

Jun 22 2005

↑ ↓ ← → "Unknown W. Brackets" <unknown simplemachines.org> writes:

Personally, I don't like this.  Specifically because the minute this 
changes, people will start:

   - complaining about #if enforcing scope.  C/C++ didn't require this, 
they'll say.
   - aligning things to the far left like with a preprocessor, which is 
ugily.  I thought that was part of why D had these things in the language.
   - asking for things like #ifdef instead of #version, and no 
parenthesis or curly braces.

Why?  Because you make it look like the preprocessor if you make this 
change.  You also make it such that, in some cases, (where things are 
aligned left already) you cannot use a preprocessor correctly - unless 
you change everything:

#version = test;
#version(test)
#{
#}

Which still leaves:

const int x = 5;
#if (x == 5)  // <-- error, preprocessor doesn't know about x!

Etcetera.  It just separates it from the language, doesn't it?  Even if 
it still is part of the compiler.

-[Unknown]


 What about this? Instead of:
 
 static if() {}
 else
 
 What about:
 
 #if() {} // static if
 #else () {} // static else
 
 If would be easy to write code mixing #if, if, #else and else without 
 confusing them.
 
 Other 'static functions' that evaluate compile-time expressions could 
 use this pragma-style syntax, e.g:
 
 #assert() {} // instead of static assert
 #is() {} // instead of iftype, or the 'static' is
          // (there would be both is and #is)
 
 It would be easy to extend this so that other functions have both 
 compile-time and run-time versions.
 
 What do you think?
 
 James McComb
 
 P.S. Maybe these should change (for consistency):
 
 #pragma() {} // instead of pragma
 #debug() {} // instead of debug
 #version() {} // instead of version

Jun 22 2005

↑ ↓ ← → Nod <Nod_member pathlink.com> writes:

In article <d9bstm$2as5$1 digitaldaemon.com>, Unknown W. Brackets says...
Personally, I don't like this.  Specifically because the minute this 
changes, people will start:

   - complaining about #if enforcing scope.  C/C++ didn't require this, 
they'll say.
   - aligning things to the far left like with a preprocessor, which is 
ugily.  I thought that was part of why D had these things in the language.
   - asking for things like #ifdef instead of #version, and no 
parenthesis or curly braces.

Why?  Because you make it look like the preprocessor if you make this 
change.  You also make it such that, in some cases, (where things are 
aligned left already) you cannot use a preprocessor correctly - unless 
you change everything:

#version = test;
#version(test)
#{
#}

Which still leaves:

const int x = 5;
#if (x == 5)  // <-- error, preprocessor doesn't know about x!

Etcetera.  It just separates it from the language, doesn't it?  Even if 
it still is part of the compiler.

-[Unknown]


 <snip>




I am not sure if you were merely making an example of how confusing it would be
for C/C++ people or not, but to clarify:

As I understand, the proposed change is meant to be purely syntactical, i.e. it
doesn't separate anything from the language, it just makes compile-time code
more eyecatching. 

This is prompted by the fact that the status quo is easily confusing when mixing
compile-time and run-time code. Also, it de-overloads the static keyword a bit,
which is also important.

Perhaps you are right that the # symbol is poised to create confusion for C/C++
users, but sometimes you have to bite the bullet and just re-learn. 

What I would consider ideal, would be to have no visible distinction between
compile- and run-time code, letting the compiler figure out which expressions
are compile-time and not. For one reason or another, Walter chose not to take
this route.

So for improving what we have, a syntax change would help. Personally, I think
the # symbol is as good as any for this purpose. It's readable, writeable,
available, and for better or for worse, C/C++ people already associates it with
compile-time executed stuff. 

-Nod-

Jun 22 2005

↑ ↓ ← → "Andrew Fedoniouk" <news terrainformatica.com> writes:

"Nod" <Nod_member pathlink.com> wrote in message 
news:d9c2po$2igp$1 digitaldaemon.com...
 In article <d9bstm$2as5$1 digitaldaemon.com>, Unknown W. Brackets says...
Personally, I don't like this.  Specifically because the minute this
changes, people will start:

   - complaining about #if enforcing scope.  C/C++ didn't require this,
they'll say.
   - aligning things to the far left like with a preprocessor, which is
ugily.  I thought that was part of why D had these things in the language.
   - asking for things like #ifdef instead of #version, and no
parenthesis or curly braces.

Why?  Because you make it look like the preprocessor if you make this
change.  You also make it such that, in some cases, (where things are
aligned left already) you cannot use a preprocessor correctly - unless
you change everything:

#version = test;
#version(test)
#{
#}

Which still leaves:

const int x = 5;
#if (x == 5)  // <-- error, preprocessor doesn't know about x!

Etcetera.  It just separates it from the language, doesn't it?  Even if
it still is part of the compiler.

-[Unknown]


 <snip>




 I am not sure if you were merely making an example of how confusing it 
 would be
 for C/C++ people or not, but to clarify:

 As I understand, the proposed change is meant to be purely syntactical, 
 i.e. it
 doesn't separate anything from the language, it just makes compile-time 
 code
 more eyecatching.

 This is prompted by the fact that the status quo is easily confusing when 
 mixing
 compile-time and run-time code. Also, it de-overloads the static keyword a 
 bit,
 which is also important.

 Perhaps you are right that the # symbol is poised to create confusion for 
 C/C++
 users, but sometimes you have to bite the bullet and just re-learn.

 What I would consider ideal, would be to have no visible distinction 
 between
 compile- and run-time code, letting the compiler figure out which 
 expressions
 are compile-time and not. For one reason or another, Walter chose not to 
 take
 this route.

 So for improving what we have, a syntax change would help. Personally, I 
 think
 the # symbol is as good as any for this purpose. It's readable, writeable,
 available, and for better or for worse, C/C++ people already associates it 
 with
 compile-time executed stuff.

 -Nod-


120% agree.

Andrew.

Jun 22 2005

↑ ↓ ← → "Unknown W. Brackets" <unknown simplemachines.org> writes:

IMHO, static if is more important not because it can't be determined, 
but because it proves it is determined.

It's just like type safety.  In scripting languages, one might say the 
compiler should be able to determine the type of the variable, for this 
example:

var x = 5;
x += 10;

Obviously it is an int.  Surely, we don't have to *TELL* the compiler 
that.  And, truth to tell, we don't - not in such simple cases.

But, sometimes it's good to be *sure*.  To know that this if is GOING TO 
BE STATIC.  And, if it's not - we'll get an error!  But, what about this:

var x = 5;
x += 10 ~ 1;

Oops.  Maybe in this imaginary (and dumb now) language, ~ might make 10 
and 1 strings, and concatenate them - resulting in 'x+= "101"', which 
would result in "5101".  A typo on our part, but it's why we have 
typesafety, isn't it?

The same goes for static if.  It's type safety, at least imho.

-[Unknown]


 | What I would consider ideal, would be to have no visible distinction 
 between
 | compile- and run-time code, letting the compiler figure out which 
 expressions
 | are compile-time and not. For one reason or another, Walter chose not to 
 take
 | this route.
 
 Indeed! This makes perfect sense. Why do we even need a "static if"? I use 
 "if(0)" a lot for skipping pieces of code during debugging, and I'll never 
 write "statif if(0)", and shouldn't have to.
 
 If the "is" (or other "operator") used inside the static if() has a 
 different meaning because it's inside a static if, then maybe its name 
 should be reconsidered instead. Or the "static" moved, ie if(static is....).
 
 L.

Jun 24 2005

↑ ↓ ← → "Walter" <newshound digitalmars.com> writes:

"Lionello Lunesu" <lio lunesu.removethis.com> wrote in message
news:d9h6oj$2q2b$1 digitaldaemon.com...
 Indeed! This makes perfect sense. Why do we even need a "static if"? I use
 "if(0)" a lot for skipping pieces of code during debugging, and I'll never
 write "statif if(0)", and shouldn't have to.


That indeed was my original thought with this. Unfortunately, some
limitations are:

1) if (0) introduces a new scope, static if(...) does not. Why does this
matter? It matters if one wants to conditionally declare a new variable:

    static if (...) int x; else long x;
    x = 3;

whereas:

    if (...) int x; else long x;
    x = 3;    // error, x is not defined

2) False static if conditionals don't have to semantically work. For
example, it may depend on a conditionally compiled declaration somewhere
else:

    static if (...) int x;
    int test()
    {
        static if (...) return x;
        else return 0;
    }

3) Static if's can appear where only declarations are allowed:

    class Foo
    {
            static if (...)
                int x;
    }

4) Static if's can declare new type aliases:

    static if (0 || is(int T)) T x;

Jun 25 2005

↑ ↓ ← → Stewart Gordon <smjg_1998 yahoo.com> writes:

Unknown W. Brackets wrote:
 Personally, I don't like this.  Specifically because the minute this 
 changes, people will start:
 
   - complaining about #if enforcing scope.  C/C++ didn't require this, 
 they'll say.
   - aligning things to the far left like with a preprocessor, which is 
 ugily.  I thought that was part of why D had these things in the language.
   - asking for things like #ifdef instead of #version, and no 
 parenthesis or curly braces.
 
 Why?  Because you make it look like the preprocessor if you make this 
 change.



Taken the words out of my mouth there.  Making it look as though D has a 
preprocessor'll go against what we're trying to throw at D programmers.

Stewart.

-- 
My e-mail is valid but not my primary mailbox.  Please keep replies on 
the 'group where everyone may benefit.

Jun 29 2005

↑ ↓ ← → pragma <pragma_member pathlink.com> writes:

In article <d97vjn$20lk$1 digitaldaemon.com>, James McComb says...
What about this? Instead of:

static if() {}
else

What about:

#if() {} // static if
#else () {} // static else

If would be easy to write code mixing #if, if, #else and else without 
confusing them.

Other 'static functions' that evaluate compile-time expressions could 
use this pragma-style syntax, e.g:

#assert() {} // instead of static assert
#is() {} // instead of iftype, or the 'static' is
          // (there would be both is and #is)

It would be easy to extend this so that other functions have both 
compile-time and run-time versions.

What do you think?

James McComb

P.S. Maybe these should change (for consistency):

#pragma() {} // instead of pragma
#debug() {} // instead of debug
#version() {} // instead of version


I've been quiet during this conversation, as I wanted to see what fell out of
the debate, if anything. 

To sum up: I don't think this is a good idea for D.

I honestly feel this would be a step backwards for D.  D's syntax is cleaner
than C's, and would certainly be harder to read with this use of the '#' symbol.
I for one find the run-time/compile-time schism between statements to be very
clear-cut and simply a part of the learning curve for the language.  

I'll add that its rare to see a language embrace different language *epochs with
the same syntax, inside the same context.  Its less syntactic baggage you have
to carry around with you as there are fewer rules to adhere to.

If consistency is what the community craves, then we should at least have #line
changed to a more d-like "pragma(line,123,`xyz`)".  This would be more
consistent with the rest of the langauge.  Its certainly a far cry from using
'#' everywhere else to match, which would only make implementation easier.

Also, a good syntax highlighter can easily fix the recognition issues between
which *epoch a statment evaluates/runs under.


(*) One can dissect any programming language into several distinct "epochs",
that span the software's life from compilation through run-time.  D's syntax
organizes pretty well across three epochs (D has no preprocessor):

- Compile Time: static if, static is, pragma, version, debug, template, mixin,
class, struct, delegate, function, typedef, alias, <constant expressions>
- Init Time: static this, <static data manipulations and init>
- Run Time: <operators and expressions>

Other epochs that D leaves out are the preprocessor, and runtime code-generation
which are supported in other langauges.

(I think '#line' is being handled by D's lexer, which technically makes it a
preprocessor token. I could be wrong about this.)

- EricAnderton at yahoo

Jun 23 2005

↑ ↓ ← → Derek Parnell <derek psych.ward> writes:

On Thu, 23 Jun 2005 18:29:56 +0000 (UTC), pragma wrote:

 In article <d97vjn$20lk$1 digitaldaemon.com>, James McComb says...
What about this? Instead of:

static if() {}
else

What about:

#if() {} // static if
#else () {} // static else

If would be easy to write code mixing #if, if, #else and else without 
confusing them.

Other 'static functions' that evaluate compile-time expressions could 
use this pragma-style syntax, e.g:

#assert() {} // instead of static assert
#is() {} // instead of iftype, or the 'static' is
          // (there would be both is and #is)

It would be easy to extend this so that other functions have both 
compile-time and run-time versions.

What do you think?

James McComb

P.S. Maybe these should change (for consistency):

#pragma() {} // instead of pragma
#debug() {} // instead of debug
#version() {} // instead of version


 I've been quiet during this conversation, as I wanted to see what fell out of
 the debate, if anything. 
 
 To sum up: I don't think this is a good idea for D.
 
 I honestly feel this would be a step backwards for D.  D's syntax is cleaner
 than C's, and would certainly be harder to read with this use of the '#'
symbol.


I think you might have missed the point. It is not about the '#' character
being used. I think that point is simply that the current syntax increases
the illegibility of D code and that an alternative would make reading and
writing code more efficient. The main problems are that using multi-word
tokens is confusing and that the compile-time nature of some aspects of the
language is not obvious from a casual reading.

 I for one find the run-time/compile-time schism between statements to be very
 clear-cut and simply a part of the learning curve for the language.  


That is to be highly commended. However, is there any reason while we
cannot make it even easier for people to adopt D?

 I'll add that its rare to see a language embrace different language *epochs
with
 the same syntax, inside the same context.  Its less syntactic baggage you have
 to carry around with you as there are fewer rules to adhere to.


Exactly! And thus multi-word tokens are excess baggage. The lack of visual
distinction between compile-time tokens and run-time tokens also increases
the number of mental rules one has to carry around.

 If consistency is what the community craves, then we should at least have #line
 changed to a more d-like "pragma(line,123,`xyz`)".  This would be more
 consistent with the rest of the langauge.  Its certainly a far cry from using
 '#' everywhere else to match, which would only make implementation easier.


That is also a reasonable suggestion. I don't think that the people
agreeing are adamant that the '#' character be used, but just that
something be done to help us read code more easily.

 Also, a good syntax highlighter can easily fix the recognition issues between
 which *epoch a statment evaluates/runs under.


It would have to be a good one to highlight "static if" and "if" correctly
in context.

 
 (*) One can dissect any programming language into several distinct "epochs",
 that span the software's life from compilation through run-time.  D's syntax
 organizes pretty well across three epochs (D has no preprocessor):
 
 - Compile Time: static if, static is, pragma, version, debug, template, mixin,
 class, struct, delegate, function, typedef, alias, <constant expressions>
 - Init Time: static this, <static data manipulations and init>
 - Run Time: <operators and expressions>


"Init Time"? Isn't this still work done by the compiler in order to
generate the intended object code?

 Other epochs that D leaves out are the preprocessor, and runtime
code-generation
 which are supported in other langauges.


Agreed. If they aren't in D then we don't have to worry about those.

 (I think '#line' is being handled by D's lexer, which technically makes it a
 preprocessor token. I could be wrong about this.)


Simple rule: If it is only used to generate output during
compilation/linking then it is a compile-time token otherwise it is a
run-time token.


-- 
Derek Parnell
Melbourne, Australia
24/06/2005 7:34:56 AM

Jun 23 2005

↑ ↓ ← → Derek Parnell <derek psych.ward> writes:

On Thu, 23 Jun 2005 15:03:40 -0700, Unknown W. Brackets wrote:

 Why?  So long as the highlighter supports tokens with spaces in them, no 
 context is needed whatsoever.
 
 Other languages, such as SQL, also have multiword tokens which 
 highlighters don't fall on the floor and spill blood over either.
 
 -[Unknown]
 
 
 It would have to be a good one to highlight "static if" and "if" correctly
 in context.




I must be using a poor highlighting editor then. It colors "static if" as
if it was "static" and "if" even though I have three tokens defined for it,
all for different colors - "if", "static" and "static if".

-- 
Derek Parnell
Melbourne, Australia
24/06/2005 8:08:18 AM

Jun 23 2005

↑ ↓ ← → "Regan Heath" <regan netwin.co.nz> writes:

On Fri, 24 Jun 2005 08:10:30 +1000, Derek Parnell <derek psych.ward> wrote:
 On Thu, 23 Jun 2005 15:03:40 -0700, Unknown W. Brackets wrote:

 Why?  So long as the highlighter supports tokens with spaces in them, no
 context is needed whatsoever.

 Other languages, such as SQL, also have multiword tokens which
 highlighters don't fall on the floor and spill blood over either.

 -[Unknown]


 It would have to be a good one to highlight "static if" and "if"  
 correctly
 in context.




 I must be using a poor highlighting editor then. It colors "static if" as
 if it was "static" and "if" even though I have three tokens defined for  
 it,
 all for different colors - "if", "static" and "static if".


What order have you defined them in? perhaps re-ordering will help it.

It seems it's not using any read-ahead, i.e. it sees "static" doesn't  
check if it's followed by an "if" colors static, then reads "if", colors  
that, etc.

Regan

Jun 23 2005

↑ ↓ ← → Derek Parnell <derek psych.ward> writes:

On Fri, 24 Jun 2005 08:10:30 +1000, Derek Parnell wrote:

 On Thu, 23 Jun 2005 15:03:40 -0700, Unknown W. Brackets wrote:
 
 Why?  So long as the highlighter supports tokens with spaces in them, no 
 context is needed whatsoever.
 
 Other languages, such as SQL, also have multiword tokens which 
 highlighters don't fall on the floor and spill blood over either.
 
 -[Unknown]
 
 It would have to be a good one to highlight "static if" and "if" correctly
 in context.




 I must be using a poor highlighting editor then. It colors "static if" as
 if it was "static" and "if" even though I have three tokens defined for it,
 all for different colors - "if", "static" and "static if".


I just tried a different editor that allows better highlighting rules and I
can now differentiate between "static", "if" and "static if" ;-)

-- 
Derek
Melbourne, Australia
24/06/2005 11:43:59 AM

Jun 23 2005

↑ ↓ ← → "Regan Heath" <regan netwin.co.nz> writes:

My first thought was that # was a bad character to use (mental association  
with C/C++ pre-processor). That doesn't mean we can't use another  
character, or change the keywords themselves.

I haven't tried to use static if at all really, but I agree a good IDE  
will be able to color it and make it stand out. D is designed to be easily  
parsable, for this exact reason.


The epoch concept is interesting, I note 'static' currently appears in 2  
epochs, compile and init. If we decide the epoch idea has merit then we  
need to fix that I reckon.

Regan

On Thu, 23 Jun 2005 18:29:56 +0000 (UTC), pragma  
<pragma_member pathlink.com> wrote:
 In article <d97vjn$20lk$1 digitaldaemon.com>, James McComb says...
 What about this? Instead of:

 static if() {}
 else

 What about:

 #if() {} // static if
 #else () {} // static else

 If would be easy to write code mixing #if, if, #else and else without
 confusing them.

 Other 'static functions' that evaluate compile-time expressions could
 use this pragma-style syntax, e.g:

 #assert() {} // instead of static assert
 #is() {} // instead of iftype, or the 'static' is
          // (there would be both is and #is)

 It would be easy to extend this so that other functions have both
 compile-time and run-time versions.

 What do you think?

 James McComb

 P.S. Maybe these should change (for consistency):

 #pragma() {} // instead of pragma
 #debug() {} // instead of debug
 #version() {} // instead of version


 I've been quiet during this conversation, as I wanted to see what fell  
 out of
 the debate, if anything.

 To sum up: I don't think this is a good idea for D.

 I honestly feel this would be a step backwards for D.  D's syntax is  
 cleaner
 than C's, and would certainly be harder to read with this use of the '#'  
 symbol.
 I for one find the run-time/compile-time schism between statements to be  
 very
 clear-cut and simply a part of the learning curve for the language.

 I'll add that its rare to see a language embrace different language  
 *epochs with
 the same syntax, inside the same context.  Its less syntactic baggage  
 you have
 to carry around with you as there are fewer rules to adhere to.

 If consistency is what the community craves, then we should at least  
 have #line
 changed to a more d-like "pragma(line,123,`xyz`)".  This would be more
 consistent with the rest of the langauge.  Its certainly a far cry from  
 using
 '#' everywhere else to match, which would only make implementation  
 easier.

 Also, a good syntax highlighter can easily fix the recognition issues  
 between
 which *epoch a statment evaluates/runs under.


 (*) One can dissect any programming language into several distinct  
 "epochs",
 that span the software's life from compilation through run-time.  D's  
 syntax
 organizes pretty well across three epochs (D has no preprocessor):

 - Compile Time: static if, static is, pragma, version, debug, template,  
 mixin,
 class, struct, delegate, function, typedef, alias, <constant expressions>
 - Init Time: static this, <static data manipulations and init>
 - Run Time: <operators and expressions>

 Other epochs that D leaves out are the preprocessor, and runtime  
 code-generation
 which are supported in other langauges.

 (I think '#line' is being handled by D's lexer, which technically makes  
 it a
 preprocessor token. I could be wrong about this.)

 - EricAnderton at yahoo

Jun 23 2005

↑ ↓ ← → pragma <pragma_member pathlink.com> writes:

In article <opssujo0zy23k2f5 nrage.netwin.co.nz>, Regan Heath says...
My first thought was that # was a bad character to use (mental association  
with C/C++ pre-processor). That doesn't mean we can't use another  
character, or change the keywords themselves.

I haven't tried to use static if at all really, but I agree a good IDE  
will be able to color it and make it stand out. D is designed to be easily  
parsable, for this exact reason.


The epoch concept is interesting, I note 'static' currently appears in 2  
epochs, compile and init. If we decide the epoch idea has merit then we  
need to fix that I reckon.


I think Derek cleaned this up neatly for both of us: things are either run-time
or compile-time.  My use of "init time" was merely to draw distinction to the
fact that 'static this' is technically a part of the runtime (code), but has a
special place during the bootstrap of a program; hence that particular use of
static has a special meaning.

- EricAnderton at yahoo

Jun 24 2005

↑ ↓ ← → Derek Parnell <derek psych.ward> writes:

On Fri, 24 Jun 2005 00:55:06 +0200, Dawid Ci�arkiewicz wrote:

 James McComb wrote:
 What do you think?


 _Personaly_ I find 'static' combinations incedibly intuitive. Each time I
 see "static assert", "static class" or "static if" I fell comfortable with
 them (I just know what they are suppose to mean without thinking). And IMHO
 '#' sign looks bad.


And to me, I see "static" and think "fixed in place, stationary" because
that is the English meaning of it - opposite to "dynamic". To me it is a
stretch to think of "static" as meaning activity done at compile-time only.
However, its the two-word token aspect that is the most disturbing.
"static_if" would be better than "static if", IMHO.

I do not care if the token is "static_if", "#if", " if", "compiler_if" or
whatever, so long as it improves comprehension when people are reading
source code.

 There are things more important than "look" but if this change would be
 because of cosmetic reasons than I would be voiting 'no'.


If by "cosmetic" you mean that we get no real benefit from changing
something then I'd agree, but this change is not cosmetic. We will all get
a real benefit from it, even the compiler writer.

-- 
Derek
Melbourne, Australia
24/06/2005 9:52:30 AM

Jun 23 2005

↑ ↓ ← → "Walter" <newshound digitalmars.com> writes:

"James McComb" <ned jamesmccomb.id.au> wrote in message
news:d97vjn$20lk$1 digitaldaemon.com...
 What about this? Instead of:

 static if() {}
 else

 What about:

 #if() {} // static if
 #else () {} // static else


While they are visually distinct, and that's a worthy goal, there are some
significant problems with it:

1) It looks too much like the C/C++ macro preprocessor. If it looks like a
macro preprocessor, people will expect it to behave like a macro
preprocessor. If the C/C++ preprocessor wasn't so deeply embedded into our
psyche, this wouldn't be an issue, but I think it would be one.

2) Currently, one can use the C/C++ standalone preprocessor to preprocess D.
(That's why there's the #line in existence, as #line is emitted by the
preprocessor.) Using #if, etc., for other things will make this impossible.

Jun 23 2005

↑ ↓ ← → "Walter" <newshound digitalmars.com> writes:

"Derek Parnell" <derek psych.ward> wrote in message
news:1qe0lfjugx0a$.1rkfw7uwcfspt.dlg 40tude.net...
 On Thu, 23 Jun 2005 22:16:53 -0700, Walter wrote:

 "James McComb" <ned jamesmccomb.id.au> wrote in message
 news:d97vjn$20lk$1 digitaldaemon.com...
 What about this? Instead of:

 static if() {}
 else

 What about:

 #if() {} // static if
 #else () {} // static else


 While they are visually distinct, and that's a worthy goal ...


 Given that it is a worthy goal, will you be doing something about


 that goal? And if so, will that be before or after v1.0?


It's a worthy goal, but there are other, competing goals. It's also a worthy
goal for all the features of D. But which one do we pick to stand out more?
I think this is the kind of thing that a good syntax highlighting editor
excells at, because it can use different colors, fonts, boldface, underline,
etc., and is all under user control.

Jun 24 2005

↑ ↓ ← → Derek Parnell <derek psych.ward> writes:

On Fri, 24 Jun 2005 00:13:27 -0700, Walter wrote:

 "Derek Parnell" <derek psych.ward> wrote in message
 news:1qe0lfjugx0a$.1rkfw7uwcfspt.dlg 40tude.net...
 On Thu, 23 Jun 2005 22:16:53 -0700, Walter wrote:

 "James McComb" <ned jamesmccomb.id.au> wrote in message
 news:d97vjn$20lk$1 digitaldaemon.com...
 What about this? Instead of:

 static if() {}
 else

 What about:

 #if() {} // static if
 #else () {} // static else


 While they are visually distinct, and that's a worthy goal ...


 Given that it is a worthy goal, will you be doing something about


 that goal? And if so, will that be before or after v1.0?


 It's a worthy goal, but there are other, competing goals. It's also a worthy
 goal for all the features of D. But which one do we pick to stand out more?
 I think this is the kind of thing that a good syntax highlighting editor
 excells at, because it can use different colors, fonts, boldface, underline,
 etc., and is all under user control.


So ... reading between the lines (as the actual question was not directly
answered - (ever think of going in to politics?) ) it seems that you are
saying ...

(A) There are many worth, competing goals for D and you have prioritized
them.
(B) You will not be doing anything to achieve this particular goal in the D
language.
(C) You recommend using another tool to achieve it instead.

I would like to point out that syntax highlighting does not work so well
with commonly printed forms of source code. Color printing of source code
is not yet economical enough for common use either in the work place or in
published hard-copy works. Most code reviewing is done using printed
(hard-copy) source code listings.

-- 
Derek
Melbourne, Australia
24/06/2005 5:23:45 PM

Jun 24 2005

↑ ↓ ← → "Walter" <newshound digitalmars.com> writes:

"Derek Parnell" <derek psych.ward> wrote in message
news:199skhy1f5i6n$.tcqfukcs4a0a.dlg 40tude.net...
 So ... reading between the lines (as the actual question was not directly
 answered - (ever think of going in to politics?) ) it seems that you are
 saying ...

 (A) There are many worth, competing goals for D and you have prioritized
 them.
 (B) You will not be doing anything to achieve this particular goal in the


 language.
 (C) You recommend using another tool to achieve it instead.


I would add to that that 'static if' is not that bad.

 I would like to point out that syntax highlighting does not work so well
 with commonly printed forms of source code. Color printing of source code
 is not yet economical enough for common use either in the work place or in
 published hard-copy works. Most code reviewing is done using printed
 (hard-copy) source code listings.


I know. One can still use boldface, fonts, etc., even with b/w hardcopy.

But I also suggest that one can use whitespace formatting and layout to
emphasize or de-emphasize various aspects of the source code.

Jun 24 2005

↑ ↓ ← → James McComb <ned jamesmccomb.id.au> writes:

Walter wrote:

What about:

#if() {} // static if
#else () {} // static else


 While they are visually distinct, and that's a worthy goal, there are some
 significant problems with it:
 
 1) It looks too much like the C/C++ macro preprocessor. If it looks like a
 macro preprocessor, people will expect it to behave like a macro
 preprocessor. If the C/C++ preprocessor wasn't so deeply embedded into our
 psyche, this wouldn't be an issue, but I think it would be one.
 
 2) Currently, one can use the C/C++ standalone preprocessor to preprocess D.
 (That's why there's the #line in existence, as #line is emitted by the
 preprocessor.) Using #if, etc., for other things will make this impossible.


I accept both of these points, and they are probably enough to kill off 
the idea of using #. But are you averse to using other characters?

For example, $:

// S stands for static... $ kind of looks like S
$if() {}   // pronounced static if
$else() {} // pronounced static else

(This might remind you of Perl, but I'm using $ on keywords, not 
variables. Other characters might be worth a look as well.)

Jun 24 2005

↑ ↓ ← → "Walter" <newshound digitalmars.com> writes:

"James McComb" <ned jamesmccomb.id.au> wrote in message
news:d9gc2f$1ica$1 digitaldaemon.com...
 I accept both of these points, and they are probably enough to kill off
 the idea of using #. But are you averse to using other characters?

 For example, $:

 // S stands for static... $ kind of looks like S
 $if() {}   // pronounced static if
 $else() {} // pronounced static else

 (This might remind you of Perl, but I'm using $ on keywords, not
 variables. Other characters might be worth a look as well.)


Using $ for various purposes has come up many times. (Currently it is an
alternative to 'length' inside array indices.) Sometimes,   gets proposed,
but it looks too awful.

Is static if that bad? Wouldn't using a syntax highlighting editor be a
better solution?

Jun 24 2005

↑ ↓ ← → Dave <Dave_member pathlink.com> writes:

In article <d9gde9$1lls$1 digitaldaemon.com>, Walter says...
"James McComb" <ned jamesmccomb.id.au> wrote in message
news:d9gc2f$1ica$1 digitaldaemon.com...
 I accept both of these points, and they are probably enough to kill off
 the idea of using #. But are you averse to using other characters?

 For example, $:

 // S stands for static... $ kind of looks like S
 $if() {}   // pronounced static if
 $else() {} // pronounced static else

 (This might remind you of Perl, but I'm using $ on keywords, not
 variables. Other characters might be worth a look as well.)


Using $ for various purposes has come up many times. (Currently it is an
alternative to 'length' inside array indices.) Sometimes,   gets proposed,
but it looks too awful.

Is static if that bad? Wouldn't using a syntax highlighting editor be a
better solution?


I feel like a fish out of water trying to edit C# and such without a nice code
editor. D changed that - Notepad works just fine for D. That's one of the things
that makes D so comfortable.. IMHO, something along the lines of the idea above
would be a worthy goal if it can be as quickly and simply implemented as the
length symbol. It just makes for easier to read code IMO, because it is easier
to distinguish than 'static' in plain old black and white.

- Dave

Jun 24 2005

↑ ↓ ← → "Regan Heath" <regan netwin.co.nz> writes:

On Fri, 24 Jun 2005 17:48:38 +0300, Lionello Lunesu  
<lio lunesu.removethis.com> wrote:
 | Is static if that bad? Wouldn't using a syntax highlighting editor be a
 | better solution?

 I have yet to encounter a IDE that can highlight "static if" differently
 from <static> <space> <if>.

 Granted, I don't use many different IDEs, so there probably is one out  
 there that can do it.


Derek found one:
digitalmars.D/25749

 But what about the "else" appearing after the "static if { ...}"?  Must  
 be some fancy highlighter to know it should be coloured 'statically'..


That's a good point.

 I guess
 this means that if "static" is changed into some prefix, it should also  
 be applied to "else":

 $version(x) {...} $else { ...}
 #version(x) {...} #else { ...}

 Or whatever. I truly hope we don't get another "what symbol is better"
 discussion. : S


Those are never productive.

Regan

Jun 26 2005